Earlier quoted context omitted.
Exactly. WASM stories always bring up wild fantasies of platform world domination, when in reality there aren't APIs for even the most basic things, let alone practical apps. In a heretical way, I've got to ask why not just use JVM byte codes, an incomparably more established platform at this point with several mature VMs and sophisticated API ecosystem, albeit not necessarily in the graphics space? Why did we want t…
Java doesn't provide a sufficient security model for running arbitrary C/C++-like code, which is the entire purpose of WebAssembly. Drop that and all the new use cases will just go back to asm.js instead.
Bringing the web up to speed with WebAssembly
151–160 of 172 posts
Re: Bringing the web up to speed with WebAssembly
#152I was a bit skeptical of WebAssembly when it started popping up, but reading through this and the MDN docs has made me get a bit more excited. In a few years WebAssembly might make for a great environment to learn about lower level programming. I've always loved assembly, since it gives you the bare minimum of concepts and tooling from which you can build everything. What's the reasonable thing to do when a grow-memo…
Once you mentioned "bare minimum of concepts and tooling from which you can build everything" I immediately thought of js module-for-everything situation. We might be getting even more of them written in webassembly.
Re: Bringing the web up to speed with WebAssembly
#153WASM has the potential to change the world... a thought: while WASM will initially appear in compute-intense functions in web apps, it has the potential to be a true "Common Language Runtime". It may become the future platform that native, dekstop apps run on. This could be a good thing, if done correctly: 1. Desktop apps have a common, safe runtime upon which they run, and the packages can be easily distributed (and…
I am also very interested in learning more about using WebAssembly as a primary deployment target for desktop applications. Recently when I was working on a cross-platform C++ application using Qt and boost, a major pain point was in understanding the different packaging conventions of the operating systems. If WebAssembly takes off, and is available on Windows, macOS, and Linux, would it be possible for me to build…
No, because at the least all three have different executable formats (PE, Mach-O and ELF respectively). I suppose it might end up being possible to ship some sort of HTML + WASM bundle that they all know how to interpret if it became common enough.
Re: Bringing the web up to speed with WebAssembly
#154We spent a long time wishing for a VM for the web that could be targetted by any language and being told that wasn't possible. WebAssembly will finally deliver that and it seems to be done by the same people/organizations. What changed?
It's called the CLR. (Common language runtime, which is what C# runs on.) The problem is that the CLR forces you into a "one-size-fits-all" garbage collector. It's good for what it does, but if your application needs are different, than the CLR just won't work.
There are plenty of VMs out there, the JVM and CLR being the biggest two. Up to now though none were usable on the web.
Re: Bringing the web up to speed with WebAssembly
#155WebAssembly is really going to bring some awesome fast processing for binary heavy tasks, like video and gaming, to the web. Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic. Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform…
>Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't.
It already is. Lua has already been ported to WebAssembly, people are writing apps in C/C++ with SDL, I've seen MVPs of .Net, and once WASM gets native garbage collection, the floodgates are going to open. The sandbox only makes it more attractive.
Re: Bringing the web up to speed with WebAssembly
#156WASM has the potential to change the world... a thought: while WASM will initially appear in compute-intense functions in web apps, it has the potential to be a true "Common Language Runtime". It may become the future platform that native, dekstop apps run on. This could be a good thing, if done correctly: 1. Desktop apps have a common, safe runtime upon which they run, and the packages can be easily distributed (and…
> "Web apps" could potentially go away I prefer to think of it instead as native apps going away. Or rather, the web becoming indistinguishable from native. If native apps start being run on WASM, and web apps start being run on WASM, and the web continues to gain access to more and more "native" APIs... it may not be long before there's basically no difference between a native app and a web app, from the end-user _o…
I feel like this won't really take off until we have something other than a web browser, or something that just feels different from a web browser, which is optimized for WASM applications, and which includes package management. Caching a WASM application locally is not much different than downloading a standalone native binary.
Re: Bringing the web up to speed with WebAssembly
#157Earlier quoted context omitted.
HTML isn't great for application code. That's the issue, and anyone targeting WASM and canvas would be looking to recreate desktop apps on the web, not traditional websites.
Yes, it's bad for applications. But that does not explain why people send their text based pages as javascript.
> But that does not explain why people send their text based pages as javascript.
Probably because they're using front-end javascript frameworks which do that, and because they were taught that this is the best and most efficient way to render anything on the web. No one wants to make a special case for text because it seems inelegant.
Re: Bringing the web up to speed with WebAssembly
#158Earlier quoted context omitted.
> "Web apps" could potentially go away I prefer to think of it instead as native apps going away. Or rather, the web becoming indistinguishable from native. If native apps start being run on WASM, and web apps start being run on WASM, and the web continues to gain access to more and more "native" APIs... it may not be long before there's basically no difference between a native app and a web app, from the end-user _o…
I feel like this won't really take off until we have something other than a web browser, or something that just feels different from a web browser, which is optimized for WASM applications, and which includes package management. Caching a WASM application locally is not much different than downloading a standalone native binary.
Yes! Get rid of the chrome, navigation buttons, etc. and give us a pseudo-VM that runs the browser as we know it as an “app”. I hope WASM and the like might eventually lead us there.
Re: Bringing the web up to speed with WebAssembly
#159Earlier quoted context omitted.
Maybe. OpenGL has a lot of history and baggage. I'm pretty sure the current browser engines don't use OpenGL for 2d graphics. I think they still use Skia (Chrome) and Cairo (WebKit). It could be as "easy" as allowing calls to be made directly to those graphics libraries in WebAssembly.
In any case, it should be hierarchical. It should be simple and efficient to move an object and all its children around.
SVG perhaps?
Re: Bringing the web up to speed with WebAssembly
#160Earlier quoted context omitted.
I feel like this won't really take off until we have something other than a web browser, or something that just feels different from a web browser, which is optimized for WASM applications, and which includes package management. Caching a WASM application locally is not much different than downloading a standalone native binary.
Yes! Get rid of the chrome, navigation buttons, etc. and give us a pseudo-VM that runs the browser as we know it as an “app”. I hope WASM and the like might eventually lead us there.
It makes sense if the web is going to be divided up between "documents" and "applications" (which it is, whether anyone likes it or not) not to run the applications in an environment designed to display documents.
Bonus points if the default is to download, cache and update the source code and "installation" is just local compilation to an appdata folder or something, similar to what browsers do with HTML, CSS and JS, rather than just download a blob of bytecode. That would make the FOSS people happy.