Web Components about ama HOT 8 CLOSED

Web components are interesting. But I'm a much bigger fan of the composability model than the inheritance model. I've never built anything with them, but from what I know I think I'm going to likely stay away from them and stick with existing solutions.

That said, I'm totally open to trying new things and seeing how they can make me more productive, so I'm keeping my eye on them.

from ama.

Oh, and as far as web components being the future... I'm on the fence on that one... But I'd say it's probable.

from ama.

I don't think Web Components are the way to go. Wilson Page wrote a good summary in The state of Web Components.

Web Components are a good play for Google to make it easier for web developers to add more complex functionality (and hook into Google services) to web sites. Polymer moved very quickly from 0.5 to 1.0 release (with breaking changes) and added shady DOM (shadow DOM to complex/hard to implement?).

I don't think declarative markup is the way to build applications. Agree composability over inheritance (remember controller hierarchy and $scope in Angular 1).

Why 3 languages - HTML, CSS and JavaScript? Just use JavaScript. Yes you still have to generate HTML and CSS for the browser but you can work in a more powerful programming language that you know already. Things like HTML imports are not necessary with ES6. For example you can already import HTML and CSS with jspm using ES6 module syntax.

from ama.

Yeah, and for me, I use webpack so I don't need to worry about "imports". I simply import './the.css' and just use the css-loader with the style-loader and it works (pre-processors are easy too). If I were doing React I wouldn't use css at all, but inline styles instead. Still haven't gotten around to doing this in my project at work.

As for the HTML, I'm in huge agreement with @gdi2290 on this. Inline your templates, makes template code smells easier to spot, also gives you a lot more power because you're in JavaScript land. Though I'm still not a huge fan of the fact that it's a string that's parsed. Love that React's components are just functions. Mind-blowingly simple imo...

from ama.

jspm css is similar to webpack import './the.css!' where '!' tells jspm to use the systemjs css plugin.

I'm also inlining templates as per @gdi2290 - there are some gnarly ones that are best kept separate but really points to fact that more abstraction to components (directives) is required. This looks like a way forward

https://github.com/andreypopp/es6-template-strings-jsx/

from ama.

That's interesting... Is the css thing part of the spec? It was my impression that System.js was trying to follow standards.

there are some gnarly ones that are best kept separate

That's the reason that you inline your templates (as you stated). It makes you feel the pain of these gnarly ones so you create a directive for sections of it. So I'd recommend still inlining those. I'm slowly removing all .html files from my project.

from ama.

it's hard to switch from templateUrl mindset. The best way to describe it is in another perspective. Think of Components as Services, now with Services we know that if there are way too many methods going on we probably should refactor into many different Services. Doing so allows us to keep each Service small with it's use domain specific concern. Now what about directives? Well think of them as helper functions that help you create a certain behavior. Now there are still reasons why you would use templateUrl but it's better people to run into the problem and realize they need to refactor into templateUrl rather than the other way around. One example of this type of suggestion is always using $apply you would always use it when you change your model. Until you understand exactly what's going on with the digest cycle you can start optimising your state management to isolate the trigger of the digest cycle (this step is never practiced in Angular apps today)

from ama.

I have never needed to use templateUrl ever since I started using webpack. The only use case I can think of is to allow people to override templates via the $templateCache. But in my apps, I have no need of that.

from ama.