Instead of building fast native application delivery and sandboxing we're taking the longer way around and reinventing OSes inside a document (!) browser.
Can't say that it makes me happy.
Can't say that it makes me happy.
What we have now really is a tragedy of the commons situation.
edit: Google maps (or equivalent) is a true game-changer that has a lot of value and one of the very few websites with actual value from javascript. But, we could just use Google Earth as a separate application for it. Just as we did in the early days when google maps on the web was a poor fit.
Very small price to pay.
I feel like when everyone says “this should be a native app” their imagined app is absolutely flawless and integrates seamlessly on every OS. But reality has rarely matched that ideal.
Today I'd use applications such as Slack and Spotify as posterchilds for bad applications. That they are built with web tech is not a coincidence.
I'm not a huge fan of a lot of web apps either but there doesn't seem to be a whole lot of introspection on the part of native app proponents. They're faster, they consume less memory, yet overwhelmingly people choose to make apps using web technologies. Why isn't anyone interested in exploring why native failed to offer what these people wanted?
- are instantly usable just by following a link
- people can share with others, without needing to install anything, by just sending a link
- work equally well on all major mobile, desktop and tablet platforms
- don't require any sort of app store or gatekeeper to distribute or use
This isn't developers not caring about the user. These are huge UX advantages, and there's no way to get them all other than building on the web.
Depends on the size of the web app and by data bandwith
>- people can share with others, without needing to install anything, by just sending a link
true, as long as the web page still exists.
>- work equally well on all major mobile, desktop and tablet platforms
I wish, most of the time web apps are either optimized for mobile phone, tablet or desktop not all three of them.
>- don't require any sort of app store or gatekeeper to distribute or use
The app can therefore change without your knowledge and execute malicious code the next time it is called.
https://medium.com/hackernoon/im-harvesting-credit-card-numb...
Not to mention that the web app is gone when the site no longer exists.
This. I'm fed-up of "mobile first". I know why it's done, more website hits are from phones than desktop/laptop systems. But "first" is supposed to mean that something comes after; an awful lot of projects aren't "mobile first", they're simply designed for mobile.
I hate smartphones. I can't use them. I can't read the screen properly, and my fingers all turn to thumbs when I try to interact with them. I own one, so that I can call a taxi when I'm out, and so I can receive SMS messages. And some government services require a mobile number. But I have no data plan, and my smartphone normally just sits on my desk.
For years I've been hearing about better frameworks and better tools for web development, but then when I open a website on the go, there are very often issues with rendering ot performance not to mention that a simple website consumes a large portion of my data bandwidth. This also happens with native apps but more often with web apps.
I haven't looked into this in detail, but I did started out programming in QBasic, used Delphi for over 20 years on Windows, and done cross-platform (all three) with WxWidgets and Qt, and I have given this some idle thought over the last few years.
I'm sure the truth is multi-faceted, but I feel it's primarily a combination of smartphones, lack of good cross-platform UI toolkits with low barrier to entry and the rise of SaaS.
Existing programs were not a good fit for smartphones. You couldn't easily take your existing C++ product and just recompile it. Simultaneously, smartphones required drastically simpler UIs, simple enough that a web page could be sufficient.
While cross-platform applications were possible with toolkits like WxWidgets and Qt, for most non-trivial programs you'd still end up with a ton of special cases needing handling. In one project we had one developer tweaking the OSX build, changing fonts and layouts to make it look and behave "proper" on that platform. It was better with Qt, but not perfect.
Also, these toolkits require a lot of ceremony to get going. Making a basic web page and adding some rudimentary javascript is quite easy, it's interactive and it's visual, which is great for learning. It's way more exciting to program something visual than mess around on a command prompt. I know many who became programmers through this route, people who otherwise hadn't thought about becoming programmers. Many of these have not moved much beyond the frontend.
Most people though don't really want to deal with computers. They want to use them, but not have to mess with them. Figuring out how to install and maintain applications, keeping track of security updates and all that jazz. This goes for individuals as well as companies. Thus the rise of SaaS.
Now, where I currently work we provide a hybrid SaaS-ish model for a Win32 desktop application. Customers provide the metal or VM, and we install and maintain the server software and client applications. However most customers don't really want to host servers in-house, and for us it's a pain to deal with all the various IT departments and their peculiarities. So both want to move to a proper SaaS, where the servers are hosted by us. Customers also want to be able to use Mac's.
This means we need a proper frontend/backend split regardless. No more direct connection to the database server. With that in mind, if you have a not-too-complex application, maybe a web page frontend is easier for both developer and user?
Now for our case, we have a complex CRUD application, so it's not so clear-cut. But if you have a relatively simple application with a handful of controls, then the choice seems to be much easier to me.
Of course, I could be totally wrong...
The web and browsers like many languages, are not something any one person or group can authoritatively prescribe.
The W3C follows the browsers, not the other way around.