WebAssembly and the Death of JavaScript - JS Monthly - February 2018
Вставка
- Опубліковано 30 вер 2024
- 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.
39:50 - " no its not gonna die"
thanks son. I just wanted to know how will he sugarcoat his title. I watched 30 second and skipped entire video. Was here for the bait anyways
Of course it wont die
All the browsers use it they cant interpret another language so until that happens besides web asm which is only really a virtualized machine where as JS can only run on the real device
I am disappointed. Nowhere did you mention the status of adding COBOL support for webasm.
PERFORM VARYING X BY 1 FROM 0 UNTIL X = 9001
SUBTRACT 1 FROM 90-HAPPINESS
END-PERFORM
I like to yell at my IDE when I code and I prefer a language that reflects that.
Excellent ! This is how a good presentation is made. High level, interesting engaging, and alway staying within the context of the topic.
yes, and of course not knowing what your examples do in 16:19 and expressing your opinion about "dirty c" in 12:10, it's so fucking professional, просто пиздец.
Great talk m8!
Outlining all the options you feel to be relevant, not pushing an agenda and sharing your personal thoughts on what the findings you present means, top notch all the way.
The big battle to be had is between Rust and Typescript if I dare a guess, it is going to be amazing to see how the coming 5 years will change the web platform.
Somehow I find you everywhere lol
we write a lot of javascript? BS, all the damn libraries and frameworks that keep spawning write the javascript. i cant wait for it to go frankly.
Can't wait for the first Electron app that uses wasm to run compiled code and utilizes 800MB of RAM.
Think you are on to something there.
javascript will not be dead, he’ll can be converted to wasm easily like babel does, so no worries about that bullshit conversation:)
Very good presentation. I only wish he would elaborate on the performance - he claims WASM isn’t substantially faster than JS? They’re benchmarking “the wrong things”, he says.
I can’t make sense of that. We’ve all seen benchmarks of JS vs C, and C typically in the order of 10-15 times faster than JS. I’ve heard people from Mozilla and NVidia say that C compiled to WASM is very close to a native C performance, so that doesn’t add up at all.
Perhaps for something like Mandelbrot it’s true, but that’s just maths performed in a single loop, which is likely easy to optimize in a JS VM or anywhere - but probably doesn’t resemble most real world applications. It’s actually popular as a synthetic benchmark, but others are benchmarking “the wrong things”? I don’t follow.
Benchmarking is generally fraught with pitfalls, so who knows what particulars the presenter was thinking of. The example that comes to my mind is the article "Maybe you don't need Rust and WASM to speed up your JS" by
Vyacheslav Egorov in which he shows how the same speedup the Mozilla team achieved by rewriting the sourcemap library in Rust could have been achieved by making changes to the JS version.
The competition in the browser market has pushed JavaScript engines to extreme lengths, so the gap between C and (engine optimized) JS is probably not as large as you think. From 20 minutes of googling (which doesn't really count as research, but hey) I'd guesstimate that C is 2-10 times faster than JS. Also, for the kinds of things most developers build, 10-15 times faster might simply not be "substantial" to his point of view. After all, latency is such a big component of perceived web application speed, and a lot of that is network limited.
Regardless, right now the bottleneck is the interface between the WebAssembly code and the DOM, which is slow enough that it would prohibit making a single page app framework entirely in WASM. But I'm definitely excited about what the performance for Canvas-based applications using WebGL and WebVR will be like!
I wrote what I considered to be a good response, then UA-cam swallowed it alive. This will probably be a worse answer since I didn't want to write it twice.
To be overly simplistic, we can say that only 1 thing affects the speed of running code, and that is the efficiency of the final machine instructions. Since the x86_64 ISA is for the most part fixed, it's not our job to optimize at that low of a level, instead we rely on Compiler Optimizations that know the tricks of the Native ISA.
JS can be said to be "slow" natively because it really is. There is a lot of type checking that has to occur, memory allocation is weird in a JIT, etc. Browser vendors/engines have done a fabulous job at finding tricks to optimize the engine and compiler to make it a sufficiently fast language. There are handfuls of blogposts about the V8 engine and some of the stuff they've done like skipping half of the type checking steps using Speculative Optimization (see ponyfoo.com/articles/an-introduction-to-speculative-optimization-in-v8 ) where they discuss how the JS addition operation is actually 10 steps in the runtime.
So WASM. Why is it not as fast as C? Because C is run through relatively ancient compilers like gcc (30 years old) that knows about all the optimizations of the ISA below it. Whereas the WASM compiler is fairly new and emits a ASM that isn't all that verbose. As noted in the talk, it only has support for numerical types as of this moment which makes things like Strings horribly slow because we're "faking it". This was intentional, because we wanted all browsers to get the tech without it being overly complex. I believe that eventually WASM will indeed get to near native speeds but it will take 2 things: 1. Finding a balance of complexity in the ISA, meaning they do need to add more features like more types or better branching/looping mechanisms and 2. Optimizing the individual language compilers for those new tricks.
While ideally WASM code speed should be independent of source code language, it probably won't end up being that way because certain language or compilers may simply get better optimizations. WASM will be getting Garbage Collection soon, allowing for languages like Ruby or Golang, but that doesn't mean Golang to WASM will run as fast as Rust or C to WASM, etc.
So why is this a good idea then? Well JS engines will inevitably continue to push optimizations to ridiculous levels with ever more diminishing returns. You can't just skip all type checks on a weakly typed language after all. Meanwhile given that very first attempts at WASM runtimes have gotten us even this good of results, I would estimate that we will see even more promising results in a very short time (1-2 years). At that point it will probably begin to achieve it's purpose, not to replace JS, but to give us options of what language we want to write in for the web.
Aaron Chamberlain very good answer, thank you :-)
And yes, options - this is the main thing for me and always has been. Web developers have been stuck with some of the worst languages in history for far too long 🙄
If you have simple DOM manipulation code your WASM might not outperform JS at all, mainly because you would be operating a foreign data structure with an imposed call overhead. However, the strength of WASM is what a lot of javascript developers fear the most: explicit memory management. Cache locality and memory access patterns are no joke. An L1 cache miss on a modern CPU is 50x faster than RAM access. In managed languages such as javascript or even java/C# memory is all over the place, tons of indirection and pointer dereferencing everywhere, poor memory access patterns. Because apparently computers are 'fast enough' anyway (hint: when you are building a large app, they stop being fast enough very quickly). When you eliminate that, you get a huge performance boost.
Rasmus Schultz
Wow, you'll need a PHD to add two numbers
C is horrible and dirty? I would say the same of javascript, in fact to me js is more dirty
lostheptapod i hate people that hate a langauage because of syntax, yeah syntax may be ugly but at the end of the day you will use the one with better performance and better libraries
Javascript is better for getting things up and going FAST which is it's primary application. C is kinda the opposite, there's a lot of knowledge you need to have to even get started. Any strongly typed language is going to have a huge barrier to entry simply because of the fact that you need to understand what all the standard object/data shapes are. Honestly i think a compromise like typescript where you get strong types when you need it and the flexibility of real time typing. If typescript had the same optimizations as c (in a lot of cases V8 does a great job of handling typing and optimizations) there wouldn't really be any reason to use other languages but we're quite a ways off from that.
Fortunately for the world there are developers who don't dwell in ivory towers of theoretica and are willing to stoop to get their hands dirty with pedestrian C for such mundane work as operating system kernels and device drivers and embedded applications in medical and communication and process control devices and vehicles and critical infrastructure of all kinds. By all means don't let their odor distract you from your groundbreaking efforts to speed up the transfer of crucial data like ads, fake news and porn by 10%.
Meat Goat my hero
Tell me your favorite language. I bet that it is written with "C" for a good reason, and your language's performance would be horrible next to it.
Before you jump the JavaScript ship, remember that frameworks like react, angular, vue, etc. are the result of two decades of evolution. It wasn’t perfect in the beginning but I would argue it’s the best time to be a web developer. If you want to jump ship, you must also forgo the browser as we know it; the idea of interpreting JavaScript into machine code.
Is there a transcript available somewhere? I read faster than anyone presents, and I suspect a lot of people do. #videoisslow
Blazor looks amazing. The .NET web development community is very excited about the possibility of writing interactive web applications exclusively in C#. A new compilation target that doesn't have JS's overhead is a very welcome thing for all other languages besides JS. I expect a flood of new web development platforms to rise from this.
Don't get too carried away, Web Assembly isn't meant for websites in general, mostly websites that require a lot of performance. Web Assembly is very much for game engines and CPU expensive editors, it's very costly for smaller to medium projects, also knowing the JavaScript community they'll probably find a way to compile to Web Assembly, though funnily enough if it isn't CPU intensive, the speeds between JavaScript and Web Assembly isn't that much different.
Scott Berry being able to use a language with excellent dev experience like C#, for a minimal perf price, is totally worth it, even for non CPU intensive apps
It's not, Web Assembly using 16mb per module, which is highly expensive for applications which aren't game engines or something of similar scope, Web Assembly isn't meant for ordinary web services, it has a specific use case.
Also because C# lacks memory control, it might be a long time before it happens, better start learning C, C++ or Rust.
Scott Berry with the current version, I totally agree. But I'm allowed to dream...
@Scott Berry - "Web Assembly using 16mb per module".
Blazor is not that large, only a few MB, and it's getting smaller and smaller as they optimize it. The goal is around 1MB I think.
Still larger than a plain html/css/js site usually is, but it's far from 16MB.
Yes please kill Javascript, and take HTML with you
Please don’t. I don’t want WASM on browsrrs
39:04 WASM will make the "app store" concept absolete. In the near future you'll just type in the domain name, wait a second for the "heavy" resources (likes pictures, models, data sets etc.) to load into the cache and you're ready to use any application, on any device, be it your IOS or Android phone or desktop computer running Linux, Windows or Mac.
Most device APIs that frameworks like Corvoda currently provide will be covered by the browser natively, just like notifications, cameram etc. are already supported.
The "Write once run everywhere" concept will finally be achieved making the web the ultimate application platform.
PWA?
Yeah, sort of.
There were 3 general problems holding web apps back so far:
- Performance, it just never really came close to native.
- APIs, like camera, sensors, filesystem, network etc.
- No support for other languages, no reuse of existing code and no flexibility.
While APIs were solved by both the browser vendors and frameworks such as Cordova - performance is the part that never really got solved until now.
Now that we have WebSockets, ServiceWorkers, WebGL, web browsers on all platforms, wrappers like Cordova and finally WASM - it's time for the web to take over most mobile and desktop apps.
The only thing that really bugs me is the DOM, which was never supposed to be used for dynamic UIs. Its a great way to describe a static document with a couple of interactive features and a really terrible one to build a dynamic modern application. Most modern UI frameworks such as Vue, React, Angular and similar are all emphasizing data binding and modularity which the DOM doesn't offer. We lose a lot of performance and memory on unnecessary layers of abstraction.
It's still very (!) hard to achieve close-native 60 fps butter smooth dynamic UIs without micro-stuttering and not eating up tons of RAM, CPU cycles and battery, that's the only reason app stores still exist.
I think we need to change the way we build web apps and I'm particularly interested in building a language similar to QML (Qt Metaobject Language). QML as a product of the Qt Company itself is not suitable for the web, it's rather the concept of the language I'm interested in. It's basically a combination of JavaScript and a declarative, modular and highly dynamic UI description language. There's no separation of "styles and markup", it's all about "components & properties", you defines components, their properties, bindings between the properties of different components and embed JavaScript logic in it (the view logic ofcourse, though the business logic can be done in separate components). Now that we have WASM and WebGL - there's almost everything we need to build a high performance scene graph backed by a language similar to QML.
I may be wrong about the DOM because it's also evolving very fast, for example: one of the problems that really annoyed me - was fixed just recently in Chrome, it's related to element-queries, a way for CSS to be applied conditionally based on the dimensions of the parent element rather than the entire document, it's called the ResizeObserver. But still, this API is only available in chrome making it only half as awesome as it could be. If such a feature was introduced to a scene-graph based on WASM and WebGL - it would automatically immediately work on all browsers and devices. Thus I think browser vendors should focus on providing a rock solid, flexible APIs such as WASM & WebGL rather than trying to turn HTML/CSS and the DOM into an application GUI platform, let the industry and communities take care of the rendering.
Sounds terribly scary in terms of security/potential vulnerabilities.
What's exactly scary? What potential vulnerabilities do you mean?
Possible vulnerabliities.
The code is compiled... so you don't have the ability to block resources like you can currently do in noscript.
Lack of transparency... Will be a case of trust who you download from..
"Javascript has validation rules". That's a good joke.
Wow! This talk just blew my mind. This is a tectonic shift which will change the web and primarily web development as we know it.
AI makes your job uncertain. This makes the usefulness of the tools you now know uncertain because of competition with other humans. Great!
For most web applications, JavaScript is the best option. Web Assembly is best used for computationally intensive web applications, such as web games.
on webassembly you could use your gui library of choice that does not limit you to javascript/html
JS can easily die if a RUST to JS transpiler is made
Ok
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.
I wouldn't call JS the most flexible language. That award should probably go to Haskell, as you can express nearly any abstraction you want there and for those which are hard to express you can write a DSL in it (and if Haskell were to get linear types and full spectrum dependent types, it would probably become the most expressive language in all categories rather than most).
Really, all practical languages are Turing complete, so they all can all do what each other can. So the expressiveness probably means the ability to build reusable abstractions (which are represented efficiently in machine code).
Pure Javascript is pretty expressive, but you generally shoot yourself in the foot with it in a big project because it's more efficient to use a type system and a compiler to catch bugs rather than hoping that programmers will never write code with bugs in it or that they will write unit tests for bugs which can be prevented automatically if you use a type system. So big project start to use a type system on top of Javascript. Typescript in particular is pretty expressive as far as type systems go, it has algebraic datatypes / disjoint unions, records, generics. But it's not as flexible as more powerful type systems.
3 years later....
More than 18 months now.. Is Javascript unconscious or half-dead at least or hospitalized?
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.
Vladan Kardasevic a major difference is that AS3 was a product, but WASM is a web standard. because of that it's already native to the major browsers. also WASM completely different to AS3. maybe AS3 will make some kind of return thanks to it
Performance? You're concating that string back one by one in JS. Oh my.
ya shocked like I was :)
Haha, also complaining about there being a lot of javascript when using create-react-app... /Facepalm like
it's not so much javascript i target the simplicity off thinking that a browser lives under system level , the complete insain asynch went out in a binary that does much more than the W3C and jquery originated, I can launch a code with 2 lines C that makes a win10 and Google litterly collapses in the system , as simply it is to run 2 accounts request a callback inside the tag classed container as CSS 3 and a html tag wrapped in a real call straight inside the service broker, now if that's JS ASM been aware :) it is a children playground on one framework that matters in Global namely Sencha , As my BCD relation is since 1990 and have a a no problem with programmers in higher level, but respect the engines off low level as the knowledge off language is such a debate in a system that speaks binary , the difference between a programmer and a coder is plain simple we speak to a device not to a script LOL , btw vs stydio code is owned by Telerik which bought Senchas framework 5 yrs ago last summer 4 weeks later that MS joined Prohress (mothercompany off telerik) IDERA bought again Sencha , so with fmsoft there are 3 oem senchas but Sencha self never sells the piece ext.js containing a outside DOM execution level as a element on a html simply get's a push target to the complete inline block a grid container scrolls with this approach as no rerendering nor DOM garbage simply cause that's coding all the rest is a peice off ducktaped helpers fixers and hacks, in my believe a browser is still simply an application, so basicly it can behave as such but it makes no sense at all when the UI runs in a browser which isn't webserver depended , so the world is become to pint zero in crazyiness, and we create a open door one which penetrates without effort nor 'criminal action' simply put code as the telemetry want's controll the service REST and SOAP will serialze a chain reaction ,
@@marcvandenbroeck3792 can I have a beer with that word salat? 😋🙂
Horrible title, by the way. Total click bait and worthy of ridicule for multiple reasons.
Anyway, that aside...
What is being spoken about here might be relevant for a handful of companies who have inexhaustable budgets and who care passionately about page load speed. I can definitely imagine a future where the makers of - say - Angular, start using a version of TypeScript that compiles to WebAssembly. However, I think that any attempts to steer the general web development community away from JavaScript will ultimately fail ...and that's a good thing!
The JavaScript community is just far too big at this stage, to drop their tools for WebAssembly.
Of course, a primary motive for increasing page load speed - out there in the marketplace - would surely be to boost SEO ranking. Sites that use (entirely) JavaScript front ends perform poorly on the search engines and I'm going to stick my neck on the line and say that switching to WebAssembly won't change that.
JavaScript is here for the long run - the long run being at least the next ten years. Even though JavaScript may not be quite as performant as WebAssembly - history has shown over and over that practicality and/or profits usually trumps ingenuity, in the marketplace. Just look at the combustion engine (still hanging on after all these years), how central heating works, the toothbrush, the MP3 audio format, fax machines, the (paper-based) voting system along with the sale and transportation of bottled water for examples of things which are far from technically efficient, but are still being used all over the world.
If I worked for the same company as the speaker (I checked them out and I understand they build trading apps and other very high tech apps) then I would absolutely be getting involved with WebAssembly. However, for the 99% of developers who never get involved in those kinds of projects, this is a big bum steer.
Instead of constantly looking for the next big thing (framework / language / whatever), I think it's a much better idea to use what is already out there to build something amazing. Being a technology evangelist is not a good strategy for putting food on the table.
You are talking out of my heart!
Spot on.
they don't have a clue what they produce, we call it a portal, where the browser uses just an entry , game ends then Sencha ext-js, C is only for thoe 99% unuseable cause the knowledge stops when it goes allocating memory , cpu cycles, adress space overlapping, defining a framework is a UI matter as the sell is simply a stolen open source called .NET where every process simply can be closed by the WM_ table , search the title , send WM_CLOSE, done, bravo :) , base code serverside and a UI is completely not what a browser you let run in, , About Js , ya also need be carefull as it's a huge risk factor, and the rendering goes completely wrong when browser think knowing better than the coder, .... ,
marc van den broeck I challenge you to return here in one week, read your own comment and see if you can make any sense of it at all.
I have no issue debating , wasm IS NOT A PLACE TO EXECUTE IN A BROWSER !!!!! , that's the FACT and if ya can't handle that omment I gladly speak in Personto person, as a lot got tweaked and I do know how what happens, i'm no so lone ryder, have Company, did ASM X86 since the first IBM PS/2 , wasm is idiotic to inject Assembly is machine code related, WEB is an unified indepedent static HTML as code text that browser made visiable under any OS, NOT for execute code, ya have my contact, I gladly debate this, as there is a lot off fools up thinking been IT core, if ya know CPU architecutre and have binairy hex , know x86 has 4 registers differt as 2 segs /reg AX,BX,CX,DX that's 64k /seg , it's not so UPnP , address space and serialize against cpu in good code makes cpu no readdress , I get the kreeps if I see code like var x="test", what is the pre-define off var? x="reserved type as variable in bytes char ,short,lon,int,float,double, all iss 1byte,2 4 8 16 32 64 ,even a boolean is 1 byte still it's just oe bit, if ya code and totall off one memory push is not alligned , creates readdress as cpu has put current code out in memory set pointer recalculate unalgned execute,move, get the process back by the pitr in a stack call, get the talk? Know how in gods sake ya think those open source ducktapes jumbo's goonna use this? NOT, the browser will do it as an OS, this makes no sense as it design is talking http under protocol 7 TCP , which was assigned port 80 443, I see browser doing loopbacks against the client system once the PID has a connect it's out, this in a container executing wasm, can go back but dive under the "so called OS kernel", if ya give this out , I assure ya I can code direct an asm triggering any device ,change the RPM off disk, CPU , I blew up lot's off devices , but this was under closed community not for public, today there is so called www-http managment? HOW foolish it can go, i'm no "hacker" as these gen, I have deep insicght and C experience, and if I tell C means , I wrote all out as my API, no librarys,no dependencys, took 10 years, the UI is no intrest but server side I don't like a browser trying to do this as I answer with a non http killing the browser , victim is user and company , keep in mind I coded a webserver application just for browser as users seems no issue with installin apps or addons, but installng application is too much, a browser is an application , only is pre-installed, so only this move makes the data exchange from 20msec to 300msec, with 6 TCP sessions , and all the crazy workers arround it , abuseing the 8080 cache, rest we discuuss in private ok :)
26:03 guy has heart attack for the information overload and feat of WASM Fatigue.
Ahahah
39:30 AutoCAD has now fully embraced WebAssembly. Here is a recent talk given at the Google I/O: ua-cam.com/video/BnYq7JapeDA/v-deo.htmlm45s
If speed has made some language died in the past, that won't be a usual case, Php is there, Python is there, Nodejs is there. On the other hand flash has died, Silverlight has died, ActiveX has died, Dart has never been popular across the web browsers. Can you debug webassembly in the browser as easy as javascript? That day may never come. Can you debug Silverlight .net code in browser? yes, but did it die? yes. So? Honestly there is nothing can prove webassembly applications can even take 5% off javascript's market share, there are really not many applications that are AutoCAD or game.
Javascript is SLOW. You need to compare real world application, not some soup up application you wrote in a day or two to be biased. Figma shows how wasm runs circle on Javascript. If you were to move object on the canvas, you can see how javascript lags and how wasm does not lag. A few millisecond of performance makes a HUGE DIFFERENCE in productivity. People should not wait for computer, computer should wait for people. Javascript does not cut it for performant graphic application.
You need to get out there and use what people use to compare javascript vs wasm. Thumb down! BTW title was clickbait, another thumb down. ahaha
The death of Javascript? :D Get yourself together man....
even in his webassembly hello world demo the javascript code was longer than his webassembly program. wtf?
Nikolay Megdanov JS is going out boy, get used to it
It's already dead. Web is vast and public. Many can write in node, fewer C#, fewer C++, fewer C, fewer Assembly, fewer bytecode... and there's a reason for that. Web is not a bootstrapper or a kernel.
as a software developer with decades of experience i really hate javascript from the bottom of my heart.
the hello world example showed how completely fucked up that is and now i saw the "webassembly hello world" the third time and it is still a javascript hello world program with a string coming from webassembly and it is not a webassembly hello world.
together that is really a bastard and the most ugly and complicated version of hello world that i saw in the last year.
in other non-perfect languages like c this just one line of code.
printf("hello world!
");
In short, failed attempts to squeeze out even more performance by making web programmers' lives even more complicated and unpleasant.
It's going to be such a pleasure to debug this "webassembly" once it starts fucking up hidden 7 layers beneath your application code.
I hate javascript and the way everyone makes all these "compilers, transpliers, minifiers, etc.." makes it even worse. It turns something that should be simple into something overly complicated.
Silverlight is essentially the same as windows app. Android copied the framework... Apple are also doing it.... the first version of silverlight used javascript instead of c# (the js version was the worst version by far)
its possible to make an processor with the same instruction set that web assembly have,? and that could improve the performance of the processor to run web assembly apps?
That would be super cool! Make a machine that just runs web apps on metal. :)
i just found out that some one is trying
github.com/WebAssembly/design/issues/1050
on an fpga not an asic, but, still!
It behaves more like java bytecode that gets converted into machine code by a JIT compiler.
Modern javascript is actually compiled by the browser at runtime and runs on "bare metal".
Most of the slowness is a result of the way memory is managed by modern managed languages.
When you allow the programmers to completely ignore memory management you have to do alot of redundant checks and hold alot of extraneous data structures that describe the actual data types and then you have garbage collection algorithms. Its essentially death by a thousand cuts. You have tons of heap allocations going on behind the scenes.
8:17 example is said to be Fibonacci but does not look like it.
Fibonacci in JS looks exactly like calculating powers in C, this is the main reason we need to replace JS.
PS as PWA omg the performance will be even worse than we already have. Autodesk with WebGL (I wonder why poems want more control over resources?)
Javascript is just hitting its stride. It's got a long ways to go yet as a language. Webassembly will only enhance its utility, not diminish it.
Death of JavaScript? We should be so lucky...
"WebAssembly will kill Javascript !"
Javascript: - Hold my beer
Javascript will not die if wasm gets everywhere ... Java script will become a matter of taste and team culture as any other language ...
Death or the right complement for high processing demand ?
Amazing talk. Very informative and insightful. Thank you.
25:00 java does not run on wasm, but the jvm could be executed in wasm :D
The fact that JavaScript still is used todat is a testament to the masterpiece created in 10 days, incredible!
>masterpiece
>dynamic typing
pick one
I've been reading about the death of javascript for about decades, languages don't die guys, just evolve
what about fortran, ada, cobol, pascal, oberon, pl-1,.....
3 years later. JavaScript is still the king
Too bad Rust is not the prettiest language to look at...
definitely not as visually appealing as say ooc-lang.
Hm, I find it pretty easy to read. Around the same as something like C#, but easier to reason about.
Right. Good luck trying to do decimal manipulations with Javascript.
Javascript is a joke that simply went too far.
No, you are the joke who didn't understand JS enough
Technically you can use decimal.js
Does the web assembly run time need a garbage collector?
slr150
As long as you can use C's free (), than no.
I don't know if you can, though. What is needed is "once a variable falls out of scope it's memory is usable again".
I don't know how the heap and stack is handled is the wasm VM, but if it works as any other vm or CPU, a GC can be put on top of it.
Looks like there is no multi threading in the wasm specification therefore; traditional GC wont be possible . Given that it's single threaded, I think you should be able to use reference counting (preferably at compile time).
slr150
You don't need multi-threading, but it helps. You can do an event-loop based system and have a mark-and-sweep task kick in now and then...
But that is still basically just ref-counting in the end.
I know that GC can be implemented without multi threading that is why I said "traditional GC" . I think for single threaded and non polymorphic input languages, it should be possible determine when a variable goes out of scope at compile time.
slr150
There is always __attribute__((cleanup(func))) in Gcc and Clang.
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.
2021... Still not dead...
webAssembly will fail. Cause it is complicated, nobody wants to learn C? You know why? Cause it is complicated. It is ok if you go to do a degree in expensive university!
Webassemby is essentially native code for the browser. You should be able to compile other language into it not just c
Javascript left the chat
Important to mention that Kotlin already supports Web Assembly via Kotlin Native (a platform for developing native programs in Kotlin - kotlinlang.org/docs/reference/native-overview.html ). Kotlin Native has some basic JS interop that covers some Web APIs (eg DOM, Canvas). Already Kotlin is far ahead of many other programming languages when it comes to WASM support (incl Swift). Can find a Kotlin Web Assembly sample here: github.com/JetBrains/kotlin-native/tree/master/samples/html5Canvas
Some significant factors contributing to Kotlin successfully targeting Web Assembly is Kotlin Native's flexible memory management (Kotlin programs/libraries use ARC with cyclic collector, and manual memory management is used with C interop - ua-cam.com/video/DqsYo_4QWSg/v-deo.html ), and Kotlin's very good platform/language interop (APIs and tooling).
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.
"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.
oh my god, it is so great, hackers will be able to destroy the MBR or the GUID of your HD or SSD and even your computer from a webpage or a nodJS file using webassembly.
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
Beta was a superior video technology to VHS but it died because of lack of adoption.
The relevance of a language is dependent on more than just its technical superiority - Ecosystem is what makes a Language. I'm not saying that Web Assembly won't replace it I'm just saying that you shouldn't think it will replace it simply because it maybe a 'superior language'
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.
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.
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.
Yea, first of all clickbait title. Second WA wont kill JS. :) WA has it's benefits and areas to use. Majority of programmers won't write code in WA. Transpilers will do the job thankfully. JS will stay and probably evolve. So no need for drama, no need to learn a new language if completly new ecosystem every darned year.
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.
the opening question turned me right off. JavaScript is more popular now than ever. its not going away. unlike me, I will leave this video now and not waste 40 minutes
Javascript isnt going anywhere, not in you lifetime or your children's....
"This is C, which is horrible and dirty"
*TRIGGERED*
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).
Is the person referred to in the beginning as a Chap really a bloke?? Also is the speaker in the video British or from Australia??
Technologies never die. You can still buy new ploughs that were designed in the middle ages. However, as someone who is used to typed languages, like C++ and C#, it is nice to know that maybe some day I will be able to get into web development without being forced to use a language that makes me gag.
you can do thegarbage collector sure but you should still let people manage their own memory if they want to go to the effort
I'm not so sure about the title, now that VueJS has grown to prove the power of JS is finally used as intented
Death of JavaScript, riiight...
I watched it through, interesting talk. WA - good for integers, difficult for strings. Who needs dom manipulation anyway? My bet is JS ain't going anywhere.
Agreed. What if parsing, compiling/optimizing and reoptimizing got faster, like it always does every year?
BTW, there is no "real" fight with JavaScript anywhere in sight. Plenty have fought and lost to it. But be my guest dear WASM.
Did you listen to the talk? He doesn't claim it will be the death, but rather that JS won't be a monopoly anymore. That for some situations, like PWAS, or WebGL, Source-Map Computation etc, we can skip JS that we chase down optimizations and just go with native code, i.e. we will have options. That's it.
I literally came just to type the same comment.
Did listen to the entire talk. Did you read the title?
He should have stuck with the title in the description - "WebAssembly and the future of JavaScript".
Of course, in the talk, he quickly retracted/corrected his statement. And while there is definitely value in WASM for code where absolute speed is of concern (ie. transcoding, physics, rendering etc.), the "for-apple-to-win-microsoft-has-to-lose", click-batey-title was unneccessary.
i think wasm will be at least 10 time faster then javascript in the final release
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.
i still dont get the idea of glsl on web like what are you going to do with it? full blown 3d game on web that runs poorly and not responsive? or some 3d web app that burns ur gpu? or some useless 3d animation that we see on codepen?
Java Applet reboot.
Calling it "new"...
keep living in ya closed vision, the web != any code based system so keep browsing meanwhile i go further protocols0-256 with every nr a 16 bit port range so have fun wir ptotocol 7 TCP or discovered UDP? left over 253 protocols ,before binding a machine code into a transport layer YOU FAIL MY TEST
Gopher.
Jabascript: you underestimate my power.
I was surprised by the bench mark that JavaScript run faster than web assembly!!! @ 18:54 . So wasm only shines at initial compilation time compared to JavaScript as JavaScript goes though many optimisation process.
Eh, I suspect that for apps that allocate a lot of memory, WASM will be a lot faster - and more importantly, predictably fast, without sudden slow downs as a GC runs. Why? Because memory reclaiming is statically known, and always the same. Consistency.
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.
Rust comes very close for memory use, and in execution speed (its a bit slower, because of mandatory array index bounds checks and the like, when they can't be statically proved to be safe at compile time).
But yes, very few others come anywhere close.
Damn good wrap up. Wish up vote x 100
So JavaScript started out as the assembly for the web, now we have Web Assembly. You know what makes even better assembly code? Assembly code. Compilers have been doing this job for half a century. Can we just use those?
Can you run the same assembly code on multiple CPU architectures ? No, of course not. This is why higher level languages like C were created.
So we will back to assembly in meanwhile...
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
Streaming compilation does reduce that latency very significantly, though... and not having to JIT (and GC) reduces it even further. Plus, WASM bytecode is much smaller size than JS text format (inefficient!)
something is definitely wrong with the new shit..
@ 5:25 Compile + Optimize Time Doesn't Angular AOT solve this? Browser still has to Parse it
I agree that web technology should move towards a compilable version of JavaScript however implementing a declarative programming language instead feels like a step backwards rather than forwards. Actually, I still don't really feel the bottle-neck is on the front-end. The bottle neck is network latency and back end processing which is why there is still a debate over what is the right language to use (NodeJS is one of them).
It doesn't matter, you can compile any language you like to WASM. Don't want something declarative? That's fine. Don't use a declarative source language.
Well, since React will just compile to that... :)
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
18:30 The Death of Your Talk
Silly and disingenious. Maybe you skipped through the talk and missed [31:30]?
Very interesting and informative! Especially the first half
Surely there will be a language that we can compile into this?
you already can use rust and c/c++
Seems a bit overly complex to me - Why not stick with Javascript and then compile it to (Web assembly) byte code?
...and we are moving back to multi-threaded environment which will grind to a halt when the user base surpasses a certain threshold
Client side == single user
Not possible, it lacks the necessary information around types and memory allocation & deallocation. TypeScript will deal with the type issue, but not the memory issue. Could ship the GC with every file, but this will make them needlessly large. Or wait till WASM implements its own opt in GC. Problem is it might not be compatible with how the JavaScript memory model works.
The dominance of JavaScript on "the most ubiquitous application platform ever" is not a historical accident. This is not to say the WebAssembly is a bad idea, but if you don't understand how the features of JavaScript made it dominant on the web, and in turn made the web the dominant application platform, you're going to have a bad time.
Incidentally, this is also a problem for JavaScript itself, when it comes to adding new features. Looking at you, SharedArrayBuffer.
Hold on.... did I get it right -- his benchmarks showed that WebAssembly is executing somewhat slower than JS. So why again do we need to jump over to webasm?
There is an ignorant cult of people who were forced to use JS, who didn't understand it, and instead they just ridicule it like pathetic repeaters.
It's much faster to start running than JS, and has more consistency because no GC. It's also smaller in size (in the actual binary encoding, not the text representation), and therefore takes less time to transfer over the network
Also importantly, because you can compile to it from multiple other languages, it means you can have the same language for front AND back end, and they can share types. Means they never get out of sync.
I dream to code C/C++ with HTML in the future sooon...
How?
no html. direct control of the screen and the graphic library of choice like qt or similar.
By 2020 Web Assembly may rise, but Saying that JS is going away is under-statement.
I think JS engine will be more faster by that time.
Only area i think Web Assembly would shine is Game Programming
Piyush Katariya i think if ruby and python can be compiled to WEBASM then beginners in coding will use them more so for beginnrs JavaScript usage may drop
Harjit Singh Python and Ruby are dynamic languages and their transpiler which emits JS code already exists. CoffeeScript can also be used which is sort of Python + Ruby like languages. most people in RoR community uses it
Piyush Katariya yes i know about coffeescript but its usage is decreasing and people are moving to other popular frameworks, ive seen vue gain some attraction recently with rails. And i didnt know their transpilers existed, i will do some research into that lol