5 ms·
Why won't it happen? If wasm can talk to the DOM, then you'll still be using HTML and CSS, and wasm in place of JS. There's no reason this couldn't be done alre
by wtetzner 10y ago
Why won't it happen? If wasm can talk to the DOM, then you'll still be using HTML and CSS, and wasm in place of JS. There's no reason this couldn't be done already by just compiling to JS, and plenty of languages already do that.
You could also render everything to a canvas to avoid HTML and CSS, but at that point there are a lot of things to re-implement, especially around accessibility.
- oblio 10y agoWell, first of all wasm needs to be implemented in all major browsers on all major platforms for it to be widely adopted. Since the major browser vendors are backing it, that should happen quite soon. But that's just the initial implementation. It needs to be implemented fully, debugged, optimized and then it needs to trickle down to user devices, including those sold 3-4-5 years ago and still in use. And then, in the second stage, wasm needs to get DOM access (as far as I know v1 won't have it). See stage 1, all over again. I'd say that the mass adoption cycle for 1 stage is roughly 5 years (where 80%+ of the browsers out there support a major feature well). So 2 stages x 5 years = 10 years. Maybe I'm too pessimistic...
- dbaupp 10y agoGiven the history of the web and what I know of the people/companies behind wasm, it seems very likely that there'll be a graceful degradation/shim in the form of a wasm interpreter written in JS/asm.JS (or even a JIT from wasm to one of them), so there'll be no need to wait for all browsers to have implemented it, it just won't live up to its performance on all platforms.
- markdog12 10y agoThere already is: https://github.com/lukewagner/polyfill-prototype-1 https://github.com/lukewagner/polyfill-prototype-1
- vanviegen 10y agoI think you are being too pessimistic about the speed of mass adoption. On the desktop: Firefox, Chrome and Edge auto-update. On mobile: Android 4.4+ (over 80% and rising fast) auto-updates its webview component. iOS receives yearly updates that are applied by a very large majority - though Apple's browser development does seem to have stagnated a bit. So it seems to me that non-updating browsers are going extinct, and that we won't be dealing with another IE6 anytime soon. We're living in the future! :-)
- Freak_NL 10y agoThe age of the evergreen-browsers is dawning. Although it will be years before the last corporate holdouts let go of their pinned IE9/IE10/IE11 browsers.
- mcbits 10y agoWhy is 80% the magic number? 5% would reach more than 100 million people. That's enough to keep a team busy and a product growing while the competition sits on its butt waiting for the next 75%.
- themihai 10y agoThere is a shim so you don't need to wait for all the browsers to implement wasm
- rubber_duck 10y agoI hate JS but replacing it with Rust for front end is a bad idea, Rust is a low level systems programming language, it's very suboptimal for high level front end code from productivity standpoint and it adds no value because it's advantages (mem safety with 0 cost abstractions) don't really matter in frontend (JS is super bad at being optimizable but it's still more than sufficiently fast).
- Manishearth 10y agomemory safety isn't the only advantage. 0 cost abstractions do matter a bit. In general abstractions let you do high level programming in lower level languages. The type system matters a lot. I used to do a lot of scripting. One thing I really missed was having a good static type system. These days I miss ADT enums in all languages. Scripting is already moving in the direction of being more type safe (typescript, python type annotations), which is awesome, but I'd love to use something like Rust in that sphere.
- adwhit 10y agoRust is indeed known for memory safety and zero cost abstractions. But there is another side to Rust which is even more interesting - a type system that is almost as powerful as those of functional languages like OCaml and Haskell, but wrapped in approachable imperative syntax. With such a type system, it is possible to encode the invariants of your application in types (using generics and algebraic data types). Then you can get very close to "if it compiles, it works". JS, in particular, is the opposite. I am never really convinced that any JS I have written is "correct". It works, until one day it doesn't. This is such a problem that there have been multiple attempts to retrofit type-systems on top of it. Rust needn't be the only language that brings strong typing to the frontend (Elm has been around for years now). But I think the prospect of speed and correctness both front and back is pretty exciting.
- rubber_duck 10y ago>But there is another side to Rust which is even more interesting - a type system that is almost as powerful as those of functional languages like OCaml and Haskell, but wrapped in approachable imperative syntax. That type system is pretty verbose because it's aimed at manual memory management which you don't really care about in front end, and the compile times are huge compared to say TypeScript or something along those lines so yeah - I agree static typing is nice - but saying you should use Rust for front-end because it has static typing is like saying every gardener should have an excavator because digging holes with hands sucks - shovels exist.
- deleted 10y ago[deleted]