Web vs. native: let’s concede defeat(quirksmode.org)
quirksmode.org
Web vs. native: let’s concede defeat
http://www.quirksmode.org/blog/archives/2015/05/web_vs_native_l.html
505 コメント
I feel we’ve gone too far in emulating native apps. Conceding defeat will force us to rethink the web’s purpose and unique strengths — and that’s long overdue.
This, a million times. Mobile websites and mobile apps have completely different strengths. The current trend is to develop them both with the same HTML-based toolchains and make them as similar as possible, which ends up being to the detriment of both.
Users don't want mobile apps that are simply a website packaged up behind the "icon on the homescreen". Those apps lack the essential benefits of native: fast and seamless access, smart use of local data, integration with device services like notifications...
There's nothing more annoying to a mobile user than an "app" that takes 10 seconds to start up because it first loads a browser engine, then makes a hundred HTTP requests to fill up that embedded browser with content. (And if the 3G network happens to be clogged, the app may end up showing nothing after 20 seconds.)
For developers, Cordova/PhoneGap-style tools are not a panacea either. It's easy to get an 80% solution done, but then you run into problems with mobile browser performance, browser differences between devices (even Android devices with the same base OS can have very different web view browser engines), etc. With all that, the last 20% of a Cordova app may well take 80% of development time, and that's rarely been budgeted in.
Shameless plug: my startup Neonto makes a UI design tool that creates usable iOS and Android code from visual layouts. It's a great way to remove the friction in creating real native apps: http://neonto.com
This, a million times. Mobile websites and mobile apps have completely different strengths. The current trend is to develop them both with the same HTML-based toolchains and make them as similar as possible, which ends up being to the detriment of both.
Users don't want mobile apps that are simply a website packaged up behind the "icon on the homescreen". Those apps lack the essential benefits of native: fast and seamless access, smart use of local data, integration with device services like notifications...
There's nothing more annoying to a mobile user than an "app" that takes 10 seconds to start up because it first loads a browser engine, then makes a hundred HTTP requests to fill up that embedded browser with content. (And if the 3G network happens to be clogged, the app may end up showing nothing after 20 seconds.)
For developers, Cordova/PhoneGap-style tools are not a panacea either. It's easy to get an 80% solution done, but then you run into problems with mobile browser performance, browser differences between devices (even Android devices with the same base OS can have very different web view browser engines), etc. With all that, the last 20% of a Cordova app may well take 80% of development time, and that's rarely been budgeted in.
Shameless plug: my startup Neonto makes a UI design tool that creates usable iOS and Android code from visual layouts. It's a great way to remove the friction in creating real native apps: http://neonto.com
I get where he's coming from, but I don't think it gets to the root issue:
Why does everything need to be a "rich experience"? Note I didn't say app-like, because many apps themselves are straightforward.
If we don't make that distinction then we risk throwing out the baby with the bathwater. He cites having to build "2 native apps" instead of one website, but that's only true if you ignore everyone who is not on recent versions of Android or iOS (certainly you're not going to support iOS < 5, right?).
The web is no-install, ubiquitous and accessible in a way no platform has ever been and which is impossible for any proprietary platform ever to be, and is backwards-compatible. Given these strengths, the effort to bring app-like functionality to the web is well-founded, because difficult though it may be, the converse of bringing the web's benefits to native apps is just plain impossible.
If when marketing wants to create these experiences we tell them to go native we're just shoveling the problem off to the poor native developers. The first step should be determining the value of said "experience", is it there to serve the user or is it there win awards?
Why does everything need to be a "rich experience"? Note I didn't say app-like, because many apps themselves are straightforward.
If we don't make that distinction then we risk throwing out the baby with the bathwater. He cites having to build "2 native apps" instead of one website, but that's only true if you ignore everyone who is not on recent versions of Android or iOS (certainly you're not going to support iOS < 5, right?).
The web is no-install, ubiquitous and accessible in a way no platform has ever been and which is impossible for any proprietary platform ever to be, and is backwards-compatible. Given these strengths, the effort to bring app-like functionality to the web is well-founded, because difficult though it may be, the converse of bringing the web's benefits to native apps is just plain impossible.
If when marketing wants to create these experiences we tell them to go native we're just shoveling the problem off to the poor native developers. The first step should be determining the value of said "experience", is it there to serve the user or is it there win awards?
This is probably going to be an unpopular opinion but I think the current push to make native feelings apps in JS is awesome. Playing with an app like Untappd and then realizing it's written by (at least originally) 2 people and still feels fluid is incredible. I've also never heard anyone except developers complain that it's not app-y enough. True things like games shouldn't be written in phonegap or react-native but I think to say that we should completely stop trying to build any native-feeling apps is wrong. I actively push anyone interested in turning their app idea into a working prototype use Meteor or React-Native or just straight up phonegap and if they get traction they can do what facebook did and rewrite.
I know this flies in the face of this article but I just don't think we should stop trying.
I know this flies in the face of this article but I just don't think we should stop trying.
The web already won.
When was the last time someone told you about an app idea and you had any vision of a Win32 (or WPF) app? The web is the defacto app platform for desktop today. Sure, there are some legacy and niche apps that are native on desktop, but mostly everything new is web based on desktop.
Mobile is a different story, but I think its due mostly to the fact that mobile HW is still changing rapidly. New sensors and other capabilities to tap into, where a standards web has to catch up. But I think this gap too will go away as mobile HW matures.
When was the last time someone told you about an app idea and you had any vision of a Win32 (or WPF) app? The web is the defacto app platform for desktop today. Sure, there are some legacy and niche apps that are native on desktop, but mostly everything new is web based on desktop.
Mobile is a different story, but I think its due mostly to the fact that mobile HW is still changing rapidly. New sensors and other capabilities to tap into, where a standards web has to catch up. But I think this gap too will go away as mobile HW matures.
Four points:
a) Tooling: yes, it's still much easier to debug a native app than a pseudo-native app.
b) "Emulating native leads to bad UX": this section is absolutely right. Stop hijacking scrolling and building in cruft.
c) "Hassle-free web": absolutely right. You don't need an app for that. Just give us the information and let us have the basic interaction we want. No, you shouldn't present your menu as a PDF either.
d) News: this is where I disagree. Users don't go to news sites so much; they go to aggregators which link them to individual articles (reddit, facebook). It's hard to deep-link into an app. This is a case of the app existing to further the commercial needs of the content provider (increase lockin, ads and tracking) in direct opposition to the wants of the user.
People keep trying to make the "magazine app" happen, and I've seen very little evidence of it working.
a) Tooling: yes, it's still much easier to debug a native app than a pseudo-native app.
b) "Emulating native leads to bad UX": this section is absolutely right. Stop hijacking scrolling and building in cruft.
c) "Hassle-free web": absolutely right. You don't need an app for that. Just give us the information and let us have the basic interaction we want. No, you shouldn't present your menu as a PDF either.
d) News: this is where I disagree. Users don't go to news sites so much; they go to aggregators which link them to individual articles (reddit, facebook). It's hard to deep-link into an app. This is a case of the app existing to further the commercial needs of the content provider (increase lockin, ads and tracking) in direct opposition to the wants of the user.
People keep trying to make the "magazine app" happen, and I've seen very little evidence of it working.
The headline is a little misleading: the article isn't about not using web technologies in favour of native apps - Instagram, for example, uses HTML5 for most of it's UI (you used to be able to see the error pages) and has great UX - but rather a call to stop making 'native app like web sites'.
> Our working assumption has been that all web sites should be app-like, and therefore tooled up to the hilt.
I don't think that's true. Some people create horrible scroll jacking functionality for whatever reason - maybe they thought it was more 'native app like', maybe they just thought it was clever. But many other web developers already consider that bad perf is bad perf and aren't willing to put up with it.
> Our working assumption has been that all web sites should be app-like, and therefore tooled up to the hilt.
I don't think that's true. Some people create horrible scroll jacking functionality for whatever reason - maybe they thought it was more 'native app like', maybe they just thought it was clever. But many other web developers already consider that bad perf is bad perf and aren't willing to put up with it.
So the customer/users want a native app!? Fine, I'll just bundle the web app with Webkit (io.js) and they'll be happy, and I don't have to worry about the app breaking in new browser versions.
Browser based applications are much easier to distribute and adds a security layer, so that you do not have to worry as much about trojan/viruses, compared to installing executables from cr4cksnh4cks.com
The browser is the perfect container. And it also helps a bit that the API's are super easy to work with. Making even the novice programmer productive and able to create powerful applications.
One reason why native is bigger on the smart-phone market is that Google, Apple and Microsoft want to completely control their ecosystem and lock people in. What I can not understand though, is why Google does it, as the majority of their income still comes from the word wide web. They have however made major advances on that front lately, to there is still hope.
As the virtualization technology advances, the gap between running on bare metal and in a container continuously decreases. So there will be little incentive running native/bare metal in the future.
We have a long way to go though. If you want to build something that make full use of the hardware, you still should go native. But I hope that changes in the future.
Browser based applications are much easier to distribute and adds a security layer, so that you do not have to worry as much about trojan/viruses, compared to installing executables from cr4cksnh4cks.com
The browser is the perfect container. And it also helps a bit that the API's are super easy to work with. Making even the novice programmer productive and able to create powerful applications.
One reason why native is bigger on the smart-phone market is that Google, Apple and Microsoft want to completely control their ecosystem and lock people in. What I can not understand though, is why Google does it, as the majority of their income still comes from the word wide web. They have however made major advances on that front lately, to there is still hope.
As the virtualization technology advances, the gap between running on bare metal and in a container continuously decreases. So there will be little incentive running native/bare metal in the future.
We have a long way to go though. If you want to build something that make full use of the hardware, you still should go native. But I hope that changes in the future.
Unless you're making something that needs really good performance (3D gaming for example) building a hybrid app wins every time. Something based on Cordova (eg PhoneGap, Ionic) with Crosswalk can get you to about 90% of the performance of a native app, with about 1/2 of the development time because it's all built with web technology. 90% is easily good enough for most applications. Cordova wraps a uiWebView in some boilerplate to make a web app effectively native to give you the 'icon on the homescreen' advantages (selling the app, in-app purchases, access to most phone APIs) with all the benefits of building for the web (easy development, lots of developers, etc).
It does not matter what platform you choose (web or mobile), bad developers develop bad software. For every horribly designed, slow, bloated website you find, you can likely find a similar horribly designed, slow, bloated native app. I'm sure you've heard of garbage in garbage out. I view development as a craft and like most crafts, not everyone has the same level of skill. This does not reflect on the platform people choose. It reflects on the people themselves, their time investment, work ethic, priorities, approach, methodologies, etc. Like with most crafts, there is usually more than one way to accomplish something; some more eloquent than others. At a very basic level, both web and native apps share many commonalities; some sort of UI being rendered and interactions with data via API calls. As long as you can reach your goal, does it really matter how you got there? How about this; the debate is ridiculous. They both rock (or suck depending on your perspective).
If we "concede defeat" of the mobile web, then we wind up with only content and functionality that has been approved and can be killed on a whim by Apple and Google. Wars have been fought over freedom of expression, and now we have voluntarily given two companies and the governments they answer to the power to crush anything they don't like, based upon cryptic and arbitrary guidelines. That is a truly scary world.
Like many things, native is perfect in theory but in practice comes with massive drawbacks. A happy medium may indeed exist, but "conceding defeat" of the mobile web isn't going to get us any closer to it.
Like many things, native is perfect in theory but in practice comes with massive drawbacks. A happy medium may indeed exist, but "conceding defeat" of the mobile web isn't going to get us any closer to it.
> 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.
1: https://events.google.com/io2015/
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/
The author is correct that modern web applications are hacks all the way down. It's crazy sometimes. But it fucking works!
Look at Google Docs, which has changed the way teams collaborate. Look at Unity which recently ported their player to the browser. Look at the Autodesk 123D suite.
With technologies like WebGL and Emscripten, we're just starting to see the tip of the "native on web" iceberg. And it's awesome. I know because I'm helping build the iceberg... :)
Look at Google Docs, which has changed the way teams collaborate. Look at Unity which recently ported their player to the browser. Look at the Autodesk 123D suite.
With technologies like WebGL and Emscripten, we're just starting to see the tip of the "native on web" iceberg. And it's awesome. I know because I'm helping build the iceberg... :)
Perhaps what we really should be thinking is that 90% of applications can, in theory, be made using either web standards, native or a mix of both.
Unfortunately lots of websites and web apps are not very well developed. They serve bloated HTML that hasn't been minified, let alone compressed. The page is unresponsive or blank until a dozen JavaScript files have been loaded. Hardly anything is cached. jQuery is loaded to do select a single element and animate it when CSS would have done.
Most well written, architectured and developed web[site|app]s will not be too different in UX for end users than a native app. Sure, you can't write a great 60 fps first person shooter game for the web, but there's nothing saying you shouldn't be able to create an RSS reader or photo sharing app or social network or anything else with either the web or native.
Unfortunately lots of websites and web apps are not very well developed. They serve bloated HTML that hasn't been minified, let alone compressed. The page is unresponsive or blank until a dozen JavaScript files have been loaded. Hardly anything is cached. jQuery is loaded to do select a single element and animate it when CSS would have done.
Most well written, architectured and developed web[site|app]s will not be too different in UX for end users than a native app. Sure, you can't write a great 60 fps first person shooter game for the web, but there's nothing saying you shouldn't be able to create an RSS reader or photo sharing app or social network or anything else with either the web or native.
Telling mobile devs not to use web tech is an example of where this argument (request? demand?) falls down. There are a lot of advantages to using web tech (cross-platform, easier to develop, easier to push updates), and the result is not necessarily worse; it may be better. CSS is a very expressive and powerful layout language, for all its rough edges. Apple uses WebViews in their own apps (like the mobile App Store app).
The rough edges of web tech will only get smoother over time.
The rough edges of web tech will only get smoother over time.
If native won, then why didn't "native" desktop software win? Everything on desktop has moved to SAAS and on the web.
We're being way too short-sighted here. In 5-10 years, I don't think smartphones will be the primary way we get information anymore. Yes, we will have mobile, but it might be mobile VR, with an infinite canvas.
I think the reason native works well on mobile today is simply because there isn't much room to work with. Once the viewports start getting larger again, the web will take over.
We're being way too short-sighted here. In 5-10 years, I don't think smartphones will be the primary way we get information anymore. Yes, we will have mobile, but it might be mobile VR, with an infinite canvas.
I think the reason native works well on mobile today is simply because there isn't much room to work with. Once the viewports start getting larger again, the web will take over.
Web APIs are in essence becoming an abstraction layer between OS and applications. It's not just about browser anymore. Browser is just one of the host for these APIs. In next decade or so, we should have all the power built in to standards that eliminates pretty much any advantage that native application can possibly have - even for heavy duty 3D gaming and offline video editing scenarios. Web APIs will and should become the standard way of developing apps across platforms. There is neither a theoretical reason that this is impossible or any other viable alternative agreeable among OS providers.
There is nothing to concede or regret about. It's just how things evolve. Get over it.
There is nothing to concede or regret about. It's just how things evolve. Get over it.
The article, when talking about the simple 'Technical' reason why web can't beat the 'native' falls flat. When most people talk about 'Web', they just mean 'Browser' - and a browser is native. The extra layer, yes, the rendering engine/JS framework - how are they very different from JVM and XAML in theory? Both add an extra layer. Are Android apps not native according to the author because it adds a layer too?
I'm a web developer with a side project. I don't have the time/energy/knowledge/bandwidth to implement native apps for IOS and android. But I CAN make it work well enough in a mobile browser.
And lets not forget: developing for android is hard. You have a variety of models, with varying versions of android, running on different carriers; i've read some horror stories, and no thanks.
I'm quite quite happy developing for the web and keeping it on the web. I don't have to answer to any gate keeper or ask for permission for a new release. I don't have to share 30% of my profits, or be careful about implementing native functionality.
They just need a browser that can render HTML/JS/CSS. That browser will only get more optimized over the years, the network will only get faster, and the technologies to optimize the web for mobile will only increase.
I say more web, not less.
And lets not forget: developing for android is hard. You have a variety of models, with varying versions of android, running on different carriers; i've read some horror stories, and no thanks.
I'm quite quite happy developing for the web and keeping it on the web. I don't have to answer to any gate keeper or ask for permission for a new release. I don't have to share 30% of my profits, or be careful about implementing native functionality.
They just need a browser that can render HTML/JS/CSS. That browser will only get more optimized over the years, the network will only get faster, and the technologies to optimize the web for mobile will only increase.
I say more web, not less.
I agree that if you have the resources to build something on native, go right ahead. But as someone who has very limited time to work on a passion project (https://turtl.it), I will be damned if I split up my efforts writing different apps for iOS, Android, and desktop. Thanks to things like Cordova, node-webkit, and various other tools, I can write my interface/logic once and run it everywhere (with a bit of wrapping).
No, it will not be perfect. Yes a native app would perform better. But I don't think my users (who continually ask me for a mobile app) are really going to care that much if the page transitions jump a tiny bit. And once Safari pulls its head out of its ass and supports AES-GCM in its WebCrypto implementation, I can do fully-native crypto in my app, and the largest performance hit goes away.
HTML5 is the poor person's write once, run everywhere. Although not perfect, it continually strives to be better. It enables someone like me, who can only work nights and weekends, to build something useful and usable for a lot of people in a minimal amount of time. If people don't like Turtl mobile because it doesn't have seamless transitions, they can use Evernote instead and have their plaintext data leaked all over the web.
No, it will not be perfect. Yes a native app would perform better. But I don't think my users (who continually ask me for a mobile app) are really going to care that much if the page transitions jump a tiny bit. And once Safari pulls its head out of its ass and supports AES-GCM in its WebCrypto implementation, I can do fully-native crypto in my app, and the largest performance hit goes away.
HTML5 is the poor person's write once, run everywhere. Although not perfect, it continually strives to be better. It enables someone like me, who can only work nights and weekends, to build something useful and usable for a lot of people in a minimal amount of time. If people don't like Turtl mobile because it doesn't have seamless transitions, they can use Evernote instead and have their plaintext data leaked all over the web.
This article feels dated. If he wrote it in 2011, I would agree with him.
Web apps don't try to recreate the native UI anymore - something that used to be the case some years ago in the iOS1-6 era. Nowadays the UI of Android 5+, iOS 7+ and WinPhone7+ look very simple and Web-alike.
Simply avoid bloated outdated big JS libraries and use a minifier to shrink the JS and CSS files.
I thought the trend reversed as many little commerce switched from offering a Android/iOS app to a mobile-friendly website. This may not be a global trend.
quirksmode.org used to be great resource in the IE6 era. Nowadays http://caniuse.com and Mozilla's MDN have replaced it completely for me as it offers up-to-date information.
Web apps don't try to recreate the native UI anymore - something that used to be the case some years ago in the iOS1-6 era. Nowadays the UI of Android 5+, iOS 7+ and WinPhone7+ look very simple and Web-alike.
Simply avoid bloated outdated big JS libraries and use a minifier to shrink the JS and CSS files.
I thought the trend reversed as many little commerce switched from offering a Android/iOS app to a mobile-friendly website. This may not be a global trend.
quirksmode.org used to be great resource in the IE6 era. Nowadays http://caniuse.com and Mozilla's MDN have replaced it completely for me as it offers up-to-date information.
One point I've not seen mentioned yet is that the web is a fantastic distribution platform. Given the option, I'd much prefer to have written my molecule rendering project[1] on a native platform, but I'd get only a fraction of the users I get when deploying to the web. The activation barrier for native apps is just so much higher because of the download/install/launch process.
For now, the URL click is king, and it's hard to beat easy when you want people to use what you've made.
[1] http://wwwtyro.github.io/speck/
For now, the URL click is king, and it's hard to beat easy when you want people to use what you've made.
[1] http://wwwtyro.github.io/speck/
I really don't know anyone who carries on these kinds of arguments. In my experience, we code for the web most of the time, because it works and is usable by most people on most devices. Once in a while, we have a compelling reason not to. When that reason comes along, we code a native app.
It isn't a competition between platforms, and we aren't trying to make them look and act the same. We just pick the platform that offers the simplest workable solution.
Maybe I just run in a more pragmatic crowd...
It isn't a competition between platforms, and we aren't trying to make them look and act the same. We just pick the platform that offers the simplest workable solution.
Maybe I just run in a more pragmatic crowd...
I think that a title of 'Browser vs. Native' instead of 'Web vs. Native' might be more accurate, since the web is so much more than just a UI... most 'apps' I think are just web apps with a 'native' GUI, not disconnected applications in and of themselves.
PPK ignores the original reason that the browser won so long ago though... it is the universal GUI for the Internet. We've had access to 'native' extensions for web apps for a long time (Java applets, Flash, Silverlight, ActiveX, etc, etc), yet these things are all but dead. Eventually the Apple vs. Android war will probably go nuclear, and users will demand that things 'just work' too. If its time to revisit this conversation, then fine... but there is nothing new under the sun.
PPK ignores the original reason that the browser won so long ago though... it is the universal GUI for the Internet. We've had access to 'native' extensions for web apps for a long time (Java applets, Flash, Silverlight, ActiveX, etc, etc), yet these things are all but dead. Eventually the Apple vs. Android war will probably go nuclear, and users will demand that things 'just work' too. If its time to revisit this conversation, then fine... but there is nothing new under the sun.
This post leads me to believe the author probably assumes there will always only be a handful of native platforms. I think, if we're lucky, the ecosystem will be far more diverse.
In the future I envision, noone in their right mind would ever think native is the way to go.
In the future I envision, noone in their right mind would ever think native is the way to go.
> Is it the web’s purpose to emulate native by inserting yet more features?
Certainly not. In my opinion, the problem with the web is that it has become too complicated. In an effort to make the web simpler for the ordinary user, the web has actually become a more complicated place for the (advanced) developer.
HTML, CSS and javascript have grown so complicated that they lack certain desirable properties, such as verifiable security, flexibility. For instance, a developer has no choice of programming language, but has to resort to javascript; we are stuck with the cooperative multitasking of the 80s (webworkers support only message-passing, no shared state); also, the developer has no choice of render engine, and to make matters worse, the developer has to write code that is compatible with about five different platforms (desktop/phone/tablet). And of course, the fact that those platforms are not identical is also due to the fact that the web is too complicated.
I'm hoping that in the future, we can make the web more simple and elegant for the developer. We need simpler primitives, not the complicated and restrictive building blocks that we have seen thus far.
Certainly not. In my opinion, the problem with the web is that it has become too complicated. In an effort to make the web simpler for the ordinary user, the web has actually become a more complicated place for the (advanced) developer.
HTML, CSS and javascript have grown so complicated that they lack certain desirable properties, such as verifiable security, flexibility. For instance, a developer has no choice of programming language, but has to resort to javascript; we are stuck with the cooperative multitasking of the 80s (webworkers support only message-passing, no shared state); also, the developer has no choice of render engine, and to make matters worse, the developer has to write code that is compatible with about five different platforms (desktop/phone/tablet). And of course, the fact that those platforms are not identical is also due to the fact that the web is too complicated.
I'm hoping that in the future, we can make the web more simple and elegant for the developer. We need simpler primitives, not the complicated and restrictive building blocks that we have seen thus far.
I just had this discussion a few weeks ago and it wasn't even about mobile applications; It was about mobile application testing frameworks. We were deciding between a hybrid approach to testing (Appium) vs native (UIAutomation). I don't think these types of debates are going to end soon because most of the decision makers in large companies have grown up with and love the web. For the most part, I've only seen the web get faster and better since the mid 90's, but that was limited to the platform of a computer.
The theoretical maximum benefit of writing a program once that runs everywhere (watch, phone, phablet, tablet, laptop, desktop, tv) and is always up to date (computing is done in the cloud) is extremely enticing but has serious performance implications. What you always end up with is a developer friendly framework that contains cases for each platform and in most cases, doesn't have all of the features each individual developer needs (Bootstrap, Appium, Node.js, React, Angular, etc...).
I want the web to win, but in most cases the DOM was not built and designed for the direction that native applications are going.
The theoretical maximum benefit of writing a program once that runs everywhere (watch, phone, phablet, tablet, laptop, desktop, tv) and is always up to date (computing is done in the cloud) is extremely enticing but has serious performance implications. What you always end up with is a developer friendly framework that contains cases for each platform and in most cases, doesn't have all of the features each individual developer needs (Bootstrap, Appium, Node.js, React, Angular, etc...).
I want the web to win, but in most cases the DOM was not built and designed for the direction that native applications are going.
Browsers need to move from tens of fine-grained permission requests, to "Do you want to install this web app and give it full access to your computer?".
And from there, they need to stop building abstractions such as WebSocket, IndexedDB etc. and start exposing raw OS capabilities such as UDP, TCP and FS. Basically packaging node.js would do the trick here.
Also see Tim Berners-Lee in "Installing web apps":
"If I can't give power to apps, then the web app platform cannot compete with native apps."
https://lists.w3.org/Archives/Public/public-webapps/2012JanM...
He asks for something fine-grained but the main point is to expose the real power of a machine to an app if the user so wishes. That's not possible today with browsers.
Browsers need to stop controlling innovation, and push core services out to the edges and let innovation happen there. Stop drafting specs for WebRTC etc. and give UDP etc. back to the people.
If the browsers don't do it, maybe someone will make a new kind of browser that will with something like Electron.
And from there, they need to stop building abstractions such as WebSocket, IndexedDB etc. and start exposing raw OS capabilities such as UDP, TCP and FS. Basically packaging node.js would do the trick here.
Also see Tim Berners-Lee in "Installing web apps":
"If I can't give power to apps, then the web app platform cannot compete with native apps."
https://lists.w3.org/Archives/Public/public-webapps/2012JanM...
He asks for something fine-grained but the main point is to expose the real power of a machine to an app if the user so wishes. That's not possible today with browsers.
Browsers need to stop controlling innovation, and push core services out to the edges and let innovation happen there. Stop drafting specs for WebRTC etc. and give UDP etc. back to the people.
If the browsers don't do it, maybe someone will make a new kind of browser that will with something like Electron.
There are several reasons mobile devices made it so that Web runtime and Web apps would not be the consensus app environment:
1. Web apps are no longer the answer to breaking Windows hegemony on apps.
2. The Web is a mouse UI. That may seem like a small thing, but look at how much trouble Microsoft has had turning Windows into a touch UI.
3. Mobile devices are the end of overlapping windows. The Desktop Metaphor was a cute idea, but it isn't appropriate for mobile devices. Web browsers, and Web apps, are made for resizeable windows.
4. The Web is great for simple interaction with dynamic content. Which is another way of saying "The Web is a big, linked, interactive e-reader." You can stretch it to try to do other things, but it isn't a comfortable stretch.
5. Pure canvas apps... ... ... </crickets>
6. No one development idiom. Nor two. Nor five. This is much less of a consensus than Android or iOS. IOS developers will be making a language transition, and Android developers will probably incorporate a dependency injection idiom into nearly all Android coding once a consensus is reached on what flavor of DI is favored, but that's about it for uncertainty.
1. Web apps are no longer the answer to breaking Windows hegemony on apps.
2. The Web is a mouse UI. That may seem like a small thing, but look at how much trouble Microsoft has had turning Windows into a touch UI.
3. Mobile devices are the end of overlapping windows. The Desktop Metaphor was a cute idea, but it isn't appropriate for mobile devices. Web browsers, and Web apps, are made for resizeable windows.
4. The Web is great for simple interaction with dynamic content. Which is another way of saying "The Web is a big, linked, interactive e-reader." You can stretch it to try to do other things, but it isn't a comfortable stretch.
5. Pure canvas apps... ... ... </crickets>
6. No one development idiom. Nor two. Nor five. This is much less of a consensus than Android or iOS. IOS developers will be making a language transition, and Android developers will probably incorporate a dependency injection idiom into nearly all Android coding once a consensus is reached on what flavor of DI is favored, but that's about it for uncertainty.
I mostly agree but the one category that does NOT need to be native is pure (text-heavy) content (i.e., news sites). In fact, it's beneficial to be web in order to support easy linking, distribution and discovery.
Also, while I agree with the "home page" question, the author makes no mention of the other important criteria: are notifications important?
Also, while I agree with the "home page" question, the author makes no mention of the other important criteria: are notifications important?
Look at a site like YouTube today. All the tooling we've created and all the progress of the open web platform that has made that site happen is incredible. If we've just given up 10 years ago, saying to ourselves that the web should only be for documents, then we would be missing out big time right now.
It’s not for every site to try and push the envelope. And mimicking native can often lead to bad results. But to go from that and say that we shouldn’t try. That’s just sad.