Polymer, a Web Components library built by Google
polymer-project.org
polymer-project.org
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
From the sound of it, they are good enough that future is already here-- except for some glaring exceptions like shadow DOM re-projections.
Again? There sure seem to be a lot of futures for the UI in the browser.
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.
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.
[Citation Needed]
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.
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.
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.
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.
In the meantime, I'm quite excited by the idea of web-components, though the implementation is staggeringly unpleasant to look at.
- 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.
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.
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.
<select id = 'menu'>
<option />
...
</select>
<x-item-editor item_key = "{{ menu.value }}"/>
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.
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.
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.
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 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.
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.
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.
:)
http://www.dartlang.org/articles/web-ui/
It's like travelling to the future :)
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...
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.
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/
[3] http://jacquesmattheij.com/How+to+make+the+Hacker+News+homep...
I'm not bothered so much by reposts though I wonder if that was a factor too, attaching brand names
[1] https://developers.google.com/events/io/sessions/324149970
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".
Sincerely, an ex-GWT developer.
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.
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".
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.
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>?
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
> <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
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...
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.
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.
The basics of using Polymer are simple:
1. Load platform.js to polyfill missing platform features, such as Shadow DOM and HTML Imports.
...
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: ____"
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".
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".
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.
Looks like we'll get actual browser support for Web Components eventually :)
I dont know why, but I really found step 4 very funny at this point.
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?
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.
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)
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shado...
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/impor...