3 ms·
> The business of rendering static text to a browser is kind of a solved problem. It's everything else that's kind of hard to deal with via a DOM api. WASM is b
by tannhaeuser 6y ago
> The business of rendering static text to a browser is kind of a solved problem. It's everything else that's kind of hard to deal with via a DOM api. WASM is breaking this discussion wide open as suddenly people are porting decades worth of native code to run in a browser.
If it is so hard to layer a coherent and not laughably overcomplicated runtime on top of a document viewer in 20 years, then it follows that it probably wasn't such a good idea to begin with. Unless you're hellbent to freeride on the web's success, and ruining it in the process. At which point we're trying to solve an economic problem (someone else's) via a technical solution.
To get a sense how far of the mark browsers still are, you only have to look into the problem of rich text editing on browsers, which is a natural step up from pure text browsing, and something the first browser did already. Today, this is only barely possible thanks to a couple rich text editor projects who made heroic efforts to work out browser quirks (with contenteditable such that the browser's spellchecking can be leveraged, or alternatively using Canvas/WebGl, essentially developing a browser-in-browser).
In a situation where browser vendors struggle to keep up, adding additional tech such as WASM is the last thing you want to do. When and if WASM gets even basic language infrastructure such as gc, DOM or WebGl bindings, or anything even mildly interesting, then it'll immediately become another maintenance problem. And as you said yourself, at best WASM can help port apps over to a browser. It's however not clear what the purpose of that exercise should be when said apps run just fine outside the browser. I'd say if there were indeed so many apps waiting to be ported over to running in the browser, then there have been sufficiently sophisticated transpilers for like 15 years now (emscripten, gwt, many others), so I'm not buying that as an argument to make browsers even more complex.
- sergeykish 6y agoYou are not in charge. If contenteditable is such a nuisance you can fix it, fill bugs and help with triage. I've been recently playing with it. There are so many bugs like noone use it. A lot of people want WASM and drive it. It is not zero sum game. There already several tiers of the browsers. Top tier opens competition with native/mobile. This may be huge - Windows, Mac, *nix, iOS, Android - universal application without walled garden. Next tier works with mostly static content - NetSurf and Dillo. Dillo is fast, no need to throw away web. Any open source browser has entire history - pull and compile. First Mozilla check in is before Gecko - Layout Classic [1]. It is not browsers who ruins experience but authors. I browse without JS, it works. [1] https://github.com/sergeykish/gecko-dev/tree/init/lib/layout https://github.com/sergeykish/gecko-dev/tree/init/lib/layout