6 ms·

This is going to be slightly off-topic. I'm mostly a "backend" dev (C/Java, server side things) that recently had to do some frontend dev again after about 4 y

This is going to be slightly off-topic. I'm mostly a "backend" dev (C/Java, server side things) that recently had to do some frontend dev again after about 4 years. The last time I did this jQuery/Bootstrap was the trend. So this time I played with React for about a month, then went to Angular (coincidently starting with React components and being an Angular virgin made me think of making everything isolated-scope directives in Angular). So the problem for me was not React being bad or Angular better but at the end of the day it has to do with: As a non-fulltime webdev I need a _complete_ widget/component library available for when I want to build my apps. With React I felt like I was constantly either having to look for components that kind-of/sort-of worked for me but had some short falls or I had to build them from scratch. Then there's the look and feel so you're either looking for components that are Bootstrap ready or Material Design-ish, etc. Even then, you take Angular Material: it's not there yet. Go to the website. That side-nav menu they have going is really nice. I wanted to use that in my app. Is that an MD component? Nope. It's a hacked together mess of custom things. Talk about "eating your own dog food". Is this common place in the web world right now? Regardless of choosing React/Angular/whatever. I mean I'm used to QT. There's a widget for just about anything. You just wire up your events and you have an app. It seems like the web world is slowly just going to end up reinventing Delphi at the end of the day when I look at things like Polymer (why has it taken so long?) All these frameworks are great but can we please just work on having feature-rich components/widgets now. And maybe keep them maintained for the next 5 years or so?

vbezhenar 11y ago
I had the impression that React's primary audience is developers who want full control over resulting DOM. While custom components are possible, you are expected to write your HTML, not wire up things and be done. You might want to check more enterprisy frameworks like extjs.
- mercer 11y ago
  Currently that's the case, but I'd say React is a very good candidate for good component-based solutions; they're just not here yet. One of the reasons I've seriously been considering React for even a lot of back-end stuff is that it's really easy to create an isolated component that combines markup, styling and behavior. Once done, I can simply require() the component on either the back- or front-end, or both, and reuse the component in other projects. Granted, for styling there's still no solution that I consider optimal, but the advantages might be worth the 'impurity' of it all. And solutions are being worked on. And granted, there are other initiatives like Web Components that are hopeful. But already now React is a great option if you want to create 'independent' and re-usable components. I think it's just a matter of time before a proper, popular component-ecosystem arrives, and what with React Native, there might even be some degree of 'unification' across platforms. That's assuming we won't abandon React en masse and switch to another even cooler solution in a few years, though :-/.
edoloughlin 11y ago
All these frameworks are great but can we please just work on having feature-rich components/widgets now. And maybe keep them maintained for the next 5 years or so? No. This is the web. We must reinvent everything every 5 minutes.
abritinthebay 11y ago
You're not looking to do web development - you're looking for a pre-assembled UI library. React isn't that. That's fine - it's not supposed to be. Hell Angular isn't that... but as it's a framework (React really isn't it's a View library) it has more of that. Angular + Bootstrap probably does most of what you would want... ... but it's an extremely narrow need. Not a general case.
- laichzeit0 11y ago
  It could very well be that I've completely misunderstood the intention of these frameworks then. I was under the impression that at the end of the day you're creating either React components and/or Angular directives when you're building a web application. And the particular framework takes care of how the view changes when the model changes, it provides you with some abstractions like Resources (to talk to REST APIs) and Routers (for navigation). Even when you look at ExtJS I don't see why they couldn't provide ReactExtJS or AngularExtJS by just wrapping their widgets so that you're either creating them with "props" or by specifying the initial "scope" if you're doing it Angular directives, for example. Creating standardized widgets which can be "wrapped" to expose a React (prop/state) or Angular (isolated scope directive) style interface, and then "skinned" (Bootstrap or Material Design or whatever) I would have thought would be the logical thing to do. As another poster commented, perhaps this is what people are calling "Components"? However, I'm pretty sure it could be done right now with what we currently have. If you say it's an extremely narrow need, I understand because typically I end up facing problems no one else seem to have :)
  - k__ 11y ago
    The problem with these front-end frameworks is, that they don't have the same scope. ExtJS is probably the most QT-like web-framework. I like your idea of writing generic code and then expose it to Angular/React/Ember. Including something like Backbone/JQuery would probably be harder, since it uses direct DOM manipulation. But those other frameworks have livecycle-hooks that get called when a component is rendered and have to provide the framework with virtual-dom/handlebars/etc.-templates that get injected at the right position. Since A/R/E don't have their own CSS (contrary to ExtJS) the styling code could be generic too (which it already is in most web-apps, with the help of Bootstrap).
robwormald 11y ago
Its interesting you use the word "component" about ten times in this post, because that's more or less exactly what Web Components are about - a set of specifications that will (hopefully/theoretically) lead to much greater interop between all this stuff. Polymer is one of the first implementations of a library built on this spec. Keep in mind though, the environment QT runs in is very different to the web, so most of us poor web devs are at the mercy of browser vendors, and as such we're often limited by the lowest common denominator.
pingec 11y ago
http://docs.telerik.com/kendo-ui/AngularJS/introduction http://docs.telerik.com/kendo-ui/AngularJS/introduction
mhd 11y ago
One of the key differences between even modern web SPAs and traditional desktop GUIs is that there's no unified look, and often not even a unified feel. Actually, having something that looks exactly like something else is often seen as a detriment, just read some discussions about how "bad" Bootstrap is... (and if it isn't a webview, the same is often true for Material Design) So a lot of the work that traditionally went into widget/VCLs/etc. is immediately not necessary and probably even unwanted. You basically have to reivent large parts of the wheel anyway. The rest is often largely component-independent, mostly event handling and data binding. So a very generic component often wouldn't help you that much, which is why a lot of the MVC libraries and frameworks available often seem to "skip" that part. One noticeable exception is ExtJS, which seems the single remaining major toolkit aiming at desktop-like applications. There you've got your standard FormPanels, GridEditors and AbstractSelectionModels. There the tables turn, and HTML/CSS is often just used as the totally abstracted away presentation layer, and you just arrange widgets in JavaScript. That means a considerable payload, and more problems if you actually need to have something more "web-like" (boy, the horror of XTemplate). For enterprise/intranet apps this matters less, of course. Which is why Ext is still rather common there and why they can afford to actually demand money for their library, despite all the competition. But again, you probably wouldn't build gmail/instagram/facebook with Ext.
- herval 11y ago
  Ironically, the vast majority of the sites look exactly the same (just like mobile and desktop apps - although these tend to have visual guidelines to stick to)...
tangue 11y ago
Unless you're working on a big project you should stick with Jquery / Jquery UI. I suspect in a year or two React will come close to what you want.
- collyw 11y ago
  Downvoted for a sensible pragmatic suggestion?
coldtea 11y ago
>having to look for components that kind-of/sort-of worked for me but had some short falls or I had to build them from scratch This thing will never change, whether with React or Angular. Web dev, due to custom design of pages, is not like using native (Cocoa, Windows Forms etc) widgets where one-size-fits-all. It's more like native apps with custom skins and widgets.
paulojreis 11y ago
> All these frameworks are great but can we please just work on having feature-rich components/widgets now. And maybe keep them maintained for the next 5 years or so? We "can", and maybe there are already quit a few. However, the thing about UI is that it's more than the sum of its parts; experience is holistic, and a UI should be conceived as a whole, not as something assembled by common components. This is fundamentally a difference between disciplines. As a developer, you'll think that reusable and isolated/modular widgets are the way to go; a UI designer, on the other hand (and not forgetting consistency), will/should(!) adapt the UI to its users and contexts.
girvo 11y ago
That exists, for vary degrees of "exists" anyway. all the good ones are commercial products for the most part. One of the nicer ones I've used is Webix: http://webix.com http://webix.com
herval 11y ago
Same background here, same frustration with Javascript frontend in general. I've been through projects that started in pure Jquery, went to Backbonejs, have a bit of Ember sprinkled at some pages, AngularJs for the most part and are not adopting React. The Javascript ecosystem is just insane...
tracker1 11y ago
I'd suggest starting with Redux[1], React, redux-react-router[2], MaterialUI[3] and Webpack[4]... in terms of the React ecosystem... it's a little bleeding edge, but a good place to start. [1] https://docs.reduxframework.com/core/getting-started/ https://docs.reduxframework.com/core/getting-started/ [2] https://github.com/acdlite/redux-react-router https://github.com/acdlite/redux-react-router [3] http://material-ui.com/ http://material-ui.com/ [4] https://github.com/erikras/react-redux-universal-hot-example/ https://github.com/erikras/react-redux-universal-hot-example...
- mattwoodnyc 11y ago
  In React, Redux as a container for "state". I think your first link is incorrect, and should instead be: http://rackt.github.io/redux/ http://rackt.github.io/redux/
  - tracker1 11y ago
    You are correct, my bad... I was only up for about 25 hours at that point... still up, and really in need of a nap soon.
untothebreach 11y ago
I found Semantic UI 2[1] to be a pretty good collection of components that I could just drop in to a project. I am also a backend person, and found it to be pretty easy to compose widgets into exactly the configuration I needed. 1: http://semantic-ui.com/ http://semantic-ui.com/
marknutter 11y ago
It's a mess, I agree, but it's something that Web Components are supposed to solve. You can really think of React, Angular, Ember, jQuery Widgets, etc. as poor polly-fills for Web Components; poor because they don't interop with each other easily (which is the pain you were experiencing). With Web Components, people can author components and anyone else can use them just like they would any built-in tag like <input> and <video>. This will give you exactly what you're wanting, which is a Bootstrap or Material Design implementation that you include in your project and instantly expand your library of DOM elements. The problem with React is that the core team has explicitly stated that they are not worried about compatibility with Web Components, so if you stick with that framework over the long term you may find yourself shut out of that bright future. The Angular team re-wrote their framework mainly because they wanted to be compatible with the upcoming Web Components spec. So, yes, it's a mess, but it's about to get a lot better. Hop over to https://www.polymer-project.org/1.0/ https://www.polymer-project.org/1.0/ to get a glimpse of things to come.
- spankalee 11y ago
  Interop isn't just an issue between components, but an issue between the browser and components, crawlers and components, and of course all the thousands of JS libraries out there. What's great about Web Components is that they don't need custom developer tools. The DOM tree _is_ your component tree, the browser naturally highlights custom elements, just like built-in elements. Editing the DOM and CSS just works. Placing an element into a temp variable and setting properties just works.
grayrest 11y ago
I've thought about why widget libraries don't work on the web since 2008. In 2007 I was making iOS webapps, in 2008 Apple put out the SDK and the native apps were better. I decided that the native apps were better because the devs didn't blow 60% of their time budget building a poor, custom widget library. The problems I've encountered: The first and most basic is that the expectation on the web is that every project will have a unique look and feel. This greatly limits the adoption of frameworks based on desktop widget library concepts (dojo, ext, sencha, cappuccino, sproutcore). The times I've used these frameworks, I spend as much time fighting the look and feel as I would building an interface from scratch. This isn't a problem if you're look and feel insensitive and desktop style widget libraries do get picked up for internal corporate apps. The second problem is size. The need to download everything, desire for reduced page load times, and lack of dead code elimination has historically made web devs more sensitive to the size of their libraries. This was a problem for libraries like YUI2, which had excellent components that simply had an option for anything somebody at yahoo wanted but adding a new widget would frequently add hundreds of K to the download. This is a reduced concern with the increased capabilities of mobile and I believe that the combination of HTTP2, having a standard module system, increased tooling (e.g. webpack), universal/isomorphic JS, and ServiceWorker provide the means to more or less eliminate this as a core problem. The third problem is CSS. The language provides no tools for abstraction when the target markup (your widget) is fixed. Happily, this problem is solved via sass. You can separate style concerns into mixins (or placeholders) and compose them into either widget or instance specific rules and avoid the cascade. The fourth problem is component composition. In order to get more code reuse, you need to be able to build up bigger widgets from small pieces and then make a lot of useful small pieces. Stateful components don't compose particularly well and I've spent a lot of time on this (in yui3, knockout, and angular) before I found React's virtual dom approach two years ago. With the vdom, it's possible to view components as functions projecting state onto a virutal DOM. Composition can then be solved by creating higher order components and using normal functional programming composition and code reuse. With care put in to how larger components are designed, it's possible (I've done it) to swap out sub components to customize behavior on a per-instance basis. I consider the core problem solved but I haven't seen the equivalent of an underscore for react components yet. The fifth problem is widget interaction. I define widgets as components that are an isolated concern (and generally maintain internal state): Autocomplete instead of FooList. Since the components are generally stateful and produce events, you have to have a protocol for having them interact with each other and the rest of the app. As an example, a FOO widget is a React component has PropTypes that get compiled into a Falcor query and all its event handlers call a function `dispatch` with an object shaped like X. Everybody comes up with this in their app but without a consensus on what the approach is, everybody's widget libraries are parochial. This is an active area of development and Web Components is Google's take on the problem. Facebook is also very interested in this with Flux/GraphQL. Once all the problems are solved (I believe we're relatively close) then we should see widget libraries come into their own. I'm estimating about 3 years before someone starts really winning the widget library battle and we get a "standard" set of widgets you're looking for. I believe that something from the React or Ember communities are the likely source and Polymer has an outside chance (I don't see how component composition works in Polymer).
UserRights 11y ago
If you need a pragmatic, complete and battle-tested gui kit for a business app, look at http://sap.github.io/openui5/ http://sap.github.io/openui5/

vbezhenar 11y ago

I had the impression that React's primary audience is developers who want full control over resulting DOM. While custom components are possible, you are expected to write your HTML, not wire up things and be done. You might want to check more enterprisy frameworks like extjs.

mercer 11y ago
Currently that's the case, but I'd say React is a very good candidate for good component-based solutions; they're just not here yet. One of the reasons I've seriously been considering React for even a lot of back-end stuff is that it's really easy to create an isolated component that combines markup, styling and behavior. Once done, I can simply require() the component on either the back- or front-end, or both, and reuse the component in other projects. Granted, for styling there's still no solution that I consider optimal, but the advantages might be worth the 'impurity' of it all. And solutions are being worked on. And granted, there are other initiatives like Web Components that are hopeful. But already now React is a great option if you want to create 'independent' and re-usable components. I think it's just a matter of time before a proper, popular component-ecosystem arrives, and what with React Native, there might even be some degree of 'unification' across platforms. That's assuming we won't abandon React en masse and switch to another even cooler solution in a few years, though :-/.

edoloughlin 11y ago

All these frameworks are great but can we please just work on having feature-rich components/widgets now. And maybe keep them maintained for the next 5 years or so? No. This is the web. We must reinvent everything every 5 minutes.

abritinthebay 11y ago

You're not looking to do web development - you're looking for a pre-assembled UI library. React isn't that. That's fine - it's not supposed to be. Hell Angular isn't that... but as it's a framework (React really isn't it's a View library) it has more of that. Angular + Bootstrap probably does most of what you would want... ... but it's an extremely narrow need. Not a general case.

laichzeit0 11y ago
It could very well be that I've completely misunderstood the intention of these frameworks then. I was under the impression that at the end of the day you're creating either React components and/or Angular directives when you're building a web application. And the particular framework takes care of how the view changes when the model changes, it provides you with some abstractions like Resources (to talk to REST APIs) and Routers (for navigation). Even when you look at ExtJS I don't see why they couldn't provide ReactExtJS or AngularExtJS by just wrapping their widgets so that you're either creating them with "props" or by specifying the initial "scope" if you're doing it Angular directives, for example. Creating standardized widgets which can be "wrapped" to expose a React (prop/state) or Angular (isolated scope directive) style interface, and then "skinned" (Bootstrap or Material Design or whatever) I would have thought would be the logical thing to do. As another poster commented, perhaps this is what people are calling "Components"? However, I'm pretty sure it could be done right now with what we currently have. If you say it's an extremely narrow need, I understand because typically I end up facing problems no one else seem to have :)
- k__ 11y ago
  The problem with these front-end frameworks is, that they don't have the same scope. ExtJS is probably the most QT-like web-framework. I like your idea of writing generic code and then expose it to Angular/React/Ember. Including something like Backbone/JQuery would probably be harder, since it uses direct DOM manipulation. But those other frameworks have livecycle-hooks that get called when a component is rendered and have to provide the framework with virtual-dom/handlebars/etc.-templates that get injected at the right position. Since A/R/E don't have their own CSS (contrary to ExtJS) the styling code could be generic too (which it already is in most web-apps, with the help of Bootstrap).

robwormald 11y ago

Its interesting you use the word "component" about ten times in this post, because that's more or less exactly what Web Components are about - a set of specifications that will (hopefully/theoretically) lead to much greater interop between all this stuff. Polymer is one of the first implementations of a library built on this spec. Keep in mind though, the environment QT runs in is very different to the web, so most of us poor web devs are at the mercy of browser vendors, and as such we're often limited by the lowest common denominator.

pingec 11y ago

http://docs.telerik.com/kendo-ui/AngularJS/introduction http://docs.telerik.com/kendo-ui/AngularJS/introduction

mhd 11y ago

One of the key differences between even modern web SPAs and traditional desktop GUIs is that there's no unified look, and often not even a unified feel. Actually, having something that looks exactly like something else is often seen as a detriment, just read some discussions about how "bad" Bootstrap is... (and if it isn't a webview, the same is often true for Material Design) So a lot of the work that traditionally went into widget/VCLs/etc. is immediately not necessary and probably even unwanted. You basically have to reivent large parts of the wheel anyway. The rest is often largely component-independent, mostly event handling and data binding. So a very generic component often wouldn't help you that much, which is why a lot of the MVC libraries and frameworks available often seem to "skip" that part. One noticeable exception is ExtJS, which seems the single remaining major toolkit aiming at desktop-like applications. There you've got your standard FormPanels, GridEditors and AbstractSelectionModels. There the tables turn, and HTML/CSS is often just used as the totally abstracted away presentation layer, and you just arrange widgets in JavaScript. That means a considerable payload, and more problems if you actually need to have something more "web-like" (boy, the horror of XTemplate). For enterprise/intranet apps this matters less, of course. Which is why Ext is still rather common there and why they can afford to actually demand money for their library, despite all the competition. But again, you probably wouldn't build gmail/instagram/facebook with Ext.

herval 11y ago
Ironically, the vast majority of the sites look exactly the same (just like mobile and desktop apps - although these tend to have visual guidelines to stick to)...

tangue 11y ago

Unless you're working on a big project you should stick with Jquery / Jquery UI. I suspect in a year or two React will come close to what you want.

collyw 11y ago
Downvoted for a sensible pragmatic suggestion?

coldtea 11y ago

>having to look for components that kind-of/sort-of worked for me but had some short falls or I had to build them from scratch This thing will never change, whether with React or Angular. Web dev, due to custom design of pages, is not like using native (Cocoa, Windows Forms etc) widgets where one-size-fits-all. It's more like native apps with custom skins and widgets.

paulojreis 11y ago

> All these frameworks are great but can we please just work on having feature-rich components/widgets now. And maybe keep them maintained for the next 5 years or so? We "can", and maybe there are already quit a few. However, the thing about UI is that it's more than the sum of its parts; experience is holistic, and a UI should be conceived as a whole, not as something assembled by common components. This is fundamentally a difference between disciplines. As a developer, you'll think that reusable and isolated/modular widgets are the way to go; a UI designer, on the other hand (and not forgetting consistency), will/should(!) adapt the UI to its users and contexts.

girvo 11y ago

That exists, for vary degrees of "exists" anyway. all the good ones are commercial products for the most part. One of the nicer ones I've used is Webix: http://webix.com http://webix.com

herval 11y ago

Same background here, same frustration with Javascript frontend in general. I've been through projects that started in pure Jquery, went to Backbonejs, have a bit of Ember sprinkled at some pages, AngularJs for the most part and are not adopting React. The Javascript ecosystem is just insane...

tracker1 11y ago

I'd suggest starting with Redux[1], React, redux-react-router[2], MaterialUI[3] and Webpack[4]... in terms of the React ecosystem... it's a little bleeding edge, but a good place to start. [1] https://docs.reduxframework.com/core/getting-started/ https://docs.reduxframework.com/core/getting-started/ [2] https://github.com/acdlite/redux-react-router https://github.com/acdlite/redux-react-router [3] http://material-ui.com/ http://material-ui.com/ [4] https://github.com/erikras/react-redux-universal-hot-example/ https://github.com/erikras/react-redux-universal-hot-example...

mattwoodnyc 11y ago
In React, Redux as a container for "state". I think your first link is incorrect, and should instead be: http://rackt.github.io/redux/ http://rackt.github.io/redux/
- tracker1 11y ago
  You are correct, my bad... I was only up for about 25 hours at that point... still up, and really in need of a nap soon.

untothebreach 11y ago

I found Semantic UI 2[1] to be a pretty good collection of components that I could just drop in to a project. I am also a backend person, and found it to be pretty easy to compose widgets into exactly the configuration I needed. 1: http://semantic-ui.com/ http://semantic-ui.com/

marknutter 11y ago

It's a mess, I agree, but it's something that Web Components are supposed to solve. You can really think of React, Angular, Ember, jQuery Widgets, etc. as poor polly-fills for Web Components; poor because they don't interop with each other easily (which is the pain you were experiencing). With Web Components, people can author components and anyone else can use them just like they would any built-in tag like <input> and <video>. This will give you exactly what you're wanting, which is a Bootstrap or Material Design implementation that you include in your project and instantly expand your library of DOM elements. The problem with React is that the core team has explicitly stated that they are not worried about compatibility with Web Components, so if you stick with that framework over the long term you may find yourself shut out of that bright future. The Angular team re-wrote their framework mainly because they wanted to be compatible with the upcoming Web Components spec. So, yes, it's a mess, but it's about to get a lot better. Hop over to https://www.polymer-project.org/1.0/ https://www.polymer-project.org/1.0/ to get a glimpse of things to come.

spankalee 11y ago
Interop isn't just an issue between components, but an issue between the browser and components, crawlers and components, and of course all the thousands of JS libraries out there. What's great about Web Components is that they don't need custom developer tools. The DOM tree _is_ your component tree, the browser naturally highlights custom elements, just like built-in elements. Editing the DOM and CSS just works. Placing an element into a temp variable and setting properties just works.

grayrest 11y ago

I've thought about why widget libraries don't work on the web since 2008. In 2007 I was making iOS webapps, in 2008 Apple put out the SDK and the native apps were better. I decided that the native apps were better because the devs didn't blow 60% of their time budget building a poor, custom widget library. The problems I've encountered: The first and most basic is that the expectation on the web is that every project will have a unique look and feel. This greatly limits the adoption of frameworks based on desktop widget library concepts (dojo, ext, sencha, cappuccino, sproutcore). The times I've used these frameworks, I spend as much time fighting the look and feel as I would building an interface from scratch. This isn't a problem if you're look and feel insensitive and desktop style widget libraries do get picked up for internal corporate apps. The second problem is size. The need to download everything, desire for reduced page load times, and lack of dead code elimination has historically made web devs more sensitive to the size of their libraries. This was a problem for libraries like YUI2, which had excellent components that simply had an option for anything somebody at yahoo wanted but adding a new widget would frequently add hundreds of K to the download. This is a reduced concern with the increased capabilities of mobile and I believe that the combination of HTTP2, having a standard module system, increased tooling (e.g. webpack), universal/isomorphic JS, and ServiceWorker provide the means to more or less eliminate this as a core problem. The third problem is CSS. The language provides no tools for abstraction when the target markup (your widget) is fixed. Happily, this problem is solved via sass. You can separate style concerns into mixins (or placeholders) and compose them into either widget or instance specific rules and avoid the cascade. The fourth problem is component composition. In order to get more code reuse, you need to be able to build up bigger widgets from small pieces and then make a lot of useful small pieces. Stateful components don't compose particularly well and I've spent a lot of time on this (in yui3, knockout, and angular) before I found React's virtual dom approach two years ago. With the vdom, it's possible to view components as functions projecting state onto a virutal DOM. Composition can then be solved by creating higher order components and using normal functional programming composition and code reuse. With care put in to how larger components are designed, it's possible (I've done it) to swap out sub components to customize behavior on a per-instance basis. I consider the core problem solved but I haven't seen the equivalent of an underscore for react components yet. The fifth problem is widget interaction. I define widgets as components that are an isolated concern (and generally maintain internal state): Autocomplete instead of FooList. Since the components are generally stateful and produce events, you have to have a protocol for having them interact with each other and the rest of the app. As an example, a FOO widget is a React component has PropTypes that get compiled into a Falcor query and all its event handlers call a function `dispatch` with an object shaped like X. Everybody comes up with this in their app but without a consensus on what the approach is, everybody's widget libraries are parochial. This is an active area of development and Web Components is Google's take on the problem. Facebook is also very interested in this with Flux/GraphQL. Once all the problems are solved (I believe we're relatively close) then we should see widget libraries come into their own. I'm estimating about 3 years before someone starts really winning the widget library battle and we get a "standard" set of widgets you're looking for. I believe that something from the React or Ember communities are the likely source and Polymer has an outside chance (I don't see how component composition works in Polymer).

UserRights 11y ago

If you need a pragmatic, complete and battle-tested gui kit for a business app, look at http://sap.github.io/openui5/ http://sap.github.io/openui5/