13 ms·

I hope WebAssembly will not only be a web technology, but the de-facto format for cross-platform high-performance embedding. Such as for plugins, scripting and

I hope WebAssembly will not only be a web technology, but the de-facto format for cross-platform high-performance embedding. Such as for plugins, scripting and extensions. Something you could send over the wire to the remote application and it could execute it with high performance and reasonable security. Cryptographic signatures can be used for more security sensitive contexts. So one thing I'm really hoping no matter what happens to WebAssembly, that the external interface and requirements are kept simple. Minimal required dependencies, no built-in class library, etc. It'd be ideal if WASM runtime environment is very lightweight, preferably just 100s of kB. The smaller, the better. Especially some kind of dependency for Javascript would be disastrous. It'd be amazing if it was possible to run small ~10 kB WASM modules remotely on a microcontroller, like Cortex M4+ or such, with say 64 kB of RAM. You could add a lot of flexibility in some applications. It actually looks very interesting for cross-platform "scripting", once there's a good cross-platform optimizing compiler library for it. From where I stand, currently the most interesting proposals of the listed ones: 0) High-performance non-web "embeddability" with low memory requirements. (Not actually listed, but very much desirable.) 1) Threading. Would greatly help performance and portability in some cases. I'm a bit sceptical whether there's a way to add this after CPU speculative attacks (Spectre, etc.) became known. 2) SIMD. Lots of filtering and data processing algorithms can greatly benefit from this. 3) Tail calls / bulk memory ops. 4) Export / import mutable globals (and good module support in general) 5) Exceptions. (Minor, portability).

madeofpalk 8y ago
That's more or less what Javascript is today.
- vardump 8y ago
  While Javascript can serve a subset of these applications, its runtime is bulky and high performance Javascript JIT weighs a lot due to required complexity. WebAssembly is a lot less complicated, and has a lot of potential.
  - swsieber 8y ago
    I would say that a nice simplified view of things is that the WebAssembly lifts complexity from execution optimization into compilation (or wasm production) optimization, allowing the runtime to be much lighter/faster.
- simion314 8y ago
  I assume with WebAssembly you could get existing c/c++ etc libraries and recompile them and use them. Even a JS lover that wants to make desktop apps could benefit of having access at the large number of existing libraries without having to use a bridge to the native libraries.
pjmlp 8y ago
Universal bytecode formats have been tried since UNCOL. https://en.wikipedia.org/wiki/UNCOL https://en.wikipedia.org/wiki/UNCOL Outside the browser it adds very little over Java, MSCLI, LLVM, P-Code, M-Code, Python Bytecodes, TIMI, DEX and a myriad of other formats. Cortex M4 is already targeted by MicroEJ and MicroPython.
- vardump 8y ago
  > Universal bytecode formats have been tried since UNCOL. No doubt there have been plenty of those. > Outside the browser it adds very little over Java, MSCLI, LLVM, P-Code, M-Code, Python Bytecodes, TIMI, DEX and a myriad of other formats. It does add one very important thing: a large ecosystem. One where security and performance matters: the web.
  - pjmlp 8y ago
    WebAssembly manipulation tooling is in its infancy compared with what is available for manipulating some of the bytecodes I mentioned on my comment. Regarding libraries, graphical debuggers and reverse code generation. Security and performance were part of Java and .NET design, hence why they have validation as part of their execution workflow. As for security on the Web, cross site scripting and WebGL exploits prove that is still room for improvement.
    - wtetzner 8y ago
      The fact that it's the only standard way to run on the web without Javascript means that every language and its dog will have a WebAssembly backend. I wonder if the real difference between WebAssembly and the other bytecodes you mentioned is just the number languages that will end up targeting it. Though, one advantage over LLVM is that it's simpler.
      - seanmcdirmid 8y ago
        Has WASM bridges the DOM problem with a nice solution yet? If not, it isn’t even a way to run on the web yet.
krapp 8y ago
>Minimal required dependencies, no built-in class library, etc. It'd be ideal if WASM runtime environment is very lightweight, preferably just 100s of kB. The smaller, the better. Especially some kind of dependency for Javascript would be disastrous. Unfortunately, what's likely to happen is that everyone just ships their WASM apps in Electron since that's already the de facto standard.
- pjmlp 8y ago
  > Unfortunately, what's likely to happen is that everyone just ships their WASM apps in Electron since that's already the de facto standard. Standard where? A couple of well know apps beloved by startups with high end desktop systems?
  - krapp 8y ago
    It's the standard for packaging "web applications" to run natively, and the path of least resistance for doing the same with code compiled to WASM. Also VS code runs on Electron, so it's hardly uncommon.
    - pjmlp 8y ago
      That is called PWA. Electron apps are as native as PWAs, with the caveat that they bring a 300 MB runtime alongside with them. I bet there are still more Swing applications in production than VSCode users. That doesn't make JAR a de facto packing format.
      - krapp 8y ago
        The point is that existing solutions in practice, however bad they might be, will always beat better solutions which only exist in theory. Electron apps (or, fine, PWAs) will become the standard model for WASM development because that model already exists, and is what developers will most readily use... and because most of the interest in WASM comes from the web development community. By the time something better comes along, it will have to fight against the network effects.
zaarn 8y ago
There is another area where WASM could become very interesting; Operating Systems. Or more specific: Kernels. A nanokernel with the capability to run a WASM binary with a simple GC could have highly portable kernel modules and due to the properties of WASM, run userspace code in ring 0 without much risk to hardware and software. Additionally stuff like paging and memory management are much simpler to begin with as the memory access pattern of WASM is much simpler (with some dynamic relocation tricks that should be possible you could even identity map and don't do paging at all) I've also thought about doing microcontrollers as you mention, however, I was thinking about Arduino's (ATmega). They would need a much simpler and more reduced WASM since you only have about 2 KB of work memory.
- kam 8y ago
  There's already a WASM-centric OS in development: https://github.com/nebulet/nebulet https://github.com/nebulet/nebulet
  - zaarn 8y ago
    Yup, that's part of where the idea comes from, I would favor more research in this area though.
    - pjmlp 8y ago
      I case you aren't aware of these, here are some pointers for Burroughs[1], Xerox's Mesa/Cedar[2], Pascal UCSD[3], M-Code[4] and Oberon Juice[5]. [1] - http://retro-b5500.blogspot.com/ http://retro-b5500.blogspot.com/ [2] - http://worrydream.com/refs/Teitelman%20-%20The%20Cedar%20Programming%20Environment,%20A%20Midterm%20Report%20and%20Examination.pdf http://worrydream.com/refs/Teitelman%20-%20The%20Cedar%20Pro... [3] - http://pascal.hansotten.com/category/ucsd-p-system/ http://pascal.hansotten.com/category/ucsd-p-system/ [4] - http://pascal.hansotten.com/niklaus-wirth/lilith/ http://pascal.hansotten.com/niklaus-wirth/lilith/ [5] - ftp://ftp.cis.upenn.edu/pub/cis700/public_html/papers/Franz97b.pdf
bryanlarsen 8y ago
"the external interface and requirements are kept simple." I would bet strongly against that happening long term. Everybody developing WebAssembly is interested in making the web better and pretty much only that. One of the biggest issues preventing WebAssembly usage right now is that you have to ship a large run-time along with your app. So there's going to be a lot of pressure to move that run-time into the browser. See the linked article: GC is the proposal the author highlights the strongest. The biggest pressure in your favour is the disparity of languages supported. They'll probably want to ensure that any built-in library functions they add are useful to a wide range of WebAssembly communities.
- couchand 8y ago
  > Everybody developing WebAssembly is interested in making the web better and pretty much only that. This is demonstrably untrue. Please peruse the design repo, I think you'll find that there are very frequently discussions of non-web applications, something folks are actually quite keen to support.
  - bryanlarsen 8y ago
    Perhaps, but the real stakeholders are the browsers. Do you really think they'd hold off on GC if somebody told them that would make it problematic on embedded?
    - TomMarius 8y ago
      Embedded maybe, but it's a good feature for literally the rest of applications.
    - steveklabnik 8y ago
      The same people who work on the browsers are the same people who are in favor of this. The initial authors of wasm created the spec in this way for a reason; it's something they care about.
- wahern 8y ago
  The moment GC is added to WebAssembly will the the moment WedAssembly becomes no more secure than JavaScript. Either that or performance will tank. The GC is one of the most complicated parts of the browser engine, and serious bugs and exploits are regularly discovered in all of them. Safer languages like Rust won't help at all in the case of WebAssembly because it's not sharing the same type system. Further more, it's all kind of pointless. No two GCs are the same. A GC is more than simply tracing. Different languages provide different semantics with regards to finalizers, for example.[1] The semantics of the GC closely mirror design decisions of the language. If you're using the JavaScript GC then your language will be limited to the semantics of JavaScript, in which case why are you bothering with some random language? [1] Are finalizers even supported? Can they run arbitrary code? Can they resurrect the object? If they can, will they run again? Can they throw an error? What happens if they throw an error? In a language like Lua these rules are very specific because they're important to the semantics of the C API, especially wrt to bindings. For example, within a collection cycle Lua finalizers are guaranteed to be run in reverse order of construction.
jmull 8y ago
> I hope WebAssembly will not only be a web technology, but the de-facto format for cross-platform high-performance embedding. I don't think that's what's happening. They are looking to integrate webassembly more deeply with its host environment (which more-or-less assumes a browser and Javascript). I don't think this is a bad thing, BTW. You may be disappointed, but they are just looking to solve a different problem then what you are concerned with. It's an imminent, practical problem, so nothing wrong with someone addressing it, even if it isn't your problem.
- kodablah 8y ago
  Disagree. Watching all of the WebAssembly discussion around proposals and the spec in the GitHub issues, the leads are always mentioning non-web uses and are always being careful to separate the JS/Web ifaces/impls.
  - jmull 8y ago
    I guess we'll see, but integrating with the host garbage collector is pretty suggestive, to me. Aside from that, an app/program/whatever delivered as webassembly will typically have strong dependencies on the target host environment, which means its not portable or cross-platform. It's not useless, since you still get to choose your own language for any target that supports webassembly (assuming things work). But code, whatever language its written in, is very strongly influenced by the frameworks & patterns provided/imposed by the host environment, by environmental constraints, not to mention the problem domain itself. E.g., assume there are bindings for any language you want... if you write a To-Do app for iOS using native controls, it's going to look pretty similar whatever the language. > ...and are always being careful to separate the JS/Web ifaces/impls I'll just point out that this is quite important if your goal is to cleanly extend browsers. You specifically don't want to duplicate or impinge anything the browsers already provide. I'm not trying to be a downer, but it seems like people are hoping/expecting webassembly to do more than it can or will (maybe I'm wrong, but that's the impression I'm getting). Meanwhile, we have a very solid use case for it, which is a much better compile target than Javascript for whatever language you might want to use for web development.
- 8y ago
kodablah 8y ago
> 4) Export / import mutable globals (and good module support in general) Already done (at least at the spec level), ref: https://github.com/WebAssembly/spec/pull/814 https://github.com/WebAssembly/spec/pull/814. I'm currently implementing it in my non-web WASM backend now :-)
- jedisct1 8y ago
  What is your non-web WASM backend?
  - kodablah 8y ago
    https://github.com/cretz/asmble https://github.com/cretz/asmble
pocketaces 8y ago
I hope not. The subset of native (for example, x86) assembly that is equivalent to webassembly is already perfectly secure. You just limit the native assembly to pure computations without any system calls. It will also always be significantly faster than webassembly. When it comes to the security of system calls, then both webassembly and native assembly needs to make sure that whatever platform-calls that are available are secure. webassembly have no benefits over native assembly when it comes to this. Also, I doubt that it will gain as much popularity as some people predict. asm.js (the "original" webassembly) has been available for quite a long time already (and the technology behind it have existed for very very long), and if it were going to create a flood of developers targeting it instead of using javascript, then I think it would have happened by now. Inertia when it comes to development tools should not be underestimated and I doubt that all of the web developers who have invested in becoming javascript "experts" want to see the ecosystem change and see all of their "experience" and "expertise" become worthless.
- fold_left 8y ago
  > I doubt that all of the web developers who have invested in becoming javascript "experts" want to see the ecosystem change and see all of their "experience" and "expertise" become worthless. Can you expand on what you mean when quoting those words in this context? I can't put my finger on what point you're trying to make here.
  - pocketaces 8y ago
    I am just a bit biased when it comes to my perception of most javascript developers. I should probably have left out the quotation marks. That would have made the comment more focused. However, with that being said, then the point is, that I find that there are significantly more developers who identify as being javascript experts than there are actual javascript experts, and that both groups contribute to the inertia.
    - batmansmk 8y ago
      First time I read JS and inertia side by side. I heard/read way more often complaints about its speed...
jsheard 8y ago
> 1) Threading. [...] I'm a bit sceptical whether there's a way to add this after CPU speculative attacks (Spectre, etc.) became known. The plan is to rely on site isolation, where every origin runs in a separate process. Spectre only exposes memory in the same process so this should make it benign. SharedArrayBuffer was disabled due to Spectre but Chrome plans to re-enable it soon: https://bugs.chromium.org/p/chromium/issues/detail?id=821270 https://bugs.chromium.org/p/chromium/issues/detail?id=821270
- nine_k 8y ago
  Of course the very point of Spectre is reading memory of unrelated processes or of an OS kernel [1]. Reading memory of the same process you're running is normal and trivial. [1]: https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)#Detailed_explanation https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...
tathougies 8y ago
Someone must have forgotten Java.
- wtetzner 8y ago
  > High-performance non-web "embeddability" with low memory requirements. I don't think Java fulfills this requirement. Or the one about tail calls. Java bytecode is too high-level, too. It forces you into a very limited execution framework.
- DonHopkins 8y ago
  Larry Ellison is an irresistible reason to forget about Java.
austincheney 8y ago
Your vision sounds like a potential vector for the widest possible distribution of malware. If you want to spin off WASM out from the browser into an independent technology then fine, but you need the same (preferably greater) security limitations that the browser already provides. Ensuring that level of constricted access uniformly and assuredly without any kind of accreditation is extremely unlikely. > Especially some kind of dependency for Javascript would be disastrous. I will not speak to outside the browser, but inside the browser this isn't changing. JavaScript remains the language of the browser and WASM is not in competition there. This isn't my personal opinion. It is the stated goal of WASM as a technology. The primary reason for that: security.

madeofpalk 8y ago

That's more or less what Javascript is today.

vardump 8y ago
While Javascript can serve a subset of these applications, its runtime is bulky and high performance Javascript JIT weighs a lot due to required complexity. WebAssembly is a lot less complicated, and has a lot of potential.
- swsieber 8y ago
  I would say that a nice simplified view of things is that the WebAssembly lifts complexity from execution optimization into compilation (or wasm production) optimization, allowing the runtime to be much lighter/faster.
simion314 8y ago
I assume with WebAssembly you could get existing c/c++ etc libraries and recompile them and use them. Even a JS lover that wants to make desktop apps could benefit of having access at the large number of existing libraries without having to use a bridge to the native libraries.

pjmlp 8y ago

Universal bytecode formats have been tried since UNCOL. https://en.wikipedia.org/wiki/UNCOL https://en.wikipedia.org/wiki/UNCOL Outside the browser it adds very little over Java, MSCLI, LLVM, P-Code, M-Code, Python Bytecodes, TIMI, DEX and a myriad of other formats. Cortex M4 is already targeted by MicroEJ and MicroPython.

vardump 8y ago
> Universal bytecode formats have been tried since UNCOL. No doubt there have been plenty of those. > Outside the browser it adds very little over Java, MSCLI, LLVM, P-Code, M-Code, Python Bytecodes, TIMI, DEX and a myriad of other formats. It does add one very important thing: a large ecosystem. One where security and performance matters: the web.
- pjmlp 8y ago
  WebAssembly manipulation tooling is in its infancy compared with what is available for manipulating some of the bytecodes I mentioned on my comment. Regarding libraries, graphical debuggers and reverse code generation. Security and performance were part of Java and .NET design, hence why they have validation as part of their execution workflow. As for security on the Web, cross site scripting and WebGL exploits prove that is still room for improvement.
  - wtetzner 8y ago
    The fact that it's the only standard way to run on the web without Javascript means that every language and its dog will have a WebAssembly backend. I wonder if the real difference between WebAssembly and the other bytecodes you mentioned is just the number languages that will end up targeting it. Though, one advantage over LLVM is that it's simpler.
    - seanmcdirmid 8y ago
      Has WASM bridges the DOM problem with a nice solution yet? If not, it isn’t even a way to run on the web yet.

krapp 8y ago

>Minimal required dependencies, no built-in class library, etc. It'd be ideal if WASM runtime environment is very lightweight, preferably just 100s of kB. The smaller, the better. Especially some kind of dependency for Javascript would be disastrous. Unfortunately, what's likely to happen is that everyone just ships their WASM apps in Electron since that's already the de facto standard.

pjmlp 8y ago
> Unfortunately, what's likely to happen is that everyone just ships their WASM apps in Electron since that's already the de facto standard. Standard where? A couple of well know apps beloved by startups with high end desktop systems?
- krapp 8y ago
  It's the standard for packaging "web applications" to run natively, and the path of least resistance for doing the same with code compiled to WASM. Also VS code runs on Electron, so it's hardly uncommon.
  - pjmlp 8y ago
    That is called PWA. Electron apps are as native as PWAs, with the caveat that they bring a 300 MB runtime alongside with them. I bet there are still more Swing applications in production than VSCode users. That doesn't make JAR a de facto packing format.
    - krapp 8y ago
      The point is that existing solutions in practice, however bad they might be, will always beat better solutions which only exist in theory. Electron apps (or, fine, PWAs) will become the standard model for WASM development because that model already exists, and is what developers will most readily use... and because most of the interest in WASM comes from the web development community. By the time something better comes along, it will have to fight against the network effects.

zaarn 8y ago

There is another area where WASM could become very interesting; Operating Systems. Or more specific: Kernels. A nanokernel with the capability to run a WASM binary with a simple GC could have highly portable kernel modules and due to the properties of WASM, run userspace code in ring 0 without much risk to hardware and software. Additionally stuff like paging and memory management are much simpler to begin with as the memory access pattern of WASM is much simpler (with some dynamic relocation tricks that should be possible you could even identity map and don't do paging at all) I've also thought about doing microcontrollers as you mention, however, I was thinking about Arduino's (ATmega). They would need a much simpler and more reduced WASM since you only have about 2 KB of work memory.

kam 8y ago
There's already a WASM-centric OS in development: https://github.com/nebulet/nebulet https://github.com/nebulet/nebulet
- zaarn 8y ago
  Yup, that's part of where the idea comes from, I would favor more research in this area though.
  - pjmlp 8y ago
    I case you aren't aware of these, here are some pointers for Burroughs[1], Xerox's Mesa/Cedar[2], Pascal UCSD[3], M-Code[4] and Oberon Juice[5]. [1] - http://retro-b5500.blogspot.com/ http://retro-b5500.blogspot.com/ [2] - http://worrydream.com/refs/Teitelman%20-%20The%20Cedar%20Programming%20Environment,%20A%20Midterm%20Report%20and%20Examination.pdf http://worrydream.com/refs/Teitelman%20-%20The%20Cedar%20Pro... [3] - http://pascal.hansotten.com/category/ucsd-p-system/ http://pascal.hansotten.com/category/ucsd-p-system/ [4] - http://pascal.hansotten.com/niklaus-wirth/lilith/ http://pascal.hansotten.com/niklaus-wirth/lilith/ [5] - ftp://ftp.cis.upenn.edu/pub/cis700/public_html/papers/Franz97b.pdf

bryanlarsen 8y ago

"the external interface and requirements are kept simple." I would bet strongly against that happening long term. Everybody developing WebAssembly is interested in making the web better and pretty much only that. One of the biggest issues preventing WebAssembly usage right now is that you have to ship a large run-time along with your app. So there's going to be a lot of pressure to move that run-time into the browser. See the linked article: GC is the proposal the author highlights the strongest. The biggest pressure in your favour is the disparity of languages supported. They'll probably want to ensure that any built-in library functions they add are useful to a wide range of WebAssembly communities.

couchand 8y ago
> Everybody developing WebAssembly is interested in making the web better and pretty much only that. This is demonstrably untrue. Please peruse the design repo, I think you'll find that there are very frequently discussions of non-web applications, something folks are actually quite keen to support.
- bryanlarsen 8y ago
  Perhaps, but the real stakeholders are the browsers. Do you really think they'd hold off on GC if somebody told them that would make it problematic on embedded?
  - TomMarius 8y ago
    Embedded maybe, but it's a good feature for literally the rest of applications.
  - steveklabnik 8y ago
    The same people who work on the browsers are the same people who are in favor of this. The initial authors of wasm created the spec in this way for a reason; it's something they care about.
wahern 8y ago
The moment GC is added to WebAssembly will the the moment WedAssembly becomes no more secure than JavaScript. Either that or performance will tank. The GC is one of the most complicated parts of the browser engine, and serious bugs and exploits are regularly discovered in all of them. Safer languages like Rust won't help at all in the case of WebAssembly because it's not sharing the same type system. Further more, it's all kind of pointless. No two GCs are the same. A GC is more than simply tracing. Different languages provide different semantics with regards to finalizers, for example.[1] The semantics of the GC closely mirror design decisions of the language. If you're using the JavaScript GC then your language will be limited to the semantics of JavaScript, in which case why are you bothering with some random language? [1] Are finalizers even supported? Can they run arbitrary code? Can they resurrect the object? If they can, will they run again? Can they throw an error? What happens if they throw an error? In a language like Lua these rules are very specific because they're important to the semantics of the C API, especially wrt to bindings. For example, within a collection cycle Lua finalizers are guaranteed to be run in reverse order of construction.

jmull 8y ago

> I hope WebAssembly will not only be a web technology, but the de-facto format for cross-platform high-performance embedding. I don't think that's what's happening. They are looking to integrate webassembly more deeply with its host environment (which more-or-less assumes a browser and Javascript). I don't think this is a bad thing, BTW. You may be disappointed, but they are just looking to solve a different problem then what you are concerned with. It's an imminent, practical problem, so nothing wrong with someone addressing it, even if it isn't your problem.

kodablah 8y ago
Disagree. Watching all of the WebAssembly discussion around proposals and the spec in the GitHub issues, the leads are always mentioning non-web uses and are always being careful to separate the JS/Web ifaces/impls.
- jmull 8y ago
  I guess we'll see, but integrating with the host garbage collector is pretty suggestive, to me. Aside from that, an app/program/whatever delivered as webassembly will typically have strong dependencies on the target host environment, which means its not portable or cross-platform. It's not useless, since you still get to choose your own language for any target that supports webassembly (assuming things work). But code, whatever language its written in, is very strongly influenced by the frameworks & patterns provided/imposed by the host environment, by environmental constraints, not to mention the problem domain itself. E.g., assume there are bindings for any language you want... if you write a To-Do app for iOS using native controls, it's going to look pretty similar whatever the language. > ...and are always being careful to separate the JS/Web ifaces/impls I'll just point out that this is quite important if your goal is to cleanly extend browsers. You specifically don't want to duplicate or impinge anything the browsers already provide. I'm not trying to be a downer, but it seems like people are hoping/expecting webassembly to do more than it can or will (maybe I'm wrong, but that's the impression I'm getting). Meanwhile, we have a very solid use case for it, which is a much better compile target than Javascript for whatever language you might want to use for web development.
8y ago

kodablah 8y ago

> 4) Export / import mutable globals (and good module support in general) Already done (at least at the spec level), ref: https://github.com/WebAssembly/spec/pull/814 https://github.com/WebAssembly/spec/pull/814. I'm currently implementing it in my non-web WASM backend now :-)

jedisct1 8y ago
What is your non-web WASM backend?
- kodablah 8y ago
  https://github.com/cretz/asmble https://github.com/cretz/asmble

pocketaces 8y ago

I hope not. The subset of native (for example, x86) assembly that is equivalent to webassembly is already perfectly secure. You just limit the native assembly to pure computations without any system calls. It will also always be significantly faster than webassembly. When it comes to the security of system calls, then both webassembly and native assembly needs to make sure that whatever platform-calls that are available are secure. webassembly have no benefits over native assembly when it comes to this. Also, I doubt that it will gain as much popularity as some people predict. asm.js (the "original" webassembly) has been available for quite a long time already (and the technology behind it have existed for very very long), and if it were going to create a flood of developers targeting it instead of using javascript, then I think it would have happened by now. Inertia when it comes to development tools should not be underestimated and I doubt that all of the web developers who have invested in becoming javascript "experts" want to see the ecosystem change and see all of their "experience" and "expertise" become worthless.

fold_left 8y ago
> I doubt that all of the web developers who have invested in becoming javascript "experts" want to see the ecosystem change and see all of their "experience" and "expertise" become worthless. Can you expand on what you mean when quoting those words in this context? I can't put my finger on what point you're trying to make here.
- pocketaces 8y ago
  I am just a bit biased when it comes to my perception of most javascript developers. I should probably have left out the quotation marks. That would have made the comment more focused. However, with that being said, then the point is, that I find that there are significantly more developers who identify as being javascript experts than there are actual javascript experts, and that both groups contribute to the inertia.
  - batmansmk 8y ago
    First time I read JS and inertia side by side. I heard/read way more often complaints about its speed...

jsheard 8y ago

> 1) Threading. [...] I'm a bit sceptical whether there's a way to add this after CPU speculative attacks (Spectre, etc.) became known. The plan is to rely on site isolation, where every origin runs in a separate process. Spectre only exposes memory in the same process so this should make it benign. SharedArrayBuffer was disabled due to Spectre but Chrome plans to re-enable it soon: https://bugs.chromium.org/p/chromium/issues/detail?id=821270 https://bugs.chromium.org/p/chromium/issues/detail?id=821270

nine_k 8y ago
Of course the very point of Spectre is reading memory of unrelated processes or of an OS kernel [1]. Reading memory of the same process you're running is normal and trivial. [1]: https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)#Detailed_explanation https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...

tathougies 8y ago

Someone must have forgotten Java.

wtetzner 8y ago
> High-performance non-web "embeddability" with low memory requirements. I don't think Java fulfills this requirement. Or the one about tail calls. Java bytecode is too high-level, too. It forces you into a very limited execution framework.
DonHopkins 8y ago
Larry Ellison is an irresistible reason to forget about Java.

austincheney 8y ago

Your vision sounds like a potential vector for the widest possible distribution of malware. If you want to spin off WASM out from the browser into an independent technology then fine, but you need the same (preferably greater) security limitations that the browser already provides. Ensuring that level of constricted access uniformly and assuredly without any kind of accreditation is extremely unlikely. > Especially some kind of dependency for Javascript would be disastrous. I will not speak to outside the browser, but inside the browser this isn't changing. JavaScript remains the language of the browser and WASM is not in competition there. This isn't my personal opinion. It is the stated goal of WASM as a technology. The primary reason for that: security.