3 ms·

The article talks about being able to integrate into the JavaScript "ecosystem," but for me the excitement of WebAssembly is that I can avoid JavaScript and an

The article talks about being able to integrate into the JavaScript "ecosystem," but for me the excitement of WebAssembly is that I can avoid JavaScript and an object system that is fundamentally unsuitable for anything other than static word-processor-like documents. (Which, to be fair, is what HTML was designed to be.) We know how to write a UI library, I think the basic components are pretty well-defined. Qt and NextStep (surviving to some extent in Cocoa) are well-regarded. Java Swing is okay. So if we could get a real UI library for use in the browser, instead a JavaScript framework poorly re-inventing it, that would be wonderful. And, best of all, it doesn't have to be in JavaScript!

Felz 9y ago
I think bypassing the entire DOM would be ultimately a good thing. There's no real choice in webdev; we are all shackled to a rickety and cobbled together mountain of legacy code. Browsers should always have been a well defined VM with everything else built on top. I'm hoping we can get away from being shackled to what Microsoft, Google, and even Mozilla think is necessary and important for developing software. What we'll lose of course is interoperability. But I think it will be worth it.
- flavio81 9y ago
  You are 100% right.
- kiriakasis 9y ago
  This would fail. > What we'll lose of course is interoperability. But I think it will be worth it. Maybe i misunderstood, but what is the web without interoperability?
ZenPsycho 9y ago
Why does nobody think of accessibility when they indulge in these weird 1980's-style-ui-library-in-a-browser fantasies?
- swsieber 9y ago
  With web assembly you don't have to write a lick of javascript to write a guide in some other language that uses a completely accessible dom tree under the hood, provided your library provides the glue (like the rust library Yew). There's no reason one couldn't wrote a UI frame work like the ones mentioned by the parent that use the dom under the covers.
- hnaccy 9y ago
  The same reason stairs exist.
imtringued 9y ago
Unless you're porting old applications you should always use the native UI toolkit of the platform you're developing for. In this case the UI toolkit is the DOM.

Felz 9y ago

I think bypassing the entire DOM would be ultimately a good thing. There's no real choice in webdev; we are all shackled to a rickety and cobbled together mountain of legacy code. Browsers should always have been a well defined VM with everything else built on top. I'm hoping we can get away from being shackled to what Microsoft, Google, and even Mozilla think is necessary and important for developing software. What we'll lose of course is interoperability. But I think it will be worth it.

flavio81 9y ago
You are 100% right.
kiriakasis 9y ago
This would fail. > What we'll lose of course is interoperability. But I think it will be worth it. Maybe i misunderstood, but what is the web without interoperability?

ZenPsycho 9y ago

Why does nobody think of accessibility when they indulge in these weird 1980's-style-ui-library-in-a-browser fantasies?

swsieber 9y ago
With web assembly you don't have to write a lick of javascript to write a guide in some other language that uses a completely accessible dom tree under the hood, provided your library provides the glue (like the rust library Yew). There's no reason one couldn't wrote a UI frame work like the ones mentioned by the parent that use the dom under the covers.
hnaccy 9y ago
The same reason stairs exist.

imtringued 9y ago

Unless you're porting old applications you should always use the native UI toolkit of the platform you're developing for. In this case the UI toolkit is the DOM.