I'm partially worried about WebAssembly. On one hand it opens up new possibilities... on the other hand, due to backwards compatibility I think that the future will look like this:
- 1 browser tab: Java runtime environment compiled to WebAssembly, loaded by some sort of enterprise app I'll have to use at work
- another browser tab: .NET BCL compiled to WebAssembly, loaded by another sort of enterprise app I'll have to use at work
- yet another browser tab: some sort of other C/C++ runtime compiled to WebAssembly, loaded by fancy site, let's call it XMail
- and yet another browser tab: another C/C++ runtime loaded by another fancy site, let's call it Ywitch
- a million other tabs with Javascript frameworks
From a certain point of view diversity is good, on the other hand there's so much fragmentation. One of the dreams when computers appeared was that programmers will build libraries that everyone will use and people would just build on top of these libraries, reaching ever higher.
Instead, we have I don't know how many re-implementations of things in various incompatible/slightly incompatible languages. And that's just for OSS, nevermind the billion proprietary re-implementations.
Truly the Tower of Babel.
As bad as Javascript is generally considered, from this philosophical point of view at least we seemed to be on the right track...
The thing is, at the end of the day, the language used to develop the site should be completely irrelevant for the user. You're not using Java or .NET to run your site, you're running WebAssembly. The tools used to generate that should be as irrelevant as whether someone used Gimp or Photoshop to create the images on the site that you're using.
Bloat is always a concern, but I don't see how WebAssembly materially changes things - as it stands right now, you're downloading the "runtime" for virtually every site you use in the form of a javascript bundle packaging up every library used to make a site function.
I learn quite a bit via "view source" or the debugger on sites that I see doing interesting things with JavaScript.
Wasm certainly makes that harder. I cant speak to what broad impact that might have, but it probably impacts me. More so as they add features like direct DOM manipulation (on the roadmap).
I think it will be much worse. Want to bet that there will be checklists and sales pitches on development tools websites where the likes of Microsoft, Oracle, Borland (Embarcadero?) will sell developers the possibility to build apps for the web using their runtimes, which will be 100% forklifted to the Web?
As-in, share-nothing, just their existing libraries cross compiled to WebAssembly.
And we will have to use those apps because we will need them for specific purposes (the typical example is enterprise apps, but also government sites, educational sites, etc.)
I'm sure that there's going to be inefficient, bloated libraries out there. That's really no different than the Javascript world today. But as time goes on, I believe the more efficient libraries, frameworks and tools will win out. No one uses jQuery UI or Sproutcore these days. The same will be true of any bloated monstrosity that is compiled to WebAssembly.
Probably includes images, although Universal apps tend to end up with a bunch of JSON embedded in the page, quasi-unique BEM style classes on everything you might conceivably want to style will bulk out the html more than strictly necessary too, Babel makes some pretty damn ugly ES5 in certain circumstances, and poorly nested SASS produces some travesties, so it might just be a cumulative effect.
In truth, I'm not really sure what constitutes an average webpage, or even if the quoted number is after gzipped assets are unpacked by the client.
Would be interested to see where that number comes from though.
Ronan Cronin is the original source [0]. Lots of news outlets picked up the story at the time. The data comes from httparchive, you can grab a breakdown here. [1]
Videos and JPGs are the worst offenders, but PNG and JS nearly tie for third in page weight. Though I think it isn't measuring gzip, but raw bytes, which changes it up a little.
> quasi-unique BEM style classes on everything you might conceivably want to style will bulk out the html more than strictly necessary too
Slightly off-topic here, but it's my sincere hope is that (of all things) CSS Grid Layout will drastically alleviate HTML bulk. I've been astounded by how much using it has simplified my markup and reduced complexity in my CSS (since you can accomplish complex layouts without intermediary containers).
Right now we have a dozen languages that transpile to JS. What WASM proposes is that we replace that with WASM. Then we will have several dozen languages with JS in first place that have critical bits compiled to WASM. We still have frameworks and other fragmentation but It promises performance.
What you say may happen but what the primary purpose of WASM is to replace JS as the target of compilation as it is now. They want a more robust and lower level language which can give higher performance as the base kinda like LLVM except for browsers. So languages like Typescript, Dart, Elm don't have to transpile to JS but to WASM which is less work and more performance.
I don't think it is that easy. These languages rely a lot on the underlying Javascript features and how they work, like objects, strings, etc. - browsers had a long time to optimise JS interpretation on the level beyond primitive values: OO-features in general, reusing classes/objects efficiently, good string concatenation/handling, things like that. And suddenly, Typescript et al should take care of those features as well? Sounds like an explosion of low-level feature requirements if you cut out the JS middleman.
JS is not being completely replaced if i understand correctly but the performance critical parts can be sped up. (Kinda like Cython and C extensions in Python).
Compiling JS to WASM has the same problems as just compiling JS to normal assembly ahead of time: It's just too dynamic.
The thing which you can compile ahead of time is an interpreter, which then checks during runtime what the actual types are and what needs to be done. You can run such an interpreter in WASM, but that will be a lot slower than what the current JS engines are able to do with Just In Time compilation.
I don't know whether it's possible to implement a JIT compiler in WASM (and thereby dynamically output and execute WASM), but running a JIT-in-WASM on top of a native-JIT (the JS engine) sounds not really desirable.
you could do something like V8 in wasm, sure, but.....think about this for a bit:
in chrome, you already have V8 as a native implementation, without the overhead of wasm -> cpu instructions. nothing would be gained.
You would need to do memory/etc. management on a level that is either more in line and more optimizable with your language design, or just stick to things as they are.
> transpile to JS but to WASM which is less work and more performance.
Citation needed. :)
It is not at all clear that WASM is an easier compilation target for a high level language like TypeScript, Dart, or Elm. You may be able to get better performance, but in return you have to implement and ship an entire runtime, GC, string representation, etc. Also, interaction with the DOM (the thing you need to actually get pixels on screen) is much harder.
Nobody will write directly in WASM just like nobody writes Assembly directly for complex stuff. Also the entire thing is officially supported now in Firefox and Chrome with Edge and safari soon to support. (P.S I am not a web developer and most of my info is from other people so I maybe wrong. If I am do tell me)
GC has been a future goal since mid-2015 [1]. At some point in the future when (if?) that's supported then WASM may become a better target for compilers than JS is today. Until then, I don't see WASM as super compelling.
Think of it like this: WASM is effectively a subset of JS. If you're compiling to run in a browser, by targeting that subset, you don't get to use any of the features outside of that subset that browsers already have high performance, battle-tested implementations of. Worse, you then have to reimplement those features yourself and ship them down with the application.
> Right now we have a dozen languages that transpile to JS
Not used in any meaningful amount, we don't. And in any case, a library transpiled from Elm to JS is usable by some other code that was transpiled from Typescript to JS. Will that be the same with WASM? Will I be able to make easily reusable WASM libraries? Will they all use the same mechanism to do so? All I've seen discussed is entire apps being converted.
By itself that’s the equivalent of dynamic linking; I don’t know if anyone’s written a static linker yet, but it’s an obvious next step.
However, just like with native code, there will be problems with different languages having different representations of strings, arrays, etc., and C and its sparse type system being the least common denominator.
> I don’t know if anyone’s written a static linker yet, but it’s an obvious next step.
Essentially just wasm-merge [0].
> However, just like with native code, there will be problems with different languages having different representations of strings, arrays, etc.,
This is the biggest hurtle. Someone needs to provide a WASM interface for backends to implement and frontends to target that provides a minimal stdlib. Until then, it's libc and posix by way of emscripten.
> And in any case, a library transpiled from Elm to JS is usable by some other code that was transpiled from Typescript to JS. Will that be the same with WASM? Will I be able to make easily reusable WASM libraries?
In short: No
With the current transpile-to-JS mechanisms all those languages use the same object model (from Javascript), the same string types, the same garbage collector, etc.
Once you compile-to-WASM, you reduce the common API surface to the WASM primitives, which are reading and writing numeric values from locations in byte arrays. To get some interoperability one would need to create a Javascript wrapper for all those WASM modules. Or in the future there might be a shared garbage collector in WASM, but even when that's the case one would require a standardized object model between all languages that compile-to-WASM and would like to interoperate.
So essentially the only hope for interop is for some language to gain enough traction early on that other languages implementers all want to be compatible with it so that it becomes the de-facto cross language interface like C did on most native platforms.
Just as it is in the desktop: you have loads of languages, libraries and runtimes. I don't really see the problem with the same happening on the web. If there is openness to diversity, chances are higher that quicker evolution will happen over time.
It's surprising how big programs are. Very basic android apps can weigh in at 30-60mb, and I've noticed cordova apps are particularly bad for that. Imagine needing to pull that much data every time you visited a new site.
We're already seeing this weird situation where websites that are perfectly usable in urban areas become impossible to use in the mountains. Urban telcom networks can be upgraded to make a 60mb runtime feel reasonable, but a lot of rural networks don't even work for todays sites.
> It's surprising how big programs are. Very basic android apps can weigh in at 30-60mb, and I've noticed cordova apps are particularly bad for that. Imagine needing to pull that much data every time you visited a new site.
Bit of a straw man Imo. WASM is specifically designed with page load in mind. It's why the garbage collector specification is so important, as languages with GCs want to use WASM but they don't want to ship their own for fear of slowing down page speeds.
> We're already seeing this weird situation where websites that are perfectly usable in urban areas become impossible to use in the mountains. Urban telcom networks can be upgraded to make a 60mb runtime feel reasonable, but a lot of rural networks don't even work for todays sites.
I agree completely, though for this I blame the companies/devs targeting a specific audience more than anything. Ie, I don't think it's the fault of "the modern web" or what languages/etc we use today for slower page speeds. For the same reason I don't blame languages we have today for desktop applications that aren't as "fast" as they could be.
We have more RAM than we did 20 years ago, and conversely programs use more available RAM. The program might be doing a "better" job (hard to measure, but I imagine UX is the main concern), or it might be doing a worse worse job.. but at the end of the day, developers took the opportunity to use languages/frameworks that used more RAM, for one reason or another.
So, just like the RAM, higher internet speeds and faster browsers have led to developers using more bandwidth than ever before. We use just as much as we can get away with, and always will.
Sure, WASM may change our idea of what is acceptable, but I don't think it will by too much. We're impatient beings, we want the damn page to load fast as hell. How willing do you think the ~2B Facebook users are to wait 30s while it downloads hundreds of MiB of some FB WASM app? I think people would flip out.
As an aside, what I think will be really interesting, will be compiling normal non-web apps WASM, as a deployment target for systems. Hypothetically, it could be the new "native" and vastly easier to deploy to for all OSs. Not intended to run on web, but still WASM. Talk about cool, Imo
> As an aside, what I think will be really interesting, will be compiling normal non-web apps WASM, as a deployment target for systems. Hypothetically, it could be the new "native" and vastly easier to deploy to for all OSs. Not intended to run on web, but still WASM. Talk about cool, Imo
Yup, WASM ports to non-web archs quite well. The abstraction overhead in most cases is very minimal.
Browser inconsistencies are the 2nd worst part of web development. Are you sure you wouldn't want to render your site in a consistent 'browser in a browser' if you could?
Surely the best hope for interop is something like WebAssembly - right now if I'm using two compile-to-JS languages it's pretty unlikely they'll be compatible, whereas with WebAssembly there will at least be a common notion of e.g. what an integer is. Hopefully that can translate into a common ABI.
> From a certain point of view diversity is good, on the other hand there's so much fragmentation. One of the dreams when computers appeared was that programmers will build libraries that everyone will use and people would just build on top of these libraries, reaching ever higher.
And main reason this hasn't happened is the lack of a good common ABI/runtime. Libraries do get reused cross-language on the JVM or CLR, but only within that platform; outside it only the lowest-common-denominator C ABI exists which means interoperation between high-level languages is basically impossible. Moving everything onto the web is a chance to make that possible.
This is like saying "I don't like running multiple native programs on my computing device because the machine instructions were compiled by different programming languages".
What he's saying is he doesn't want to download JVM each time he opens a page, and would rather have all pages use the JVM he already has. What you said has nothing to do with the original comment.
Can we all solemnly swear that we will never port the JRE to webassembly? Please? I mean, it's ridiculous to have Java Assembly -> WebAssembly -> CPU Assembly. Actually.... this is missing some more abstraction layers, like a precompiler or two - let's have Tomcat and Groovy or something on WebAssembly :D !
As far as I understand it currently uses JS as a target, but might switch to WASM soon.
But don't worry about the abstraction layers, we might even have some more :-) E.g. some kind of intermediate language between WASM and CPU assembly (like LLVM IR). Or the CPU µops which are even below the real assembly. Or Java maven plugins like annotation processors, which transform some Java code into others. Or even on top of that some interface definition languages, which are transformed into Java through code generators.
> let's have Tomcat and Groovy or something on WebAssembly :D !
Not sure if Apache Groovy is a good example of software that might benefit from a WebAssembly target. Somebody already tried creating an edition that compiles to Javascript, but I guess it doesn't get used much because its Wikipedia page is being considered for deletion on the grounds it's "Not a notable software library". [1]
My entire joke is unnecessary layers of interpretation/abstraction that is either run live (THREE INTERPRETED BYTECODE STAGES!) or transpiled/compiled through. i.e. too much bullshit that is guaranteed to slow down your app significantly
That dream is one that many have tried to achieve but it's what I call the software paradox: any system or framework that is capable of doing everything is so complex to learn and configure that it's nearly always easier to build something bespoke from scratch
I don't think that the complexity is unbounded. The Java standard libraries and the .NET BCL are really big, true, but you don't need to use all of them to use them. They're quite neatly segmented.
The fact that we have both libraries is due to reasons mostly outside of software development and computer science concerns (licensing, politics, etc.).
I don't see why for any non-vertical domain, in theory, we couldn't manage the complexity of having just one huge standard library available to Java, C#, Python, Ruby, etc.
Verticals are another story, that's where things get scary. But I wouldn't put medical imaging libraries in the standard libraries, anyway :)
> I don't see why for any non-vertical domain, in theory, we couldn't manage the complexity of having just one huge standard library available to Java, C#, Python, Ruby, etc.
I think you can look to pre-existing multi-language ecosystems like the JVM, .NET, etc. that show that this isn't always the greatest idea. Languages have different idioms and ways of approaching problems, and using a standard library geared towards a stateful, OOP language is going to feel out of place and awkward in a functional language (and vice versa).
> many re-implementations of things in various incompatible/slightly incompatible languages
This is why WebAssembly's lack of a garbage collector (which could be optional) strikes me as strange. What we'll get is every web page including code implementing an informally specified, bug-ridden, slow GC instead of using the excellent ones already present in browsers. I hope this will be fixed.
I understand that not every programmer and not every language wants to pay GC costs, but there are ways around that.
(Even without GC, the same applies to languages that explicitly manage memory for "speed". Their implementations will also have to work hard to provide "fast" allocators on top of the primitives provided.)
GC support [is coming][1]. Just because they didn't include it with the initial Minimum Viable Product release, doesn't mean it won't ever be available.
I thought it might be on the compiling platform to provide GC if it wants to.
As you said some devs/apps are better off without GC, but also I imagine competition would more or less ensure the most performant or overall effective platforms would end up being the de facto standards.
And some platforms (e.g. React, Vue, etc.) may find one GC tends to work better than another for them or want to implement their own.
I'm not sure if WASM can host libraries on CDNs, but if so once a user has that stuff cached from one site or another bloat wont really be a problem either.
> I thought it might be on the compiling platform to provide GC if it wants to.
Yes, the compiling platform can use WebAssembly's memory primitives to implement its own GC. But (besides the wasted work of implementing it) this is unlikely to be as efficient as a native, tuned GC on the target platform.
The question is, how much of the pros that took people to do JavaScript/browser front-ends are available for WASM apps?
X-to-JavaScript compilers were available for decades now, still most write their stuff in JavaScript.
What WASM will change, I think, is that libraries or applications, that were native before, now get ported to the browser.
So JS devs will do what they always did, maybe a bit more every year.
And people who didn't write browser apps, will more and more move to do their thing with WASM.
Also, look into enterprises, it will take them an eternity to get new WASM-enabled browsers to their users and even then I could imagine their admins to disable it.
> X-to-JavaScript compilers were available for decades now, still most write their stuff in JavaScript.
A lot of that is friction and fear of pigeon holing, that using something that transpiles to JS will limit project/career options later more so than plain JS will. I don't see that as a big issue as long as you keep an eye on developments elsewhere, at least it is no bigger issue than using a particular framework for your application. Then again I've out of date in this area (I keep an eye on developments and played with some of them, but have used-in-anger very little newer than jQuery), having specialised somewhat data-side when I'm not working on legacy projects, so I could be wrong there.
> What WASM will change
I think the key difference between JS transpilers and using WASM is that the latter promises significant performance improvements for some work where the former is more syntactic sugar for the developers (improving their performance rather than the application's, or perhaps even sometimes at the cost of a little app performance due to the extra abstraction). I see WASM finding a very useful niche in libraries for number-crunching, AI, and other compute intensive tasks, while the majority of any project's code outside that (where there is no practical performance gain to be had) remains JS.
> Also, look into enterprises, it will take them an eternity to get new WASM-enabled browsers to their users and even then I could imagine their admins to disable it.
I work at a 100k+ employees enterprise in the financial sector and our official, sanctioned browser version is about to be one that has wasm enabled by default. The fact that old versions make systems vulnerable to attacks have been changing this enterprise culture of rarely updating software.
I think you're missing the more imminent concern: that entire vendored browser runtimes are shipped as wasm packages, taking away ad blockers, hyperlinking, translating, accessibilty ...
We could have gone with a better JS replacement adopted by all players -- with ints, typing (or gradual typing), more optimisable, better memory management options (e.g. buffers, "value objects", etc)...
With the current speed of replacement of evergreen browsers it would take 2-3 years and we could start using it (some immediately if they only targeted specific newer browser versions e.g. for their enterprise apps).
Instead we got exactly what you describe + piling on stuff on top of JS.
And we'd still be stuck with a "one-size-fits-all" mentality for the browser. The desktop and server environments have amply demonstrated that different languages have different strengths, and it's a good thing in my mind that we can have solutions tailored for different sorts of problems and applications.
>The desktop and server environments have amply demonstrated that different languages have different strengths
I believe that the main thing demonstrated in practice is that everybody [1] just likes one or another Algol derived language, from a small set of languages with superficial differences between them.
Java, C#, Golang and their dynamic cousins, Python, Ruby, Javascript which have suddenly all adopted a longing for static types (Typescript and flow, Python type annotations, etc) and for async execution (asyncio, channels in Golang, async/await in C#, etc), and all piling functional features. It's like they are converging.
Sure, they still have semantic and syntactic differences, but in the end, not that important in the grand scheme of things. I think that not catering to any superficial preference of all programmers can eliminate endless bikeshedding and be hugely beneficial -- it worked wonders for JS both in terms of industry involvement (excellent JITs and tooling from 4 huge vendors), and in terms of traction/community/libs.
What's sad is not that we don't have 20+ languages for the web, but that the one we have was a quick kludge for a totally different use, and not that great for what it's now used.
[1] the casual expression meaning "most people", not the universal quantifier meaning "all with absolute no exceptions".
The most recent open issue is from 6 months ago and posits whether the project is still active. It definitely feels "experimental", but a bit outdated already.
ThinScript was very impressive because it was put together in a short amount of time to show a language that could compile to either JavaScript or web assembly.
The question is if WASM is really meant to be a compile target for anything resembling Javascript, or indeed of any language implementing garbage collection. And yeah, I know that there are proposals to include GC in WASM. And yeah, I know that a lot of people would love to program at the high abstraction level of JavaScript, only faster. Thing is, Javascript runtimes are already highly optimized at running Javascript type code. I think to really get faster, we'd have to face the tradeoffs.
The main tradeoff, IMHO, is memory management. If you go full OO with a lot of object allocations, and with a garbage collector picking up the litter in the background, then you will be freed to focus upon business logic and your development will move faster. If you manage memory yourself, C style, then you are in for a world of pitfalls and potential pain, but you can make your algorithms tighter and faster. What to pick depends upon your priorites. Postgres is written in C, for speed. A lot of modern web apps are written in full stack Javascript, for agility.
I envision the future of web assembly not as a compile target for your entire codebase, but as a way to optimize the tight loops and algorithms that do the heavy lifting, but leave the rest of the web application as Javascript. Also I think that once you go down that road, you have deliberately picked speed over convenience with respect to the methods in question.
The way that it's going to work, I think, is not by having a Javascript-type language compile into WASM, but by having a more low level language which easily compiles to WASM, but which also compiles to (slower) Javascript to support older browsers.
Did you try looking? LLVM has a WebAssembly backend, so things that can be compiled with LLVM (from your list, at least C++ and Rust) can be compiled to WebAssembly as well. See a guide here: https://gist.github.com/yurydelendik/4eeff8248aeb14ce763e
I haven't tried it; let us know how it went! Not sure how many hoops you have to jump through to compile the languages' standard libraries.
Half of the c output seems to be unicode boilerplate. Should there have been unicode to begin with? I guess they are going the way of go, but wonder whether they would take other useful "high level" features like concurrency handling and gc, if they started looking that way.
- 1 browser tab: Java runtime environment compiled to WebAssembly, loaded by some sort of enterprise app I'll have to use at work
- another browser tab: .NET BCL compiled to WebAssembly, loaded by another sort of enterprise app I'll have to use at work
- yet another browser tab: some sort of other C/C++ runtime compiled to WebAssembly, loaded by fancy site, let's call it XMail
- and yet another browser tab: another C/C++ runtime loaded by another fancy site, let's call it Ywitch
- a million other tabs with Javascript frameworks
From a certain point of view diversity is good, on the other hand there's so much fragmentation. One of the dreams when computers appeared was that programmers will build libraries that everyone will use and people would just build on top of these libraries, reaching ever higher.
Instead, we have I don't know how many re-implementations of things in various incompatible/slightly incompatible languages. And that's just for OSS, nevermind the billion proprietary re-implementations.
Truly the Tower of Babel.
As bad as Javascript is generally considered, from this philosophical point of view at least we seemed to be on the right track...