3 ms·

We are using it for implementing a rather large project. I plan on writing a few articles on our experiences with it in the next couple of months. What you nee

by tinco 12y ago

We are using it for implementing a rather large project. I plan on writing a few articles on our experiences with it in the next couple of months. What you need to keep in mind that Polymer is largely experimental software, I would not recommend it yet for generic audience websites. The polyfills are nice, but you have to keep a tight eye on performance, and a new browser release could very easily pull out the rug from under you, as the Chrome release last month did, and make your site not work for a large chunk of users. I personally would not do it if I had a whole bunch of browsers I had to test every single thing in. It also takes a little while to get accustomed to the Polymer way of doing things. Our app is a single page webapp and there's many things we had to find out for ourselves. Most Polymer documentation is about rendering views, not writing controllers or models that suit web applications. From what I heard, they are working on a tighter integration with Angular. If that would become an official thing it would probably improve their opinionatedness on controllers/models. I personally am not a fan of Angular, so perhaps I would not follow that anyway ;)

hhsnopek 12y ago
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.

by tinco 12y ago

hhsnopek 12y ago

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.