At the risk of getting a bunch of down-votes: Am I the only one who is afraid we are just going to turn the browser into a delivery mechanism for a bunch of fat-apps?
Remember the old websites that displayed all their content entirely within a Flash application? You couldn't email links, bookmark pages, parse page content with automated tools, etc. That's what I'm worried about.
Somebody is going to come up with a CMS that "compiles" websites to monstrosity WASM applications. Hopefully the types of websites I interact with won't be the kinds for whom such a horrible idea has appeal.
There are, and will always be, websites that are ugly, fat, obtrusive and whatnot. Thing is: you don't have to visit them.
WebAssembly has the potential to say play video games, including AAA titles, without having to install anything on your computer. Same goes for many software projects such as CAD, office, video editing... You could use all this from your browser.
I don't know about you, but I find this perspective very exciting.
> WebAssembly has the potential to say play video games, including AAA titles, without having to install anything on your computer.
It depends on how you define "being installed". All files living on FileAPI and IndexedDB does not make too much difference than using direct file access and SQLite. They will be cached and they will live on your computer. Well, at least until your browser faces storage pressure and decides to randomly delete website data.
I mean, yeah, everything lives in a sandbox and there's potentially less security issues. Not having to give admin privileges to an application which allows you to build houses out of blocks is a good idea. On the other hand, the capabilities of the platform is increasing like crazy and it's just a matter of time before it converges with the operating system itself.
So, I don't know. The whole situation is weird. I think we needed better operating systems with granular permissions and we're getting there using a very convoluted way.
Some fat apps have a bootstrap that caches the core application in localstorage or some other facility. It may not be a solved problem for gigabyte sized apps.. but it is in concept a problem with a solution.
If that were the case, obviously it wouldn't work without some infrastructure changes.
But imagine an app where each function (like, say, the levels filter) was downloaded as needed and cached. That might be possible sooner rather than later.
I'm sure there are plenty of reasons why that's a non-starter. But I don't think that it's impossible to have an application of whatever complexity running in a browser... I mean, I remember when doom came out and I had a hard time running it on my machine without tweaking the configuration. And now...
Js and WebAssembly are both quite compact, I don't think many apps will be more than 10-100 MB. Of course they may contain extra data such as images for the ui or translations in text files but those can be downloaded on the side and cached.
the thing is, these apps are already multi-GB when compiled for x86/x64 platforms.
and please, please whoever is doing it - the performance will be crap compared to instant desktop. you can't get around it. it doesn't matter how powerful PC or how fast internet connection will be. I see it on gmail with my 100 mbs connection all the time, PC being quite performant one. when it was 800 mbs nothing changed.
I can accept it in gmail/facebook/whateva where expectations are low, but for anybody doing serious work in these tools, it will be frustrating, annoying experience for foreseeable future. As an complement to desktop app (say on the roads), why not. But nothing more
WASM is designed to implement stuff that are computationally expensive. The typical junk you want to remove is not. If somehow WASM is used to protect this junk from you filtering it, this is probably done deliberately. WebDesigners can always find ways to bother you, but you can always punish them by not visiting their website anymore.
If I am the only one punishing them out of millions of views it won't have any effect. I haven't bought an IPhone but it hasn't forced Apple to make a device I want to buy.
At a guess there could be an initial download of the base app with the most common functions that's ~50-100MB that you can cache and then functions/plugins can be streamed in as a when you use them.
It's too soon to worry about. Currently you still need to keep your UI in JavaScript / HTML / CSS so Web Assembly isn't going to be replacing that to deliver "fat apps" just yet.
Regardless, when there does come a time that WASM has full DOM access you'll just be replacing a ton of JavaScript and other code with WASM bytecode. Today you can already transpile many languages to JavaScript and some frameworks even allow you to never even touch JavaScript and still create web applications. I don't see this being much different with the exception that you'll no longer be required to used or transpile to JavaScript and this could end up faster (that's a big COULD and will probably depending on what you're doing and how).
Now THIS is what I'm interested in. The HTML / CSS / JS triple threat has existed for, what, two decades at this point? So many other techniques have emerged for rendering GUIs and I would really love to see more exploration into this, even if it circled back to HTML / CSS / JS being the better bet I'd still highly value the experimentation.
With automatic updates delivered when the vendor wants to, not when you do. And partial downloading of applications as you hit new features. And we'll need to keep track of disk use for the things...yay, browser package manager!
You mean excited? With WASM-native APIs for the DOM and WebGL we can basically run full desktop apps without Javascript hacks in the browser. That's amazing.
I could even imagine something like a browser but with no HTML or DOM. With just WebGL and maybe a few other APIs you could have a really awesome app platform.
>Am I the only one who is afraid we are just going to turn the browser into a delivery mechanism for a bunch of fat-apps
If by "just" you mean "exclusively," then no.
I would be willing to bet that the vast majority of content on the web even today isn't "webapps" but basic HTML, maybe with some JQuery or Google analytics somewhere, but more or less still just documents. Webassembly augments what can be done in the browser, but it still serves a niche set of use-cases when the whole web is considered.
Until the day comes when you can't publish anything to the web without a compiler toolchain then I wouldn't worry.
Isn't that already happening? Plenty of news sites are already fat apps, when you think about how much code they load to only deliver static content and maybe support comments, very little of the code being useful to end users.
I see where you're coming from. I have, however, tested a couple of news sites (e.g. BBC, The Guardian) while using an add blocker and the results are very interesting. The "amount of news" is nowhere near the "amount of adds". Without the adds, the news websites (some; I obviously couldn't test them all...) have a decent "size" and load quick enough.
I'm concerned about the "fat" (especially when using high-level languages with a big runtime), but I'm quite enthusiastic about the integrated distribution- and runtime-platform the web is turning into, especially when the alternatives are closed walled-garden platforms.
In addition to this more "official" work on getting .NET and WebAssembly to play nicely, there is another effort to get a small .NET runtime working in the browser [1]. The demos are compelling [2].
Great to see Mono increasing reach. I bet that Xamarin team with MS backing will slowly make it the default tool for decent cross-platform development. C# is amazing, AoT performance rocks, there are bindings to all the native UIs.
It's also mature enough nowadays, so I'm going to use Mono for future projects.
