D4mations.com

WebAssembly and the Death of JavaScript – JS Monthly – February 2018



WebAssembly and the future of JavaScript – Colin Eberhardt

For more than 20 years JavaScript has been the only ‘native’ language of the web. That’s all changed with the release of WebAssembly. This talk will look at what WebAssembly is, why it matters and crucially what it means for JavaScript and the future of web development. JavaScript brought interactivity to the web more than 20 years ago, and despite numerous challenges, it is still the only language supported by the browser. However, as those 20 years have passed we’ve moved from adding a little interactivity to largely static sites to creating complex JavaScript-heavy single page applications. Throughout this journey, the way we use JavaScript itself has also changed. Gone are the days of writing simple code snippets that are run directly in the browser. Nowadays we transpile, minify, tree-shake and more, treating the JavaScript virtual machine as a compilation target.

The problem is, JavaScript isn’t a very good compilation target, because it simply wasn’t designed to be one.

Born out of asm.js, a somewhat crazy concept dreamt up by Mozilla, WebAssembly was designed from the ground up as an efficient compilation target for the web. It promises smaller payloads, rapid parsing and validation, and consistent performance … and it’s ready to use, right now!

This talk will look at what’s wrong with the way we are using JavaScript today and why we need WebAssembly. It will delve into the internals, giving a quick tour of the WebAssembly instruction set, memory and security model, before moving on to the more practical aspects of using it with Rust, C++, and JavaScript. Finally, we’ll do some crystal-ball gazing and see what the future of this rapidly evolving technology might hold.

Original source

d4mer

, , , , , ,

50 responses to “WebAssembly and the Death of JavaScript – JS Monthly – February 2018”

  6. C was born when people use killo byte memory.
    It means that programmer have to manage memory usage very very well.
    That's why no other language can bit C/C++ in memory efficiency and speed.

  7. What I want is not death of JS but to give option to developers with their preferance.
    It is monotomy of one language in web ecosystem for decades.
    Choosing language in web is "1" frequency until now(for JS), hope to be changed to "1/n" in the future for all.

  17. For anyone interested I have developed MetaphaseJS, a super easy, efficient and agnostic state management for Javascript. It uses a SQLite compiled to Javascript using Emscriptem. Basically you can save your state to a in-browser, in-memory relational database and use familiar sql queries to execute CRUD operations on data. Very powerful and easy. Link with repo and demo: https://github.com/YagoLopez/metaphasejs

  22. Keeping JavaScript and learning GLSL (OpenGL Scripting Language), so you can write custom shaders that run on the GPU, seems like a better investment for Web devs looking to get into low-level browser APIs. JavaScript is so fast now days that using WebGL to put custom code on the GPU is the only way you can realistically make stuff run one or two orders faster.

  24. with all the respect for the speaker, javascript (in fact any language) has its own advantages and disadvantages and vulnerabilities, but it's the only web programming language and there are so many developers around the world that are working with it day in and day out so it will never die ever, so this is one of this talk's problems, web assembly is here to help us do complicated things much easier, in fact, i'm a js developer and i'm learning wasm too, why? cause they're meant to work together, none of them is going to replace the other one, they're going to work along with each other. so please stop saying that. wasm actually works when js is there it's embedded in the browser's engine, yea, but the interactivity and the server side js will be always there, no matter what. and also wasm is meant to do something different than the js does, it compiles your c++ and other languages for the browser engine to make web apps with none web native languages, js is meant to do server side and front end stuff also you can make awesome web apps with it too. and also we are not in 90's to write machine languages we move forward not backward. wasm is there to only help us improve the user experience and also making native web apps.

  27. It's funny how all that started with assembly like 80 years ago, then people started using higher level languages like Fortran, Lisp, C/C++, Java/C#, all those scripting languages which deal with everything for you to the point you didn't care about typing and array size (because arrays are dynamic) and now we go way back trying to kinda emulate lower level languages to achieve better performance

  28. It is so annoying to see comments of people simply hating on one or the other. They can both coexist in harmony. Sadly, the speaker did not make it clear with his poor choice of title. JavaScript will still exist in several applications which don't contain much computational work. When it comes to the need for speed and performance however, WebAssembly obviously wins. The .wasm format is as close to 1s and 0s as posible. One must also realize that WebAssembly is very young compared to JS. It still has a lot of room to grow. Remember when JS was in its infancy. Well look at it now.

  29. "Assembly" has some connotations that wil make some people expect it to be super fast or something.

    The point is to get back at C/C++, ie. an EXISTING language and narrow the gaps for cross-platform development. Or a modern one, like Go or Rust as he mentions. And meanwhile rethink the minifyjs deployment nightmare and other hacks that crept in.

    It is MS OLE all over again, just different.

  31. Isn't this just re-inventing the JVM which was running on the browsers back in the 90s? Now the JVM is modular and open, it's a shame that is not being used for this purpose. Just expose an API for the JVM to access the DOM and this will be so much simpler.

  33. Hm… Photoshop as a web app… I would wager that Adobe is putting HEAVY research into that. Because it would probably allow them to combat piracy even more efficiently. They already basically force users to use their products only on machines with internet connections, so there would be no loss in customer base for them through that.

  34. Actually, I've found the native node module workflow with N-API relatively pleasant.
    And it seems like LLVM can't handle Windows native code anyway, as opposed to node-gyp's msbuild (duh).

  35. There's a good deal of excitement about getting more 'code' into the web page and bringing that code closer to the cpu. I don't think the new web language advances in a direction that addresses the important issues the ideal of an 'assembly language' for the web. We now have Rust, Go, and a few other contenders to replace Javascript. Reducing the time between code load and interactivity may not really be advanced by creating a better language

  37. Someone learns HTML, you can do that very quickly the basics in maybe a half hour and be creating your own web pages. You can add to that with CSS. You don't need to know all of CSS to be able to use it. You can use as little or as much as you want and still create web pages. After a while you might see some simple Javascript function and add it to a web page. Again you don't need to know how to write Javascript to use it. you can use as little or as much as you want to. You can modify small bits to fit what you need and learn as you write more web pages.

    With all these other browser languages scripting or otherwise, that simply isn't the case. You need to know all of the language or at the very least have a very good grasp of programming in general to be able to do almost anything useful with them.

    In the one case you can learn very little and do a lot, and in the other you need to learn a lot before you can do very little. That is why Javascript will not be replaced any time soon. Nothing comes close to the ease of transition from the very simple to the very complex like html-css-javascript.

  40. What a silly pompous statement. JS was built in 10 days but took 20 years to improve it. Web assembly will be just one of the many langs fighting for attention. Built by yet another nerd who seeks for a short fame, This dude even missed fact that ancient PHP is doing very well, while new langs take pity mkt percentage year after year. Progs are not that stupid, they use what gets work done. We don't have time to waste learning lang after lang only to fulfill every nerd's vanity

  41. I absolutely love JavaScript. I have learned all the mainstream frameworks for front-end and starting working with the backend frameworks. JavaScript is a perfect language in my book (not literally but pretty close). JavaScript is not restrictive and rigged. JavaScript is flexable and nible. Something other languages are not. Java is extremely rigid. C# also extremely rigid. OOP is great and all, but it's not the be-all-end-all. JavaScript can utilize both the OOP and procedural paradigms. It's not going away while other languages are so rigid. Maybe if Java or C# becomes more flexible it'll have a greater say, but JavaScript is still the most flexible language out there. The only thing better is C and C++. I wouldn't mind C++ based API's, that would be cool.

  44. ha-ha… It doesn't matter what such tech folk thinking but all languages, browsers will cause you pain of using them until investors getting profit from such companies like Google, Microsoft, Oracle. Ha-ha.. If you don't like javascript – go truck driving.

  48. Personally hate JS. Ten years ago when we had AS3 (which was ES6+ even back then) we all knew JS is completely unsuitable for anything but basic gif animations and form validations. After they kill AS3 there was nothing out there to replace it, so we were forced to downgrade to JS again. Thank God its getting replaced with TypeScript. After 10 years we are getting back to the same concepts with TypeScript and native ES6. Thats the future. Web Assembly and such (half done) attempts have no chance in professional development. Lets be real.

Leave a Reply