People might not like it but i really think native apps are going to die once everyone figures out how to optimize this crazy web stack.
Trying to replace native applications with runs-in-the-browser RIAs is nothing new, but we're at least finally agreeing on the language/implementation, so maybe this time will truly be different.
There is one thing that is new: the users do not need to install a separate piece of software, and it's kept up to date by the browser vendor - which means for enterprise users one less piece of software to certify/test for updates/compatibility, and for private users one software less which installed adware on each update (Java IIRC still does) and has that "risky" association like Flash does.
I think a lot of techies underestimate people's willingness to install stuff on their PCs, especially when that stuff is needed to do tasks they really want and are a couple of clicks away.
Enterprises often disabled (or heavily whitelisted) both Flash and Java in the browser due to malware concerns as they were (and still are) an effective vector for malware.
This time will truly be different because it developed out of a document viewer.
Every programmer knows html though not the frameworks. But these are seperate.
Also the two most popular browsers are multiplatform. You can write a website and make it work on whatever computer you need.
If so, I am skeptical especially with end of moore's law.
Edit: I was a bit mis-informed, the design document is an interesting read.. https://github.com/WebAssembly/design/blob/master/Rationale....
But that 50GB is probably for more then 100 hours of playtime, which amounts to a persistent 145kb/s. With some caching up front, I think this could actually work. There literally is no need to have everything on disk before starting. Maybe a few hundred megs before starting, but even that is less then a few minutes on most connections, which is a lot faster then downloading the full game before starting.
(Web workers are around since ca. 2010 so this is not very new)
More recently you have shared typed arrays that work like shared memory between threads (as of Safari 10.1 / Chrome 60, Firefox too)
What I find most painful about this development is that this new platform requires Javascript and wrapping everything inside an HTML document.
(It's the other way around, if you want to keep using Javascript, the expectation is that you'll start to depend on WebAssemby in the future.)
However, 8 years later, things really don't seem to be moving in that direction. Native is always going to be one step ahead in terms of speed and ability.
We would need to see native features start to stall so the web can catch up in ability, and websites need to do a lot of work to catch up in speed.
Back when the first iPhones debuted without an app store, Apple claimed that everyone could just use web apps. That didn't last long.
Browsers as a better software platform, will significantly accelerate the rate at which software eats everything.
Most software should ideally just work, no installs, period. The browser can act as that platform and it can go a lot further than it has so far. More to the point, there is no other future outcome than the browser becoming that vehicle, nothing can stop it from moving that direction at this point.
You don't need something equivalent to maximum native performance to do what 99% of users want to do. The rare edge cases that need extreme performance will remain native.
Browsers probably will win, but mostly by accident and as a result of network effects rather than any inherent qualities. As a platform it's positively awful, though it is getting better in fits and starts.
Ideally we'd have proper sandboxing, proper compilation, proper libraries, proper access to hardware. Alas, all of that good stuff is basically a historical footnote at this point.
With the goal of making the runtime simpler to implement for non-browser venders. While browser vendors could add a profile to run the format.
Android has tried out this app-streaming model, but seemingly about 0.04-heartedly.
I select software because it does something that I want, in a way that I want it done. I avoid web-based software when possible because it has a tendency to shift underneath me and break the way that I want the software to work....or the company decides that it needs to pivot, and I lose access to something I was depending on.
Software that installs comes closer to "just works" than software hosted online, IMO. Make it available in the repo/store/whatever, and that gets rid of a lot of install friction.
> You don't need something equivalent to maximum native performance to do what 99% of users want to do. The rare edge cases that need extreme performance will remain native.
Throughput? Probably not. But please fix the dang latency. It makes software just painful.
You don't have a GUI toolkit pre-defined if you start out with c++ (yes, it takes freedom, but gives ease of development, which seems to be today's currency).
Your UI could be HTML, but equally it could be a WebGL-based UI. Some UI libraries already use OpenGL as a backend so adding support for a WebGL backend shouldn't be too hard.
You can also stream Qt applications via WebGL (runs server side, UI streamed to the browser): https://blog.qt.io/blog/2017/07/07/qt-webgl-streaming-merged...
Some asm.js Qt examples: http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc...
Some WebAssembly Qt examples: https://github.com/msorvig/qt-webassembly-examples
Then you might as well ship a native binary. Beyond cross-compilation and window system bindings, there aren't many more portability concerns. But then you're rebuilding the browser, so the question is whether you can do it better than Google/Microsoft/Apple by including only the truly necessary bloat for your use-case. Bonus: you get to avoid browser politics.
It isn't an either\or choice. You can do both. WebAssembly gives your application a "zero install" option and native gives you better performance.
* Easy distribution without installation
* No worries about dependencies for end users
* Much more consistent, and in most cases, better security
* Cross platform
* No walled gardens
* Only Linux end users have to care much about dependencies
* You're kidding right?
* Sure, if you only target one browser your code will probably work more or less the same on that one browser on at least some of the OSs it runs on
* There aren't any walled gardens in PC Destkop land worth talking about, other than maybe the package repositories of Linux distributions.
>Now you have signups, instead of installation
How are these mutually exclusive? Plenty of desktop software requires a signup first. And plenty of webapps do not require a login.
>Only Linux end users have to care much about dependencies
It's rare to find a game that doesn't start by installing DirectX, Visual C++ Redistributable, and more.
>You're kidding right?
Modern browsers have powerful sandboxes and always-active updates to address security threats. Sounding indignant isn't actually making a point.
>Sure, if you only target one browser your code will probably work more or less the same on that one browser on at least some of the OSs it runs on
Browsers are very standardized these days. It's very rare that I write code that doesn't work cross-plat immediately.
>There aren't any walled gardens in PC Destkop land worth talking about, other than maybe the package repositories of Linux distributions.
And on mobile? Remember we're talking true cross platform here. Apple's App Store has far more limitations than you'll run into on the web.
It isn't. My point is, signups are at least as inconvenient as having to install things, and are quite prevalent on the platform. It doesn't make much sense to credit the web's success on removing the need for installs. Hell, it was still super popular even when installing Flash was basically a requirement.
> It's rare to find a game that doesn't start by installing DirectX, Visual C++ Redistributable, and more.
All of which is handled automatically for the user (and regardless is usually unnecessary and only done the way it is because of Microsoft's distribution license terms for DirectX).
>Modern browsers have powerful sandboxes and always-active updates to address security threats. Sounding indignant isn't actually making a point.
OS's have always active updates, in Windows's case whether you want them or not, and plenty of security options. Web browsers have a huge attack surface that has been exploited at least as often as OSs.
> Browsers are very standardized these days. It's very rare that I write code that doesn't work cross-plat immediately.
Impressive. I guess all those frameworks out there that are meant to abstract away all the implementation quirks between IE's various iterations, Edge, Chrome, and FF are useless then?
> And on mobile? Remember we're talking true cross platform here. Apple's App Store has far more limitations than you'll run into on the web.
Mobile web is still a goddamned garbage fire as far as I can tell. There's a reason all those popular web sites have native apps in the app store.
Some != all, it's definitely -not- the majority.
>Modern browsers have powerful sandboxes and always-active updates to address security threats. Sounding indignant isn't actually making a point.
I have a trusted bloated ball of incomprehensible code running whatever it wants with direct access to memory, video and my entire filesystem. Revoking access to the first set of things is impossible and limiting filesystem access is unlikely to be feasible or actionable for most people.
The Browser is the epitome of complication, people tout security in the browser as if it's infallible yet through complication bugs are more common and prolific. Browsers are not a magic bullet no matter how much there is a wish to "pass the buck".
All you're doing by making browsers more complicated is:
A) Giving more attack surface
B) Increasing complexity to audit.
C) Ensuring the big guys are never challenged.
Web browsers grew up with an always-on Internet connection -- continuously pushing updates to code and data. This has expanded to continuous updates "all the way down" (the native code browser auto-updating on top of an auto-updating OS).
Rebuilding core features such as these, even if by selecting unencumbered open-source libraries, basically means winding up in nearly the same place (since browsers are competing to optimize their implementations). Finding a way to connect to the browser foundation underneath whatever layer in the stack begins feeling bloated is worth evaluating, but there are diminishing returns.
Thankfully it has been largely ignored until web devs decided to start using Electron.