Ask HN: Should I use Polymer for my next project?
Should I Use Polymer from Google for next project?
What are advantages and disadvantages for using Polymer?(www.polymer-project.org)
What are advantages and disadvantages for using Polymer?(www.polymer-project.org)
81 comments
[ 2.1 ms ] story [ 169 ms ] thread- 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.
> - 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.
> 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".
you definitely told shadowmint to go fuck himself.
1. In production, all imports get concatenation into 1 HTML import.
2. Any web component can use assets that need to be compiled, such as SCSS or CoffeeScript.
It's called Emcee, and is available here: http://www.github.com/ahuth/emcee
@jastanton phrased it nicely in another comment here: https://news.ycombinator.com/item?id=7971847
It's much safer to do it this way than rely on polymer. IMHO. When web components really are here for everyone, you are still stuck with polymer libs and tools and all the code is bound to them. Who knows, polymer might be considered bloat then?
That said, these aren't really the same kind of libraries at all, so I'm not sure why this is such a x vs y thread. Ideally, react and web components are fully composable, and it doesn't really matter where the element came from.
[0]: http://mozbrick.github.io/ [1]: http://www.x-tags.org/
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.
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!
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.
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.
2) You can make web apps that look and feel native (on Android) for free.
I have nothing but good things to say about React. Try that instead.
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 (Code here: https://github.com/badsyntax/polymer-twitter)
Concatting styles is a whole different story, conceptually it doesn't fit in with encapsulated compontents.
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.
It also let's you use CoffeeScript or SASS (or anything else that Sprockets recognizes).
BUT, it is slow in FF30, Safari and failed a lot in IE11.
IMO, Big G is trying very hard to push web technologies that tightly couple to Chrome - same as what MS/IE did a few years back trying hard to force ActiveX, Silverlight down the developers' throat.
I'm betting < 20% chance Polymer will still be in IO talk 3 years from now. (remember GWT, Dart, Angular?)
You have to remember that Polymer is a library that helps you implement Web Components. The APIs for Web Components are being integrated directly into the browser. Chrome already has them, and Firefox is landing them now. Even Microsoft is interested.
This is not another framework.
edit: Check out http://jonrimmer.github.io/are-we-componentized-yet/ for a summary of the progress on the Web Components standards.
So it's not that they are "built for Chrome". It's that they are built for "new HTML5 specs" and only Chrome happens to support them right now. Point me to where Silverlight was an HTML spec?
Now, things like NaCl on the other hand are a lot more similar to what Microsoft used to do, but there's still a major difference, and that is that what they are building is open source and everyone can do their own implementation of it. You could never do that with ActiveX or Silverlight. Plus, you could also say Firefox is doing the same as Google with asm.js, which nobody else has adopted so far.
These things are a little more like that, but at least they are open source. The HTML5 features, though, just happen to be implemented faster by Chrome.
Kinda of remind me of how "open" android is progressing. More and more "features" are pushing into "google experience" layers - also look at how open is the android TV.
BTW, chrome is doing the same on the extension side.
I see the pro/con on the "extension move" - reduce the security risk , etc.
But it is sure feel like the Jedi master is feeling the power of the dark side - "working within the system" is not as fun as just being the Empire.
Regarding IE failures -- do you have any more information? All of the elements should be cross platform. It would be great to file these issues at https://github.com/Polymer, if you haven't already.
A React component at its most basic is just an object that implements a render() method that is responsible for rendering markup. See the React home page for examples http://facebook.github.io/react/index.html.
Since React is just a view layer though, you're left to your own devices for everything else. So if you're evaluating it from the perspective of a whole SPA, then it becomes more complicated.
* No functionality overlap in primitives
* Composability of primitives
How do Polymer and React as primitives fulfil said properties ? There's certain overlap in functionality. Composability is not guaranteed.
Did you mean to convey a different idea by "orthogonal" ?
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 ;)
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) 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!
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.
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.
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.
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.
We haven't had any issues with speed or page performance and only target chrome however.
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.
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?
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.
It's better to have one file for a component. Example: 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
[0]http://www.polymer-project.org/resources/faq.html#xtags
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.htm...
The calculator demo is pretty simple: http://www.polymer-project.org/components/paper-calculator/d... (source: 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/
And the demo app at I/O is here: http://www.polymer-project.org/apps/topeka/ (source: https://github.com/polymer/topeka/ and https://github.com/polymer/topeka-elements)
Do you guys have a timeline for this, e.g. "try it for production-quality apps that are scheduled to ship Fall 2014"?
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.
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 :)
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.
http://cl.ly/image/062Q0F0h1T1s
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.