[scrollaway]

> So web apps can't have reusable components now?

I'm not saying they can't, I'm saying they don't. You go ahead and try to fix that, create widget#772981 that still won't support typed-selection, or will break with large text or what not... I've seen too many of those, most of them bad, and none of them standard. So far, React is the only thing that even comes close to a sane model for a contender to UI development on the desktop, and it still mostly fails the accessibility checkbox.

> WebAssembly will take over for web apps eventually.

More eventualism. Do you have evidence for that? Do you even have evidence that it'll be better than what we have now in other languages if it does take over?

> UX knowledge isn't toolkit dependent

A lot of it is. You'd be surprised just how much UX is crammed into Qt Widgets for example. Years of experience making them more accessible, more usable, more consistent with the platform they're running on, etc.

[ZenoArrow]

> "I'm not saying they can't, I'm saying they don't."

They already do. Electron, Web Components, etc...

> "Do you even have evidence that it'll be better than what we have now in other languages if it does take over?"

Compare the performance of vanilla JS vs. asm.js. It is clear from what developers have stated that WebAssembly performance will exceed the performance of asm.js, the threading improvements alone should offer noticeable benefits.

> "Years of experience making them more accessible, more usable, more consistent with the platform they're running on, etc."

So what are we looking at to replicate that? A theme per platform? Some accessibility work? What else?

It should be noted that the web isn't starting from zero with UX either, we've already had 20+ years of refinements to the web user experience.

[scrollaway]

> They already do. Electron, Web Components, etc...

And nobody can agree on which to use. It's not standard if it's just "some set of components some people reuse". A far cry from standardization.

> Compare the performance of vanilla JS vs. asm.js.

That's not what I'm comparing. I'm comparing the performance of native toolkits vs web toolkits on asm.js. It pales in comparison, and the battery usage is through the roof. ymmv?

> So what are we looking at to replicate that?

1. Standardization of components (developer does not have to build their own scrolling system, context menu, etc) 2. Themability of components at the application level (developer can style components not to clash with the style of the application) 3. Themability of components at the platform level (user can style the application not to clash with the style of their own desktop) 4. Performance needs to shoot way, way up. Apps can't rely on a performant GPU, it's unreasonable to ask that of every device at this point in time. Some day maybe every device will come with their own high performance GPU, but eventualism cannot excuse bad coding practices and unnecessary layering.

The rest should follow. But I still don't see us getting any of those things, any time soon. These are not easy problems to solve.

[ZenoArrow]

> "And nobody can agree on which to use. It's not standard if it's just "some set of components some people reuse". A far cry from standardization."

Atom uses Electron, VS Code uses Electron, Light Table uses Electron (starting with v0.8).

As for the web side, web apps are a young field, what else would you expect?

There are certainly popular UI elements, Bootstrap for example.

If you want to make an web app that looks native, using React Native could be a good solution.

[mwcampbell]

An app based on React Native isn't a web app anymore. But it's not quite native either; it doesn't use the native button and list view controls on either iOS or Android.