1. 33
  1.  

  2. 17

    Thanks for the writeup. However, I’m not sure I share your excitement. I can boil it down to two points:

    1. This reminds me of all the hoopla around the JVM as it was coming out: one language to rule them all! Distributing bytecode instead of compiled binaries! Write once, run anywhere! I see how WebAssembly improves on some of this story, but it still has a sameness to it, except it’s dubbed ‘open.’ As a user, why do I care? As a developer, why do I care? HTML 5 displacing Flash has meant that ads are more invasive and harder to block, honestly.

    2. The importance placed on not diverging from the Web platform doesn’t win any points from me. I get that people dislike crappy implementations of subplatforms that just get in the way, but I also want to see serious competition to HTML/CSS when it comes to laying out UIs. As someone who likes what the web stands for so much and yet loathes the actual workings of it, it feels like things like this subtly reinforce the “everything is web development” hegemony by continuing to prop these things up in the name of compatibility.

    Mind you, I’m very happy that JS can finally be displaced as the lingua franca of webapps!

    1. 4

      This reminds me of all the hoopla around the JVM as it was coming out: one language to rule them all! Distributing bytecode instead of compiled binaries! Write once, run anywhere! I see how WebAssembly improves on some of this story, but it still has a sameness to it, except it’s dubbed ‘open.’ As a user, why do I care? As a developer, why do I care? HTML 5 displacing Flash has meant that ads are more invasive and harder to block, honestly.

      There’s a big difference between Java and WebAssembly. While you could totally imagine a bare JVM that just runs JVM bytecode, it always came with its standard lib, the TLS implementation and everything around it. And even then, the JVM needs to come with a garbage collector, which wants to take control of all memory. The teasing thing about WASM is that it only talks about portable code, but not about a portable API. It’s quite different from the JVM in the aspect that it isn’t a platform in itself.

      1. 1

        I’m not sure if that’s a good thing. Or a bad thing. It feels like it might affect download sizes, but other than that it doesn’t really matter.

    2. 15

      I’m not particularly thrilled with either the tone or content of this essay.

      First, there’s some revisionism:

      The first reason that WebAssembly is different is that it’s succeeded, and those technologies did not.

      The essay goes on to redefine “success” in some super-niche way and qualify it, but this is rhetorically dishonest. I might as well write in an essay that “The first reason I disagree with them is that @steveklabnik is a fascist” and then go on to explain that by that I mean a fascist who supports government control of resources and careful policing of speech…sure, under that tortured definition I am both consistent and not wrong, but you wouldn’t be faulted for observing that I’m not right either.

      They were never standardized, and that matters a lot.

      JVM was never standardized.

      Flash was not built on ES3/ES4 standards.

      Unfortunately, just because something is standardized and went through the wringer doesn’t mean it isn’t hot steaming garbage.

      If you built an applet in one of these technologies, you didn’t really build a web application […] You lost all of the benefits of other web technologies; you lost HTML, you lost CSS, you lost the accessibility built into the web.

      Most of those features didn’t exist when Java applets first came out in 1995. Most of the useful stuff that Flash was good at didn’t exist in browsers for most of the 00’s. The essay is trying to sell you on a state of history that didn’t exist in any meaningful way.

      “Don’t break the web” is a very, very important rule for browser vendors.

      “…unless it gets you marketshare” is the rest of the sentence that the author leaves out. Browser vendors (and hell, let’s be real here: we mean Google, Apple, Microsoft, and that’s basically it these days) break things all the time and don’t care. https://caniuse.com/ is a monument to this fact.

      Then there’s seeming misunderstanding about how browser development works:

      These companies have significant motive to make profit, not to make the web better.

      “Making profit” is how IE managed to deliver the first working version of CSS. Similarly, how they delivered a little thing called XMLHttpRequest, a small api with passing utility later adopted by every other browser manufacturer.

      Google Chrome delivered lots of neat features ahead of standardization specifically so they could feed the ad machine. And Mozilla happily rode those coattails for a good long time.

      I think the notion of “let’s make the web better” ultimately–intentionally or not–boils down to “let’s serve ads better”, once you look at things in context.

      …and how companies work…

      WebAssembly is a joint venture between Mozilla, Google, Apple, Microsoft, and others. It’s not trying to push anyone’s particular platform, but instead represents the shared interests of a wide number of stakeholders, both corporate and individual.

      So, two ad-driven companies, a company known specifically for locking-down platforms (and goofing around in standards and industry groups if one’s familiar with OpenGL or the development of the Cell processor), and a company who is switching to moving as much of their stuff into the cloud–where it can be taxed and leased to users without fear of reprisal. I see why they might want to support WASM.

      …and how maintenance works…

      It’s hard enough to maintain one runtime, let alone two. And then how do you integrate them?

      Runtimes don’t all need to be integrated, and we handily managed to keep the runtimes for JVM and Flash maintained for more than a decade, by letting interested parties support them.

      …and how language proliferation and the Tower of Babel work…

      Do we really want to christen one language as the next language of the web? We already have JavaScript. Are we someday going to introduce a third language? A fourth? An agnostic approach is significantly better for longevity’s sake.

      Picking one language is better for longevity’s sake. Standardization–the shibboleth touched on here and there in this essay–would suggest that we take one language and adopt and update it as needed.

      Wasm, as I rallied about many a time, is likely to make frontend dev skills even less portable than they already are. It’s an opportunity to let language writers and well-meaning developers rediscover every mistake in their language and find some way of introducing it into the browser and then saddling devs with their shortcomings!

      …and how security works.

      Wasm is missing some features of regular assembly language that can cause security vulnerabilities, like stack smashing. Wasm is memory-safe, which is huge!

      And yet it directly enables malware and side-channel attacks, while it’s proponents kinda ignore the issue and forge ahead.

      ~

      We’re all going to be stuck with the outcome of this, and folks promoting the technology for their own career advancement or aesthetics are doing so, seemingly to me, without enough care for the ramifications of what they’re pushing.

      EDIT: Cleanups to soften this up a bit…my annoyance got in the way of my politeness.

      EDIT: Removed many “actually”’s in various headers, since I read them in my head as “well ak-shu-alee”

      1. 23

        I’m going to give you one reply, but that’s it; we have such a divergence of opinion so often that I don’t feel like we’re really going to agree, but I would like to respond to some things.

        The essay goes on to redefine “success” in some super-niche way and qualify it, but this is rhetorically dishonest.

        I tried to be super clear here that this is from an implementor’s perspective. Success in this context means “becoming part of the web platform.” I don’t feel that’s dishonest, it’s about being clear about exactly what I’m trying to talk about.

        JVM was never standardized.

        That’s a specification, not a standard.

        Flash was not built on ES3/ES4 standards.

        “built on” does not mean “conforms with”; ActionScript and ECMAScript are similar, but different.

        Unfortunately, just because something is standardized and went through the wringer doesn’t mean it isn’t hot steaming garbage.

        This is true, but that’s why I qualified what this post is about. The user’s perspective is something else entirely.

        Most of those features didn’t exist when Java applets first came out in 1995.

        CSS was in development at the time, and shipped in 1996, it’s true. But regardless of the start, that kept being true. They could have added support, but they did not. It’s effectively the same.

        https://caniuse.com/ is a monument to this fact.

        CanIUse, to me, is more about when you can adopt new features. They ship in different browsers at different times, but eventually, a lot of stuff is the same. Crossplatform web development has never been easier.

        Runtimes don’t all need to be integrated, and we handily managed to keep the runtimes for JVM and Flash maintained for more than a decade, by letting interested parties support them.

        Yet they still were full of vulnerabilities. This was due to the disconnect I talk about in the article. It also doesn’t address the inherent complexity in coordinating two runtimes compared to one.

        enables malware

        This was already possible with JS, wasm doesn’t fundamentally change things here

        and side-channel attacks,

        This article is clickbait nonsense. It says that this could happen, but ignores that everyone involved with WebAssembly is acutely aware of these issues, and is not moving forward until they’re addressed. Heck, before Meltdown/Spectre was announced, I was in a room with one of the main designers of WebAssembly, and someone brought up SharedArrayBuffer for some reason. He said “yeah so you shouldn’t rely on that and I can’t talk about why”. Then we all found out why.

        You’re letting your disdain bias you against the facts.

        while it’s proponents kinda ignore the issue and forge ahead.

        TC39 is not the body that standardizes WebAssembly.

        We’re all going to be stuck with the outcome of this, and folks promoting the technology for their own career advancement or aesthetics are doing so, seemingly to me, without enough care for the ramifications of what they’re pushing.

        This kind of slander is why I rarely post to lobste.rs anymore. I’m out.

        1. 2

          This was already possible with JS, wasm doesn’t fundamentally change things here

          It makes things easier, and the general increase in performance allows more interesting and obtrusive categories of malware than we saw with JS.

          Heck, before Meltdown/Spectre was announced, I was in a room with one of the main designers of WebAssembly, and someone brought up SharedArrayBuffer for some reason.

          There’s no sane way to have multiple threads and shared memory primitives of which I’m aware that don’t enable timing attacks at this time. The option seems to be to remove them entirely, and the Github link shows that at least a few people are hesitant to do that.

          TC39 is not the body that standardizes WebAssembly.

          Thank you for the correction–I don’t know if there is a lot of bleedover between the groups. If there is, my concern remains.

          This kind of slander is why I rarely post to lobste.rs anymore. I’m out.

          That’s my honest opinion, slander wasn’t my intent. This pattern is being repeated everywhere in our industry. If you don’t think it applies in your case, please correct me.

          1. 12

            That’s my honest opinion, slander wasn’t my intent.

            Making an unsubstantiated accusation in a public forum is slander, even if you happen to believe the accusation to be true.

            And to be clear, you accused promoters of wasm of self-interestedly putting career/aesthetics above the common good. You made no allowance for the idea that they might actually have decent reasons for believing and acting as they do. If they disagree with you on wasm, then they are simply a bad person.

            Putting all of that behind a “it seems to me” doesn’t actually change what you are saying. If you meant something else, I strongly suggest rewording. If not, then please don’t post such attacks on Lobsters.

            1. 3

              Please consider the original phrasing–there’s a reason I picked it:

              We’re all going to be stuck with the outcome of this, and folks promoting the technology for their own career advancement or aesthetics are doing so, seemingly to me, without enough care for the ramifications of what they’re pushing.

              I state one thing as fact: we’re stuck with the outcome of the wasm debate.

              I state the rest as opinion: the set of people promoting the technology, who are doing so for their own career advancement or aesthetics, seem to be doing so without enough care for the ramifications of widespread wasm adoption it seems to me.

              There is a much more direct way of slandering people if that’d been my goal.

              1. 5

                Sidestepping the question of whether it’s slander: it’s non-constructive and counterproductive to speculate about the intentions and motivations of the people you are discussing with. It’s poisoning the well.

            2. 6

              That’s my honest opinion

              It’s an accusation, not a matter of opinion.

          2. 6

            Browser vendors (and hell, let’s be real here: we mean Google, Apple, Microsoft, and that’s basically it these days)

            I’m sure you know you’re writing to a Mozilla employee. Does saying “you’re not even a real browser vendor” really help your argument?

            (I’ve worked at Mozilla. Loved it, but competing against some of the largest and most well-funded corporations in the world is hard, and it can be frustrating to see what they get away with. Jabs like this pile up and demoralize you.)

            1. 2

              In my haste I plain forgot to list Mozilla. One of many glaring oversights I’ve made today.

              That said, my point is that there are really only 4 vendors that matter, since the vast, vast majority of browsers are powered using one of 3 or 4 engines.

              1. 2

                That makes more sense. Thanks for clarifying.

          3. 5

            spoiler: no.

            1. 8

              I usually link to Betteridge’s Law when I write a post like this, but didn’t this time.

              Apparently a significant portion of people found the title to be clickbait-y, but I thought it was a pretty straightforward question. Oh well!

              1. 6

                This knee-jerk reaction against “clickbait” kind of annoys me. Imo there is nothing wrong with an article having a title that attempts to engage a reader and pique their interest. I would also much rather a title pose a question and answer it in the article, rather than containing the answer in the title itself. (The latter can lead to people just reading the title and missing any nuance the article conveys).

                1. 7

                  I agree. Clickbait really implies that the article has no meaningful content. If the article is actually worth reading, it’s not clickbait, it’s catchy.

                2. 1

                  It’s a fine title, imo. Maybe there’s a better one possible, but it’s fine.

                  1. 2

                    “WebAssembly is not the return of Java Applets and Flash.”

                    Edit: I did enjoy the article, however.

                    Edit2: As site comment:

                    I had no idea what the “kudos” widget was, moved my mouse to it, saw some animation happening, and realized I just “upvoted” a random article, with no way to undo it. Wondeful design. >.<

                    1. 1

                      That’s fine, and probably an improvement, but worth a correction? I don’t really think so.

              2. 1

                IMO anyone who says flash failed isn’t really paying attn

                1. 1

                  Nah, the whole reason things like Flash and Java applets failed and were ultimately bug ridden is that they represented totally different sub-platforms from the web itself.

                  In 2018, Javascript is as much a part of the web as HTML, so WebAssembly gets to benefit from all the incredibly hard work that goes into sandboxing and security around the browser platform.

                  1. 5

                    Nah, the whole reason things like Flash and Java applets failed and were ultimately bug ridden is that they represented totally different sub-platforms from the web itself.

                    That is one of the points that I attempted to make in the article.

                    1. 3

                      I am totally guilty of posting before reading, but I just read it and it’s an excellent article!

                      As an adjunct to your point around both adding additional paradigms and platforms to the already perhaps too rich web platform, Java applets had the disadvantage that the Java folks kept trying to switch frameworks. Started with AWT, then hey let’s implement Swing in applets, then let’s try that other thing whose name I can’t remember … JavaX maybe?