10 ms·

I'm hoping web assembly eventually completely replaces javascript. It would be amazing if we could theoretically compile any language down to be browser compati

I'm hoping web assembly eventually completely replaces javascript. It would be amazing if we could theoretically compile any language down to be browser compatible.

gchamonlive 5y ago
This is something that I wanted to hear more from people invested in frontend. I work exclusively as a DevOps/DataOps/Backend engineer and have little contact with stuff running in the browser. I did, however, work with AngularJS back in the day, and although the framework itself didn't lend itself to nicely to productivity and simplicity, I believe that what I found most confusing was how unergonomic the browser environment itself was, from not dealing with a filesystem (and thus having to resort to tricks like transpiling and bundling) to the rather terse API, not having for instance a SQLite natively and not being able to enable something like this without bringing copious amounts of megabytes of extra javascript deps... Is the browser environment becoming more dev-friendly with the adoption of WebAssembly? I ask that because, in my opinion, if the browser itself doesn't evolve, it doesn't matter which language we use, interacting with it will still be a hassle. All in all, it feels like the browser advanced a lot in technology for optimization and resource management, but not so much in becoming more user-friendly to the developer.
- Tade0 5y ago
  > not having for instance a SQLite natively We had this for a brief moment in the form of Web SQL, but as a rule web standards require independent implementations to be developed, and all the implementors were using SQLite under the hood. The current alternative is IndexedDB - for better or worse. > Is the browser environment becoming more dev-friendly with the adoption of WebAssembly? Yes, but that doesn't have much to do with WebAssembly. JavaScript as a language evolved, we have TypeScript with its flexible and expressive type system and bundling is becoming less of a pain with each consecutive framework re-written using ES2015 modules(and loaded via e.g. Snowpack https://www.snowpack.dev/ https://www.snowpack.dev/). WebAssembly is helpful when there's a need for some heavy lifting - e.g. in software codecs, but that's still a niche application.
  - peterthehacker 5y ago
    Technologies like TypeScript are still dependencies that require transpiling to vanilla JavaScript and add to the bundle size. While typescript is becoming more and more common (for good reason) it still is effectively a workaround that compensates for the unergonomic-ness of the browser environment. You could make the same argument for frameworks like Angular, React and Vue. If WebAssembly replaced js, then newer, more efficient browser languages could be invented. Like a new implementation of typescript could be created that is statically compiled and more efficient. All of this transpiling from x to js and y to css would be unnecessary.
    - bri3d 5y ago
      The "y to CSS" part would still be there - even with WebAssembly, your UI options are still pretty much the DOM (great for documents and form entry, not so great for applications) or canvas (too low level and loses platform consistency, accessibility, usability, really every affordance of an operating system).
      - peterthehacker 5y ago
        Good point. I was thinking of changing styles via DOM, like CSS-in-JS, but you’re right that “y to CSS” would still be there.
      - UnpossibleJim 5y ago
        I'm going to ask an ignorant question and I'm sorry, but couldn't you basically write an application in web assembly, using OpenGL and creating whatever UI you wanted in there, and just use CSS for the scaffold? You'd only need a mobile and desktop web app, but you'd need one anyway, right? (Note.. I'm very obviously not a web developer, so forgive my naivete).
        hnfong 5y ago
        Yes. For example: https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html https://workspaceupdates.googleblog.com/2021/05/Google-Docs-... But it's going to be a very "heavy" custom framework that takes time to download and load. Overkill in most cases.
- tmm84 5y ago
  The problem was WebAssembly despite what people think isn't a JS replacement. WebAssembly isn't designed to go after DOM manipulation and the rest of the browser world (in short, think calculating physics and heavy number crunching instead of whether or not some input with id blah is blank). The best analogy I can give is this, imagine using Lua and calling of compiled code (C/C++/Rust/etc), this is the JS/WebAssembly way of doing things. Does the web browser (an application for reading documents written in hypertext), need to evolve? Or, has the web browser been asked to do more than it should and we need a new type of application? So much of the internet is based around the fact that the basics of the web browser can't change (don't break the web!). If the basics can't change then maybe the need for a new standard where the basics fit the application is required.
  - johnmaguire 5y ago
    What would you change?
  - dmos62 5y ago
    The browser has been a system-within-a-system for a long time now. That's a pretty big problem, because it's inefficient computation-wise and has very low interoperability with the host system, which has big implications. The user also has sort of an upside: the browser, being isolated on the host machine, is very portable. And, maybe safer, but I'd argue against this point, because a monolith is too hard to audit; if you want security and correctness you need many small components, not one huge one. But, those are user problems. Big vendors enjoy non-interoperability, because it lets them do user lock-in and have monopolies. That's also why we hardly have medium-sized vendors: only gigantic and minuscule. If I had a magic wand, - I'd make Web maximally interoperable, give an API to everything: look up Youtube recommendations or listen to Spotify programmatically or from the command line; - introduce legislation to forbid non-interoperable for-profit (or infrastructure-level) software; otherwise businesses are incentivized to make walled gardens and lock-in users; e.g. no more countless chat apps; - get rid of Javascript: it creates too many security and fingerprinting problems, and, if everything has an API, you don't need it; - break up the browser into a composition of smallest independent components possible; it will get you `apt install facebook-local-events`; - get rid of password-based authentication: what a horrible idea that was; - get rid of any client-side possibility to track or fingerprint users; if you're making choices about what services to use or how, those choices can be fingerprinted, depending on some other things, but that's another matter; the other party should not be exposed to what hardware or software or configuration you use or how you use your peripherals; - introduce consumer and competition protection laws to bring software out of the wild wild west in terms of legislation. I've more or less described the destruction of Web as we know it, but also a creation of something much better, in my eyes. Doesn't sound very feasible, but that's what I'd do if I had a magic wand.
- mr_toad 5y ago
  Not having direct access to the file system or the network or to a database are because of the sandbox, not because of JavaScript. You can do all those things in Node. Web Assembly isn’t going to get rid of the sandbox.
  - gchamonlive 5y ago
    You could have fakeroot, for instance: https://wiki.debian.org/FakeRoot https://wiki.debian.org/FakeRoot Sandbox doesn't imply not having a file system available (for example, for use in imports), I believe this is more of a historic limitation than a strictly technical one (just because we need the sandboxing concept). I know. Fakeroot is not strictly sandboxing, but I think it illustrates the point.
laurencerowe 5y ago
That’s already pretty much the case. Python has been though it’s not fast and the stack size limit is problematic. https://github.com/pyodide/pyodide https://github.com/pyodide/pyodide Pyodide is used in https://jupyterlite.readthedocs.io/ https://jupyterlite.readthedocs.io/ Maybe things will improve with web assembly GC, though it will require work to port GC languages to it.
- redfox2 5y ago
  Guido mentioned he was focusing work on CPython to make Python faster
NelsonMinar 5y ago
It's about time to reinvent Java applets.
rank0 5y ago
idk how I feel about web assembly. At least now we can see what client-side javascript is doing. If WASM becomes mainstream then all client side code is going to be essentially binary blobs.
- ben-schaaf 5y ago
  With all the minification and JS being used as a compile target for other languages it's already essentially binary blobs.
  - rank0 5y ago
    I agree with what you're saying but WASM is just way more difficult to reverse engineer. Also if WASM becomes the standard, everyone will have binary blobs running in their browser at every web page by default. At least now its only for web apps which are intentionally obfuscated/minified/transpiled/whatever...
divbzero 5y ago
I’ve noticed both “plain HTML please” and “Wasm is awesome” sentiments expressed on HN. I wonder if these reflect two distinct subpopulations, or if there is an intersection of HNers who like both ideas. The existence of both sentiments speaks to the idiosyncratic history of the web. The browser is powerful because it has grown to be ubiquitous, but also has this odd dual mandate of displaying static content and running dynamic apps.
- diordiderot 5y ago
  I think it's more of a dislike for slow, laggy, and frankly janky experiences caused by excessive JavaScript or under qualified JS developers over the past 10 years.
tiew9Vii 5y ago
I don't think Webassembly will ever replace Javascript in the browser. Javascript has a low barrier of entry and if you are creating React/Angular sites there's little to gain from Webassembly for someone not interested in safer languages. Saying that I am really interested in Webassembly and think the word web in Webassembly does it a disservice. I have started to think of Webassembly as a light weight JVM. It's heavy sandboxing makes it really interesting as an evolution to FaaS (Function as a service) such as AWS Lambda. Lucet which Fastly is using for their Compute@Edge reports 35 micro second code start time! I can't wait until Fasly put there Compute@Edge on general release so I can try it. I've been playing with Cloudflare workers and as they us Chrome to run WASM files you have to mess about writing Javascript shims so a bit rough around the edges debugging. Webassembly should realise the original goals of serverless providing a cross platform runtime with security guarantees and be fast and lightweight. Most people package an entire OS in Docker containers, with WASM they get a small cross platform artifact. This project already looks like a way to run them in K8s https://github.com/deislabs/krustlet https://github.com/deislabs/krustlet. It also looks great for cross platform media devices. Have the bulk of your code as a WASM binary and then have very thin platform specific shim the WASM interacts with.
jacobmischka 5y ago
I don't think this is ever going to happen. JavaScript is still and probably always will be the language used to manipulate webpages and interact with the user, it's extremely optimized and a quite fast and effective scripting language. WebAssembly provides an amazing opportunity to do general computing in webpages more efficiently than with the JavaScript scripting language, but it's not designed to interact directly with the user or documents. Certainly that _could_ change in the future, but that's not one of its design goals and I don't think it would even be particularly effective at it.

I'm hoping web assembly eventually completely replaces javascript. It would be amazing if we could theoretically compile any language down to be browser compatible.

gchamonlive 5y ago

This is something that I wanted to hear more from people invested in frontend. I work exclusively as a DevOps/DataOps/Backend engineer and have little contact with stuff running in the browser. I did, however, work with AngularJS back in the day, and although the framework itself didn't lend itself to nicely to productivity and simplicity, I believe that what I found most confusing was how unergonomic the browser environment itself was, from not dealing with a filesystem (and thus having to resort to tricks like transpiling and bundling) to the rather terse API, not having for instance a SQLite natively and not being able to enable something like this without bringing copious amounts of megabytes of extra javascript deps... Is the browser environment becoming more dev-friendly with the adoption of WebAssembly? I ask that because, in my opinion, if the browser itself doesn't evolve, it doesn't matter which language we use, interacting with it will still be a hassle. All in all, it feels like the browser advanced a lot in technology for optimization and resource management, but not so much in becoming more user-friendly to the developer.

Tade0 5y ago
> not having for instance a SQLite natively We had this for a brief moment in the form of Web SQL, but as a rule web standards require independent implementations to be developed, and all the implementors were using SQLite under the hood. The current alternative is IndexedDB - for better or worse. > Is the browser environment becoming more dev-friendly with the adoption of WebAssembly? Yes, but that doesn't have much to do with WebAssembly. JavaScript as a language evolved, we have TypeScript with its flexible and expressive type system and bundling is becoming less of a pain with each consecutive framework re-written using ES2015 modules(and loaded via e.g. Snowpack https://www.snowpack.dev/ https://www.snowpack.dev/). WebAssembly is helpful when there's a need for some heavy lifting - e.g. in software codecs, but that's still a niche application.
- peterthehacker 5y ago
  Technologies like TypeScript are still dependencies that require transpiling to vanilla JavaScript and add to the bundle size. While typescript is becoming more and more common (for good reason) it still is effectively a workaround that compensates for the unergonomic-ness of the browser environment. You could make the same argument for frameworks like Angular, React and Vue. If WebAssembly replaced js, then newer, more efficient browser languages could be invented. Like a new implementation of typescript could be created that is statically compiled and more efficient. All of this transpiling from x to js and y to css would be unnecessary.
  - bri3d 5y ago
    The "y to CSS" part would still be there - even with WebAssembly, your UI options are still pretty much the DOM (great for documents and form entry, not so great for applications) or canvas (too low level and loses platform consistency, accessibility, usability, really every affordance of an operating system).
    - peterthehacker 5y ago
      Good point. I was thinking of changing styles via DOM, like CSS-in-JS, but you’re right that “y to CSS” would still be there.
    - UnpossibleJim 5y ago
      I'm going to ask an ignorant question and I'm sorry, but couldn't you basically write an application in web assembly, using OpenGL and creating whatever UI you wanted in there, and just use CSS for the scaffold? You'd only need a mobile and desktop web app, but you'd need one anyway, right? (Note.. I'm very obviously not a web developer, so forgive my naivete).
      - hnfong 5y ago
        Yes. For example: https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html https://workspaceupdates.googleblog.com/2021/05/Google-Docs-... But it's going to be a very "heavy" custom framework that takes time to download and load. Overkill in most cases.
tmm84 5y ago
The problem was WebAssembly despite what people think isn't a JS replacement. WebAssembly isn't designed to go after DOM manipulation and the rest of the browser world (in short, think calculating physics and heavy number crunching instead of whether or not some input with id blah is blank). The best analogy I can give is this, imagine using Lua and calling of compiled code (C/C++/Rust/etc), this is the JS/WebAssembly way of doing things. Does the web browser (an application for reading documents written in hypertext), need to evolve? Or, has the web browser been asked to do more than it should and we need a new type of application? So much of the internet is based around the fact that the basics of the web browser can't change (don't break the web!). If the basics can't change then maybe the need for a new standard where the basics fit the application is required.
- johnmaguire 5y ago
  What would you change?
- dmos62 5y ago
  The browser has been a system-within-a-system for a long time now. That's a pretty big problem, because it's inefficient computation-wise and has very low interoperability with the host system, which has big implications. The user also has sort of an upside: the browser, being isolated on the host machine, is very portable. And, maybe safer, but I'd argue against this point, because a monolith is too hard to audit; if you want security and correctness you need many small components, not one huge one. But, those are user problems. Big vendors enjoy non-interoperability, because it lets them do user lock-in and have monopolies. That's also why we hardly have medium-sized vendors: only gigantic and minuscule. If I had a magic wand, - I'd make Web maximally interoperable, give an API to everything: look up Youtube recommendations or listen to Spotify programmatically or from the command line; - introduce legislation to forbid non-interoperable for-profit (or infrastructure-level) software; otherwise businesses are incentivized to make walled gardens and lock-in users; e.g. no more countless chat apps; - get rid of Javascript: it creates too many security and fingerprinting problems, and, if everything has an API, you don't need it; - break up the browser into a composition of smallest independent components possible; it will get you `apt install facebook-local-events`; - get rid of password-based authentication: what a horrible idea that was; - get rid of any client-side possibility to track or fingerprint users; if you're making choices about what services to use or how, those choices can be fingerprinted, depending on some other things, but that's another matter; the other party should not be exposed to what hardware or software or configuration you use or how you use your peripherals; - introduce consumer and competition protection laws to bring software out of the wild wild west in terms of legislation. I've more or less described the destruction of Web as we know it, but also a creation of something much better, in my eyes. Doesn't sound very feasible, but that's what I'd do if I had a magic wand.
mr_toad 5y ago
Not having direct access to the file system or the network or to a database are because of the sandbox, not because of JavaScript. You can do all those things in Node. Web Assembly isn’t going to get rid of the sandbox.
- gchamonlive 5y ago
  You could have fakeroot, for instance: https://wiki.debian.org/FakeRoot https://wiki.debian.org/FakeRoot Sandbox doesn't imply not having a file system available (for example, for use in imports), I believe this is more of a historic limitation than a strictly technical one (just because we need the sandboxing concept). I know. Fakeroot is not strictly sandboxing, but I think it illustrates the point.

laurencerowe 5y ago

That’s already pretty much the case. Python has been though it’s not fast and the stack size limit is problematic. https://github.com/pyodide/pyodide https://github.com/pyodide/pyodide Pyodide is used in https://jupyterlite.readthedocs.io/ https://jupyterlite.readthedocs.io/ Maybe things will improve with web assembly GC, though it will require work to port GC languages to it.

redfox2 5y ago
Guido mentioned he was focusing work on CPython to make Python faster

NelsonMinar 5y ago

It's about time to reinvent Java applets.

rank0 5y ago

idk how I feel about web assembly. At least now we can see what client-side javascript is doing. If WASM becomes mainstream then all client side code is going to be essentially binary blobs.

ben-schaaf 5y ago
With all the minification and JS being used as a compile target for other languages it's already essentially binary blobs.
- rank0 5y ago
  I agree with what you're saying but WASM is just way more difficult to reverse engineer. Also if WASM becomes the standard, everyone will have binary blobs running in their browser at every web page by default. At least now its only for web apps which are intentionally obfuscated/minified/transpiled/whatever...

divbzero 5y ago

I’ve noticed both “plain HTML please” and “Wasm is awesome” sentiments expressed on HN. I wonder if these reflect two distinct subpopulations, or if there is an intersection of HNers who like both ideas. The existence of both sentiments speaks to the idiosyncratic history of the web. The browser is powerful because it has grown to be ubiquitous, but also has this odd dual mandate of displaying static content and running dynamic apps.

diordiderot 5y ago
I think it's more of a dislike for slow, laggy, and frankly janky experiences caused by excessive JavaScript or under qualified JS developers over the past 10 years.

tiew9Vii 5y ago

I don't think Webassembly will ever replace Javascript in the browser. Javascript has a low barrier of entry and if you are creating React/Angular sites there's little to gain from Webassembly for someone not interested in safer languages. Saying that I am really interested in Webassembly and think the word web in Webassembly does it a disservice. I have started to think of Webassembly as a light weight JVM. It's heavy sandboxing makes it really interesting as an evolution to FaaS (Function as a service) such as AWS Lambda. Lucet which Fastly is using for their Compute@Edge reports 35 micro second code start time! I can't wait until Fasly put there Compute@Edge on general release so I can try it. I've been playing with Cloudflare workers and as they us Chrome to run WASM files you have to mess about writing Javascript shims so a bit rough around the edges debugging. Webassembly should realise the original goals of serverless providing a cross platform runtime with security guarantees and be fast and lightweight. Most people package an entire OS in Docker containers, with WASM they get a small cross platform artifact. This project already looks like a way to run them in K8s https://github.com/deislabs/krustlet https://github.com/deislabs/krustlet. It also looks great for cross platform media devices. Have the bulk of your code as a WASM binary and then have very thin platform specific shim the WASM interacts with.

jacobmischka 5y ago

I don't think this is ever going to happen. JavaScript is still and probably always will be the language used to manipulate webpages and interact with the user, it's extremely optimized and a quite fast and effective scripting language. WebAssembly provides an amazing opportunity to do general computing in webpages more efficiently than with the JavaScript scripting language, but it's not designed to interact directly with the user or documents. Certainly that _could_ change in the future, but that's not one of its design goals and I don't think it would even be particularly effective at it.