I like JavaScript a lot, I've got no problem with it. But when WebAssembly can access the DOM (or replace it) it seems likely that performance-critical code will use that instead.
AFAIK web assembly is not much faster than native javascript for general purpose code. I think the main usage of web assembly will be in optimising hot paths in math libraries, codecs and various performance sensitive code, but those are not critical parts for the majority of JS projects.
> AFAIK web assembly is not much faster than native javascript for general purpose code.
I've heard this before, and I'm sure it's true for "naive" code, but I find this a very unsatisfying truism because it does not tell me why. What is keeping WASM from being faster? Or alternatively: what is giving JavaScript an inherent edge in certain tasks.
My guess would be that for more complicated tasks, WASM currently shines wherever Typed Arrays used to potentially give an increase in performance: wherever you can allocate a big chunk of memory once, and fast access to it is the main bottleneck, and that for most other things still is too much overhead in communication with the rest of the browser.
But I simply don't know and it annoys me tremendously.
The WASM compilers are still being optimized. Most of what you see in the wild is compiled using LLVM, even the Rust project. The WASM target is still under development so you can expect a lot of improvement there.
One day we will see a language that compiles natively to WASM. Maybe even exclusively to WASM, with crazy optimizations akin to GCC's tricks with x86. I just hope it won't have objects.
Ah, that makes sense. That also would imply that more and more domains where JS has the advantage now will shift towards WASM in the long term.
Might part of the issue also be that there are now two compilation phases: to-WASM, and WASM-to-native? If the WASM bytecode produced isn't easily optimised by the WASM-to-native phase (I assume only the most basic optimisations are made at that stage) that may also result in slowdowns.
I'm wondering if this can become a source of unexpected instability in WASM performance across JavaScript engines, kind of like how built-in functions can vary wildly in performance across JavScript engines right now.
Yes, but how much of the browser code out there is is truly performance critical.
For a lot of code out there it is important that it perform well enough but it won't see much benefit from WebAssembly because of bottlenecks elsewhere (the DOM, the user, the network). Keeping the maintainability benefits JS currently has over WA is a bonus worth paying a small performance price, but you still want that price to be as small as practically possible.
As WA and the toolchanins for which it is the final compile target mature, this may change. But I suspect JS has a place, a place where performance considerations are often not insignificant, for some time to come, with WA for extra performance in truly critical areas (i.e. proper number crunching).
Sure, the major frameworks may move to wasm under the hood, but the users of the library will still likely be coding in ES6. We will probably see a lot of APIs where the backend is implemented in wasm with a friendly, scriptable frontend in typical ES6.
That said, I’m actually skeptical wasm will ever find much of a use case with the DOM. The browser itself is already heavily optimized for working with the DOM, so wasm is unlikely to be competitive in speed except for specific use cases.
> Sure, the major frameworks may move to wasm under the hood, but the users of the library will still likely be coding in ES6. We will probably see a lot of APIs where the backend is implemented in wasm with a friendly, scriptable frontend in typical ES6.
Why? If WASM has access to the DOM, and it's competitive in terms of performance - why would JS still by the goto? At that point, people will just choose whatever language they want, I don't see JS having an advantage there any longer. Especially since many people don't want to use JS to begin with, but have been forced to.
> That said, I’m actually skeptical wasm will ever find much of a use case with the DOM. The browser itself is already heavily optimized for working with the DOM, so wasm is unlikely to be competitive in speed except for specific use cases.
I'll be sad if that is true. Though, I'd even be willing to take minor performance hits to use the languages/etc I want. How much of a hit I'd be willing to take would really depend on the application needs, of course.
> Many of us do want to use JS. The language has evolved a lot over the past few years and people love it.
No one _(with any sense)_ thinks JS is somehow going to be deleted. Nor am I saying JS is going anywhere - if anything, I'm not even talking about JS, I'm not sure why you pointed out that JS is going to exist afterwards. Do I misunderstand your point?
> Client-side JavaScript isn't going anywhere. Look how popular Node is despite all the alternatives.
Well to be clear, there isn't alternatives, if the user wants a shared tooling, shared libraries, shared language.
I don't think Node became popular years ago because JavaScript is so wooping awesome. Hell, when NodeJS came out transpilers (CoffeeScript/etc) were massively popular because of how much many people hated JavaScript.
Node was popular despite many peoples dislike for the language. I worked for ~4 years at a company who built an entire platform in CoffeeScript, as did a few other companies we worked with.
That's not to say that JavaScript is terrible, ES6+ is becoming really nice. I'm just saying, Node's popularity is clearly not evidence of JavaScript being awesome. Node is a symptom of people wanting a singular environment, and not having any choice about JavaScript.
Perhaps I misunderstood
your point. You seemed to ask why people would want to use JS once WASM effectively
puts it on a level playing field with other languages.
Ah nah, I meant more like - if you wanted to, why wouldn't you. Not that anything is explicitly better than anything else.
It sounded like people were claiming that WASM cannot dethrone JS, that JS will always be the language of the web, etcetc. So my question was more.. Why?
Personally I don't think it is (clearly haha). Once DOM access is reasonable, I think many (myself included) will move away quickly. Web frameworks are not that hard, so the existing ecosystem of languages is a bit of a meaningless argument as I see it. Hell, even within JS, the ecosystem is largely isolated solos of code. Eg, sure I can choose between React, Angular, Ember, etcetc - but I wouldn't choose two of them at the same time. The ecosystem in that case only helps me in that I can choose, but they're rarely tools I collectively use.
So back to my original point, myself, and I imagine my shop, would make the switch pretty quickly as soon as WASM is viable for our target languages. Viable means page load execution, memory, speed, etc - all variable parameters depending on the project of course.
> It sounded like people were claiming that WASM cannot dethrone JS, that JS will always be the language of the web, etcetc. So my question was more.. Why?
You seem to be missing the biggest (at least to me) advantage of JS - how dumb it is.
It's great that beginners don't have much to learn. They do not need any complex environment setup. And even seniors get benefit of easy onboarding.
And considering web will always be primarily about UI i.e. high level code writable by any random guy without CS degree, why would JS lose its dominance?
Being the top language and being the goto might be different though.. although I'm not sure how to properly word the two, but what I mean is:
A goto language is the language that most people are going to use because of the benefits for the problem domain. Eg, you're not going to write an embedded device application with a GC language like JS/Py/Go/etc. You're far better off with a low level, low memory and predictable language.
Right now, JS is the goto for the web. It's actually not the only "choice", transpilers exist for many languages to JS, but it slows the app down, increases size, etc. So while people have options, the disadvantages of other Langs on the web make JS the goto.
Saying that JS will no longer be the goto (or however you want to word it) doesn't mean people will stop using JS any more than embedded systems not using Python hurts Python. But it does mean people have options, and JS is a language of choice now, not requirement. At least, that's my dream - hopefully WASM provides that.
> Why? If WASM has access to the DOM, and it's competitive in terms of performance - why would JS still by the goto? At that point, people will just choose whatever language they want, I don't see JS having an advantage there any longer.
Because of the built-in garbage collector, only non-garbage collector languages will actually be faster on WASM (so not that many of them) and the JS ecosystem is already so big that you would need a lot of work to match it in its current state.
Because that's where the libraries are. In most cases, a language's ecosystem is far more important than the language itself.
We seem to get the next great front-end framework every couple years. Maybe the next great one will be in a language other than Javascript and at that point we'll start to see a significant language shift.
WASM will also be used to port applications in other languages to the web. And if you're a Rust or C++ shop, maybe you don't want to write your frontend in JS.
If that was shipping today, it would be another 7-10 years for browsers to catch up. At wasm's current rate, it won't be available for another few years. The ability to make decent garbage collectors also looks to be very far out.
If you are writing JS today with even a couple years of experience, it's guaranteed to be used for everything until you retire (well, if retiring from a company after putting in your 20 was still a thing).
But how often do front end applications have performance critical code that operates on the DOM? Even then, it's more likely that if you need to render something that requires that much processing power it'd make more sense to use something like canvas with WebGL.
