Polymer, a Web Components library built by Google

by bpierre • 13 years ago

239 117 13 years ago

napoleond• 13 years ago

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• 13 years ago

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

andyl• 13 years ago

Is related to Angular in any way ??

chrisfarms• 13 years ago

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

jasoncartwright• 13 years ago

http://www.polymer-project.org/faq.html#is-this-project-rela...

eldude2• 13 years ago

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

ble• 13 years ago

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.

MatthewPhillips• 13 years ago

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.

scottjmiles2• 13 years ago

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

v13inc5• 13 years ago

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

ender7• 13 years ago

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

_pmf_• 13 years ago

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

Joeri3• 13 years ago

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.

just2n4• 13 years ago

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.

tjholowaychuk3• 13 years ago

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.

ergo14• 13 years ago

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

unwiredben• 13 years ago

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• 13 years ago

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.

rjd• 13 years ago

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?

bbllee2• 13 years ago

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.

randomfool2• 13 years ago

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.

petercooper• 13 years ago

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.

superchink• 13 years ago

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.

bpierre• 13 years ago

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

wmf• 13 years ago

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

chewxy• 13 years ago

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

btilly• 13 years ago

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.

eldude2• 13 years ago

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

dmragone2• 13 years ago

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

ilaksh2• 13 years ago

Similar to AngularJS also a Google project.

dmragone2• 13 years ago

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

randomfool2• 13 years ago

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.

Pxtl3• 13 years ago

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.

bsimpson• 13 years ago

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

neilk2• 13 years ago

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.

mindcrime3• 13 years ago

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.

tosh4• 13 years ago

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.

tosh4• 13 years ago

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:

http://www.dartlang.org/articles/web-ui/

It's like travelling to the future :)

just2n4• 13 years ago

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

neilk2• 13 years ago

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

tjholowaychuk3• 13 years ago

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

tjholowaychuk3• 13 years ago

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!

drivebyacct23• 13 years ago

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

visarga2• 13 years ago

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

drivebyacct23• 13 years ago

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)

jhuckabee• 13 years ago

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?

dragonwriter2• 13 years ago

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

tosh4• 13 years ago

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.

ebidel5• 13 years ago

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

spankalee• 13 years ago

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

drivebyacct23• 13 years ago

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.

v13inc5• 13 years ago

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

ebidel5• 13 years ago

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

v13inc5• 13 years ago

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

Pxtl3• 13 years ago

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.

stephen• 13 years ago

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.

tosh4• 13 years ago

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

visarga2• 13 years ago

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

level09• 13 years ago

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.

salimmadjd2• 13 years ago

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.

ams61102• 13 years ago

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.

salimmadjd2• 13 years ago

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

purplelobster2• 13 years ago

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.

ams61102• 13 years ago

Sounds like Cappuccino?

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

lenkite• 13 years ago

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

kickingvegas2• 13 years ago

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

Sincerely, an ex-GWT developer.

cshenoy• 13 years ago

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.

kickingvegas2• 13 years ago

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

ebidel5• 13 years ago

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

bowyakka• 13 years ago

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

scriptproof• 13 years ago

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• 13 years ago

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.

abhidilliwal• 13 years ago

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

mariusandra• 13 years ago

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

ebidel5• 13 years ago

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

namespace• 13 years ago

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

regularfry• 13 years ago

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

beatpanda• 13 years ago

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

newbie12• 13 years ago

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.

rimantas• 13 years ago

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

jkomoros• 13 years ago

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.

qompiler• 13 years ago

Did Google just patent pieces of HTML? Hilarious!

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

yareally• 13 years ago

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/

gcr2• 13 years ago

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

dragonwriter2• 13 years ago

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

gcr2• 13 years ago

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

edwinyzh• 13 years ago

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.

Polymer, a Web Components library built by Google

Related Stories