> What I'm curious is why the platforms don't adapt to how the developers have found works best?
Here's my take:
- The web was visualized as a way to publish academic documents in a hyperlinked document system. Librarians and academics live in this world. We hear the word "semantic" from them a lot.
- The visual web was visualized as a way to publish documents that had a precise look. Graphic designers live in this world. They don't care about semantics. They do care about pixel perfect layouts and cool effects.
- The web app was visualized as a way to deliver software to users with lazy, "click link to install"-like behavior. What this crowd cares about is providing server functionality to users, and other concerns like semantics or pixel perfect are often secondary.
- The single page web app is also visualized as as a way to deliver software to users with lazy, "click link to install"-like behavior. They differ from the web app group in that they try to have more server functionality right in the client. Again semantics and pixel perfect are secondary. App complexity is a big problem that this group contends with, and this is what the article discusses.
Given these different ways of visualizing the web (and I'm sure I've left a few out), it's no wonder that we're stuck with the mess that is today's web development. The right solution is a sensible runtime for app development, that doesn't force you to render UI through the DOM and doesn't make it hard for you to get access to basic things like the local file system. We've known this forever (anyone remember Flash?).
WASM feels like it might finally allow app developers to do all of the software things that native platform developers get to do easily, and with the added bonus of strong sandboxing. It's early days yet, I think the "Ruby on Rails"-moment has not yet arrived there yet, i.e. a very popular, easy way for devs to create whatever app-de-jour everyone's excited about.
But WASM is weirdly allergic to the DOM and to javascript. The core, fundamental interfaces are terrible and highly disputed, so it will be restricted to mainly-WASM apps for some time.
That’s only a problem if your goal is to keep on doing the same old web apps the same old way, just delegating part of the program logic to WASM which, I agree, will be more complicated. But if you’re going to use WASM why limit yourself to using the DOM and JavaScript? Why not use a programming environment that lets you use more sophisticated tools?
Here's my take:
- The web was visualized as a way to publish academic documents in a hyperlinked document system. Librarians and academics live in this world. We hear the word "semantic" from them a lot.
- The visual web was visualized as a way to publish documents that had a precise look. Graphic designers live in this world. They don't care about semantics. They do care about pixel perfect layouts and cool effects.
- The web app was visualized as a way to deliver software to users with lazy, "click link to install"-like behavior. What this crowd cares about is providing server functionality to users, and other concerns like semantics or pixel perfect are often secondary.
- The single page web app is also visualized as as a way to deliver software to users with lazy, "click link to install"-like behavior. They differ from the web app group in that they try to have more server functionality right in the client. Again semantics and pixel perfect are secondary. App complexity is a big problem that this group contends with, and this is what the article discusses.
Given these different ways of visualizing the web (and I'm sure I've left a few out), it's no wonder that we're stuck with the mess that is today's web development. The right solution is a sensible runtime for app development, that doesn't force you to render UI through the DOM and doesn't make it hard for you to get access to basic things like the local file system. We've known this forever (anyone remember Flash?).
WASM feels like it might finally allow app developers to do all of the software things that native platform developers get to do easily, and with the added bonus of strong sandboxing. It's early days yet, I think the "Ruby on Rails"-moment has not yet arrived there yet, i.e. a very popular, easy way for devs to create whatever app-de-jour everyone's excited about.