2 ms·

I agree with this - to add on though: Polymer DOES NOT replace models and controllers, use this to render, and continue to use a MV* or MVC. Polymer gives you

I agree with this - to add on though: Polymer DOES NOT replace models and controllers, use this to render, and continue to use a MV* or MVC. Polymer gives you access to web components now providing a polyfill. I love web components, but there when we have logic inside a html is were I start to regret using it. example is [core-ajax](https://github.com/Polymer/core-ajax https://github.com/Polymer/core-ajax) There is literally no reason to have this, this should be apart of your javascript. On that note you should use polymer, but don't combine your logic and structure. I think of web components as advance templates that can be used. If you implement your own web components keep your logic separate!

tinco 12y ago
Yes exactly, this is one of the lessons we learned early on. The polymer team have build a bunch of elements that actually represent services or models. Their philosophy is that everything can be a web component. We experimented with this a bit, but quickly found this to be rather worthless, it effectively means you have changed the location of your services from the Javascript namespace to the DOM. I'm not saying that's terrible, just that it does not have any clear advantage to me, and a clear disadvantage would be that your services have to be accessed through the dom using for example element.getElementById() instead of just accessing them as they are defined on window or however the angular people do it with their fancy dependency injections. That said, we do pull of some nice tricks that involve a bit of logic through combining components, and we do use web components as controllers. It is a bit like old school ASP.net code behind, but I like it. edit: I have to be fair, I just remembered the advantage they aim for. When your services and models are also webcomponents, then you can make your dependency on them explicit using html imports, which would be the HTML5 solution for the problem RequireJS solves.

tinco 12y ago

Yes exactly, this is one of the lessons we learned early on. The polymer team have build a bunch of elements that actually represent services or models. Their philosophy is that everything can be a web component. We experimented with this a bit, but quickly found this to be rather worthless, it effectively means you have changed the location of your services from the Javascript namespace to the DOM. I'm not saying that's terrible, just that it does not have any clear advantage to me, and a clear disadvantage would be that your services have to be accessed through the dom using for example element.getElementById() instead of just accessing them as they are defined on window or however the angular people do it with their fancy dependency injections. That said, we do pull of some nice tricks that involve a bit of logic through combining components, and we do use web components as controllers. It is a bit like old school ASP.net code behind, but I like it. edit: I have to be fair, I just remembered the advantage they aim for. When your services and models are also webcomponents, then you can make your dependency on them explicit using html imports, which would be the HTML5 solution for the problem RequireJS solves.