> Native apps talk directly to the operating system, while web apps talk to the browser, which talks to the OS. Thus there’s an extra layer web apps have to pass, and that makes them slightly slower and coarser than native apps. This problem is unsolvable.
But what if the browser is the OS?
I agree with the point though that we shouldn't be trying to emulate native to the T with web applications, that we shouldn't be stuffing them full of JavaScript. I think the Google IO 2015 web app [1] is a good example of what can be done on the web right now with minimal overhead.
This is clearly just my laptop (or maybe firefox) but that google site took about 30 seconds to load up. Every time I click on the tab that has it open - my computer fan whirs up to near full speed and it locks up firefox's graphic rendering until it finishes the page. Once loaded there is an unusable level of lag on the browser and CPU usage is levelling at 55 odd percent.
Then the user has chosen, for whatever good reasons, to run a pretty limited OS, and in doing so has chosen not to be able to take advantage of all the things that having a much less limited OS would offer.
This is only true right now and only if browsers were not working to make more low level stuff available. There is very little limiting about being in a browser these days. Drivers, perhaps. Kernel stuff, perhaps.
But as far as a game is concerned? Or an email application? Or anything in the context of this discussion? Not too much limiting them.
It will always be true forever, or at least for as long as a web browser is a program run within an actual operating system.
It's not a competition. Pick the right tools for the job. If the job is getting your eMail or playing a relatively simple game, and a web browser abstracting as an OS can support your needs, knock yourself out.
If the job is something a bit bigger than that, use a more powerful OS.
Take a look at what's currently available in desktop web browsers: maps, document and spreadsheet editing, highly interactive charts, video conferencing etc. (things previously thought impossible/impractical for a web browser to do) If you need huge amounts of data to even run your application, the argument to go native makes some sense, but the browser (even on mobile) isn't as inherently limited as the article describes.
Lets not try to limit the web, but try to make it better and then let the users decide which they would prefer to use.
I'm not limiting the web. You're not limiting the web. The web has limits. Actual, hard physical limitations (along with confidentiality and privacy limits); limits that something running entirely locally, directly with your actual operating system simply suffers, and will always suffer, to a much, much, much lower degree. Your opinion (and my opinion) is meaningless when confronted with actual, physical reality.
Besides having to transfer data to run the application in the browser, what limitations are inherit in a web-based application? (I acknowledged the data transfer limitation in my previous comment).
Browsers (especially mobile browsers) are unnecessarily limiting what can be done on the web. Adding additional permissions could enable browsers access to more system resources and components, especially on mobile.
Could you provide some examples of applications that don't require a lot of data that couldn't be run in a web-based environment, because of physical (and not current browser or software) limitations?
Doesn't even necessarily have to transfer data with web workers, service workers, caching, etc.
Google IO 2015, I believe, stores it's data so that when you load it up it loads from a cache that it's service worker will reload once you have it open. Allowing it to work offline and removing the cost of transfer at the beginning.
But what if the browser is the OS?
I agree with the point though that we shouldn't be trying to emulate native to the T with web applications, that we shouldn't be stuffing them full of JavaScript. I think the Google IO 2015 web app [1] is a good example of what can be done on the web right now with minimal overhead.
1: https://events.google.com/io2015/