1. 26

  2. 17

    You know, I have a real problem with agreeing with the claim while disagreeing with the examples. Contrary to the author’s claims, the CSS layout system is freakishly complicated, the fully generalized RDF semantic web was dead on arrival, I have to side with the linguistic descriptivism that led to the HTML5 parser, and as for URLs, the widespread success of phishing attacks proves that they don’t work.

    But WebAssembly really is the correct solution to the wrong problem. Honestly, so is the aforementioned freaky CSS layout system. The web was never supposed to need either of those things, and the only reason it’s needed now is because of perverse network effects that turned the world’s most popular document database into the world’s worst designed application platform.

    1. 3

      Also, we have web assembly because googles proposal, native client, didn’t catch on.

      1. 6

        And ActiveX and NPAPI and Flash and Silverlight–decades of every browser stake holder trying to find a way to run binaries in the browser.

        1. 1

          Flash absolutely did catch on—it was installed basically universally for years, and failed more because Adobe horrendously mismanaged it than due to fundamental issues with the technology.

          Personally, I don’t think WebAssembly is significantly worse than having Javascript at all. Running random code from the internet is a terminally bad idea (and always has been, even long before Meltdown and Spectre gave us specific, compelling reasons to fear it); it makes precious little difference if that code is in source code form or a binary translation thereof (or, since minification/“uglification” is very common these days, a text translation thereof).

    2. 10

      Now, take this state of affairs and apply EME to it. Imagine a few years down the road it seems expedient to take the infrastructure which is already present and ubiquitous, and create Version 1.1 of Encrypted Media Extensions, which also applies to code. Not only, at this point, has “view source” been completely obliterated, but it would actually be a crime—at least in the United States—to try to do what has been taken for granted for the last 30 years.

      Folks complained about this, but it’s dismissed as tinfoil hattery and stodginess, because it’s waaaaay more important that people be able to program browsers in their favorite pet language. Play stupid games, win stupid prizes.

      1. 6

        By being declarative and deterministic, and rendered in ordinary plain text, HTML and CSS conceal no surprises, which is likely why they are not considered “real programming” by “real” programmers. This property, however, makes them especially easy to learn. Moreover, they are all you need to learn in order to achieve a great many useful results in an open Web.

        I’m not sure how charitable to be with this statement. Both HTML and CSS require “virtual machines” for presentation and it’s just that the virtual machine is hidden deep in the bowels of the browser and the rendering pipeline. So in that sense both HTML and CSS are not really just “plain text” but more code interpreted by a hidden part of the web stack that no one other than the browser engineers have any control over because it is baked into the core of the browser (unlike JavaScript which has more obvious semantics because it is not hiding the fact that it is a programming language).

        The same argument that applies to JavaScript applies to WebAssembly. WebAssembly exposes more parts of the stack to user space and allows more control instead of having to rely on hard-coded rendering rules for HTML and CSS. In theory anyone can implement an interpreter for WebAssembly and be off to the races. That’s all a long-winded way of saying I don’t think HTML and CSS are as simple as the author makes them out to be.

        The rest of it seems reasonable to me. Any organization that was created to solve a problem at some point starts propagating a variation of the problem it was meant to solve because it has become really good at solving variations of that problem. Google I guess is really good at crawling so whatever advantage it can eek out for itself to make it harder for some upstart to do the same will be prioritized and pushed forward. Other organizations do the same thing in their respective domains and this is a social problem so we need to address it as a social problem instead of couching it in technical language and chasing technical solutions about open standards.

        This also reminds me of a quote

        “It is a mistake,” he said, “ to suppose that the public wants the environment protected or their lives saved and that they will be grateful to any idealist who will fight for such ends. What the public wants is their own individual comfort. We know that well enough from our experience in the environmental crisis of the twentieth century. Once it was well known that cigarettes increased the incidence of lung cancer, the obvious remedy was to stop smoking, but the desired remedy was a cigarette that did not cause cancer. When it became clear that the internal-combustion engine was polluting the atmosphere dangerously, the obvious remedy was to abandon such engines, and the desired remedy was to develop non-polluting engines.”

        ― Isaac Asimov, The Gods Themselves

        1. 5

          Sure do wish these posts had publication dates on them :/

          1. 4

            In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

            – Priority of Constituencies, from HTML Design Principles

            I consider the current status of web to be “authors over users”. Authors should not be able to choose how their contents look, especially not in pixel perfect manner. That right belongs to users. This is the root of all complexity of CSS and interoperability problems.

            1. 1

              vote with your feet. Go for the browsers where you as a user feel considered more important than web authors or implementors.

              1. 1

                And which one is that?

                1. 2

                  Surely depends on each individual user and their priorities (capable apps, OS integration, battery efficiency, security, privacy), no?

                  I’m biased of course 😏