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 ;)
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!
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.
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
I'm not sure why the polymer website is not optimised like this.
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.
It's slow for me also on Chrome 35, but i can't jump to any assumptions on why, without doing the proper debug. For example, the home page is loading a video and adding syntax highlighting to code examples, which can also be slow. Also the UX can be improved using [unresolved] on elements: http://www.polymer-project.org/docs/polymer/styling.html#fou...
When it was brought up 5 days ago here: 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.
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?)
Hi, I'm on the Dart team and spoke at IO this year. Remember what? :)
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.
People keep confusing this it seems. What Google is doing here is NOT like what Microsoft did. Google is merely implement many new HTML5 features ahead of Microsoft (which is usually the most behind in HTML5 support) and others.
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 performance: it will get much better once browser have implemented http://www.w3.org/TR/2014/WD-shadow-dom-20140617/. Shadow DOM is not easy to polyfill (especially because of some issues in how the browser's C++ objects were presented to JavaScript as prototypes.)
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.
I've done projects in both Angular and React and I find the latter to be much simpler to reason about. Scopes, transclusions and directives are often confusing. React is just nestable Polymer-like components of encapsulated markup and behaviour.
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.
- 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.
> - 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.
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.
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".
IMHO, if you (nonpersonal you) identify as a Javascript developer instead of a web developer, you're a very limited and narrow-minded developer. Learning a new language is easy, and installing some new tooling shouldn't take more than a minute nowadays. Looks like Polymer is installed using Bower anyway, which is pretty standard.
If you are a webdeveloepr that builds non-Javascript tools that don't integrate with the rest of Javascript tooling, you will have a very isolated, limited, unadopted and narrow-minded niche you carve for yourself.
got an example? I've not seen any decent 'assembly' tools that pull all the bits together (ie. specifically post compile, turning your separate elements into one self contained .html include)
Well we haven't implemented it yet, but we use Gulp. So my plan is to just concat everything together. I've read there's a syntax for defining resources inside html files, which is probably what we're going to do.
ReactJS is a solid solution if you need to ship something _today_, but I think the trend will continue towards WebComponents as they become standardized across vendors (if not Polymer then x-tags, if not x-tags then... etc). In that sense, it's better to familiarize oneself with the technologies that we'll be seeing more of in the future just as we did with new HTML5 elements a few years ago.
As I see it, the inside of Web Components still need a nice and structured way to function. I'd build my app using ReactJS now, and when I decide to use web components, I can transform each separate ReactJS component into a web component, ReactJS-tag for ReactJS-tag as I see fit.
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?
Polymer includes a Web Components polyfill, so you can write raw Web Components if you want to. Polymer is really just some syntactic sugar over that (and other specs thrown in, like html imports, templates, etc).
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.
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.
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.
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.
I used it for a project about a year ago (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.
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 :)
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’)
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.
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.
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.
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...
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.
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
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 ;)