7 ms·

Node, webpack, yarn, npm, frameworks, UMD, AMD, arghhh! Yes, the way most web developers click together their project these days is a bloated mess. But Web Ass

• pjmlp 8y ago
  That is the only way Web will ever catch up with native, by becoming itself yet another generic purpose VM platform. In the process it will be the revenge of plugins.
  • TekMol 8y ago
    The web already is 'generic purpose'. Outputting JS or WA does not make any difference in that regard. It just makes things a bit faster.
    • erikpukinskis 8y ago
      It’s not necessarily any faster. You can shoot yourself in the foot quite easily too, performance wise.
      • mankash666 8y ago
        It's more predictable, when generated from a strongly typed language. Most of the times, due to the strong typing, it is faster. However, there's a cost involved in compiling, invoking and passing data in and out of a wasm module. If the overhead cost is greater than the raw performance gain, there's no discernable difference
        • uluyol 8y ago
          Don't forget about crossing language boundaries. Using JNI can be slower than pure Java code, and I think the same is true for wasm-js interop [1]. When wasm gets "native" access to the DOM and other browser features this may change, but until then, DOM manipulation is probably going to be faster in js. [1] someone should benchmark this.
          • johncolanduoni 8y ago
            JNI transitions (at least on OpenJDK and Android) are much more expensive that WebAssembly<->JavaScript transitions. For the latter the same JIT is being used on both sides and there is no need for a GC transition. JNI is also far from as fast as it could be; .NET’s PInvoke is much more efficient (and easier to use).
            • pjmlp 8y ago
              Mark Reinhold already stated on a few talks, including at JavaONE that Sun designed it that way on purpose as they wanted to keep everyone true to WORA without carrying native code around. Which is also a reason why a replacement is being done as part of Project Panama, initially advocated by Charles Nutter due to the JRuby project issues. http://openjdk.java.net/jeps/191 http://openjdk.java.net/jeps/191 In alternative, if you have the source code available there is a way not to any transitions. Java now has GraalVM and .NET had C++/CLI (nee Managed C++) since the beginning.
    • rubber_duck 8y ago
      In this version of web assembly only ! Web Assembly is gimped because it needs to be compatible with existing JS runtimes - when they add threading support you will no longer be able to run a WASM shim in JS but at the same time WASM will become a lot more general purpose.
      • TekMol 8y ago
        Javascript already has multithreading via webworkers. That's not something WASM will introduce.
        • rubber_duck 8y ago
          SharedArrayBuffer is only available in chrome and FF and they disable it by default so no way to do standard multithreading via webworkers.
          • TekMol 8y ago
            It was disabled because of spectre. Multithreaded WASM isn't here either. I think WASM will face the same security considerations.
          • untog 8y ago
            Webworkers are multithreading. You just have to use slower, async communication methods. WASM will likely be the same way, given the security considerations.
            • pjmlp 8y ago
              WASM will have more low level support. https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md https://github.com/WebAssembly/threads/blob/master/proposals...
      • johncolanduoni 8y ago
        Existing JS runtimes actually use shared-memory concurrency a ton, even ignoring the (currently disabled) SharedArrayBuffer. Code generation and garbage collection have at least some concurrent stages on all the major JS engines. JavaScriptCore even exposes this in its API.
    • derefr 8y ago
      Sure, the web is sometimes used that way currently, but few projects are using full-on Foo-to-JS compilers like GWT or ClojureScript that make the original source entirely illegible when viewed through the browser console. Instead, projects are mostly using "light" transpilers built to have clean mappings to JS semantics, like TypeScript, where the original source can be recovered and traced by the browser as long as the transpiler generates a source-map. WASM really won't work with the "source map" paradigm, and so a move to a web where most development uses languages that compile to WASM, is a move to a more opaque, less learnable web. (And also one that browser extensions have far less of an ability to intercede in.)
      • kreetx 8y ago
        But there's an upside, no? There is no way to reference an undefined variable in go? So if the compiler is correct, so will be the result, and errors would be found compile time. (written by a non-go-expert)
        • ovao 8y ago
          While you cannot reference an undefined variable in Go, you can still dereference nil pointers and invoke other operations that result in a panic (some of the standard library functions can panic).
      • Felz 8y ago
        Why won't WASM really work with the "source map paradigm"? Is there something fundamentally different about bytecode that means it cannot be traced back to its original source, given tooling support?
        • slimsag 8y ago
          WASM will have source map support, if it does not already. There is already support on Firefox nightly it seems: https://github.com/yurydelendik/wasm-source-map-emscripten https://github.com/yurydelendik/wasm-source-map-emscripten
      • eklitzke 8y ago
  • chiefalchemist 8y ago
    But if catching up means taking on baggage and complexity, is that still a win. Technology is a means, not an ends. Of course non-native should evolve, but taking a copy-cat approach seems like a not so good plan.
  • skybrian 8y ago
    By itself, adding the Go SDK to the mix is unlikely to simplify the toolchain. To do that, you need to remove more complexity than you add. There might be a chance to simplify if you're already using Go on the server and you remove a lot of other stuff.
  • solarkraft 8y ago
    Luckily the "plugins" will be bundled with the apps. The trade-off is ever-increasing download sizes.
    • pjmlp 8y ago
      In the age of using JavaScript to render text.
• billybolton 8y ago
  No webassembly is a solution to it. JS just sucks. Actually so does HTML and CSS. The entire web ecosystem is a closed platform. The reason that the front end stack is constantly bloated is because JS,HTML & CSS are awful. If the people behind wasm were smart, they'd allow generic handles to a graphics context so that people can write/export other rendering frameworks. Strong typing is good, reactive programming is good. Using html and css strings is idiotic, and we couldn't build alternatives to this model for the past 30 years.
  • gedy 8y ago
    > If the people behind wasm were smart, they'd allow generic handles to a graphics context so that people can write/export other rendering frameworks Games maybe, but for normal applications sounds like would just end up with worse graphics than old Java applets, Swing, etc.
  • derefr 8y ago
    HTML (or any SGML-derivative, really) + CSS is the only application view format we have in common use that allows for clients of all shapes and sizes to reformat the page to fit them (with reflow rules, browser-default styles, and user-agent styles); and for alternative clients like screen-readers or "scraper"-like API clients to work with the view without the author having considered their needs ahead of time; and, best of all, for client-supplied optional third-party extensions to go into the view and mutate it to suit whatever custom purpose the client desires. In other words, by mandating that the application view layer interacts with the client by delivering declarative (HTML) or imperative (JS) instructions to populate a semantic document (the DOM), rather than to populate a particular viewport; and by mandating that styling considerations are kept as separated as possible from that document; we can then operate on that document apart from the application's control, and render it the way we want to, or parse it into something entirely else. A large part of the point of "the web" as a technology stack, is to provide exactly that capability. There's even a name for explicitly targeting such use-cases as a developer: HATEOAS (i.e. making your API endpoints act like web pages as well, in that they're also "documents" embedding hyperlinks to related documents, and form-input descriptions for making queries against the document—so that API clients can "navigate" your API just like browsers navigate your site. In extremis, your API becomes your site—since, if every endpoint is already responding with hyper-documents, your controllers can just have a logic for "Accept: text/html" that renders that hyper-document into hypertext, and attaches styling to it.) If you don't care about any of that, you don't need the web. You just need a Hypercard viewer with an address bar. Or Lotus Notes.
• bitL 8y ago
  Initially you'll use JavaScript as a top-level glue and all the submodules in WebAssembly. Then once it's stable you just get rid of all the JavaScript. You can even completely abandon DOM/HTML if you like and won't feel speed penalty for it.
  • untog 8y ago
    JavaScript as glue and WebAssembly modules is more complicated, though, not less. The JS ecosystem is a complicated mess, it's undeniable. But once you take the time to learn it, it's fine. In the majority of cases WebAssembly is just give to give the lazy an excuse to use a language they already know rather than learn something new. And as for abandoning the DOM... yeah, it's not a great model. But is a dozen incompatible, competing rendering frameworks (that each site downloads separately) going to be good for the web?
    • bitL 8y ago
      For DOM - we will see I guess. It simply opens the door for some much needed competition ;-)
    • akira2501 8y ago
      > But once you take the time to learn it, it's fine. For a short period of time, sure.. but the ecosystem evolves quickly, and often in inexplicable ways. > In the majority of cases WebAssembly is just give to give the lazy an excuse to use a language they already know rather than learn something new. Most people program in return for money, not for self-satisfaction at learning yet another single-purpose language. > But is a dozen incompatible, competing rendering frameworks (that each site downloads separately) going to be good for the web? How is this significantly different from where we are now?
      • untog 8y ago
        > self-satisfaction at learning yet another single-purpose language is a weird way of describing learning the language native to the web platform. I don't see a lot of people screaming about having to learn Objective C or Swift to make iOS apps. > How is this significantly different from where we are now? Err, because the DOM is a universal standard that comes built-in to every browser? <div style='background:red'/> looks the same everywhere, with no extra code required. If you're building a new renderer from scratch you're going to have a lot more code users need to download.
• baq 8y ago
  You don't throw web assembly in there and keep js, you throw js out at the same time.
  • AndyMcConachie 8y ago
    If you look at the sheer number of requests to fetch some JS from some random website happen when loading a modern web page this will not be possible. Web pages rendering depend on JS being pulled from many places, and often not under the dev's control. So we'll end up with a mix of JS and WASM whether we like it or not.
    • tzahola 8y ago
      Strange... I’ve seen plenty of “modern” websites without 3rd party JS bloat.
  • tomjakubowski 8y ago
    It would be tricky to completely throw JS away until WASM is able to call into the "browser APIs" (DOM, XHR, etc.)