18 ms·

Ask HN: Should I use Polymer for my next project?

74 points by HeinZawHtet 12y ago

Should I Use Polymer from Google for next project? What are advantages and disadvantages for using Polymer?(www.polymer-project.org)

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.
joemaller1 12y ago
I really liked the Polymer demos from I/O, but stepping back, it seems an awful lot like React without the compatibility. Polymer does appear to be more than just another Google flash-in-the-pan. They've got a good team, which is working closely with the Chrome team and Google's investment at I/O was significant. I wonder how the Angular folks are feeling. Facebook is using React right now, when will Google put Polymer into production? Hopefully Polymer will get around to some practical compatibility. Otherwise I'll make a note in my calendar for 2016.
- ffreire 12y ago
  Perhaps the biggest concern right now is vendor buy-in from other browser vendors such as Microsoft and Apple. It appears that React, at least for the time being, is a more immediate and practical approach to composing UIs. I'll still be mixing Polymer into internal/side projects to keep up to date on its status, but I don't think I'll be pushing anything public facing for the foreseeable future.
- deleted 12y ago
  [deleted]
robin_reala 12y ago
Why would you? I’ve never been a fan of adopting technology for technology’s sake without a problem that you’re trying to solve with it. (n.b. that problem could acceptably be ‘I want to learn more about this technology’)
- bsimpson 12y ago
  1) If Web Components work as-advertised, we'll be able to build our own primitives for the first time in the history of the web stack; no more shoehorning rich Internet apps into a framework that was designed for academics to share term papers. This is both fantastic and a fundamental shift in the way apps are written. 2) You can make web apps that look and feel native (on Android) for free.
  - robin_reala 12y ago
    Sorry, I phrased my original post badly. That wasn’t a rhetorical question, it was posed to the OP. They didn’t give any reasoning as to why they wanted to adopt Polymer, just a blanket ‘should I?’. Your reasons are both valid though.
wnevets 12y ago
do you care about < IE10?
- taf2 12y ago
  no :)
shadowmint 12y ago
A couple of down sides of web components: - they interact poorly with requirejs and amd in general. - they flat out dont work at all in IE8 - there's no 'good' solution for the request hell you get from loading 50 components; although some of the tooling is getting there (vulcanize). - the tooling in general is currently rubbish; no way to easily combine sass + jade + coffee into a web component (eg. with gulp, no the dart bindings don't count as tooling). no way to have external resource files. ...but despite that all, they're fantastically productive, great for testable ui, great for making reusable elements you can use in multiple projects. Short answer is: yes, unless you have to support IE8.
- DCKing 12y ago
  > - they interact poorly with requirejs and amd in general. > - the tooling in general is currently rubbish; no way to easily combine sass + jade + coffee into a web component (eg. with gulp, no the dart bindings don't count as tooling). no way to have external resource files. If you use Dart and its Polymer libraries, these two things should not be a problem. Why does that not count? He didn't say he wants to use Sass, Jade or CoffeeScript. IMO, Dart is becoming much more interesting to me as it seems it is the best way to work with Polymer.
  - rektide 12y ago
    Most javascript developers want to use Javascript and want to use what's available in the defacto javascript package manager (npm) and want to use the build tool that works with the javascript packages (browserify). Suggesting using something other than Javascript, it's packages, and it's preeminent packager to get started with Polymer is exactly the problem parent was highlighting, and your suggestion is bloody not well helping.
    - DCKing 12y ago
      Why the hostile reaction? Expanding your horizons is not a bad thing. > Most javascript developers want to use Javascript OP mentions nothing, parent mentions CoffeeScript. Dart also has packages and an official package manager. It also has a dogfooded official Polymer library. Setting up a modular toy project with packages was easier to understand in Dart than JS for me. I don't see how I'm "bloody well not helping".
chrismonsanto 12y ago
The Polymer website uses Polymer and it is slooooow. That's a huge red flag to me. I have nothing but good things to say about React. Try that instead.
- evilduck 12y ago
  When it was brought up 5 days ago here: https://news.ycombinator.com/item?id=7945084 https://news.ycombinator.com/item?id=7945084 there was also lots rendering issues in most every browser except Chrome. I'd stay away from using it in production until they've ironed out the kinks.
- mradmin 12y ago
  Slow UI or slow loading? Slow loading is due to all the HTML imports generating HTTP requests. This can be optimised by inlining the web-components, using a tool like https://github.com/Polymer/vulcanize https://github.com/Polymer/vulcanize I'm not sure why the polymer website is not optimised like this. [edit] Here's what vulcanize does: http://polymer-twitter.badsyntax.co:8002/build.html http://polymer-twitter.badsyntax.co:8002/build.html (Code here: https://github.com/badsyntax/polymer-twitter https://github.com/badsyntax/polymer-twitter) Concatting styles is a whole different story, conceptually it doesn't fit in with encapsulated compontents.
  - chrismonsanto 12y ago
    For me, on Firefox 30, I can see the basic structure of the page immediately, then my browser freezes for ~1.5 seconds, and I see the rest. I checked out the front page in FF's devtools, and could only see two uncached network requests, both to youtube.com. So I am assuming that Polymer itself isn't hitting the network. Furthermore AJAX doesn't freeze the browser, so I can only conclude that it's the actual JS that is causing that lag. On Chrome 35 the freeze is for a much smaller duration but I can still feel it. I'm currently on my (fairly beefy) desktop, so I imagine it's even more noticeable on an older laptop or phone. EDIT: indeed, from a cold cache, it's even slower, and wow there are a lot of HTTP requests.
    - 12y ago
STRML 12y ago
I used it for a project about a year ago (https://github.com/STRML/securesha.re-client/tree/master/polymer https://github.com/STRML/securesha.re-client/tree/master/pol...). I found that it was difficult to keep the service up and working; while older browsers still seem to load it quite well, Chrome continues to natively implement parts of the (changing) spec. When Polymer detects native capability for a given feature, it turns its polyfills off. But if the spec has changed, you are no longer supporting the spec as it was when you wrote your code; and inevitably, your application will crash. I think Polymer has a lot of potential - I definitely enjoyed using it (check out the `app/elements/raw-xhr` and `webworker` elements for some fun; invisible DOM elements that process data!). But if I were to do another application like this, I think I'd just do it with React. It's less of a moving target and has a lot of the same benefits (and more), with the exception of CSS sandboxing.
- dfreedm2 12y ago
  Sorry to hear about that. Thankfully the specs are done now that everything is shipping in Chrome 36. I hope you'll find some useful web components in the future that you can just drop in to whatever project you're working on and save some time!
  - STRML 12y ago
    Is that so - are the specs final now?
general_failure 12y ago
For a mobile project, it is just too slow. I would go with ember
greenjello 12y ago
The only reason to use polymer is if you need the L style UIs they discussed at Google I/O. While Google's really good at Java apis, they're really terrible at JS apis. I love Google, but I would be very hesitant to use their JavaScript libraries or frameworks. A lot of people I've talked to (on irc, es-discus, etc.) don't agree with web components, but Google's pushing it hard. Web components are poorly based good ideas, and polymer is poorly based on web components, and your app will be (poorly) based on that. Other people have started posting some of the problems with polymer.
- HeinZawHtet 12y ago
  you said "some of the problems with polymer". Can i get that resources. Because i am making some research with Polymer. thank
- bsimpson 12y ago
  I don't know if it's fair to say an entire organization is good or bad at an individually-attributable skill. The Polymer team wrote the app framework for WebOS. They're not some generic Java guys who got put on a web project. They have a pretty deep background in JS.
- ffreire 12y ago
  I think you're confounding Polymer with Paper. The core Polymer elements that have currently been released make no assumption as to your UI preference, which means you can style them individually as you please. I've been creating my own Polymer elements for an internal project and have been pleased with the result so far. We've got some particular branding requirements that I've been able to reproduce to great effect. I think as long as you stay away from the messy parts of Polymer (such as making XHR requests in the DOM) then you may find the experience more agreeable.
nobleach 12y ago
I would go with the idea behind Polymer but probably not Polymer itself. Most of the newer frameworks have some sort of component analog. Angular has directives, Ember has components. You can simulate components with Backbone/Marionette. ReactJS is AWESOME and fits right in with the whole component mentality. The project I did with straight Polymer was fun, but I ended up having to scrap it, as the Chrome last month caused blocker issues.
- spankalee 12y ago
  Angular directives, Ember components, or any other framework's components are not the same as Web Components. The browser doesn't, and won't ever, understand what they are. They have very weak encapsulation unless used solely within a single framework. You can't easily use them across frameworks. The current battle of frameworks has lead to massive fragmentation. Pulling together a React view with an Angular dropdown and an Ember tree view is damn near impossible. Web Components are real elements. You can use them wherever you can use elements - including in all those other frameworks. That's the difference.
transientbug 12y ago
So I've been porting part of our internal analytics system at work over to using polymer and I have to say: damn. It's nice to have and being able to make custom reusable elements that can expose a preset functionality and a powerful (if you write it that way) api is pretty nice. Overall I'm pretty happy with it, but can't really speak for how usable outside of our little sphere it is. We haven't had any issues with speed or page performance and only target chrome however.
tangue 12y ago
Polymer looks like a project to push boundaries. While I found the demos at i/o quite cool; I'll quietly waiting for Angular (or Ember if you're this kind of person) to implement Web Components...
wereHamster 12y ago
It depends on what kind of website or web app you are working on. I noticed that polymer is not really suitable for highly dynamic web applications. With ReactJS you can use all of the javascript control structures (if/then/else, conditions, loops, functions etc). With polymer you are restricted to bind, repeat and ref, which are not enough to adequately cover the requirements of a complex application. My recomendation is to use polymer if it's a mostly static website with just a few moving parts, and ReactJS otherwise.
- dfreedm2 12y ago
  Polymer has if (not else yet), repeats loops, functions, and expressions: http://www.polymer-project.org/docs/polymer/expressions.html http://www.polymer-project.org/docs/polymer/expressions.html
- spankalee 12y ago
  Polymer is used to build very complex applications. Not only do Polymer templates have bind, if, repeat, and ref, which are enough to cover the _vast_ majority of cases, by they work by binding to an expression which can drive more complex behavior. I'm curious what you think you can't do with Polymer templates?
  - wereHamster 12y ago
    I didn't say polymer can't do it. What I'm saying is that certain constructs are more difficult to write in polymer. Or involve more code and indirection. Most apps will have their core data loaded into nice JavaScript objects and class instances. With react the transformation of that data into DOM is a one step process. With polymer you have to first map that data to javascript primitives which are consumed by expressions which then generate the DOM. I guess ultimately it's my preference to having types (I use TypeScript) which can be used inside the rendering code to ensure correctness. With polymer you lose some of that because everything ends up in these untyped expressions.
dilipray 12y ago
Pros: Because Polyfill is who web should be built. It's the best way to develop a web applications. It's future friendly. It's better to have one file for a component. Example: https://github.com/PolymerLabs/google-map https://github.com/PolymerLabs/google-map Where they have everything. CSS, JS and Template in one page. Cons: You shouldn't be using it for everything and of course not for the next project. Google doesn't use it for production. It makes tons of requests. Comments: Try to use it for few demo projects test the performance and take a decision. If you want to use it. It works best with require.js and you can't just dive into it Polymer(Deep Sea) without having experience(Wearing a oxygen cylinder). https://gist.github.com/tantaman/7222599 https://gist.github.com/tantaman/7222599
user1241320 12y ago
I would also be interested in comparisons with http://www.x-tags.org/ http://www.x-tags.org/
- ffreire 12y ago
  Well, there's this little blurb in the faq[0], not sure if that helps you any. [0]http://www.polymer-project.org/resources/faq.html#xtags http://www.polymer-project.org/resources/faq.html#xtags
- spankalee 12y ago
  One of the biggest differences is that X-Tags doesn't have templating or data-binding, or some of the sugar for reacting to DOM changes. With X-Tags you either manipulate the DOM directly, or bring in another library.
epayne 12y ago
My plan: go all in on Angular (wish it were Ember or Backbone) through 2015. These frameworks have reached a maturity and popularity that makes them useful and reliable. I expect to switch to Polymer / Web Components early 2016. I work at a very large company. I think it makes sense for us to stay in the "late majority" because most benefits come for technology adopters after the trail has not only been blazed but has been thoroughly paved and landscaped by others. There may be competitive advantages however to individual developers and smaller organizations (startups) who can pioneer the new.
dfreedm2 12y ago
One important question: Do you need to ship something right now? If so, its important to keep in mind that Polymer is in a "developer preview" state, and we have not declared it production ready yet. If you need to ship, then use whatever you feel the most comfortable with. Fewer cognitive barriers and less stress. However, if you've got the time to play around and learn how web components work, then hop aboard! There's an introduction tutorial here: http://www.polymer-project.org/docs/start/tutorial/intro.html http://www.polymer-project.org/docs/start/tutorial/intro.htm... The calculator demo is pretty simple: http://www.polymer-project.org/components/paper-calculator/demo.html http://www.polymer-project.org/components/paper-calculator/d... (source: https://github.com/polymer/paper-calculator https://github.com/polymer/paper-calculator) Salesforce has a nice polymer-based web component set for building mobile apps that integrate with the Salesforce apis: https://github.com/ForceDotComLabs/mobile-ui-elements/ https://github.com/ForceDotComLabs/mobile-ui-elements/ And the demo app at I/O is here: http://www.polymer-project.org/apps/topeka/ http://www.polymer-project.org/apps/topeka/ (source: https://github.com/polymer/topeka/ https://github.com/polymer/topeka/ and https://github.com/polymer/topeka-elements https://github.com/polymer/topeka-elements)
- bsimpson 12y ago
  That's consistent with what we've been hearing from Matt, but I believe contrary to how Rob answered a similar question at I/O. Do you guys have a timeline for this, e.g. "try it for production-quality apps that are scheduled to ship Fall 2014"?
timothya 12y ago
I haven't built an application in Polymer yet (though I did have a good experience building a small application about a year and a half ago with Dart's WebUI library, which implemented a lot of the Web Component features before Polymer and the web browser layer was ready), so I don't have any advice on how ready Polymer is for prime-time yet. What I will say is that we should remember that Web Components is where the web platform is going. This isn't some one-off library by Google; both Chrome and Firefox are getting all of the web component primitives built into the browser, and it looks promising that we'll see them arrive in IE and Safari as well. Polymer is some sugar on top of those primitives to make them easier to work with, but in any case, the next generation of web apps will start using web components and probably some library like Polymer or XTags. The time to start learning and playing around with web components is now, even if it's not time to build massive applications in them quite yet.
jastanton 12y ago
I have been playing a lot with Polymer over the last 4 months or so. Here are my thoughts: From what I can tell Polymer works closely with the Chrome team and the features that this "framework" offers are really just upcoming tech that is being built into chrome and is being made available by Polymer. Things like web components, html imports, templating etc... are built built into the browser so the longer you use polymer the less of polymer you will use. When I describe polymer to people I say it's an opinion layer on top of upcoming tech. And in addition to that everything is polyfilled to some older browsers, but right now is aimed towards the evergreen browsers. When you ask "should I use Polymer", what I hear is, "should I get a jump start on the upcoming future of the web"? Lets be clear here, Mozilla, IE, Chrome etc... are all merging on these technologies. Object observers, templating, web components etc... are all emerging, Polymer is just one way you can use them now and tie them all together in an opinionated way. If you don't like it you don't have to use polymer you could just use plain ol JS and achieve the exact same solution, just slightly more verbose and with less support. Now as to wether or not you should use it? Depends who your audience is. If you need a huge wide support from old browsers, probably not. If you're doing tooling for your company then yeah I would, it would be great to get used to the way the web is migrating towards. Just keep in mind everything is still solidifying, so there might be some awkward corner cases or something, but honestly it's just plain old Javascript soooo it's pretty vanilla so you shouldn't have too much difficulty if you know JS. Last thing I have to say about Polymer. It's going to stretch the way you think of the DOM and JS. The way everything is structured and the way you should be thinking about it is that every DOM node should be considered an instance of a class. The DOM node exposes an API and away you go plugging and playing into the rest of your JS. It's really fun once you get used to it. This will really stretch you when they introduce the ajax api as a DOM node. wat. Crazy things are happening, some good, some will need to be changed. Full disclosure I work at Google as a software engineer that specializes in frontend, so I am exposed to this a lot though I do NOT work on the project. That's about it :)
higherpurpose 12y ago
Use it if you have an Android app, too, at least.
ilaksh 12y ago
I hope that the Mozilla people are working closely with the Google people on Polymer, and vice versa. If you are building an internal tool or an application where you can dictate that they use a specific version of Chrome or Firefox then I think you should default to Polymer now. Or at least default to trying to make it work first before going on to other things.
bradchoate 12y ago
What is it about the home page that makes the font face (on everything) adjust weight as you hover on different things? This even happens in Chrome. That can't be by design. http://cl.ly/image/062Q0F0h1T1s http://cl.ly/image/062Q0F0h1T1s
bennycreative 12y ago
I'm not sold on the idea that you need Web Components (and thus Polymer/React) to build or maintain a complex web app. I think that "complex" can mean a lot of different things. I know from experience that things like <canvas> and Web Workers are already showing a lot of promise by bringing multi-threaded processing to the browser for graphics- and other CPU-intensive operations. I'm also excited for WebRTC, the telephony APIs, WebGL, and other things. These things will help us build complex web apps. When it comes to code maintainability, there is no shortage of organizational frameworks (backbone, angular, etc.), utility libraries (jQuery, underscore, etc.). These are helping me build complex apps. What is Polymer doing for me? Allowing me to use Web Components and shadow DOM? Oh, how earth-shattering. No thanks.
chawk 12y ago
I've just played around with it, I hate it at first glance. It's like Google is now saying we need to follow their pattern to make a responsive website.

74 points by HeinZawHtet 12y ago

Should I Use Polymer from Google for next project? What are advantages and disadvantages for using Polymer?(www.polymer-project.org)

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.

joemaller1 12y ago

I really liked the Polymer demos from I/O, but stepping back, it seems an awful lot like React without the compatibility. Polymer does appear to be more than just another Google flash-in-the-pan. They've got a good team, which is working closely with the Chrome team and Google's investment at I/O was significant. I wonder how the Angular folks are feeling. Facebook is using React right now, when will Google put Polymer into production? Hopefully Polymer will get around to some practical compatibility. Otherwise I'll make a note in my calendar for 2016.

ffreire 12y ago
Perhaps the biggest concern right now is vendor buy-in from other browser vendors such as Microsoft and Apple. It appears that React, at least for the time being, is a more immediate and practical approach to composing UIs. I'll still be mixing Polymer into internal/side projects to keep up to date on its status, but I don't think I'll be pushing anything public facing for the foreseeable future.
deleted 12y ago
[deleted]

robin_reala 12y ago

Why would you? I’ve never been a fan of adopting technology for technology’s sake without a problem that you’re trying to solve with it. (n.b. that problem could acceptably be ‘I want to learn more about this technology’)

bsimpson 12y ago
1) If Web Components work as-advertised, we'll be able to build our own primitives for the first time in the history of the web stack; no more shoehorning rich Internet apps into a framework that was designed for academics to share term papers. This is both fantastic and a fundamental shift in the way apps are written. 2) You can make web apps that look and feel native (on Android) for free.
- robin_reala 12y ago
  Sorry, I phrased my original post badly. That wasn’t a rhetorical question, it was posed to the OP. They didn’t give any reasoning as to why they wanted to adopt Polymer, just a blanket ‘should I?’. Your reasons are both valid though.

wnevets 12y ago

do you care about < IE10?

taf2 12y ago
no :)

shadowmint 12y ago

A couple of down sides of web components: - they interact poorly with requirejs and amd in general. - they flat out dont work at all in IE8 - there's no 'good' solution for the request hell you get from loading 50 components; although some of the tooling is getting there (vulcanize). - the tooling in general is currently rubbish; no way to easily combine sass + jade + coffee into a web component (eg. with gulp, no the dart bindings don't count as tooling). no way to have external resource files. ...but despite that all, they're fantastically productive, great for testable ui, great for making reusable elements you can use in multiple projects. Short answer is: yes, unless you have to support IE8.

DCKing 12y ago
> - they interact poorly with requirejs and amd in general. > - the tooling in general is currently rubbish; no way to easily combine sass + jade + coffee into a web component (eg. with gulp, no the dart bindings don't count as tooling). no way to have external resource files. If you use Dart and its Polymer libraries, these two things should not be a problem. Why does that not count? He didn't say he wants to use Sass, Jade or CoffeeScript. IMO, Dart is becoming much more interesting to me as it seems it is the best way to work with Polymer.
- rektide 12y ago
  Most javascript developers want to use Javascript and want to use what's available in the defacto javascript package manager (npm) and want to use the build tool that works with the javascript packages (browserify). Suggesting using something other than Javascript, it's packages, and it's preeminent packager to get started with Polymer is exactly the problem parent was highlighting, and your suggestion is bloody not well helping.
  - DCKing 12y ago
    Why the hostile reaction? Expanding your horizons is not a bad thing. > Most javascript developers want to use Javascript OP mentions nothing, parent mentions CoffeeScript. Dart also has packages and an official package manager. It also has a dogfooded official Polymer library. Setting up a modular toy project with packages was easier to understand in Dart than JS for me. I don't see how I'm "bloody well not helping".

chrismonsanto 12y ago

The Polymer website uses Polymer and it is slooooow. That's a huge red flag to me. I have nothing but good things to say about React. Try that instead.

evilduck 12y ago
When it was brought up 5 days ago here: https://news.ycombinator.com/item?id=7945084 https://news.ycombinator.com/item?id=7945084 there was also lots rendering issues in most every browser except Chrome. I'd stay away from using it in production until they've ironed out the kinks.
mradmin 12y ago
Slow UI or slow loading? Slow loading is due to all the HTML imports generating HTTP requests. This can be optimised by inlining the web-components, using a tool like https://github.com/Polymer/vulcanize https://github.com/Polymer/vulcanize I'm not sure why the polymer website is not optimised like this. [edit] Here's what vulcanize does: http://polymer-twitter.badsyntax.co:8002/build.html http://polymer-twitter.badsyntax.co:8002/build.html (Code here: https://github.com/badsyntax/polymer-twitter https://github.com/badsyntax/polymer-twitter) Concatting styles is a whole different story, conceptually it doesn't fit in with encapsulated compontents.
- chrismonsanto 12y ago
  For me, on Firefox 30, I can see the basic structure of the page immediately, then my browser freezes for ~1.5 seconds, and I see the rest. I checked out the front page in FF's devtools, and could only see two uncached network requests, both to youtube.com. So I am assuming that Polymer itself isn't hitting the network. Furthermore AJAX doesn't freeze the browser, so I can only conclude that it's the actual JS that is causing that lag. On Chrome 35 the freeze is for a much smaller duration but I can still feel it. I'm currently on my (fairly beefy) desktop, so I imagine it's even more noticeable on an older laptop or phone. EDIT: indeed, from a cold cache, it's even slower, and wow there are a lot of HTTP requests.
  - 12y ago

STRML 12y ago

I used it for a project about a year ago (https://github.com/STRML/securesha.re-client/tree/master/polymer https://github.com/STRML/securesha.re-client/tree/master/pol...). I found that it was difficult to keep the service up and working; while older browsers still seem to load it quite well, Chrome continues to natively implement parts of the (changing) spec. When Polymer detects native capability for a given feature, it turns its polyfills off. But if the spec has changed, you are no longer supporting the spec as it was when you wrote your code; and inevitably, your application will crash. I think Polymer has a lot of potential - I definitely enjoyed using it (check out the `app/elements/raw-xhr` and `webworker` elements for some fun; invisible DOM elements that process data!). But if I were to do another application like this, I think I'd just do it with React. It's less of a moving target and has a lot of the same benefits (and more), with the exception of CSS sandboxing.

dfreedm2 12y ago
Sorry to hear about that. Thankfully the specs are done now that everything is shipping in Chrome 36. I hope you'll find some useful web components in the future that you can just drop in to whatever project you're working on and save some time!
- STRML 12y ago
  Is that so - are the specs final now?

general_failure 12y ago

For a mobile project, it is just too slow. I would go with ember

greenjello 12y ago

The only reason to use polymer is if you need the L style UIs they discussed at Google I/O. While Google's really good at Java apis, they're really terrible at JS apis. I love Google, but I would be very hesitant to use their JavaScript libraries or frameworks. A lot of people I've talked to (on irc, es-discus, etc.) don't agree with web components, but Google's pushing it hard. Web components are poorly based good ideas, and polymer is poorly based on web components, and your app will be (poorly) based on that. Other people have started posting some of the problems with polymer.

HeinZawHtet 12y ago
you said "some of the problems with polymer". Can i get that resources. Because i am making some research with Polymer. thank
bsimpson 12y ago
I don't know if it's fair to say an entire organization is good or bad at an individually-attributable skill. The Polymer team wrote the app framework for WebOS. They're not some generic Java guys who got put on a web project. They have a pretty deep background in JS.
ffreire 12y ago
I think you're confounding Polymer with Paper. The core Polymer elements that have currently been released make no assumption as to your UI preference, which means you can style them individually as you please. I've been creating my own Polymer elements for an internal project and have been pleased with the result so far. We've got some particular branding requirements that I've been able to reproduce to great effect. I think as long as you stay away from the messy parts of Polymer (such as making XHR requests in the DOM) then you may find the experience more agreeable.

nobleach 12y ago

I would go with the idea behind Polymer but probably not Polymer itself. Most of the newer frameworks have some sort of component analog. Angular has directives, Ember has components. You can simulate components with Backbone/Marionette. ReactJS is AWESOME and fits right in with the whole component mentality. The project I did with straight Polymer was fun, but I ended up having to scrap it, as the Chrome last month caused blocker issues.

spankalee 12y ago
Angular directives, Ember components, or any other framework's components are not the same as Web Components. The browser doesn't, and won't ever, understand what they are. They have very weak encapsulation unless used solely within a single framework. You can't easily use them across frameworks. The current battle of frameworks has lead to massive fragmentation. Pulling together a React view with an Angular dropdown and an Ember tree view is damn near impossible. Web Components are real elements. You can use them wherever you can use elements - including in all those other frameworks. That's the difference.

transientbug 12y ago

So I've been porting part of our internal analytics system at work over to using polymer and I have to say: damn. It's nice to have and being able to make custom reusable elements that can expose a preset functionality and a powerful (if you write it that way) api is pretty nice. Overall I'm pretty happy with it, but can't really speak for how usable outside of our little sphere it is. We haven't had any issues with speed or page performance and only target chrome however.

tangue 12y ago

Polymer looks like a project to push boundaries. While I found the demos at i/o quite cool; I'll quietly waiting for Angular (or Ember if you're this kind of person) to implement Web Components...

wereHamster 12y ago

It depends on what kind of website or web app you are working on. I noticed that polymer is not really suitable for highly dynamic web applications. With ReactJS you can use all of the javascript control structures (if/then/else, conditions, loops, functions etc). With polymer you are restricted to bind, repeat and ref, which are not enough to adequately cover the requirements of a complex application. My recomendation is to use polymer if it's a mostly static website with just a few moving parts, and ReactJS otherwise.

dfreedm2 12y ago
Polymer has if (not else yet), repeats loops, functions, and expressions: http://www.polymer-project.org/docs/polymer/expressions.html http://www.polymer-project.org/docs/polymer/expressions.html
spankalee 12y ago
Polymer is used to build very complex applications. Not only do Polymer templates have bind, if, repeat, and ref, which are enough to cover the _vast_ majority of cases, by they work by binding to an expression which can drive more complex behavior. I'm curious what you think you can't do with Polymer templates?
- wereHamster 12y ago
  I didn't say polymer can't do it. What I'm saying is that certain constructs are more difficult to write in polymer. Or involve more code and indirection. Most apps will have their core data loaded into nice JavaScript objects and class instances. With react the transformation of that data into DOM is a one step process. With polymer you have to first map that data to javascript primitives which are consumed by expressions which then generate the DOM. I guess ultimately it's my preference to having types (I use TypeScript) which can be used inside the rendering code to ensure correctness. With polymer you lose some of that because everything ends up in these untyped expressions.

dilipray 12y ago

Pros: Because Polyfill is who web should be built. It's the best way to develop a web applications. It's future friendly. It's better to have one file for a component. Example: https://github.com/PolymerLabs/google-map https://github.com/PolymerLabs/google-map Where they have everything. CSS, JS and Template in one page. Cons: You shouldn't be using it for everything and of course not for the next project. Google doesn't use it for production. It makes tons of requests. Comments: Try to use it for few demo projects test the performance and take a decision. If you want to use it. It works best with require.js and you can't just dive into it Polymer(Deep Sea) without having experience(Wearing a oxygen cylinder). https://gist.github.com/tantaman/7222599 https://gist.github.com/tantaman/7222599

user1241320 12y ago

I would also be interested in comparisons with http://www.x-tags.org/ http://www.x-tags.org/

ffreire 12y ago
Well, there's this little blurb in the faq[0], not sure if that helps you any. [0]http://www.polymer-project.org/resources/faq.html#xtags http://www.polymer-project.org/resources/faq.html#xtags
spankalee 12y ago
One of the biggest differences is that X-Tags doesn't have templating or data-binding, or some of the sugar for reacting to DOM changes. With X-Tags you either manipulate the DOM directly, or bring in another library.

epayne 12y ago

My plan: go all in on Angular (wish it were Ember or Backbone) through 2015. These frameworks have reached a maturity and popularity that makes them useful and reliable. I expect to switch to Polymer / Web Components early 2016. I work at a very large company. I think it makes sense for us to stay in the "late majority" because most benefits come for technology adopters after the trail has not only been blazed but has been thoroughly paved and landscaped by others. There may be competitive advantages however to individual developers and smaller organizations (startups) who can pioneer the new.

dfreedm2 12y ago

One important question: Do you need to ship something right now? If so, its important to keep in mind that Polymer is in a "developer preview" state, and we have not declared it production ready yet. If you need to ship, then use whatever you feel the most comfortable with. Fewer cognitive barriers and less stress. However, if you've got the time to play around and learn how web components work, then hop aboard! There's an introduction tutorial here: http://www.polymer-project.org/docs/start/tutorial/intro.html http://www.polymer-project.org/docs/start/tutorial/intro.htm... The calculator demo is pretty simple: http://www.polymer-project.org/components/paper-calculator/demo.html http://www.polymer-project.org/components/paper-calculator/d... (source: https://github.com/polymer/paper-calculator https://github.com/polymer/paper-calculator) Salesforce has a nice polymer-based web component set for building mobile apps that integrate with the Salesforce apis: https://github.com/ForceDotComLabs/mobile-ui-elements/ https://github.com/ForceDotComLabs/mobile-ui-elements/ And the demo app at I/O is here: http://www.polymer-project.org/apps/topeka/ http://www.polymer-project.org/apps/topeka/ (source: https://github.com/polymer/topeka/ https://github.com/polymer/topeka/ and https://github.com/polymer/topeka-elements https://github.com/polymer/topeka-elements)

bsimpson 12y ago
That's consistent with what we've been hearing from Matt, but I believe contrary to how Rob answered a similar question at I/O. Do you guys have a timeline for this, e.g. "try it for production-quality apps that are scheduled to ship Fall 2014"?

timothya 12y ago

I haven't built an application in Polymer yet (though I did have a good experience building a small application about a year and a half ago with Dart's WebUI library, which implemented a lot of the Web Component features before Polymer and the web browser layer was ready), so I don't have any advice on how ready Polymer is for prime-time yet. What I will say is that we should remember that Web Components is where the web platform is going. This isn't some one-off library by Google; both Chrome and Firefox are getting all of the web component primitives built into the browser, and it looks promising that we'll see them arrive in IE and Safari as well. Polymer is some sugar on top of those primitives to make them easier to work with, but in any case, the next generation of web apps will start using web components and probably some library like Polymer or XTags. The time to start learning and playing around with web components is now, even if it's not time to build massive applications in them quite yet.

jastanton 12y ago

I have been playing a lot with Polymer over the last 4 months or so. Here are my thoughts: From what I can tell Polymer works closely with the Chrome team and the features that this "framework" offers are really just upcoming tech that is being built into chrome and is being made available by Polymer. Things like web components, html imports, templating etc... are built built into the browser so the longer you use polymer the less of polymer you will use. When I describe polymer to people I say it's an opinion layer on top of upcoming tech. And in addition to that everything is polyfilled to some older browsers, but right now is aimed towards the evergreen browsers. When you ask "should I use Polymer", what I hear is, "should I get a jump start on the upcoming future of the web"? Lets be clear here, Mozilla, IE, Chrome etc... are all merging on these technologies. Object observers, templating, web components etc... are all emerging, Polymer is just one way you can use them now and tie them all together in an opinionated way. If you don't like it you don't have to use polymer you could just use plain ol JS and achieve the exact same solution, just slightly more verbose and with less support. Now as to wether or not you should use it? Depends who your audience is. If you need a huge wide support from old browsers, probably not. If you're doing tooling for your company then yeah I would, it would be great to get used to the way the web is migrating towards. Just keep in mind everything is still solidifying, so there might be some awkward corner cases or something, but honestly it's just plain old Javascript soooo it's pretty vanilla so you shouldn't have too much difficulty if you know JS. Last thing I have to say about Polymer. It's going to stretch the way you think of the DOM and JS. The way everything is structured and the way you should be thinking about it is that every DOM node should be considered an instance of a class. The DOM node exposes an API and away you go plugging and playing into the rest of your JS. It's really fun once you get used to it. This will really stretch you when they introduce the ajax api as a DOM node. wat. Crazy things are happening, some good, some will need to be changed. Full disclosure I work at Google as a software engineer that specializes in frontend, so I am exposed to this a lot though I do NOT work on the project. That's about it :)

higherpurpose 12y ago

Use it if you have an Android app, too, at least.

ilaksh 12y ago

I hope that the Mozilla people are working closely with the Google people on Polymer, and vice versa. If you are building an internal tool or an application where you can dictate that they use a specific version of Chrome or Firefox then I think you should default to Polymer now. Or at least default to trying to make it work first before going on to other things.

bradchoate 12y ago

What is it about the home page that makes the font face (on everything) adjust weight as you hover on different things? This even happens in Chrome. That can't be by design. http://cl.ly/image/062Q0F0h1T1s http://cl.ly/image/062Q0F0h1T1s

bennycreative 12y ago

I'm not sold on the idea that you need Web Components (and thus Polymer/React) to build or maintain a complex web app. I think that "complex" can mean a lot of different things. I know from experience that things like <canvas> and Web Workers are already showing a lot of promise by bringing multi-threaded processing to the browser for graphics- and other CPU-intensive operations. I'm also excited for WebRTC, the telephony APIs, WebGL, and other things. These things will help us build complex web apps. When it comes to code maintainability, there is no shortage of organizational frameworks (backbone, angular, etc.), utility libraries (jQuery, underscore, etc.). These are helping me build complex apps. What is Polymer doing for me? Allowing me to use Web Components and shadow DOM? Oh, how earth-shattering. No thanks.

chawk 12y ago

I've just played around with it, I hate it at first glance. It's like Google is now saying we need to follow their pattern to make a responsive website.