If there was something dramatically better for every use case (which is not IPFS) it would slowly displace HTTP in new deployments and there would still be HTTP for a very, very long time. The Web we have, in other words, isn't going anywhere.
Okay. I guess you're welcome to do that? We browser coders will just continue to go to market faster. It's pretty cool that, if you put your work in, you can make a GUI on the browser that is accessible to all desktops and phones. That's 2 billion users.
The obvious question is: what would you replace it with? Do you want to replace it all with native apps? Or do you think that this whole internet thing is overrated?
What's wrong with native apps? They use less memory, battery, and processor than an interpreted stack. They can be more responsive than the hardwired 16ms latency built into the browser. If you need network it's not hard to open a socket. The browser itself is a native app opening sockets.
In pretty much every respect, native apps are better for the user than web apps. The person that benefits the most from web apps is the developer.
I'm not taking a side here, but I would like to advocate for a fair comparison, since you have skipped all of the trade-offs in the other direction.
For example, web apps are often easier to discover, easier to update, easier to manage (since you only have one version in the wild you have to handle), easier to launch (especially for first-time users), easier to use from different platforms, more secure (debatable, but since the browser has huge companies working to keep it secure, and your native app that's just opening sockets doesn't, it probably is true), ...
There's pros and cons to both sides. Just framing the situation as "my side has these benefits, therefore there is no reason to consider your side" is not an honest discussion.
How can that possibly be true? A web app can appear in a search engine. A native app's website can appear in a search engine and in a platform App Store.
> easier to update,
because "clear your cache and reload the page" has been said by no frustrated support/technical staff, ever?
> easier to manage (since you only have one version in the wild you have to handle),
Except when there are cache issues. Or when you have multiple servers and need to upgrade them without downtime. Not to mention all the stuff required to host your app needs to handle enough scale to load not just any potential server side data but also the entire ui, possibly every time someone loads it (opposite of the cache problem above). Must be easier though, I've never heard of any web apps being unavailable because the servers were overloaded.
> easier to launch (especially for first-time users),
How is typing a or clicking a link easier than tapping/clicking an icon?
> easier to use from different platforms,
If your browser on your platform is supported. And you have the right version.
> more secure (debatable, but since the browser has huge companies working to keep it secure, and your native app that's just opening sockets doesn't, it probably is true)
This is a joke, right? Did you suddenly forget all the huge leaks of massive amounts of information from hacked web apps? Pretty much no web apps use local storage exclusively. So your attack surface is not "the browser", it's the browser, the network stack, the network itself (see: ddos on Dyn, Comodo/WoSign bullshittery to name a couple from the last month alone), your server host(s), your server os/stack, your server side app logic, your server side db/storage stack.. Do I need to go on?
> How can that possibly be true? A web app can appear in a search engine. A native app's website can appear in a search engine and in a platform App Store.
Because when I come across a web app in a search engine, I can click it, use it instantly, evaluate it, and decide to stay or leave, all within seconds. No checking if the app I found supports my platform, no click-through to my native app store, no download and installation process, no delay, instant feedback.
> because "clear your cache and reload the page" has been said by no frustrated support/technical staff, ever?
Not sure I follow. Are you asserting that native apps are easier to update than web apps?
> If your browser on your platform is supported. And you have the right version.
The combinations are smaller than the combinations of operating systems and phones one would have to worry about.
> This is a joke, right?
Is this a good way to have a productive conversation?
> Did you suddenly forget all the huge leaks of massive amounts of information from hacked web apps?
Do you think only web apps communicate with servers?
> Not sure I follow. Are you asserting that native apps are easier to update than web apps?
I'm saying the processes are more robust. You either have the old app or the new one. You're never left with half of each, and you aren't beholden to random caches about whether or not you get the update.
> The combinations are smaller than the combinations of operating systems and phones one would have to worry about.
That can't possibly be true. Most platforms have more than one browser available, and with the exception of Microsoft, browsers don't have a "use x.y.z version rendering" like platform sdks.
Edit: unless you're taking the approach of: it works with this specific platform device running browser X, so it must work with all others running X. In which case, why not take the same approach to native apps?
> Do you think only web apps communicate with servers?
Where did I say that? Nowhere.
Web apps must contact servers and any remotely useful app will have all its storage server side.
In addition, web apps rely on servers to deliver the very thing the user sees and interacts with. UI spoofing has become such an issue browser vendors are reverting back to make it harder for web pages to present native looking dialogs etc.
Native apps can operate in a client server model, but a great deal of them don't need to because their use case is for local work, and even those that do, are merely transferring data over that channel. They aren't dependent on the same channel for the very interface the user sees.
Claiming that web apps are more secure is the most ridiculous thing I've read in a long time.
I disagree. I think updating a web app is vastly more robust. You update the source, and the only possible issue you have is caching and platform compatibility (the former is a real issue, the latter is mostly alleviated by decent testing).
Updating native apps (due to the next point) is much more problematic because the number of platforms is much higher.
> Most platforms have more than one browser available
Yeah but you can't multiply the number of browsers times the number of operating systems, because Firefox on Linux and Firefox on Windows and Firefox on Android and Firefox on MacOS are (for 99% of the apps) the same target.
> Claiming that web apps are more secure is the most ridiculous thing I've read in a long time.
Are you interested in a real discussion? Or just posturing?
I agree, they are better and faster! But they're expensive, from an engineering-time point of view. I think that small teams with a new product would struggle to have solid native apps on ios, android, windows, osx and linux simultaneously.
I've also gotten a pretty bad taste in my mouth about some companies pushing a native app down my throat. TripAdvisor would only show me the first three reviews on a place if I was browsing via mobile, as a way to push me to download the app. And now that they're on my android they sent me a couple of spammy notifications before I disabled them. I wanted to treat TripAdvisor like a website, not like an app that has access to all phone.
I have gotten to hate most Android apps, constantly sending notifications - spam on the screen, phone on the desk going "ding, ding, ding" all afternoon :-(
On iOS, I've been adopting a policy of refusing the request for permission to send me notifications, unless I can think of a good reason I'd want to see them. I can always change my mind later and approve it if I need to, after all.
"What's wrong with native apps?" Can you even imagine having a native app for everything we do today in browsers? An app for each Credit Card I hold. A native app for each news site I read. A native app for every social media site. A native app for all the map searches, directions, etc. we all use. Security updates? Nightmare. Multi-OS support? forget about it. We'd all be back to a Windows monopoly. No thanks.
If a bank/credit union/etc doesn't have a native app in 2016, I doubt they have a web app that's usable on a phone either.
> A native app for each news site I read
Right, because RSS readers and aggregators aren't totally a thing.
> A native app for every social media site
Those literally exist today.
> A native app for all the map searches, directions, etc. we all use
You realise you don't need a new app for each search you want to do? I don't even understand this premise.
> Security updates? Nightmare
Right, because having half-baked web-apps with millions of user's personal data all stuck in a big fat juicy database in one spot, just waiting to be breached and spread like herpes in a brothel has worked out so fucking well.
Every major mobile platform and the two leading commercial desktop platforms have app store infrastructure which provide automatic updates of client-installed apps.
> Multi-OS support? forget about it.
Right, because no app ever has been developed cross platform, and every web app ever created works perfectly in every browser with zero effort from the developer.
> We'd all be back to a Windows monopoly.
Wat.
Edit: additionally, a number of the things you describe, i.e. news sites, aren't web-apps in the way most people think. They offer very limited if any interaction or functionality for the user except navigating to find/read other news content, and possibly leave feedback. Those sorts of things are what the web excels at, because they're essentially used for one-way content viewing.
Because you really don't need a native application to look up the time the local Thai place is open or if the local independent movie theater has a showing tonight. Installing two native apps to do that is burdensome on consumers and producers
You do remember that Windows is the dominant os for end users? Almost all ui's would have to be created for Windows, and possibly for the other operating systems also. That's probably a lot of extra work.
If developers were better about releasing quality, multi-platform software using their 1970s languages of choice, maybe we wouldn't have all moved to the browser.
ACID correct distributed transactions create very, very painful performance problem because you have to lock across multiple physical machines separated by network connection(s).
Or y'know, you just don't do them correctly and accept a substantial rate of quietly corrupted data.
There isn't really a good option unless you have absurd amounts of money compared to your transaction volume.
They are possible but they are not possible to make per formant compared to the alternative.
Google falls under the "absurd amount of money" camp.
> Protocol Buffers have performance implications for query
processing. First, we always have to fetch entire Protocol Buffer columns from Spanner, even when we are only interested in a small subset of fields.
There are a number of performance costs documented in the paper. Simply because you can solve it via money doesn't mean it works for all situations.
By Hadoop, do you mean HBase? Something else? I'm not sure how much overlap there is. Rethink is geared towards ad-hoc OLTP-type patterns (albeit with a document-like data model), whereas Hadoop is oriented around batch/stream processing. A better comparison would be CouchDB or MongoDB.
Actually yes, but so most sites has some legalese in the TOS and there is also fair use.
IANAL. TINLA. You can probably quote a comment from one HN user, but if you copy all the comments from one "famous" user of HN and write a book with them, then you'll probably get some copyright problems.
Nope, your sentences are not as valuable as you think. Neither is mine. But a great book containing thousands of sentences is valuable enough to to be purchased.
