6 ms·

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 b

by eldude 13y 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

deleted 13y ago
[deleted]
ble 13y 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 13y 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.
  - dustingetz 13y ago
    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.
    - ibdknox 13y ago
      Light Table is pretty darn fast and that's using the regular old html/js/css we have now. :)
      - bbllee 13y ago
        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.
- scottjmiles 13y ago
  Both the native ShadowDOM implementation in Chrome/Canary and the ShadowDOMPolyfill support reprojection.
v13inc 13y 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 http://www.polymer-project.org/getting-started.html
- ender7 13y ago
  This video of a talk they gave today is a pretty good introduction: https://www.youtube.com/watch?v=0g0oOOT86NY https://www.youtube.com/watch?v=0g0oOOT86NY
  - fatbat 13y ago
    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!
_pmf_ 13y 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.
Joeri 13y 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.
- just2n 13y 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.
  - k__ 13y ago
    > if you think you're being more productive towards building any scale user interfaces with ExtJS, you're doing EVERYTHING wrong. [Citation Needed]
    - just2n 13y ago
      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.
ergo14 13y ago
My first thought when i saw that was: they are reinventing dojotoolkit.

by eldude 13y ago

deleted 13y ago

[deleted]

ble 13y 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 13y 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.
- dustingetz 13y ago
  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.
  - ibdknox 13y ago
    Light Table is pretty darn fast and that's using the regular old html/js/css we have now. :)
    - bbllee 13y ago
      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.
scottjmiles 13y ago
Both the native ShadowDOM implementation in Chrome/Canary and the ShadowDOMPolyfill support reprojection.

v13inc 13y 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 http://www.polymer-project.org/getting-started.html

ender7 13y ago
This video of a talk they gave today is a pretty good introduction: https://www.youtube.com/watch?v=0g0oOOT86NY https://www.youtube.com/watch?v=0g0oOOT86NY
- fatbat 13y ago
  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!

_pmf_ 13y 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.

Joeri 13y 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.

just2n 13y 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.
- k__ 13y ago
  > if you think you're being more productive towards building any scale user interfaces with ExtJS, you're doing EVERYTHING wrong. [Citation Needed]
  - just2n 13y ago
    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.

ergo14 13y ago

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