Hacker News Reader

Comment by eldude | Hacker News Reader

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

View on HN

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

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.

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.

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

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.

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.

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

Reply on news.ycombinator.com