9 ms·

Yes, you're right. This can allow to avoid JS in browser altogether one day. As a hardcore JavaScript developer I welcome this tech for a couple reasons. For o

by maga 10y ago

Yes, you're right. This can allow to avoid JS in browser altogether one day. As a hardcore JavaScript developer I welcome this tech for a couple reasons. For one thing, it's undeniably a significant step forward for Web Platform as a whole. For another, now people can struggle with the peculiarities of the said Web Platform with their own languages. The legitimate grievances associated with JS over the years were due to the browser APIs and first of all DOM, which wasn't designed for JS to begin with and later just accumulated problems for the sake of backwards compatibility.

RussianCow 10y ago
I don't think that will be feasible in the near future, because in order to run another language in the browser (say, Python) through wasm, you will need to bundle the entire runtime with your app, which is an unacceptable amount of overhead for most apps.
- comex 10y ago
  I feel like this shouldn't be the end of the world. If everyone uses the same CDN for a given language's runtime (with subresource-integrity to ensure security), even a 1MB download should be... tolerable. Not great, but tolerable. Load time is also an issue, but WebAssembly is designed to greatly improve initial load time compared to asm.js.
  - hackcasual 10y ago
    I'm currently working on a large-ish code based designed primarily to run via Emscripten. Current optimized .js size is 3MB. While the WASM size is noticeably smaller <2MB, startup time is actually worse due to browsers compiling everything ahead of time.
    - maga 10y ago
      > startup time is actually worse due to browsers compiling everything ahead of time. On an upside, with WASM browsers can potentially save a snapshot of the compiled code to speed up re-runs. I recall the idea was promoted back when Dart was expecting to get its own VM, and one of the things that it would be capable of was this snapshot using.
      - hackcasual 10y ago
        True, and I've seen great results with Firefox's asm.js AOT mode, but the app I'm working on has a lot of non cached users.
  - Klathmon 10y ago
    That has been tried and failed with JavaScript libraries in the past. Even if you can get everyone to agree on one canonical CDN (you can't), you also need to get everyone to agree on one version of the file at the CDN. Plus cache sizes on most platforms are laughably small (a heavy page can completely blow out your cache on mobile devices). IIRCthere was a "study" while back that found by using the most common CDN at the time to host jQuery, you only got like a 5% cache hit rate. This was because of multiple CDNs, multiple versions, multiple ways to reference the version (1.2.3 vs 'latest'), and http/HTTPS. In my past experience, we had more trouble with people blocking our CDN via corporate networks or something.
    - douche 10y ago
      One of the problems with JS is the unbelievable amount of churn. It's not uncommon to see libraries have version half-lives in the days or weeks. The firewall issue is always going to be a problem on corporate networks. I don't think we're ever realistically going to get away from having to self-serve dependencies if you want to ensure that things are going to work, particularly if it's software that is deployed in on-premise, internal servers.
      - Klathmon 10y ago
        But this isn't a js churn problem. Even if updates only happen every 6 weeks, that means that unless the majority of devs update their links every 6 weeks the distribution of links out there will be spread out enough to be nearly worthless. And while updates every 6 weeks might seem crazy to you, unless we just don't version the links (which seems like a terrible idea), even simple bugfxes blow the whole system. Plus CDN hosted systems come with a bunch of other downsides. Lack of http2 pushing, tree shaking and bundling doesn't work, being able to compile with your own settings, and more. CDNs aren't the solution here, something like using service worker and/or an "install" process for web apps will solve all of these and more.
    - TurningCanadian 10y ago
      I wonder why browsers don't use subresource integrity to share cached items across origins. Maybe they do? If hash collisions is a problem, they could limit it to certain hash algorithms.
- labrador 10y ago
  I don't think anyone is suggesting that people do this. The idea is to save time by compiling JavaScript ahead of time and shipping the results of the compilation, which I think I understand to be a binary version of an AST.
  - Klathmon 10y ago
    IIRC one of the bigger reasons behind wasm is to cut out the parsing time for JS (which is currently a pretty big bottleneck to startup time and memory, especially on mobile devices)
- kruhft 10y ago
  Would not the browsers start 'bundling' for popular languages (python, ruby, Common Lisp ;-) or allow for cache 'preloads' for popular runtimes?
  - RussianCow 10y ago
    How would you draw the line on which languages/runtimes deserve to get bundled/cached? You could make the same argument for JavaScript libraries—shouldn't web browsers just bundle jQuery?—but there's ultimately no good way to do that.
    - kruhft 10y ago
      I see a move to (browser?) specific based installer packages and a re-thought static 'cache' mechanism/area to do the preload. Of course, we move from the beauty of no-install software on the web back to runtime installing but...maybe it would be better?
- jay_kyburz 10y ago
  I'll do it, I don't care if its 10 meg.
moron4hire 10y ago
I would really like to know specifics on your criticism of DOM. I've seen a lot of people complain about DOM over the years, but I've never heard anything specific.
- mememachine 10y ago
  I think having it be entirely separated from JS was a mistake. A lot of the web is Apps not documents and the separation is often much more of a hindrance than a help. Obviously it can be nice for organization, but that should really fall more on the individual to decide than the spec.
  - moron4hire 10y ago
    In what way do you consider DOM separate from JS such that it causes difficulty for application development?
    - mememachine 10y ago
      Take the entire usecase for ReactJS as my example
      - moron4hire 10y ago
        Seeing as I don't see the need to use React, I also don't see your point.
        mememachine 10y ago
        Do you see the need for the C language? They both make life significantly easier
        moron4hire 10y ago
        To draw a comparison between JS and assembly is to seriously misunderstand both.

by maga 10y ago

RussianCow 10y ago

I don't think that will be feasible in the near future, because in order to run another language in the browser (say, Python) through wasm, you will need to bundle the entire runtime with your app, which is an unacceptable amount of overhead for most apps.

comex 10y ago
I feel like this shouldn't be the end of the world. If everyone uses the same CDN for a given language's runtime (with subresource-integrity to ensure security), even a 1MB download should be... tolerable. Not great, but tolerable. Load time is also an issue, but WebAssembly is designed to greatly improve initial load time compared to asm.js.
- hackcasual 10y ago
  I'm currently working on a large-ish code based designed primarily to run via Emscripten. Current optimized .js size is 3MB. While the WASM size is noticeably smaller <2MB, startup time is actually worse due to browsers compiling everything ahead of time.
  - maga 10y ago
    > startup time is actually worse due to browsers compiling everything ahead of time. On an upside, with WASM browsers can potentially save a snapshot of the compiled code to speed up re-runs. I recall the idea was promoted back when Dart was expecting to get its own VM, and one of the things that it would be capable of was this snapshot using.
    - hackcasual 10y ago
      True, and I've seen great results with Firefox's asm.js AOT mode, but the app I'm working on has a lot of non cached users.
- Klathmon 10y ago
  That has been tried and failed with JavaScript libraries in the past. Even if you can get everyone to agree on one canonical CDN (you can't), you also need to get everyone to agree on one version of the file at the CDN. Plus cache sizes on most platforms are laughably small (a heavy page can completely blow out your cache on mobile devices). IIRCthere was a "study" while back that found by using the most common CDN at the time to host jQuery, you only got like a 5% cache hit rate. This was because of multiple CDNs, multiple versions, multiple ways to reference the version (1.2.3 vs 'latest'), and http/HTTPS. In my past experience, we had more trouble with people blocking our CDN via corporate networks or something.
  - douche 10y ago
    One of the problems with JS is the unbelievable amount of churn. It's not uncommon to see libraries have version half-lives in the days or weeks. The firewall issue is always going to be a problem on corporate networks. I don't think we're ever realistically going to get away from having to self-serve dependencies if you want to ensure that things are going to work, particularly if it's software that is deployed in on-premise, internal servers.
    - Klathmon 10y ago
      But this isn't a js churn problem. Even if updates only happen every 6 weeks, that means that unless the majority of devs update their links every 6 weeks the distribution of links out there will be spread out enough to be nearly worthless. And while updates every 6 weeks might seem crazy to you, unless we just don't version the links (which seems like a terrible idea), even simple bugfxes blow the whole system. Plus CDN hosted systems come with a bunch of other downsides. Lack of http2 pushing, tree shaking and bundling doesn't work, being able to compile with your own settings, and more. CDNs aren't the solution here, something like using service worker and/or an "install" process for web apps will solve all of these and more.
  - TurningCanadian 10y ago
    I wonder why browsers don't use subresource integrity to share cached items across origins. Maybe they do? If hash collisions is a problem, they could limit it to certain hash algorithms.
labrador 10y ago
I don't think anyone is suggesting that people do this. The idea is to save time by compiling JavaScript ahead of time and shipping the results of the compilation, which I think I understand to be a binary version of an AST.
- Klathmon 10y ago
  IIRC one of the bigger reasons behind wasm is to cut out the parsing time for JS (which is currently a pretty big bottleneck to startup time and memory, especially on mobile devices)
kruhft 10y ago
Would not the browsers start 'bundling' for popular languages (python, ruby, Common Lisp ;-) or allow for cache 'preloads' for popular runtimes?
- RussianCow 10y ago
  How would you draw the line on which languages/runtimes deserve to get bundled/cached? You could make the same argument for JavaScript libraries—shouldn't web browsers just bundle jQuery?—but there's ultimately no good way to do that.
  - kruhft 10y ago
    I see a move to (browser?) specific based installer packages and a re-thought static 'cache' mechanism/area to do the preload. Of course, we move from the beauty of no-install software on the web back to runtime installing but...maybe it would be better?
jay_kyburz 10y ago
I'll do it, I don't care if its 10 meg.

moron4hire 10y ago

I would really like to know specifics on your criticism of DOM. I've seen a lot of people complain about DOM over the years, but I've never heard anything specific.

mememachine 10y ago
I think having it be entirely separated from JS was a mistake. A lot of the web is Apps not documents and the separation is often much more of a hindrance than a help. Obviously it can be nice for organization, but that should really fall more on the individual to decide than the spec.
- moron4hire 10y ago
  In what way do you consider DOM separate from JS such that it causes difficulty for application development?
  - mememachine 10y ago
    Take the entire usecase for ReactJS as my example
    - moron4hire 10y ago
      Seeing as I don't see the need to use React, I also don't see your point.
      - mememachine 10y ago
        Do you see the need for the C language? They both make life significantly easier
        moron4hire 10y ago
        To draw a comparison between JS and assembly is to seriously misunderstand both.