> In the last article, I explained that programming with WebAssembly or JavaScript is not an either/or choice. We don’t expect that too many developers will be writing full WebAssembly code bases.
I see this statement all the time, but it doesn't make sense. If you're looking at any programming language out there, they all have a growing members of their community asking and showing interest in targeting WebAssembly for their language of choice. It's not just C/C++. Go, Rust, Ruby, Python, Crystal, Nim, D, and many more. Now you might get the reaction that "meh, why would anyone write web apps with Rust?", but that's an irrelevant question. Companies are going to see this as an opportunity to save resources and become more efficient, especially since wasm has so much better perf than JITed JS and the possibility of going isomorphic is a reality (back-end & front-end written in Ruby for example, deriving from the exact same codebase and shares code).
Now I'm not saying "WebAssembly will take over JS!", what I'm saying is that it perhaps, possibly, maybe will. It will depend on these languages and how they add support for it, what abstractions and integrations they provide with their current ecosystems. And of course, how WebAssembly will improve over the coming years.
I agree completely, but I would take it a step further:
If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually. There are huge benefits to be had for teams that want to be able to code their full stack in a language that isn't JS.
We never asked for JavaScript (well the vast majority of us), but we've been stuck with it for the past two decades for all things web. Now that a doorway to replacing it with a general-purpose solution has been cracked, I expect the industry to kick it wide open as soon as possible. Not because JS is bad per se (it has certainly gotten much better), but because a lot of developers would simply prefer to use something else.
> something else that offers native bindings to other languages will eventually...
No it won't.
This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript.
Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mobile and desktop?
Microsoft? Come on. Apple? Google? Google tried with dart and failed.
Who else, seriously, is going to step up?
We can day dream about the magical 'no js' world, but it's never going to happen if web assembly doesn't work.
Currently we're seeing the reverse, js stretched off the browser, onto the server, into mobiles, onto iot devices.
You've got to layout some pretty damn fine arguments about why that trend is going to suddenly reverse.
Web assembly is pretty much our last best chance to flip javascript off and have something better...but it might already be too late for that to work. :/
> This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript.
Do people really hate JavaScript that much? I've grown fond of it in recent years, especially after ES6.
I really do hate javascript that much. It was somewhat acceptable when it was confined to the browser for simple scripting. But the more complicated the application and the more it moves out of the browser the more it's flaws get magnified.
Yes. People really hate JavaScript that much. ES6 brought some sanity to the language, but I continue to be firmly in the camp of continuing to hate and despise its existence.
Weird. I remember hating it ages ago. So much so that I was developing a Python->JavaScript transpiler (before all the cool kids were writing transpilers!) and blogging about how bad it was [1].
Granted, that was back in 2008 and most of my complaints have been addressed now almost a decade later (except for destructors, it still doesn't have those, but I also don't need them anymore).
These days I move between JavaScript, Python, Go, and C seamlessly and I can honestly say that I don't hate any of them as much as clients, managers, and 3rd party code.
People have definitely had and continue to have successful careers in, and many actually enjoy, JS.
I would never debate that. I think language choice for many people is a personal decision. There are some that I will hold my nose and use; not even complain too much. There are others that the minute there is an alternative to, I would use that instead. JS is in the latter camp for me.
If it helps, my current favorite language is Rust... they may be syntactically similar, but I just can't stand the semantics, or lack there of, of JS.
Yes. People really hate C that much. C++ brought some sanity to the language, but I continue to be firmly in the camp of continuing to hate and despise its existence.
Electron is awesome. And with webassembly, I think electron will be even better. Electrons success is because it offers a single Dev experience across all major platforms, windows, macOS, Linux and the web.
It's a great container for reducing the work to deliver code across platforms.
JavaScript is a necessary evil right now; it's the least common denominator for delivery. I would probably choose typescript if I were starting a new app right now to target it, though I want to play with Rust and webassembly soon.
It's success is not bc of JavaScript; it's because it merges the cross platform Dev experience.
I don't hate JS but would rather write my web codebase in something else, something that has a standard lib for instance. ES6 is also a transpile to JS language on the browser. The main problem is that we are stuck with ancient JS on the browser and WASM could fix that. Wouldn't you rather conpile ES6 to WASM instead of JS?
browsers that support WASM will support ES6 natively. compiling ES6 to WASM would not be a good idea, since you would have to send a garbage collector and full dynamic language runtime down the pipe instead of just using the one in the browser.
wouldn't you rather just run ES6 right in the browser instead of compiling it first at all?
If all major browsers support 100% of the spec and every implementation is bug to bug compatible with the others, yes, I would rather run ES6 directly in the browser. The problem is fragmentation and not supporting the whole spec -- some functions working in Firefox and Chrome and not implemented in IE/Edge or Safari.
For example, on the type of projects I work on, all tooling is certified by customers IT and anything extra requires change request, that might get approved, or not.
I don't quite agree with the all-or-nothing assessment, but your passion is exactly why this will happen.
Too many of the silent developer masses (probably mostly back-end engineers) have and continue to feel this way about being stuck with JS. The genie's out of the bottle, it's not going back in.
Is TypeScript as annoying a language to code in as Javascript? Or is it comparable to other modern languages like Swift and Go? If it is, I'd say that pain of dealing with Javascript (for developer productivity and happiness) is already taken care of.
Typescript is a type safe language that "compiles" into javascript. The Microsoft implementation compiles on save, so you work in your file.ts and a program running somewhere fires when the file is saved and converts it to file.js which you would distribute.
I haven't used it yet, but the demo from Anders looked good. It's an attempt to fix the "loosey goosey" nature of javascript. I would be great if browsers supported it as a built in language.
> If you watch the video, you'll notice the argument notation is name: type rather than type name. I think Anders is reminiscing about his Delphi days.
ActionScript and the proposed ECMAScript 4 also use the name:type notation, so there is definitely some prior art in the web sphere
Thats not really what he asked though. If in the end a developer can work 98% in TS, do they really care if it runs as JS or something else if it solves their problems with the language ?
I have heard from people that love TS, but surprisingly many that also prefer pure ES6 JS.
You should think of typescript as javascript+ more than a different language. It looks more like what javascript would look like in 2-3 version if the governing body thought static types were important to add.
TypeScript is a joy to program in. I was on a project where we had the opportunity to turn on all the strict checks (no use of any, no implicit nulls, etc.), and it was super enjoyable and efficient to program in.
You have algebraic types (well, 99%), union types, and concise ways of expressing tree types.
I would imagine it is more pleasant than Swift or Go, though I haven't used either of those very much.
The question was whether the concern of JS being frustrating is already solved by TypeScript, in which case WebAssembly is less important than it would be otherwise.
(Which isn't to say that there aren't other questions like efficiency and already-existing codebases written in other languages.)
Java failed to be what JavaScript became for a number of reasons, but I think the primary was the fact that it never integrated with HTML as cleanly as JS.
It could have been JS, but it was strangled to death by Sun (on the client).
Java also has the problem of long startup times while the JIT is doing its thing. Javascript has always just started executing right away. Waiting a minute or two for a Java loading bar wasn't fun.
JavaScript hasn't always worked that way. My guess is that if Java had become the tool for this, then it's startup times would have been fixed. Pure speculation of course.
If Sun had not killed Hotjava and continued to develop and market it, Java instead of JS might have been the frontend web programming language today. There were millions of Java applets written in a very short time and a Java browser would have been a first class citizen for hosting those apps.
Not the intention, but I see that interpretation. It's not hard to imagine oracle making a netbeans plugin for free and an expensive enterprise version that's faster. Selling point is leveraging existing back end skills.
> If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually
When I read this I realised that WASM might just pave the way for something more fundamental: browser runtime stdlib.
One of the big issues, even highlighted in this very thread, is that people are wary of forcing 10MB+ blob downloads on their users. What would the effect be if browser provided a proper stdlib?
What was the last time you wrote something that was 10MB after compiled to native code when optimizing for space?
Linux + BusyBox is less than 2MB (I've fitted it in floppies not too long ago) if you don't include the drivers for everything. I've created a 10MB binary set that implements an entire email server, with everything statically linked, and in Haskell (that leads to inherently big binaries).
Yes, I still remember the days when we could have core Linux experience on one 1.44MB floppy disk. This keeps reminding me how bloated most modern software are.
no, WASM will not replace JS unless somehow, overnight, the idea of downloading 30mb of compiled runtime libraries to read an inaccessible-to-screenreaders news article becomes appealing.
but i wouldn't hold my breath for 1990's style java applet loading throbbers to come back into fashion. there's a reason that stuff got outcompeted by the supposedly "inferior" javascript.
what wasm competes with is flash games, insecure java applets, and npapi and nativeclient in general.
JS isn't required to display a news article, and never has been. You can make a fast, beautiful and modern news site using only HTML and CSS, without a byte of JS.
Take a look at the source for any molasses-slow news site. The only site-specific JS will be jQuery, and a few basic event handlers to do things like show and hide elements, which could have been done with CSS.
99.9% of the JS will be advertising, analytics, and tracking. People understand that these sites are tracking them, but I think most people have not idea just how much tracking is going on. Major news sites have hundreds of tracking libraries loaded per-page. That is the only reason they are slow.
You're probably access web sites sitting at home or office, where you have decent 10+ Mbps channel. All this changes when you travel and you use either slow public WiFi or phone tethering. Yes, there's 4G, but in most places in most countries 4G coverage is very poor: it's only in the most populated areas.
I travel between countries and of course I hate staying in huge cities because they're expensive and noisy. But when you move to smaller towns, there're usually limited options for connecting to the Internet.
Last year in India I spent 2.5 hours incessantly trying to open my bank website to make an urgent payment. All these huge React/Redux bundles were loading for ages, and they aren't cached and there's no support for resuming download after it dies because of some timeout or because you were looking at the spinner for 30 minutes and decided to click reload button.
And even when these huge SPA load, they're totally broken on slow connections. People become lazy and they don't handle timeouts and responses coming in weird order because of the slow channel. Even if you manage to open SPA on slow connection, it's a pain to use, almost impossible with all these XMLHttpRequests on every click transferring megabytes of data after every click or typing any letter. :(
Well, I'm talking about "state of the art" apps. You can always fallback to server-side rendering/pure html if the connection is too slow and you can't afford the boostrap/init download. Depending on your use case SPA may actually be an improvement as the static resources can be cached. WASM is supposed to compete with native apps. Why don't you complain about MBs to download on native apps?
that's peasant level net :P. 100 or bust {literally what I have home and better at work). seriously though, indeed the web is overbloated and I don't think there is coming back
You still have to ferry data in and out of Javascript to interact with the page. In the long-term, maybe language-specific bindings to interact with DOM APIs will become popular, but otherwise to get anything done in most cases you're probably going to expend enough effort on ferrying things in and out of JS land to negate the possible benefits of not needing to deal with a different language. I'd be surprised if many do it soon for anything more than a small high-performance core or for a large application that has a small DOM surface area (a game that just renders to a canvas).
Yes of course, but only during the early stages. The post-MVP roadmap for WebAssembly specifies DOM & Web API integration (http://webassembly.org/docs/gc/), so that specific case will too disappear with time.
edit: I'd like to clarify that I'm not saying wasm will boom in usage over night, but as time goes on, the rough edges clears up & features like these are added it might become the better choice.
JavaScript is strong competition both on the front end (source ecosystem) and the back end (compiler target).
For people who don't want to use JavaScript (they are using a different source ecosystem), compile-to-WebAssembly toolchains will be in direct competition with compile-to-JavaScript toolchains. It's not at all clear which ones will win. It may be different for each language.
For C++ and Rust I'd expect WebAssembly will perform well, since it fits these languages' runtime model better. But for garbage-collected languages, compiling to JavaScript may result in smaller and faster code, since you can reuse JavaScript's runtime instead of downloading it. There may not be any reason for Elm or Dart (for example) to replace a compiler that works well with one that targets WebAssembly. Or if you like Go, I'd at least try out GopherJS before thinking you need a whole new toolchain.
It's not just performance, either. Generating somewhat-readable JavaScript that you can debug using Chrome Devtools when something goes wrong is a pretty nice advantage.
Isn't debugging just a short interation away from being like native debugging? You get a source map, you see C++ in the devtools with C++ variables and a C++ call stack and an option to "view webassembly"
I have to assume the browser teams are working on this
That might work well enough for C++, but I'm not sure how well it would work for other languages. For example, apparently gdb doesn't work all that well for debugging Go programs?
Each language has its own peculiarities for how objects are represented on the heap.
To be fair, a generational mark-sweep GC algorithm doesn't take much more space over the compile-time modifications to the code itself. A reasonably performant GC algorithm suitable for most front-end work would probably only add about 10 kilobytes to 20 kilobytes of code to an executable. That can be downloaded and cached in the blink of an eye.
The problem is that you need to get all the GC root nodes on the stack. This is platform specific and must be implemented by the browser. The only crossplatform way is to create an additional shadow stack that contains only the root nodes but this means you pay an additional cost for the GC on every function invocation.
That would only be required for data on the GC heap. Yes, you would have to implement an FFI for communicating with the browser, especially for any callbacks into the browser that take allocated memory, but it is far better to build a hygienic FFI if you want to use a GC language than re-architect the browser with GC support.
It can be done. There may be pain, but the pain can be managed.
EDIT: by that I mean that one would need to maintain two heaps. One for data that interacts with the browser and that is wrapped by the FFI as external resources, and one for the internal system itself, which can be managed via GC. Only the WebAssembly code would have to manage GC roots, which can be done as per any GC language.
Honestly I don't see how a low-level paradigm takes over a field when every other trend is towards ever more abstraction. Sure, wasm has its rightful place, like DX12/Vulkan, but it's a tiny fraction of apps/projects. Most likely we'll see js-to-wasm preprocessors of sorts to invoke optimized calls when it matters, but most devs won't touch low level (much like most game devs don't touch engines/middleware).
There's the 1% edgy companies built on node+rust/D and what-have-you, and then there's the 80% wordpress crowd who longs for a human-readable programming language a la Star Trek. I think the latter is a future that will come unimpededly over this century, as far as the majority of the industry is concerned.
More pressingly, people are waiting for async and other cool multi-threaded features in JS, and ES6 really is a second coming of sorts in that regard. Long gone are the days of horrendous paradigms once we adopt the 2016 spec, really.
Economically, because that's the true judge ultimately, we have to consider the existing JS ecosystem: actual prods, skillsets, experience, actual needs of businesses who fund the construction of the web currently solved by JS, and so on and so forth. It's a giant thing, that JS. If we had a better alternative today, we'd still be writing JS in many projects in 2020 and maintaining some of it late into that decade. Let's face it, JS is here to stay, there's no turning back now --see how polarizing Java has always been for another historical case, and see how it's still top 3: can't suddenly undo all that cash poured into production, can't instantly retrain hordes of programmers.
I'll say one thing about wasm though: it's a formidable effort that paves the way towards a truly 'next-gen' web paradigm, most notably suited to be actuated (viewed) within a VR/AR environment; it's also a prime candidate to run on the smallest devices at the heart of an "ambient"/IoT ecosystem. I'm considering a superset of low-level networking protocols that go beyond the web, obviously. And I haven't researched anything about it yet but I suspect the low-level hooks of wasm could be hacked to do some fancy ML stuff on-the-spot (thinking low-cost online algos and reinforcement learning here, if we are to make our 'ambient' IoT ecosystem able to 'learn' about us as users and map the physical world semantically).
Ha, fascinating times, really. Let's just not lose sight of how the real world operates, though, if only to improve on that. In due time when ideas become feasible under the right circumstances. Low-level programming is very much not how we've trained the bulk of tech people since the smartphone era / mobile paradigm essentially. It'll take time to shift, if we ever did. I don't think we will, in the grander scheme of things.
I see this statement all the time, but it doesn't make sense. If you're looking at any programming language out there, they all have a growing members of their community asking and showing interest in targeting WebAssembly for their language of choice. It's not just C/C++. Go, Rust, Ruby, Python, Crystal, Nim, D, and many more. Now you might get the reaction that "meh, why would anyone write web apps with Rust?", but that's an irrelevant question. Companies are going to see this as an opportunity to save resources and become more efficient, especially since wasm has so much better perf than JITed JS and the possibility of going isomorphic is a reality (back-end & front-end written in Ruby for example, deriving from the exact same codebase and shares code).
Now I'm not saying "WebAssembly will take over JS!", what I'm saying is that it perhaps, possibly, maybe will. It will depend on these languages and how they add support for it, what abstractions and integrations they provide with their current ecosystems. And of course, how WebAssembly will improve over the coming years.