Hacker News new | comments | ask | show | jobs | submit login
Polymer, a Web Components library built by Google (polymer-project.org)
239 points by bpierre on May 16, 2013 | hide | past | web | favorite | 117 comments

I was at the Google IO talk and talked to Matt McNulty, my old boss from Palm, and was blown away with what they're building.

This is the future of UI in the browser.

The declarative nature, the encapsulation, the data bindings, the attribute and event-driven APIs are all orders of magnitude simpler than existing JavaScript / HTML UI element componentization. The reusability of a custom element compared to an HTML snippet with some associated JavaScript and CSS cannot be overstated.

EDIT: understated > overstated

> This is the future of UI in the browser.

Again? There sure seem to be a lot of futures for the UI in the browser.

Do they have any interesting examples or sample code? The examples on the Getting Started page [0] don't give me a good idea of how this framework will work in practice.

[0]: http://www.polymer-project.org/getting-started.html

This video of a talk they gave today is a pretty good introduction: https://www.youtube.com/watch?v=0g0oOOT86NY

Thank you for that. Without a working demo it was hard to wrap around how this can be used. The video totally made me want to use it now!

Is it really that revolutionary? Component-driven declarative web frameworks have been around for years (Dojo and Extjs did it way back in 2007). Perhaps the syntax of polymer is nicer, but is it really nicer than something like ember?

Not that i disagree that components are the way forward. It's why i switched to extjs in 2008. Encapsulation into components is the only way to build large scale user interfaces without programming yourself into a corner.

I wouldn't use ExtJS as an example of how to do anything right. Nothing (no frameworks, no previous standards, not even plugins) has ever enabled true component-level sandboxing within the same document. This is just HTML/CSS/JS that is sandboxed into its own component. This library isn't revolutionary, because it's intended to be a polyfill for future-facing (and present) standards which aren't yet widely supported. But what these standards describe IS revolutionary.

A "component" in every library/framework ever has just been some HTML template along with some accompanying JS that makes it "do" stuff. You shove that on your page and watch as your CSS styles conflict with it and break the way it looks or your JS modifies something it relies on and breaks its functionality. They break, all the time. A component as described here does not suffer from such problems.

FYI: if you think you're being more productive towards building any scale user interfaces with ExtJS, you're doing EVERYTHING wrong.

I've got 110.000 lines of ExtJS code and a million users who disagree with your assessment of ExtJS. It is most definitely not true that ExtJS components conflict in the way that you describe. Ext achieves this by abstracting html and css almost entirely, which is also why making ExtJS apps work in IE7 is almost effortless. I imagine at some point they'll be able to retrofit the API to use web components underneath.

> I imagine at some point they'll be able to retrofit the API to use web components underneath.

They still use absolute positioning, don't use CSS whenever possible, and manually do everything in JS just to support IE. All of its vbox/hbox code is already obsolete as of flexbox but it doesn't use flexboxes (instead it manually calculates everything, and it's about 1000x slower than the browser at this, and I can provide benchmarks of this if you'd like). It doesn't even try to do this via feature detection. Why would you expect this thing that absolutely positions everything, even when it's almost always unnecessary, to conditionally support web components? Flexbox is well supported in SASS/Compass and they don't even use that (styles, enable via feature detect with a class, it'd literally be a 100 line patch to support). Never gonna happen. ExtJS is an abomination. I don't understand why Sencha hasn't killed it yet -- they have so many bright people and so many awesome projects, yet this continues to be the giant radioactive elephant in the room.

Instead of building for the lowest common denominator, it should progressively enhance. Specific CSS and supporting code for IE loaded as a module. Firefox, Chrome, Safari, and others don't need about 60% of the code ExtJS has as it literally serves to re-implement browser features for IE. Web developers do this by hand to great success, and create richer and more capable web applications than anything I've ever seen built on ExtJS without "coding themselves into a corner." Like I said, ExtJS is a terrible example of how to create and use a component-based model.

ExtJS components do break exactly as I said. For one, their interfaces change and fundamental problems with the layout system cause significant breakage from version to version. Build a custom component that itself contains other components -- next version it's broken. This isn't possible with web components. Take styling: every major version difference has completely broken styling in ExtJS applications. This isn't true of web components.

Well, shadow dom and web components are browser level features, and it will take many years before all browsers in active use support them, so right now the benefits they offer are purely theoretical in the real world. But, i don't see anything in ExtJS that would prevent keeping the same superficial API and rejiggering the component internals to use shadow DOM. With sencha touch they already demonstrated that the API can remain largely unchanged yet be based on pure CSS, but again this is not feasible for ExtJS until IE9 is the oldest version in active use, which is years away still. You're right that they should have two layout systems, one for legacy browsers and one for modern browsers in pure CSS, but it seems they lack the resources to do this right now.

As for your opinions about ExtJS itself, we'll have to agree to disagree. I never had this bad experience you describe. Version upgrades for me went smoothly, even with a custom theme. My bugfixes overrides file is less than 500 lines, which is quite reasonable on a library that size. I admit that i'm still on ExtJS 3, which might go a long way to explain our difference in opinion. In another comment you mentioned having to rewrite a lot of components. That sounds like someone trying to make the framework into something it's not. In my experience as long as you accept that each component is a black box (like they will be under shadow dom) and only use composition and documented properties to build new things, then stuff works just fine. If however you start adapting the internals... "you're doing it wrong" ;)

Also, i strongly disagree on the feasbility of progressive enhancement. I tried that for years before ExtJS, to the point of writing my own progressively enhanced grid with many of the features of Ext's grid. The need to support IE6 meant i could never build the rich UI's i wanted without a gazillion ugly hacks that took up way too much time. Ext through its abstraction of those hacks was an incredible productivity boost. I suppose the feasiblity depends heavily on two things: (1) do you need desktop-like UI primitives, and (2) do you need to support legacy IE? I my case the answer to both is 'yes', and progressive enhancement didn't pan out. But maybe i was doing it wrong by not dumbing down my UI for the browser's limitations.

i have 50k lines of Ext 3 and I agree with his comment, fwiw. We've completely abandoned it for a polymer-like approach. Ext 3 doesn't separate model and view. Ext 4 has better "model-view-whatever" separation but I never really studied it deeply.

> if you think you're being more productive towards building any scale user interfaces with ExtJS, you're doing EVERYTHING wrong.

[Citation Needed]

Years of experience working with the library and being forced to rewrite almost every major component of it due to it being completely buggy and broken. Version upgrades massively break every application using it. It's impossible to style because its "component" abstraction is leaky. The component DOM-mirror they maintain is broken by almost any 3rd party code that does anything. Debugging it is a bigger pain in the ass than debugging in IE6.

The day I started using things like AngularJS and Backbone, I was able to create well over 100x more stuff in the same amount of time, all of it comparably bug-free and significantly more in line with web standards. I built a massive 1000+ view SPA in ExtJS. Getting it to scale to that point was an enormous technical feat -- it has O(n^2) and O(n^3) and worse algorithms EVERYWHERE and does massive amounts of unnecessary layout work because it doesn't actually use the DOM/CSS and let them do the things they were designed to do. The end result is everything is absolutely positioned with overlaps abound and a single page layout causes tens of thousands of unnecessary reflows and repaints. This is why you will never find anyone complaining that ExtJS applications are fast.

Everything is nicer than ember :p, but no seriously it's not that Polymer is nice, it's that _finally_ having something unified in the browsers will be nice. Web components will help truly modularize things and people can finally ditch jQuery plugins. I wouldn't use polyfills personally, I'll wait for the real deal but it's a start.

Have you tried using the polyfills yet?

From the sound of it, they are good enough that future is already here-- except for some glaring exceptions like shadow DOM re-projections.

The future is here, but we don't know how to deal with it yet. How we currently create web applications is so fundamentally different... that it's almost like learning from scratch. It still doesn't tell you how to construct your application (aside from using components, of course). You'll still have some type of "application wide script", I think, to do stuff like routing.

I see it more as a potentially native impl of MVVM which is currently done in the application layer. the speed optimization is important if we want to have UIs as complex as, say, an IDE in the browser, which is pretty clearly where we are headed this decade.

Light Table is pretty darn fast and that's using the regular old html/js/css we have now. :)

I think the parent of your comment meant: "the speed optimization is important if we want to have UIs as complex as an IDE _built with these new APIs_" --because polyfills do lots of work to emulate browser features.

Both the native ShadowDOM implementation in Chrome/Canary and the ShadowDOMPolyfill support reprojection.

My first thought when i saw that was: they are reinventing dojotoolkit.

Can someone explain this to me like I'm a 5 year old and have no idea what any of it means? What will it help me do that I can't otherwise? What tech does it compare to, if any (direct competitors)?

One difficulty with building large single-page web applications is having a decent component model.

Right now, web pages are mostly composed of primitives (divs, etc) which are the building blocks for complex UIs, but there's not a first-class way of bundling these together into richer components such as a tab control, or a data bound listbox.

The web components basically standardize a way to encapsulate more complex UI components, so you can do something like: <x-tab-view></x-tab-view>.

Even beyond a rich community of pre-built components for you to consume, they make it easier for you to make your applications composable-

<my-header></my-header> <my-paging-content> ... lots of content ... </my-paging-content> <my-footer></my-footer>

Hopefully this all makes it much easier to build larger single-page apps.

I realize it hasn't been like that in about a decade, but whenever I start seeing web-component tech I get bad flashbacks to ASP.net WebForms.

In my opinion the worst thing about WebForms were statefulness almost everywhere and very complicated page lifecycle including the refresh of nested components. For small applications it's great, but has problems when you're trying a large, dynamic product. Composability is much easier with MVC, where you can link to controller actions instead of always depending on the way nested controls process postback events and rebuild themselves.

Exactly. I actually kinda liked the ideas behind WebForms - the ViewState thing was a clever way to shoehorn statefulness into the Web. But the abstractions in it were so leaky and brittle as to be worse-than-useless. The page lifecycle was a nightmare, data-binding was frustratingly finicky about types and parameters (and it was always a roll of the dice whether a given component would use empty strings or nulls to indicate an empty value) and so on.

Web forms was full of half-assed abstractions. Every postback it re-built your control tree and re-applied the viewstate, but any actual additions or removals of controls made in code-behind were not part of this rebuild and viewstate application, so it completely half-assed the control rebuild and thrashed its own abstraction. If you added a new control dynamically on one postback, you had to re-add it every postback, which demolishes the stateful model it presents with respect to the properties of controls.

What was wrong with it? I haven't used ASP at all (outside of some tutorial a decade or so ago), so I don't know. Curious to see if there are any pitfalls we're headed for, and if they're avoidable.

In the meantime, I'm quite excited by the idea of web-components, though the implementation is staggeringly unpleasant to look at.

Adobe Flex was also completely based on this "components" model. I would say that it is a useful approach, but as you suggest, not without its pitfalls. Adobe mxml was pretty much the same as this is: xml based markup, with custom components, these in turn implemented in a combination of mxml markup, AS3 scripts and css styles. I was a flex early adopter, and used it for some years. Later I abandoned it, mostly because I got tired of writing excessive boilerplate code in java-styled AS3, and also because html started to evolve. I can remember some tips. Please excuse my diffuse language, I am talking straight from memory.

- Avoid messy component structures. Keep component definitions simple. Use components hierarchies and keep nesting levels simple.

- On complex UIs, "application intention" can get lost in a sea of anonymous data bindings. Use good documentations practices. Avoid data binding spaghetti.

- On complex UIs, Use good planing for data binding. Because debugging it is "data binding hell".

- Know your components well. Sometimes components capabilities may differ slightly from what you are trying to accomplish. Trying to go against the components quirks, can be very expensive.

- Data binding is not the panacea. There are scenarios that are best served with other approaches.

WebForms, how I hate thee, let me count the ways.

It perverts the web's statelessness. It imposes some half-assed, hacky state via "viewstate". You have to constantly prune the amount of viewstate which controls add to a page, or you end up with 50kb of viewstate in the markup!

It is incredibly complex! The event model is difficult to understand, there are many steps - at a page level and later at a control level. I've never met anybody who truly understands it. You have a problem? Trial and error and sticky tape until you get it balancing just right that it works. Change with caution!

Promotes highly coupled code. The "code behind" all but begs you to put your business logic in your view. Testing is basically impossible, unless you adopt a framework like WebFormsMVP. This eases things somewhat, giving a cleaner model to work with and forces you to move business logic out of the view. But that can be a challenge on occasions too, because you eventually have to deal with the complex event model underpinning the framework (as I described above).

WebForms is basically demoware. Looks great when you drag a few controls on a page, click a few buttons, and have it pulling data into a sortable/filterable grid. As soon as you want to produce clean markup, styled as you want, performing some complex interactions, you'll end up wanting to pull your hair out.

Disclosure: I've worked with webforms for around 4 years.

They also allow you to plug the inputs of one component into the outputs of another in a declarative way with model-driven views. So, if you have a menu that allows a user to choose a piece of data to work with, you can do something like this:

    <select id = 'menu'>
        <option />
    <x-item-editor item_key = "{{ menu.value }}"/>
I haven't used the library yet, so I'm sure the syntax is wrong, but you can see how x-item-editor can know which item to edit by consuming the select's value property, without needing any glue in the JS.

The modern web app has gone way beyond the simple HTML page - now there are components in all but name, handling their own libraries, network connections, establishing model-view-controller separation, and communicating with other components via events. But it's all simulated out of the technologies originally made for web pages.

One sign that things have gone very wrong: a lot of developers have to treat the web page as a kind of compilation target. We've lost the simplicity the original web had.

The authors believe in a future where if you wanted a particular rich text editor in your web app, you could just put <my-rich-text-editor/> in there. Done.

No web browser can do this stuff today, but libraries like Polymer are trying to bridge the gap between today's browsers and the way they may look in the future.

As another poster mentioned, it's attacking the same problems as Angular.js, with a similar approach. Indirectly it's competing with pretty much every client side web app framework.

No web browser can do this stuff today, but libraries like Polymer are trying to bridge the gap between today's browsers and the way they may look in the future.

We should probably stop calling them "web browsers" at this point. We've basically re-implemented the idea of an Operating System in the browser, so we now have a full-fledged OS like Linux, BSD, Plan9, OS/2, Minix or whatever, being used to host a "poor man's OS" which is recreating most of what the base OS does!

To say "things have gone very wrong" is a dramatic understatement in many ways. I still think we messed up by migrating away from the mobile-code approach for apps. But I largely blame Sun for that, as they screwed the pooch by shipping the Consumer JRE about 7 years too late, ignoring needed features for doing desktop and interactive apps (like modern audio and video codecs, etc.) and didn't stay on top of JRE security. Now, Java, which was probably the best "mobile code" platform that ever got mainstream traction, is basically dead as a client platform. :-(

Browsers are great for doing what they were designed to do: Browsing hypermedia. But to shoehorn "remote application delivery" into the browser seems like a step sideways (at best) to me. We're layering hacks on top of hacks on top of hacks now, to try and recreate the "app" experience inside the browser. This strikes me as sub-optimal.

The web is still for documents. It's for a resource that lives at a URL. It's markup, not programming, and that's the very reason it has lived to be twenty years old and the main way that information is communicated. It's how we're able to hold this conversation right now — people are comfortable stitching together words in XML-ish constructs.

The people making games, applications, and lush webGL marketing demos are people who can throw lots of engineering resources at a problem until it does the thing they want it to do. Web dev has always been an insane mountain of hacks in order to get pages to render, but the attractive and democratic reasoning is that that extra effort is worth it if the maximum number of people can access the information. People on old computers, cheap smartphones, kindles, chumbys, whatever. The best computer is the one you have on you, that sort of thing. Access and ease-of-adoption are powerful things.

So that's why I see web components as something that enables people writing markup more than it empowers people writing giant javascript applications. This is so that people can add <twitter-tweet href="twitter.com/name">My Cool Tweet</twitter-tweet> tags to their wordpress blogs, and so that the people making that <twitter-tweet> tag can be confident that it will render and not look horrible on that person's blog. It's so that the complex, app-ish things can be abstracted away and added to documents with a declarative and logic-less syntax.

No amount of java applets would have ever made up for that.

So that's why I see web components as something that enables people writing markup more than it empowers people writing giant javascript applications. This is so that people can add <twitter-tweet href="twitter.com/name">My Cool Tweet</twitter-tweet> tags to their wordpress blogs, and so that the people making that <twitter-tweet> tag can be confident that it will render and not look horrible on that person's blog. It's so that the complex, app-ish things can be abstracted away and added to documents with a declarative and logic-less syntax.

Sure, and to the extent that Web Components do that, they are a good thing. Where I think we've gone a bit wonky is more on the "giant javascript applications" where we're using a great document delivery platform as a half-baked application runtime.

For better or worse, the way software delivery has evolved on the web is that documents contain applications.

I think that if we had known where we wanted to go, it may have been better to start the other direction, and make a web app API that basically allowed apps to contain documents. That would have avoided significant amounts of pain, and ended up looking more similar to what we have anyway -- web apps wanting or needing a larger and larger degree of extension-like autonomy and permission sharing with the browser.

Of course it's sub-optimal, nobody is arguing against that. But from where we are today, there is no other way forward. There's not going to be another technology suddenly spring up that will replace the browser and allow websites as well as apps to run on any device in a matter of seconds, without installation simply by typing a short address and hitting enter. We're layering hacks upon hacks, but you'll just have to deal with it and stop complaining at some point, because no matter how much you'll complain it won't change.

There's never only one way forward. Besides, how does the old saying go:

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.

So who knows, maybe somebody reads one of my rants one day and goes "Hey, this mindcrime guy has a point... and furthermore, I see a better way to do this" and takes some initiative. Who knows what might happen?

Now, are the odds of that infinitesimal? Probably, but that's OK. I ran for public office (and lost) as a Libertarian, so that tells you what I think about odds. :-)

The important point here is "adaptation". The unreasonable do not "create new worlds", they just adapt the one they are living in.

Like Angular.js from an end-user/developer's perspective but goes beyond that. Instead of being a framework it is an effort to polyfill the actual Web Components spec.

This means that Polymer will eventually be supported natively by browsers which means that in the future we'll have something like Angular without needing to do the heavy-lifting at the framework-level.


Also if you are interested in Polymer but want to actually use it in production right now (like we to at Blossom.io) check out Dart's Web UI:


It's like travelling to the future :)

A "web component" is some stand-alone combination of HTML/CSS/JS that does some thing. It should not conflict with the application that uses it in any way. It should, however, allow the application to communicate with it (to modify its state) and to potentially change its appearance in a way that will not break the component.

A problem with HTML/JS/CSS pre-shadow DOM is that it was impossible to actually build a component as described above. There was no way to sandbox the HTML/JS/CSS that's used to build the component from the application. There was always the possibility for contamination.

What the specs that Polymer is intended to polyfill permit is a combination of this sandboxing capability along with other means of permeating this sandbox with the functionality needed for such sandboxed components to be truly useful (how useful is something you embed in your page then can't access/talk to at all?). This includes data binding, events, allowing parent CSS to apply to certain things (in a very explicit, named way, which allows the parent application to style the component in a manner the component creator deems appropriate, and not in a way that will break the component), etc.

These standards, in effect, define features that once implemented will permit true web components to be built.

For more: http://www.html5rocks.com/en/tutorials/webcomponents/shadowd...

Similar to AngularJS also a Google project.

Yeah I got that feeling. I've used and like Angular, but can't figure out why I'd want to use this instead.

I have the exact same question. Polymere does databinding, and custom html elements, but I think Angular does it a little better.

I think AngularJS has more features but Polymer is more modular and designed to be more easily adoptable over time and also fit in with Web Components. I also think that a few things in Angular are hard to figure out, whereas this looks a little more straightforward. So if this Polymer thing could add some of the stuff that Angular has like routing with pushstate then I will definitely consider using it.

Meta question: Is there still a compelling point to having long-term unique URL checking on HN if submitters are going to tack on things like "?repost"?

It makes sense over the period of a day or so to avoid 100 simultaneous duplicate items, but beyond that it seems people are working around it all the time anyway.

This is an interesting question. I submitted this link yesterday, and it did not make it to the HN homepage. Still, I was almost certain that it could start an interesting HN discussion to read. Today I chose to repost it with a clear ?repost rather than a less visible trick, and it was still upvoted (better timing I suppose): the fact that it is a repost did not seem to bother the upvoters.

I have no solution to propose, but the timing seems to be the most important factor for HN submissions, as we already know [1][2][3], and I think these small hacks are acceptable to work around the problem: reposts are not a big source of pollution, and users can report abusive behaviors with the flag button.

[1] http://hnpickup.appspot.com/

[2] http://hnbuffer.com/

[3] http://jacquesmattheij.com/How+to+make+the+Hacker+News+homep...

Fun fact: I posted this 2 days ago: https://news.ycombinator.com/item?id=5709231, also around the same time (hour) as you. Mine didn't have "By Google" in it though since I was not sure about that.

I'm not bothered so much by reposts though I wonder if that was a factor too, attaching brand names

Given comments from pg like https://news.ycombinator.com/item?id=5693221, it is clear that if tricks like this become common, using them will be ban-worthy.

Perhaps /newest should show 30 random items submitted in the last 24 hours.

I think it ended up on the front page today because it was the Google IO presentation today that really showed off what they are accomplishing with Polymer. I'd encourage everyone to watch the demo[1] starts at 3:51:30.

[1] https://developers.google.com/events/io/sessions/324149970

Direct link to the start of the demo: http://www.youtube.com/watch?v=FDEMA6OhvGo&t=3h51m48s

I don't think there is any long-term unique URL checking. I'm pretty sure it only checks for recent duplicates. I think that's by design.

This framework looks really cool, but "built by Google" is a misnomer.

Software like Closure, or the gold linker - these deserve to be called "built by Google". Internal tools, battle tested over years, released to the public.

Angular and Polymer are more like what I'd call "technologies by Googlers".

It's a good way to get more interest, look at "twitter"'s bower

So let's see where Polymer ends up 2 years from now.

Sincerely, an ex-GWT developer.

From their FAQ:

Over time as more browsers implement these emerging standards, the foundation layer will diminish and ultimately disappear.

So more or less, they want it to be gone.

The foundational layer goes away over time. Everyone's app gets better/stronger/fast :) The opinionated sugaring layer on top of Web Components (the Polymer layer) won't go away.

That said, one goal is to have a continuous feedback loop with standards bodies to get things spec'd out if it makes sense to add them to the web platform. Similar to how querySelector landed after jQuery made it "a thing".

I can only hope this to be true. I consider such a statement to be aspirational at best.

Polymer IS a backport of a new web standard, which lets you use it with current browsers.

What a frustrating website. I had to read the comments here to figure out why I might be interested in it.

Hmm, there seems to be quite a bit of magic here that is a bit offputting.

For example, in their Getting Started page [0], they have an example of binding component data to elements. It appears that the Age slider is bound to the {{age}} value because its ID is "ageInput". I would prefer to declare the binding with a data-bind="age" attribute on the input, or something else equally explicit.

[0]: http://www.polymer-project.org/getting-started.html

Data binding happens at the property level. For example, you can remove the id/for attributs from those elements and things still work correctly:


Thanks for the example!

Does this mean that it is the value="{{age}}" attribute that is causing the binding?

What happens if I want to do something like: <input value="{{firstName}} {{lastName}}"></input>?

Correct. In that example, the value attribute is bound to the element's age property. Basically, anything in {{}}.

> <input value="{{firstName}} {{lastName}}">

This will work as you expect (http://jsbin.com/ecejiy/6/edit). Plus, if either of those property values change, the input.value will be updated accordingly.

By the way, you can also add/define your own syntax for MDV bindings: https://github.com/Polymer/mdv/blob/master/docs/syntax.md

I just tweaked the GP's example to used <input value="{{name}} ({{age}})"></input>, which rendered as expected. The field wasn't bound to the age or name properties though, which makes sense.

In practice, this almost seems like "sugar" that automatically binds an input to a value if it's value contains ONLY the property.

To test out the binding sugar, I tried using this input: <input value=" {{name}}"></input> (note the space before {{name}}), which did not bind {{name}} to the input.

I'm still of the opinion that the binding should be more explicit.

Edit: typo fix

This is good feedback. We wanted to start with an easy mode, so people could on ramp quickly. In this case, you just use {{ }} for various kinds of binding and Polymer will (try to) do the right thing. I suspect we will need an alternative syntax for folks like yourself that want an explicit, engineering mode.

If anyone is interested, I hacked together a proof-of-concept framework with a different take on the {{ }} style binding: https://news.ycombinator.com/item?id=5741708

Oh God, I'm having more ASP.Net WebForms flashbacks. Databinding is one of those things MS never really got right despite having something like a thousand kicks at that can.

As a independent software developer that does a fair amount of web based work, I wished they had included Opera (Presto based Opera) in their compatibility list[1]. Yes, I'm aware most people don't use Opera before someone reminds me, but there are a lot of Opera Mobile/Mini users. On a personal standpoint, I like to make sure the js/css I write degrades gracefully and supports Opera Desktop too (something that Google has had troubles with caring about in certain sites they maintain).

They also don't mention how it works on older versions of browsers (specifically IE and if it works fine on IE 9 and 8). I generally don't care about anything before IE 8 anymore, but with jQuery dropping support for IE 8 in jQuery 2.0, I am wondering if Google followed suit. It says only the latest versions of browsers[2], which if taken literally, means IE 10 only and that's a very small subset of IE use as a whole (like 1-2%) [3].

Also don't see any mention for how it works with the non-Chrome (though still webkit) stock Android browser that most Android devices come with by default. I mean it could fall under Chrome, but it's not the same and not all features are supported by the non-Chrome stock browser (and varies by Android OS version). I'm guessing it's similar to mobile safari though[4].

[1] http://www.polymer-project.org/compatibility.html

[2] http://www.polymer-project.org/faq.html (In practice, this means we support the most recent versions of Chrome, Safari, Internet Explorer, and Firefox.)

[3] http://arstechnica.com/information-technology/2013/02/intern...

[4] http://mobilehtml5.org/

Google now has 3 players in the single page web app framework game: Angular, Dart (with web ui), and now Polymer. Why not join forces and make one killer framework?

> Google now has 3 players in the single page web app framework game: Angular, Dart (with web ui), and now Polymer. Why not join forces and make one killer framework?

Because when you have lots and lots and lots of resources and the best solution to a problem isn't immediately apparent, often pursuing multiple solutions until one shows itself to be the winner is a more effective use of those resources than picking one when the right choice is unclear and focussing all your efforts there.

As far as I know all of the teams are aware of each other and even share some resources (code) as well as insights about best practice and API design.

The angular people probably have the most experience re real-world usage and what works better and what doesn't. Web UI afaik is getting inspiration from Angular and closely tracking polymer spec & API wise.

I expect (and I don't have a crystal ball) that Angular will eventually adopt more and more Web Component stuff as it gets supported by browsers and might add polyfills from polymer (many projects will want to look at and use polyfills from polymer I think)

If you want to experience the power of Web Components right now Web UI is the project that will get you the farthest in terms of browser support from what I understand.

It might look like three different efforts but they are closely related from a 'learn something new & push boundaries'-POV :)

We as web developers are the ones who benefit from this.

Dart's Web UI is built on top of Web Components. At least in the case of Polymer and Dart, Web Components are the "framework" :)

And GWT and Closure. Google isn't a single entity.

Giant polyfills are scary! Looking forward to native implementations! Curious about the perf of this one, going to check it out, looks like solid work!

I am completely confused by this. Here's what their getting started guide looks like:

    The basics of using Polymer are simple:
    1. Load platform.js to polyfill missing platform features, such as Shadow DOM and HTML Imports.
What does "polyfill" mean? What is "Shadow DOM" and "HTML Imports", and how does it benefit me as a web developer?

It would help if the front page had something like this, but with blanks filled in: "Polymer helps the web developer to ____ more [easily|quickly|reliably] than ____. This is what doing ___ looked like before: _____; this is what it looks like with Polymer: ____"

> What does "polyfill" mean? What is "Shadow DOM" and "HTML Imports", and how does it benefit me as a web developer?

Polymer is a pre-alpha framework with a warning on every page that "only the daring need apply." If you don't know what things Shadow DOM and HTML Imports are (and can't be bothered to click the links under "Platform technologies" for those things"), you probably aren't in the audience Polymer is addressing right now.

> It would help if the front page had something like this, but with blanks filled in: "Polymer helps the web developer to ____ more [easily|quickly|reliably] than ____. This is what doing ___ looked like before: _____; this is what it looks like with Polymer: ____"

It probably would, except that right now those blanks would be hard to fill out since except for the low-level infrastructure, most of it hasn't been built yet, and the concept seems mostly to be "lets see what kind of app framework we can build on top of a set of emerging standard technologies, now that we've built polyfills that let us use those technologies on current browsers that lack native support for them".

Thanks for the clarification. I think I'll check back once these things solidify.

I mentally parsed this as "Web UI Components" and thought to myself, "Wow, this looks a lot like Bootstrap". Turns out that the page is indeed built using Bootstrap, and the library is a collection of polyfills.

it seems to support primarily 'evergreen' browsers according to this: http://www.polymer-project.org/compatibility.html

With angular and now polymer, we are seeing a complete paradigm shift in approaching web client development. This is a beautiful metamorphosis to watch. From the days of early HTML tag race (blink, marque, etc.) to addition of asynchronous XML reading with IE 4, to various AJAX helper libraries (jquery, etc) to frameworks with their own complexity and now what we are seeing in the past 12 months or so.

Just think, at some point we might achieve the replication of capabilities local/native applications had 15 years ago. And then what's the difference, except probably now your data is stored online somewhere.

The difference is, I can give a URL to anybody and expect my app to work on their phone, tablet or laptop, without installation, within a matter of seconds. Their data stored online somewhere means that their devices are always synced, and it doesn't matter from where they use the application.

We'll see. In a lot of ways that was already the case with the web. People seem to ignore that email was, and remains, more or less this very ubiquitous web app "dream". Even 10 years ago I could log into hotmail from any computer on any browser, my mail was always "synced" (since I was always more or less directly manipulating the server), and I could see my mail on my phone way before the smartphone revolution. But it remains to be seen whether these technologies will actually make that possible for a wider array of applications. That is to say, is email just a fluke because it happens to have very simple constraints?

The problem of saying "once you can easily write an app you can hit with a URL you get all this for free everywhere!" is that it ignores the "pesky details" of data conflicts and fundamental differences in platforms. Just because my tablet or phone can hit the Photoshop web app URL doesn't mean that app that was designed for a desktop is going to be at all usable on my tablet or phone. No amount of pointer events or reactive layout will fix the problem of sometimes (often? rarely? who knows) needing a truly differently well thought out design for these very different platforms. Is the problem with getting complex apps like these missing "frameworks" or just the leg work of actually rethinking what it means to edit a photo on a tablet vs a desktop. Time will tell I suppose.

Regarding data conflicts, the second you give people the perception that there data is just magically going to always sync and be there when they need it you are going to run into the very real abuse of multiple edits that need to be conflict resolved and the fact you designed your app for a theoretical world where you always have internet when that really isn't the case yet.

All that being said, I agree this is some approximation of the model we will be using some day when we "figure this out".

The "network computer" is becoming a reality 15 years later

So, I know Google is putting out a lot of these Web component specs--how likely are they to get certified/widely accepted?

Is Mozilla/etc. on-board with all of it?

I can't tell if it's an industry-wide movement, or just a bunch of the Google AngularJS guys having fun writing up W3C specs.

Mozilla has a very similar project that is aligned with polymer:


Looks like we'll get actual browser support for Web Components eventually :)

When they decide to include it in the browser the change will come fast - these days browser updates go very well.

This is what a lot of the former engineers on the Enyo team have been working on. However, Enyo is a living and growing project, now under the sponsorship of LG Electronics. If you want to see what their older implementation does check out http://enyojs.com/.

This is not the same as Enyo. Probably not even close. Agreeably they are both Component Frameworks but the similarity ends there. Enyo's component description is in Javascript. Polymers is in HTML. And that is what sets them apart.

1.Clone the project to your app’s root folder. See Get the code. 2.Fire up a web server in your app’s directory. 3.Include polymer.js in your main page: <script src="Polymer/polymer.js"></script> 4.Read the Getting Started guide.

I dont know why, but I really found step 4 very funny at this point.

Looks strikingly similar to Mozilla's XUL and XBL for web. They were far too ahead of their time.

There's a bug in your getting started guide. Under "Binding between components and native elements" index.html contains <tk-element></tk-element>, but should contain <tk-binding-to-elements></tk-binding-to-elements> :-)

Thanks for the heads up. Fixed through the magic of PRs! https://github.com/Polymer/docs/commit/1b9f0c361f84ce0157a13...

I'm tired of this crap. I like HTML. It works, everywhere. Why does everyone hate it so much?

This is HTML! But with tags that you can create, and pass values to, and do things in the browser. It actually empowers developers who don't grasp javascript by encapsulating it.

We love HTML, too. That's why we're so excited about web components--it brings the power back to HTML (and DOM) instead of in some parallel universe in script.

Probably because people keep ignoring what "T" stands for in HTML and keep trying to morph it into WAML.

Why do all the hip UI frameworks nowadays have type that you have to struggle to see ?

So... is this XSLT reinvented?

I'll admit it looks like it'd be a tonne nicer (less verbose and strict) than XSLT but it all looks very familiar to me... just add a client library and you have the same thing?

Or am I missing something here?

Yes, you are missing something. :) This is trying to provide polyfills for and build on top of Shadow DOM and Custom Elements.

While some of the features in them could be provided just by templating stuff (though it would be mildly to very inconvenient), at least the visible DOM / shadow DOM separation and scoped styles wouldn't be possible.

Not really, this deals a lot more with lifecycle events, constructors, inheritance, scoping of styles, etc. To do so it's operating at a completely different level, very much in the DOM.

Did Google just patent pieces of HTML? Hilarious!


Wouldn't it be amazing if Twitter Bootstrap get re-implemented in Web Components (now Polymer)? Then the html code that uses it will be much cleaner.

Sounds like Cappuccino?


I am confused, doesnt google already have Angular.Js, Closure.Js, GWT, and many others .?

If i have well read the doc, while angular has new attributes, Polymer adds new tags to HTML. That seems a step ahead apparently.

Angular also adds new tags ( and custom ones too). You can decide whether you want to use your component ( or "directive") as an attribute , an element, or a css class, and angular will automagically replace them.

I don't think this is officially by google, instead by some googlers

Seeing people excited about this reminds me of the thread the other day with the desktop developers insisting that web design is still like it was 10 years ago and is still the same hacky cludgy mess it was then. Fortunately, Angular.JS and now Polymer have given us much cleaner and more mature methods.

Needs more overlap with Angular. (Sorry, this isn't meant to be sarcastic if it were being interpreted as such)

I thought Angular was becoming the One True Way. Now I am confused.

I'm a bit myself as well, I need to fire up a Polymer project tonight and work through a few things and see how it goes compared to my experience with Angular.

I was always under the impression that the Components infrastructure of Angular.JS was what was driving the spec for Web Components. Maybe I misunderstood, maybe it is and it's just doing so alongside Polymer, or maybe I should play around with them more and write something up (or the best option, wait until someone more knowledgeable has done the work and summarized it for me)

Is related to Angular in any way ??

Solving some similar problems, but the aim of this appears to be a mega-polyfil playground for the (still work in progress) HTML Web Components standards:



Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact