
Polymer, a Web Components library built by Google - bpierre
http://www.polymer-project.org/?repost
======
eldude
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

~~~
Joeri
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.

~~~
just2n
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.

~~~
Joeri
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.

~~~
just2n
> 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.

~~~
Joeri
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.

------
dmragone
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)?

~~~
randomfool
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.

~~~
Pxtl
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.

~~~
sgrove
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.

~~~
nzonbi
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.

------
petercooper
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.

~~~
bpierre
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...](http://jacquesmattheij.com/How+to+make+the+Hacker+News+homepage)

~~~
eldude
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>

~~~
johnbaum1968
Direct link to the start of the demo:
[http://www.youtube.com/watch?v=FDEMA6OhvGo&t=3h51m48s](http://www.youtube.com/watch?v=FDEMA6OhvGo&t=3h51m48s)

------
neilk
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".

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

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

Sincerely, an ex-GWT developer.

~~~
cshenoy
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.

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

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

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

------
v13inc
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>

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

<http://jsbin.com/ecejiy/2/edit>

~~~
v13inc
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>?

~~~
v13inc
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

~~~
scottjmiles
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.

~~~
v13inc
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>

------
yareally
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...](http://arstechnica.com/information-
technology/2013/02/internet-explorer-still-growing-as-windows-7-starts-its-
decline/)

[4] <http://mobilehtml5.org/>

------
jhuckabee
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?

~~~
dragonwriter
> 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.

~~~
tosh
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.

------
tjholowaychuk
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!

------
gcr
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: ____"

~~~
dragonwriter
> 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".

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

------
napoleond
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.

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

------
salimmadjd
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.

~~~
ams6110
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.

~~~
purplelobster
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.

~~~
tolmasky
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".

------
stephen
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.

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

<http://www.x-tags.org/>

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

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

------
unwiredben
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/>.

~~~
ganarajpr
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.

------
level09
_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.

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

------
mariusandra
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> :-)

~~~
ebidel
Thanks for the heads up. Fixed through the magic of PRs!
[https://github.com/Polymer/docs/commit/1b9f0c361f84ce0157a13...](https://github.com/Polymer/docs/commit/1b9f0c361f84ce0157a1396ed03336355fba7b7c)

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

~~~
newbie12
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.

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

------
rjd
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?

~~~
bbllee
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.

------
qompiler
Did Google just patent pieces of HTML? Hilarious!

<https://github.com/Polymer/toolkit-ui/blob/master/PATENTS>

------
edwinyzh
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.

------
ams6110
Sounds like Cappuccino?

<http://www.cappuccino-project.org/>

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

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

~~~
bsaul
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.

------
drivebyacct2
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.

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

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

~~~
drivebyacct2
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)

------
andyl
Is related to Angular in any way ??

~~~
chrisfarms
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:

[https://dvcs.w3.org/hg/webcomponents/raw-
file/tip/spec/shado...](https://dvcs.w3.org/hg/webcomponents/raw-
file/tip/spec/shadow/index.html)

[https://dvcs.w3.org/hg/webcomponents/raw-
file/tip/spec/impor...](https://dvcs.w3.org/hg/webcomponents/raw-
file/tip/spec/imports/index.html)

