12 ms·

Web assembly always makes me a little sad. It feels like we are going back to flash only it won't be bad this time, I promise, no really. I always feel like th

Web assembly always makes me a little sad. It feels like we are going back to flash only it won't be bad this time, I promise, no really. I always feel like the most obvious use for it is to start writing truly hateful and abusive code. I'm sure this is because I'm getting old.

nwah1 11y ago
The important use case is to allow people to write web applications with their language of choice, instead of horrible javascript. And get near full performance.
- klodolph 11y ago
  I think this is important. Probably because I have the "worse is better" article from 1991 open in another tab, and if you s/Lisp/Javascript/g then many of the criticisms ring true. Some of what made Unix, Windows, and Mac OS healthy environments for development was the fact that all developers were equally well off, you didn't have to pay a tax for writing something in a language other than Lisp. You could keep your Fortran code, and mix it into a C program, run from a Bourne shell, running in terminal emulator written in C and a WM written in Lisp. You can replace any part with a part written in a different language. JavaScript will continue to be dominant, but we desperately need to be able to write things in the language of our choice.
  - nostrademons 11y ago
    Hmm? You paid a huge tax in desktop development for writing in a language other than the one the OS was written in. All of the platform documentation & examples were in its "native" language. You usually had to marshall data structures yourself to fit the data formats of the native language. You had to write shims (oftentimes in assembly!) that would bridge the calling conventions of your preferred language to those that the frameworks were written in. There's a reason that C became the dominant language during the 80s and early 90s: it's because Win32, UNIX, and MacOS >=7 were all written in it. That's a large part of what Worse is Better was about. Richard Gabriel founded a company to write software for Lisp Machines, pivoted it to run Lisp on commodity hardware, found that all of his customers would rather just write in C, pivoted it again to do a C++ dev environment, and eventually went out of business. The renaissance for other languages was really during the web era, when everything just spit out HTML and it didn't matter what the server was written in. Once customers started demanding rich interactivity on the client, there was a strong incentive to write everything in Javascript, and then a strong incentive to write the servers in Javascript too, and then a strong incentive to use Javascript for other things like native apps and IoT devices too.
    - klodolph 11y ago
      Yes, you paid a tax. But my argument here is that the tax for writing in different languages on Win32, Unix, and Mac OS was far cheaper than the tax for writing in other languages on a Lisp machine. This is because translating low-level code to high-level code is not as straightforward as the reverse operation. For example, if I compile C to JavaScript, how do I even think about writing a function like memcpy()? You end up with a monster like asm.js where interacting with the DOM is a chore. Yes, the web brought a renaissance in different languages. But we already had a bunch of different languages lying around when the web became important. We were already using different languages to write desktop software. I didn't even learn C until the late 1990s, but I was happily writing software before then. WebAssembly is going to make languages other than JavaScript palatable in the browser, and I can only see that as a good thing.
    - lispm 11y ago
      > Richard Gabriel founded a company to write software for Lisp Machines, The company Gabriel founded (Lucid Inc.) was never supposed to write software for Lisp Machines. Its mission from day zero was to develop a Common Lisp implementation for stock hardware (SUNs, etc.). Symbolics, the Lisp Machine maker, refused to fund a portable Common Lisp implementation (which Gabriel and Benson, the latter then at Symbolics, proposed). > found that all of his customers would rather just write in C, pivoted it again to do a C++ dev environment, and eventually went out of business Actually the Lisp business of Lucid Inc. financed the C++ development. It was a gamble. They easily could have continued to develop and sell Common Lisp (their main competitors from that time, Franz Inc. and LispWorks are still alive) and stay in a small/shrinking niche. But Lucid tried to diversify and to grow. The idea was to write a C++ environment with a similar and improved development experience as a Lisp system. They used the cash cow they had and eventually sunk the whole company when the C++ system flopped in the market. Their C++ system (Energize) was very expensive, technically complex, ...
- z3t4 11y ago
  I think that's like saying: "I prefer to use the hammer instead of the screwdriver" for something with a helical ridge. You are better off re-inventing Java or Python, but in a container and streamed over the Internet from an URL.
- jondubois 11y ago
  I can't believe people still bash JavaScript. I've used a lot of different languages including Java, C#, C++, AVR Assembly, Python and others but JavaScript is my favourite and I would not want to go back. I think its a shame that some people just didn't seriously try JavaScript. It's a very powerful, expressive language. Also, testing with JS is amazing - Especially unit testing on Node.js. It lets you do stuff like redefine entire objects, properties or methods at runtime (for stubbing). Also, JS is great for writing asynchronous logic.
  - cballard 11y ago
    I've tried JavaScript, and I decided I preferred type safety. This kind of thing: > It lets you do stuff like redefine entire objects, properties or methods at runtime Sounds horrifying to me, because, as in Ruby[1], library authors will decide that's a good idea. Typeclasses/protocols solve this problem perfectly, while maintaining type safety. [1]: for some reason, this seems to be less of an issue in Python and Obj-C, even though it's totally doable?
    - vardump 11y ago
      If type safety is what you miss, why not to use some transpiler like TypeScript? http://www.typescriptlang.org/Tutorial http://www.typescriptlang.org/Tutorial
      - cballard 11y ago
        Then you're not writing JavaScript, which was OP's concern. TypeScript is fine (although Elm, Swift, and Haskell are more interesting, IMO).
        1ris 11y ago
        Look at purescript. In order to install this madness you need to install not less than 5 package managers, but you might like it.
- masswerk 11y ago
  Sorry to say, but the web isn't about writing apps in the language of your choice. If it's beyond plain, passive HTML, it's about running applications on foreign hosts/resources without a well specified license to do so. Scripting languages provide both audible code and a small load as compared to binary object code (which is, why we had them on servers and clients in the first place). If we turn the web into an anything-goes bonanza using binary code without any keys, credentials, or permissions, WebAssembly (and Turing complete CSS as well) may be well the beginning of end of the web as we know it, giving raise to a new, leaner and more restricted platform (for which some are already on the lookout, BTW). [Edit] A small real world example: Client asks me to implement a third party plugin to allow them direct communications with their users via their website. A quick scan of the source code tells in a minute that the script isn't just doing that, but is also tracking user behavior and is phoning home related data. Now I can ask the client, if they really want to expose their users to this. With WebAssembly, there's no chance to do so.
  - MichaelGG 11y ago
    Why are you under the impression there won't be disassemblers and decompilers for WebAssembly? It's not like a bunch of minified JS is going to be "quick" to go through.
    - masswerk 11y ago
      Even, if there would be a suitable disassembler, this would just account to an exponential curve in terms of auditing any software. (We're not speaking of minutes here anymore, but rather of months or even years – who will be willing to pay for it?) BTW, with minified JS, you've just to recode variable names (while anything adequate to system calls has to be in plain text somewhere by definition), with WebAssembly, this becomes an entirely different story. – No comparison.
      - MichaelGG 11y ago
        This is basically the same case for traditional binaries. I'm no RE expert, but when I've done such work it consists of "renaming variables" including functions and looking for calls to imported functions. Intentionally obfuscated code is harder. But nothing stops JS from loading a bunch of encrypted strings, self-modifying at runtime, using eval+substring (at various offsets) on loaded and renamed functions to make it hard to know if there are calls to other functions, let alone what they are. It can still be done, and obfuscated JS is probably easier than obfuscated x86 but saying it makes an audit only take minutes means it's not really being obfuscated.
modeless 11y ago
Web assembly doesn't add new APIs or capabilities to the web platform. It only makes code run faster and makes porting C++ code easier. What about that is hateful or abusive?
- kuschku 11y ago
  That now we can’t read the source of webpages at all anymore? The whole "anyone can look at it, learn from it" part is gone? We’re steering towards more proprietary code. Say, for example, if I want to run Google’s "Star Wars" easter egg in Firefox. With JS, I could grep through the de-uglified and de-obfuscated code quickly, and find that its useragent detection would work if I’d just append "AppleWebKit Chrome/45.0.0.0." to the UserAgent. With WebAssembly, I’d have to spend far more work.
  - modeless 11y ago
    You can't read the obfuscated code directly. You have to use tools to deobfuscate it. With Web Assembly it will be the same. There will be tools to help you read the code. You may proclaim that they won't work as well but I think it's premature to say that. Web Assembly is not machine code.
    - kuschku 11y ago
      Web assembly is very generic byte code. I fear I’d end up spending ages in IDA breaking a DRM scheme implemented in WebAssembly, just like I did with NaCl. That’s not neat.
- c0nfused 11y ago
  Sorry, my intent was not to imply that web assembly was hateful or abusive but that the code I might write using it falls into two categories 1. Performance critical code 2. Sneaky stuff I really don't want the user to be able to read. Category two seems like the sort of thing that I would absolutely want to be able to write binary code that executes without user interaction. It seems like right now the focus is quite rightly on #1, but that #2 seems like it will inevitably become an issue.
walterbell 11y ago
Do you like any other visions for the future of the web? Brendan Eich's startup hasn't shared much about their plans, http://www.cnet.com/news/mystery-startup-from-ex-mozilla-ceo-aims-to-go-where-tech-titans-wont/ http://www.cnet.com/news/mystery-startup-from-ex-mozilla-ceo...
jacobolus 11y ago
The main use for it (for me at least) is to write fast numerical code (physics modeling, audio processing, image processing, machine learning, 3D rendering, statistical analysis, etc.) in a deterministically fast way against an easy-to-reason-about programming model with an ability to manually allocate memory and structure data, instead of hoping that every browser’s heuristic-driven JIT will be able to optimize some high-level code the same way. Most of the program logic can remain standard Javascript, but the little kernels of hot numerical code can be much more effectively optimized. This gives Javascript/browsers the ability to handle problems which were previously only possible to tackle with native C programs.
- ezy 11y ago
  The issue with this is that if you care about speed, you need to be using SIMD -- and wasm doesn't seem to want to support it -- stating a "minimum viable" standard from the year 2000.
  - jacobolus 11y ago
    Existing Javascript JITs also don’t output SIMD instructions as far as I know. I expect SIMD support can be added to wasm at some future date.
    - ezy 11y ago
      I wasn't really referring to wasm vs JS (which is easy to outperform), but reaching equivalent speed to native, which is the ultimate goal, I'd hope. Otherwise you're just throwing performance away... But, I was a little quick on the trigger. It's not obvious, but after drilling through the design docs for a half hour.. I found a tentative discussion of how SIMD might be added later (based on some kind extension mechanism).
  - nwmcsween 11y ago
    Why wouldn't llvm be able to emit SIMD when it can vectorize? The idea the SIMD is the end all to fast computing is pretty short sighted IMO.
klodolph 11y ago
What makes WebAssembly like Flash? Please elaborate. You already can't just read someone's JavaScript code if they're using a transpiler or uglify or something like that, it looks like line noise and you basically have to go through a lot of work to reverse engineer it. WebAssembly is no worse. The JavaScript environment on the web reminds me of the "walled gardens" that were Lisp machines back in the day, that force you to write code in Lisp, or if you wanted to write in C you would get end up with a bit of a nightmare on your hands. The Lisp machines were beautiful and integrated and the source code was everywhere, but they weren't for everybody, and in the end it was the diversity of Windows, Unix, and Mac OS that replaced them. WebAssembly is Unix, JavaScript is a Lisp machine.
- wwweston 11y ago
  > What makes WebAssembly like Flash? Please elaborate. It's pretty straightforward. Both tend towards the Big Binary Blackbox Blob. It's true that WebAssembly has advantages Flash, Java, and Silverlight didn't really have in terms of being freely reimplimentable and (potentially) native to the browser. And it's probably a good thing that a browser can be a VM via a target-intended subset of JS. BBBB may be the right thing for some applications. But to the extent that the browser becomes something developers see primarily as The VM That Lived (and there are clearly a lot of developers in this boat) yes, we're forgetting lessons we should have already learned from the difference between Flash/Java and the open web. > You already can't just read someone's JavaScript code if they're using a transpiler or uglify or something like that, it looks like line noise and you basically have to go through a lot of work to reverse engineer it. WebAssembly is no worse. I'm clearly in the minority, but I had qualms about uglify and other source manglers from the beginning for the same reasons people have qualms about Web Assembly: they break the benefits of view source. I get that they can also be tools that help squeeze out performance, and I use them selectively for that reason, but as far as I can tell, most of the web development world uses this as an excuse to stop actually thinking about the issue -- and for that matter, to stop thinking about how they're putting together their web app ("we're using minification and gzip and doing an SPA using Ember/Angular/LatestDesktopLikeFramework because that's what professionals do now, why do we have performance problems?"). Similarly, I've seen a lot of people use compiling to JS as an end run around what are essentially aesthetic/subjective issues with JS as a language when they'd probably do just as well spending more time learning to use it (as far as I can tell in years of working with all of them, JS is in exactly the same league with Python and Ruby and Perl other similar dynamic languages). That doesn't mean there are no beneficial cases for JS as a target (personally, I'm intrigued by Elm), but I think I'm justified in being afraid that people will use it as insulation from superficial problems. > that force you to write code in Lisp Lisp doesn't force you to write code in Lisp. That's one of the reasons why it's awesome -- and potentially horrible. Transpiling/compiling can be similarly awesome and potentially horrible for a lot of the same reasons.
ossreality 11y ago
>I'm sure this is because I'm getting old. "this" being you making wildly inaccurate statements and burying your head in the sand?
aikah 11y ago
The big difference is that WebAssembly can only do what Web APIs allows it to do. You'll have to do the same AJAX calls, the same DOM manipulations as with Javascript. There is no plugin here. > I always feel like the most obvious use for it is to start writing truly hateful and abusive code. Sure, but it will also developers to have a better experience by allowing them to chose the language they want, and not to be forced to use JavaScript. Choice is good, it's something you cannot deny.
kristopolous 11y ago
We will eventually come to terms with the fact that Flash was 15 years ahead of everything else on multiple fronts and we ought to have been just chastised the terrible developers doing awful and horrendous things with pretty technically sound software.
- loup-vaillant 11y ago
  If only Flash weren't proprietary…
- Scaevolus 11y ago
  HTML5 _still_ isn't able to deliver the quality interactive experiences (Games) without applying a lot more effort. Even "simple" things like cross-browser low-latency sound effects are still difficult. Flash presents a single platform with a single vendor that can innovate as quickly as they like. The web platform is inevitably cumbersome and slow in comparison -- over a decade later they're still playing catch-up. I'm looking forward to WebGL ads that eat battery life with excessive shaders.
  - kristopolous 11y ago
    As a strong supporter of open source, doing a comparative analysis of HTML5 and Flash, I have to admit that private enterprise was able to kick the ball forward so much faster here ... I remember watching a vector animation version of a "tell-tale heart" in flash in 1998. On a 28.8 connection it played smoothly full-screen on a 120mhz pentium with 16mb of ram. I remember clicking the play button and having it just miraculously starting to play without any wait, streaming down and uncompressing in real time. I was floored by it. 12 years later I was invited to watch a spiderman animation demo using HTML5 ... there was a 30 second load time, the framerate was probably 1fps, the audio didn't work, the content didn't render properly ... It's like how Microsoft was able to pull off nearly everything we could do today by shoe-horning their activeX technology into ie3. Just load a bunch of cab files and drop them into the page like OLE components and bam, you got just about everything. The interactivity could bootstrap - that is, not need any extra plugin and you could engage with the other content on the site using vbscript or javascript interfaces in a two-way manner. It was pretty nice. Netscape retorted with their JVM integration but it just wasn't the same ...
sliverstorm 11y ago
Many of the worst parts of flash had to do with (IMO) the single-source nature, that is to say Adobe. Flash is using all your RAM? Flash is slow? Flash is hard to develop good UI for and integrates poorly in browsers? Too bad, it's Adobe's runtime & plugin, or nothing.
sklogic 11y ago
WebAssembly is a way to finally get rid of that overgrown scripting abomination that people started to take for a real language. And arguably it is the only way to get rid of that thing, any other will simply create another insufferable abomination.
coldtea 11y ago
>Web assembly always makes me a little sad. It feels like we are going back to flash only it won't be bad this time, I promise, no really. Only if you miss the obvious and blatant technical and license differences.

nwah1 11y ago

The important use case is to allow people to write web applications with their language of choice, instead of horrible javascript. And get near full performance.

klodolph 11y ago
I think this is important. Probably because I have the "worse is better" article from 1991 open in another tab, and if you s/Lisp/Javascript/g then many of the criticisms ring true. Some of what made Unix, Windows, and Mac OS healthy environments for development was the fact that all developers were equally well off, you didn't have to pay a tax for writing something in a language other than Lisp. You could keep your Fortran code, and mix it into a C program, run from a Bourne shell, running in terminal emulator written in C and a WM written in Lisp. You can replace any part with a part written in a different language. JavaScript will continue to be dominant, but we desperately need to be able to write things in the language of our choice.
- nostrademons 11y ago
  Hmm? You paid a huge tax in desktop development for writing in a language other than the one the OS was written in. All of the platform documentation & examples were in its "native" language. You usually had to marshall data structures yourself to fit the data formats of the native language. You had to write shims (oftentimes in assembly!) that would bridge the calling conventions of your preferred language to those that the frameworks were written in. There's a reason that C became the dominant language during the 80s and early 90s: it's because Win32, UNIX, and MacOS >=7 were all written in it. That's a large part of what Worse is Better was about. Richard Gabriel founded a company to write software for Lisp Machines, pivoted it to run Lisp on commodity hardware, found that all of his customers would rather just write in C, pivoted it again to do a C++ dev environment, and eventually went out of business. The renaissance for other languages was really during the web era, when everything just spit out HTML and it didn't matter what the server was written in. Once customers started demanding rich interactivity on the client, there was a strong incentive to write everything in Javascript, and then a strong incentive to write the servers in Javascript too, and then a strong incentive to use Javascript for other things like native apps and IoT devices too.
  - klodolph 11y ago
    Yes, you paid a tax. But my argument here is that the tax for writing in different languages on Win32, Unix, and Mac OS was far cheaper than the tax for writing in other languages on a Lisp machine. This is because translating low-level code to high-level code is not as straightforward as the reverse operation. For example, if I compile C to JavaScript, how do I even think about writing a function like memcpy()? You end up with a monster like asm.js where interacting with the DOM is a chore. Yes, the web brought a renaissance in different languages. But we already had a bunch of different languages lying around when the web became important. We were already using different languages to write desktop software. I didn't even learn C until the late 1990s, but I was happily writing software before then. WebAssembly is going to make languages other than JavaScript palatable in the browser, and I can only see that as a good thing.
  - lispm 11y ago
    > Richard Gabriel founded a company to write software for Lisp Machines, The company Gabriel founded (Lucid Inc.) was never supposed to write software for Lisp Machines. Its mission from day zero was to develop a Common Lisp implementation for stock hardware (SUNs, etc.). Symbolics, the Lisp Machine maker, refused to fund a portable Common Lisp implementation (which Gabriel and Benson, the latter then at Symbolics, proposed). > found that all of his customers would rather just write in C, pivoted it again to do a C++ dev environment, and eventually went out of business Actually the Lisp business of Lucid Inc. financed the C++ development. It was a gamble. They easily could have continued to develop and sell Common Lisp (their main competitors from that time, Franz Inc. and LispWorks are still alive) and stay in a small/shrinking niche. But Lucid tried to diversify and to grow. The idea was to write a C++ environment with a similar and improved development experience as a Lisp system. They used the cash cow they had and eventually sunk the whole company when the C++ system flopped in the market. Their C++ system (Energize) was very expensive, technically complex, ...
z3t4 11y ago
I think that's like saying: "I prefer to use the hammer instead of the screwdriver" for something with a helical ridge. You are better off re-inventing Java or Python, but in a container and streamed over the Internet from an URL.
jondubois 11y ago
I can't believe people still bash JavaScript. I've used a lot of different languages including Java, C#, C++, AVR Assembly, Python and others but JavaScript is my favourite and I would not want to go back. I think its a shame that some people just didn't seriously try JavaScript. It's a very powerful, expressive language. Also, testing with JS is amazing - Especially unit testing on Node.js. It lets you do stuff like redefine entire objects, properties or methods at runtime (for stubbing). Also, JS is great for writing asynchronous logic.
- cballard 11y ago
  I've tried JavaScript, and I decided I preferred type safety. This kind of thing: > It lets you do stuff like redefine entire objects, properties or methods at runtime Sounds horrifying to me, because, as in Ruby[1], library authors will decide that's a good idea. Typeclasses/protocols solve this problem perfectly, while maintaining type safety. [1]: for some reason, this seems to be less of an issue in Python and Obj-C, even though it's totally doable?
  - vardump 11y ago
    If type safety is what you miss, why not to use some transpiler like TypeScript? http://www.typescriptlang.org/Tutorial http://www.typescriptlang.org/Tutorial
    - cballard 11y ago
      Then you're not writing JavaScript, which was OP's concern. TypeScript is fine (although Elm, Swift, and Haskell are more interesting, IMO).
      - 1ris 11y ago
        Look at purescript. In order to install this madness you need to install not less than 5 package managers, but you might like it.
masswerk 11y ago
Sorry to say, but the web isn't about writing apps in the language of your choice. If it's beyond plain, passive HTML, it's about running applications on foreign hosts/resources without a well specified license to do so. Scripting languages provide both audible code and a small load as compared to binary object code (which is, why we had them on servers and clients in the first place). If we turn the web into an anything-goes bonanza using binary code without any keys, credentials, or permissions, WebAssembly (and Turing complete CSS as well) may be well the beginning of end of the web as we know it, giving raise to a new, leaner and more restricted platform (for which some are already on the lookout, BTW). [Edit] A small real world example: Client asks me to implement a third party plugin to allow them direct communications with their users via their website. A quick scan of the source code tells in a minute that the script isn't just doing that, but is also tracking user behavior and is phoning home related data. Now I can ask the client, if they really want to expose their users to this. With WebAssembly, there's no chance to do so.
- MichaelGG 11y ago
  Why are you under the impression there won't be disassemblers and decompilers for WebAssembly? It's not like a bunch of minified JS is going to be "quick" to go through.
  - masswerk 11y ago
    Even, if there would be a suitable disassembler, this would just account to an exponential curve in terms of auditing any software. (We're not speaking of minutes here anymore, but rather of months or even years – who will be willing to pay for it?) BTW, with minified JS, you've just to recode variable names (while anything adequate to system calls has to be in plain text somewhere by definition), with WebAssembly, this becomes an entirely different story. – No comparison.
    - MichaelGG 11y ago
      This is basically the same case for traditional binaries. I'm no RE expert, but when I've done such work it consists of "renaming variables" including functions and looking for calls to imported functions. Intentionally obfuscated code is harder. But nothing stops JS from loading a bunch of encrypted strings, self-modifying at runtime, using eval+substring (at various offsets) on loaded and renamed functions to make it hard to know if there are calls to other functions, let alone what they are. It can still be done, and obfuscated JS is probably easier than obfuscated x86 but saying it makes an audit only take minutes means it's not really being obfuscated.

modeless 11y ago

Web assembly doesn't add new APIs or capabilities to the web platform. It only makes code run faster and makes porting C++ code easier. What about that is hateful or abusive?

kuschku 11y ago
That now we can’t read the source of webpages at all anymore? The whole "anyone can look at it, learn from it" part is gone? We’re steering towards more proprietary code. Say, for example, if I want to run Google’s "Star Wars" easter egg in Firefox. With JS, I could grep through the de-uglified and de-obfuscated code quickly, and find that its useragent detection would work if I’d just append "AppleWebKit Chrome/45.0.0.0." to the UserAgent. With WebAssembly, I’d have to spend far more work.
- modeless 11y ago
  You can't read the obfuscated code directly. You have to use tools to deobfuscate it. With Web Assembly it will be the same. There will be tools to help you read the code. You may proclaim that they won't work as well but I think it's premature to say that. Web Assembly is not machine code.
  - kuschku 11y ago
    Web assembly is very generic byte code. I fear I’d end up spending ages in IDA breaking a DRM scheme implemented in WebAssembly, just like I did with NaCl. That’s not neat.
c0nfused 11y ago
Sorry, my intent was not to imply that web assembly was hateful or abusive but that the code I might write using it falls into two categories 1. Performance critical code 2. Sneaky stuff I really don't want the user to be able to read. Category two seems like the sort of thing that I would absolutely want to be able to write binary code that executes without user interaction. It seems like right now the focus is quite rightly on #1, but that #2 seems like it will inevitably become an issue.

walterbell 11y ago

Do you like any other visions for the future of the web? Brendan Eich's startup hasn't shared much about their plans, http://www.cnet.com/news/mystery-startup-from-ex-mozilla-ceo-aims-to-go-where-tech-titans-wont/ http://www.cnet.com/news/mystery-startup-from-ex-mozilla-ceo...

jacobolus 11y ago

The main use for it (for me at least) is to write fast numerical code (physics modeling, audio processing, image processing, machine learning, 3D rendering, statistical analysis, etc.) in a deterministically fast way against an easy-to-reason-about programming model with an ability to manually allocate memory and structure data, instead of hoping that every browser’s heuristic-driven JIT will be able to optimize some high-level code the same way. Most of the program logic can remain standard Javascript, but the little kernels of hot numerical code can be much more effectively optimized. This gives Javascript/browsers the ability to handle problems which were previously only possible to tackle with native C programs.

ezy 11y ago
The issue with this is that if you care about speed, you need to be using SIMD -- and wasm doesn't seem to want to support it -- stating a "minimum viable" standard from the year 2000.
- jacobolus 11y ago
  Existing Javascript JITs also don’t output SIMD instructions as far as I know. I expect SIMD support can be added to wasm at some future date.
  - ezy 11y ago
    I wasn't really referring to wasm vs JS (which is easy to outperform), but reaching equivalent speed to native, which is the ultimate goal, I'd hope. Otherwise you're just throwing performance away... But, I was a little quick on the trigger. It's not obvious, but after drilling through the design docs for a half hour.. I found a tentative discussion of how SIMD might be added later (based on some kind extension mechanism).
- nwmcsween 11y ago
  Why wouldn't llvm be able to emit SIMD when it can vectorize? The idea the SIMD is the end all to fast computing is pretty short sighted IMO.

klodolph 11y ago

What makes WebAssembly like Flash? Please elaborate. You already can't just read someone's JavaScript code if they're using a transpiler or uglify or something like that, it looks like line noise and you basically have to go through a lot of work to reverse engineer it. WebAssembly is no worse. The JavaScript environment on the web reminds me of the "walled gardens" that were Lisp machines back in the day, that force you to write code in Lisp, or if you wanted to write in C you would get end up with a bit of a nightmare on your hands. The Lisp machines were beautiful and integrated and the source code was everywhere, but they weren't for everybody, and in the end it was the diversity of Windows, Unix, and Mac OS that replaced them. WebAssembly is Unix, JavaScript is a Lisp machine.

wwweston 11y ago
> What makes WebAssembly like Flash? Please elaborate. It's pretty straightforward. Both tend towards the Big Binary Blackbox Blob. It's true that WebAssembly has advantages Flash, Java, and Silverlight didn't really have in terms of being freely reimplimentable and (potentially) native to the browser. And it's probably a good thing that a browser can be a VM via a target-intended subset of JS. BBBB may be the right thing for some applications. But to the extent that the browser becomes something developers see primarily as The VM That Lived (and there are clearly a lot of developers in this boat) yes, we're forgetting lessons we should have already learned from the difference between Flash/Java and the open web. > You already can't just read someone's JavaScript code if they're using a transpiler or uglify or something like that, it looks like line noise and you basically have to go through a lot of work to reverse engineer it. WebAssembly is no worse. I'm clearly in the minority, but I had qualms about uglify and other source manglers from the beginning for the same reasons people have qualms about Web Assembly: they break the benefits of view source. I get that they can also be tools that help squeeze out performance, and I use them selectively for that reason, but as far as I can tell, most of the web development world uses this as an excuse to stop actually thinking about the issue -- and for that matter, to stop thinking about how they're putting together their web app ("we're using minification and gzip and doing an SPA using Ember/Angular/LatestDesktopLikeFramework because that's what professionals do now, why do we have performance problems?"). Similarly, I've seen a lot of people use compiling to JS as an end run around what are essentially aesthetic/subjective issues with JS as a language when they'd probably do just as well spending more time learning to use it (as far as I can tell in years of working with all of them, JS is in exactly the same league with Python and Ruby and Perl other similar dynamic languages). That doesn't mean there are no beneficial cases for JS as a target (personally, I'm intrigued by Elm), but I think I'm justified in being afraid that people will use it as insulation from superficial problems. > that force you to write code in Lisp Lisp doesn't force you to write code in Lisp. That's one of the reasons why it's awesome -- and potentially horrible. Transpiling/compiling can be similarly awesome and potentially horrible for a lot of the same reasons.

ossreality 11y ago

>I'm sure this is because I'm getting old. "this" being you making wildly inaccurate statements and burying your head in the sand?

aikah 11y ago

The big difference is that WebAssembly can only do what Web APIs allows it to do. You'll have to do the same AJAX calls, the same DOM manipulations as with Javascript. There is no plugin here. > I always feel like the most obvious use for it is to start writing truly hateful and abusive code. Sure, but it will also developers to have a better experience by allowing them to chose the language they want, and not to be forced to use JavaScript. Choice is good, it's something you cannot deny.

kristopolous 11y ago

We will eventually come to terms with the fact that Flash was 15 years ahead of everything else on multiple fronts and we ought to have been just chastised the terrible developers doing awful and horrendous things with pretty technically sound software.

loup-vaillant 11y ago
If only Flash weren't proprietary…
Scaevolus 11y ago
HTML5 _still_ isn't able to deliver the quality interactive experiences (Games) without applying a lot more effort. Even "simple" things like cross-browser low-latency sound effects are still difficult. Flash presents a single platform with a single vendor that can innovate as quickly as they like. The web platform is inevitably cumbersome and slow in comparison -- over a decade later they're still playing catch-up. I'm looking forward to WebGL ads that eat battery life with excessive shaders.
- kristopolous 11y ago
  As a strong supporter of open source, doing a comparative analysis of HTML5 and Flash, I have to admit that private enterprise was able to kick the ball forward so much faster here ... I remember watching a vector animation version of a "tell-tale heart" in flash in 1998. On a 28.8 connection it played smoothly full-screen on a 120mhz pentium with 16mb of ram. I remember clicking the play button and having it just miraculously starting to play without any wait, streaming down and uncompressing in real time. I was floored by it. 12 years later I was invited to watch a spiderman animation demo using HTML5 ... there was a 30 second load time, the framerate was probably 1fps, the audio didn't work, the content didn't render properly ... It's like how Microsoft was able to pull off nearly everything we could do today by shoe-horning their activeX technology into ie3. Just load a bunch of cab files and drop them into the page like OLE components and bam, you got just about everything. The interactivity could bootstrap - that is, not need any extra plugin and you could engage with the other content on the site using vbscript or javascript interfaces in a two-way manner. It was pretty nice. Netscape retorted with their JVM integration but it just wasn't the same ...

sliverstorm 11y ago

Many of the worst parts of flash had to do with (IMO) the single-source nature, that is to say Adobe. Flash is using all your RAM? Flash is slow? Flash is hard to develop good UI for and integrates poorly in browsers? Too bad, it's Adobe's runtime & plugin, or nothing.

sklogic 11y ago

WebAssembly is a way to finally get rid of that overgrown scripting abomination that people started to take for a real language. And arguably it is the only way to get rid of that thing, any other will simply create another insufferable abomination.

coldtea 11y ago

>Web assembly always makes me a little sad. It feels like we are going back to flash only it won't be bad this time, I promise, no really. Only if you miss the obvious and blatant technical and license differences.