Slashdot Mirror

← Back to Stories (view on slashdot.org)

Will WebAssembly Replace JavaScript? (medium.com)

Posted by EditorDavid on from the WebAssembly-language dept.

On Tuesday Firefox 52 became the first browser to support WebAssembly, a new standard "to enable near-native performance for web applications" without a plug-in by pre-compiling code into low-level, machine-ready instructions. Mozilla engineer Lin Clark sees this as an inflection point where the speed of browser-based applications increases dramatically. An anonymous reader quotes David Bryant, the head of platform engineering at Mozilla. This new standard will enable amazing video games and high-performance web apps for things like computer-aided design, video and image editing, and scientific visualization... Over time, many existing productivity apps (e.g. email, social networks, word processing) and JavaScript frameworks will likely use WebAssembly to significantly reduce load times while simultaneously improving performance while running... developers can integrate WebAssembly libraries for CPU-intensive calculations (e.g. compression, face detection, physics) into existing web apps that use JavaScript for less intensive work... In some ways, WebAssembly changes what it means to be a web developer, as well as the fundamental abilities of the web.
Mozilla celebrated with a demo video of the high-resolution graphics of Zen Garden, and while right now WebAssembly supports compilation from C and C++ (plus some preliminary support for Rust), "We expect that, as WebAssembly continues to evolve, you'll also be able to use it with programming languages often used for mobile apps, like Java, Swift, and C#."

22 of 235 comments (clear)

  1. No by Anonymous Coward · · Score: 5, Informative

    From the web assembly web page:

    Is WebAssembly trying to replace JavaScript?

    No! WebAssembly is designed to be a complement to, not replacement of, JavaScript. While WebAssembly will, over time, allow many languages to be compiled to the Web, JavaScript has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web....

    1. Re:No by Xtifr · · Score: 5, Informative

      It's being developed by Microsoft, Google, Apple, and Mozilla, and has been demoed in beta versions of Chrome and MS-Edge already. Mozilla is merely the first out the door with an official release.

    2. Re:No by JDG1980 · · Score: 3, Interesting

      No! WebAssembly is designed to be a complement to, not replacement of, JavaScript. While WebAssembly will, over time, allow many languages to be compiled to the Web, JavaScript has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web....

      That's disappointing. JavaScript is an absolutely terrible language, and it's insane that it has been the only choice for client-side Web scripting/programming up until now. Hopefully this is just diplomatic BS. Once WebAssembly is updated to support access to the DOM (the current version can't do that), then there is no good reason for anyone to use JavaScript for anything ever again.

  2. First Webassembly malware post! by slazzy · · Score: 3, Funny

    Yeah!

    --
    Website Just Down For Me? Find out
  3. The cloud by Anonymous Coward · · Score: 5, Insightful

    This new standard will enable amazing video games and high-performance web apps for things like computer-aided design, video and image editing, and scientific visualization...

    But I don't *WANT* to do that shit in a web browser. I want it to live on my local computer where companies can't charge me $5, $10, or $250 per month or I lose access to all my critical data.

    I'm still astonished that one of my clients is running a Linux mail server and it works perfectly for them. Their total cost over the ~8 years they've been running it has been about $1,000/year, and most of that is paying for us to add new users, create mailing list/groups, and remove fired employees.

    Their first year on the Exchange 358 cloud bullshit would have cost them approximately $15k in licensing.

    1. Re:The cloud by Anonymous Coward · · Score: 3, Funny

      It's cute that you're your small town IT guy, but real businesses where people deal every hour with more money than you make a year require professional software, and that's where the quality of advanced offerings from Microsoft shine.

    2. Re:The cloud by Pinky's+Brain · · Score: 5, Insightful

      Since small businesses make up most of the economy I hope we don't run out of small town IT guys.

      The professionals seem comparatively completely fucking useless.

    3. Re:The cloud by lucm · · Score: 3, Interesting

      Their first year on the Exchange 358 cloud bullshit would have cost them approximately $15k in licensing.

      For a service similar to a Linux mail server, that means they have 250 users (Office365 = $5/mailbox). I don't know how fast you can drive to their office but if their Linux mail server crashes or gets stolen, that's 250 people with no email for as long as it takes for you to fix the problem.

      On the other end, if the office loses internet connection (which would also make a Linux server useless), those users can still access their Office365 email from their phone or home internet connection.

      Email is a commodity and it's a no-brainer to outsource it to a provider that benefits from economy of scale and state-of-the-art data centers staffed 24x7.

      --
      lucm, indeed.
    4. Re:The cloud by AchilleTalon · · Score: 4, Insightful

      Even if I share your comments, the original point about Web Assembly has nothing to do with what the poster complained about. I mean, Web Assembly doesn't introduce that problem, it is already there for decades. So, I welcome Web Assembly for what it is, a mean to increase the performance of applications in the browser. Now, should we or shouldn't we have complex applications in the browser and which ones is another matter.

      However, the browser is a convenient way to distribute applications inside an enterprise. In that case, you don't have thousands of unknown parties trying to hack your browser and making it crawling instead of running.

      I would probably prefer enterprise applications based on Web Assembly than on Flash or even mostly Javascript.

      --
      Achille Talon
      Hop!
  4. Re:Hard to argue against Betteridge here by luismontbau · · Score: 5, Informative

    Well, Google Chrome 57 also incorporates WebAssembly, and soon, so will Safari and Edge. If you're interested in the future of the web, I suggest you read all the articles, they are quite interesting. I think it's the only chance the open web has against walled app gardens.

  5. Re:Maybe in the long term by Richard_at_work · · Score: 5, Interesting

    Meh, not so much - its the *default* language for clientside web interaction right now, and thats the *only* reason it has the establishment that it has.

    The only thing that would have to happen for Javascripts domination to be threatened is for multiple browsers supporting something better, and thats happening with WebAssembly. Once developers realise they can stick to their language of choice and cross compile to WebAssembly, thats pretty much game over for JS - think of all the reasons touted for using Node.js, just this time think about them being used against JS...

    I wouldnt be at all surprised to see a significant shift start to happen in the next 18 months.

  6. Chrome too by campuscodi · · Score: 5, Informative

    Google also officially added support for WebAssembly in Chrome 57, released 3 days ago, btw

  7. JS "programmers" are too incompetent for that by gweihir · · Score: 4, Informative

    WebAssembly will primarily allow real coders to write applications that run in browsers. No JavaScript wannabees need to apply.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:JS "programmers" are too incompetent for that by Anonymous Coward · · Score: 5, Insightful

      SO much this.

      The reason JS gets so much hate is not because the language itself, it's the horrific fucking developers that (ab)use it.
      Most of them abstract the damn language away under shit like jQuery that adds a metric fuckton of overhead to the language.

      It's not even amateur small-time devs either, it's huge ones too.
      So-called Enterprise-quality code, full of high-overhead code for very little functionality, said overhead only there to prevent IDIOTS from making mistakes.
      Google even do it. Youtube, Gmail, Maps, all slow as fuck now. Try run ANY of those on a machine from even 5 years ago, never mind 10. They are even slow on modern hardware for NO FUNCTIONAL REASON, just lazy developers writing high-overhead code for obfuscation / low-transmission cost reasons. (yet it would be far easier to compress your code and decompress it on client end, then run THAT, insanely faster too)
      The HTML5 video system is so slow it is funny, especially since most major browser vendors are pushing for its replacement as primary content source for video over Flash. The piece of shit spec has barely any support for hardware emulation on old or NEW hardware. The levels of inconsistency in HTML5 video is nuts. I've seen old machines handle it fine, yet something from past 2 years choke on it. It is a horrible, horrible spec not even remotely close to being complete.
      As much as I hate W3C for their monolithic nonsense of yesterdecade, they were 100% correct when they said HTML5 wouldn't be complete until 2020~. 100% correct indeed. The amount of syntactic sugar in that spec to cater to retards that refuse to learn the language is only going to make things even slower.

      It happens in loads of other languages as well.
      PHP another common one. The PHP community is horribly stupid as a collective. (including ITS own developers!)
      Python is another. Python suffers even more so because it is ridiculously high-overhead NATIVELY, it is horrendously slow. I have no idea why people can stand it. Even for prototyping it is bad. (more so because the syntax is horribly different from most languages)

      Idiots are ruining the programming community.
      They've made the entire industry horrible to live in.
      If you know anyone considering programming, tell them fucking no and get in to computer science instead. Or mechatronics or something else interesting. That one in particular will be a very good one since robotics is a hugely growing industry.
      Programming is a dying area. It's saturated with IDIOTS that are too lazy to learn languages, so ask "smarter" people on Stackoverflow or similar sites.
      There's literally summer courses in programming that teach people to ASK questions on stackoverflow! (fucking India)

  8. Re:Native code running in the Browser? by NoNonAlphaCharsHere · · Score: 5, Funny

    Yaaaaayyyyyyyyy!!!!!!
    I, for one, cannot wait to load webpages with near-native busy-wait code written by some amateur to do really really useful shit, like check every 7 seconds if there's been an update to their homepage (a la Huffington Post).

  9. Re: Native code running in the Browser? by Zero__Kelvin · · Score: 3, Informative

    This has nothing to do with Active X, and furthermore your implication that if Microsoft tried and failed at something then nobody else need try is absurd.

    --
    Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  10. Looks good to me by steveha · · Score: 5, Informative

    I read through the fine articles and even watched a couple of the videos. Overall this looks like a good idea to me.

    The basic idea: WebAssembly is an assembly language for a virtual machine, which is very easy to translate into native code. It was designed to be compact so it will download quickly; in particular they chose a stack-based virtual architecture so that an "ADD" instruction implicitly adds the top two numbers on the stack, so "ADD" and similar operations are always single bytecodes. Also, while JavaScript only has a single "number" type which is implicitly float, WebAssembly has multiple built-in native types including 64-bit integer.

    It should be no less secure, and no more secure, than JavaScript. However almost all the overhead of an interpreted language is gone: instead of just-in-time compilation, detecting "hot spots" and optimizing, and de-optimizing when assumptions are invalidated, all the browser has to do is translate the virtual machine code into native code and run it.

    For the initial release (i.e. right now) WebAssembly does not support garbage collection. This is a sensible decision given what it is and what it does, but they said they will look at giving it some GC abilities in future releases.

    I like the original idea that JavaScript would always be human-readable and people could learn by studying the code from the sites they visit. However, this idea is not really active now. It's common practice to run JavaScript code through a "minifier" that packs it to make it as small as possible so it will load quickly, and minified code isn't very friendly to read. There are tools available to somewhat beautify minified JS, but I'm certain that there will be tools to "decompile" WebAssembly and produce something sort-of readable. So while in this one area WebAssembly is not quite as nice as JavaScript, I don't think it's a significant thing, and it's not even remotely enough to make me oppose WebAssembly.

    Developers will be able to take existing code in languages like C, C++, etc. and compile them into this portable virtual machine language, and web browsers will be able to load and run them quickly. People will be able to write browser apps that run at near-native-speed and they will run on all the major web browsers and on whatever CPU you have (x86 and ARM for now). I don't really see a downside and I see lots of upside.

    --
    lf(1): it's like ls(1) but sorts filenames by extension, tersely
    1. Re:Looks good to me by steveha · · Score: 3, Informative

      the small benefit of JavaScript is that we can disable it and/or prevent certain function calls if you want to (e.g. my browser asks me if alert() is allowed to trigger or intercepts audio() and video() tags etc etc.

      All I know about WebAssembly is what I read in TFA but I'll bet you that it will still be possible to block API calls exactly the same way. In fact, if my understanding is correct, WebAssembly doesn't come with any API calls; it will need to ask JavaScript to do things like pop up an alert().

      Here, have a link I Googled up for you. Here's you you do an alert() from WebAssembly: you import alert() from JavaScript and call that.

      https://gist.github.com/cure53/f4581cee76d2445d8bd91f03d4fa7d3b

      So whatever you are doing right now to forbid alert() would continue to work when your browser downloads WebAssembly code.

      If you're going to obfuscate calls even further into machine code and allow for code to run directly on a CPU and manipulate memory without the capacity for inspection, you've given up all control.

      I've already made my position on that clear. Bytecode is less readable than minified JS but not by that much.

      Plus I don't actually pick apart all the minified JS my browser is running and inspect it in advance. And I figure with GMain and such my browser is running a lot of minified JS.

      --
      lf(1): it's like ls(1) but sorts filenames by extension, tersely
    2. Re:Looks good to me by steveha · · Score: 3, Informative

      allow for code to run directly on a CPU and manipulate memory

      I missed this the first time around. WebAssembly is sandboxed exactly like JavaScript is. It is neither more secure nor less secure than JavaScript.

      --
      lf(1): it's like ls(1) but sorts filenames by extension, tersely
  11. It will be slow anyway by Blaskowicz · · Score: 3, Interesting

    Obviously this will allow much faster "apps" but we all know what that means. Tons of "features" i.e. yet more bloat and "innovation" i.e. new version of shit that looks like it's for cell phones and runs 4x slower.
    Javascript engines got a lot faster a few years ago and all we got was a ton of garbage and google making their "Maps" excruciatingly slow unless you run brand new hardware. Also, javascript Doom got taken off the internet for copyright infrigement and all the games are on Android Google Play anyway.
    Devs, stop masturbating to your i5/i7 laptop and your Samsung S7 and don't forget to also test on sensible specs like 1GHz and unsupported AMD graphics. People aren't interested into upgrading every other year to a computer that can run Crysis just to do the same things we did back in 2005 or so.

  12. Re:Miss out on apps not ported to your OS by epyT-R · · Score: 4, Interesting

    What's better: using a JavaScript or WebAssembly app in a web browser and having it fuck up your workflow when it magically changes/disappears one day, or having to run a specific OS to run a native, local application that's there forever until you choose to abandon it?

  13. Inner Platform Effect by CnlPepper · · Score: 3, Informative

    I'm just going to leave this here: https://en.wikipedia.org/wiki/...

    If you want native speeds, use the OS. This is doing nothing more than complicating development - now rather than just OS differences you have every possible permutation of OS and browser to deal with when bug fixing.