Live data from Hacker News

It's Time for Server-Side Browsers

camendesign.com

31–40 of 45 posts

Re: It's Time for Server-Side Browsers

#31
post #3

Or we could stop treating the HTTP/browser combination as an application delivery platform. It's unpopular here, but it's becoming exceptionally obvious as the correct choice.

How should we treat it? What is the alternative application delivery platform? Where is it becoming exceptionally obvious? Tks in advance.

We should treat it as a document delivery and linking system, as it was designed to be.

Currently, the alternative application delivery platform is the App Store, the runaway success of which is neatly proving the point that the web just isn't up to the job of serving applications in the way we've been trying to hack it to become.

That's also where it's becoming exceptionally obvious, as people struggle mightily (even Apple themselves) to create web apps that have a look and feel anywhere close to those of native apps. And users feel the difference, sense the request/response bubbling underneath and the JS churning on top, and reject them.

Re: It's Time for Server-Side Browsers

#32
post #2

Isn't it how mobile Opera works already?

It’s how Opera Mini works (sort of) but not how Opera Mobile works.

Going by the title, yes, that's (sort of) how Opera Mini works, but going by what he wrote, no, not really. He seems to be talking about browsers as servers on the client side, not turning browsers into glorified image viewers.

Re: It's Time for Server-Side Browsers

#33
post #2

Isn't it how mobile Opera works already?

It’s how Opera Mini works (sort of) but not how Opera Mobile works.

Every Opera can use Opera Turbo to get recompression of pages. The author is talking about something more than that, though, he's basically talking about VNCing to a server.

Re: It's Time for Server-Side Browsers

#35
post #11

Could someone translate what this is actually trying to talk about into something clear? This blog post reminds me of someone on weed trying to relate to you this profound idea to you and rambles on stream of consciousness style. He wants there to be no 'centralization' (that is, servers) and have things run on a cloud of people's web browsers, yet at the same time it still talks to mysql somewhere? We won't need any…

What I understood is that the author wants the browser to run on the server and then stream the video, VNC-style. That's a profoundly silly idea, since you'd have to basically get one server per user for any semi-CPU-intensive rendering, and to what benefit? I don't know.

Re: It's Time for Server-Side Browsers

#37

Earlier quoted context omitted.

... Which assumes people keep their machines running 24/7 on unlimited data connections. It's a nice idea from a tech point of view, but for the life of me I cannot see how it's superior to what we already have.

Well, except some degree of redundancy would be built in to the storage scheme á la BitTorrent. As far as data volume, I've got to imagine the data usage per user would be significantly less than BitTorrent. The desirable aspect of this system is obvious - the only people who see your data are people who've seen a QR code from someone in your social graph - your FaceTorrent profile will never, ever be indexed by Goog…

> The desirable aspect of this system is obvious - the only people who see your data are people who've seen a QR code from someone in your social graph - your FaceTorrent profile will never, ever be indexed by Google.

What if Google started offering, say, free Google Coupons (assuming they roll their own groupon) in exchange for befriending them on FaceTorrent? Not all of my friends and relatives value privacy as much as I do.

Re: It's Time for Server-Side Browsers

#38

Earlier quoted context omitted.

How should we treat it? What is the alternative application delivery platform? Where is it becoming exceptionally obvious? Tks in advance.

We should treat it as a document delivery and linking system, as it was designed to be. Currently, the alternative application delivery platform is the App Store, the runaway success of which is neatly proving the point that the web just isn't up to the job of serving applications in the way we've been trying to hack it to become. That's also where it's becoming exceptionally obvious, as people struggle mightily (eve…

Thank you for your answer. It's a valid example but I guess it doesn't prove the point that the web isn't up to the job of serving applications. Maybe in mobile that's true, maybe mobile it's the future. For now I would counterargue that web app market is much bigger than the mobile app market.

For whoever downmoded me RTFM: http://paulgraham.com/road.html. If there is a new road ahead write a new road ahead essay close to that form so I can understand. I won't stand for empty vanguardism.

Re: It's Time for Server-Side Browsers

#39

Earlier quoted context omitted.

We should treat it as a document delivery and linking system, as it was designed to be. Currently, the alternative application delivery platform is the App Store, the runaway success of which is neatly proving the point that the web just isn't up to the job of serving applications in the way we've been trying to hack it to become. That's also where it's becoming exceptionally obvious, as people struggle mightily (eve…

Thank you for your answer. It's a valid example but I guess it doesn't prove the point that the web isn't up to the job of serving applications. Maybe in mobile that's true, maybe mobile it's the future. For now I would counterargue that web app market is much bigger than the mobile app market. For whoever downmoded me RTFM: http://paulgraham.com/road.html . If there is a new road ahead write a new road ahead essay c…

I don't think your lack of understanding entitles you to demand someone write a 2000-word essay for you.

But, briefly, many of the points in Road can still be right with the conclusion being wrong. Yes, data is more important than computer, and server-side computation and storage of data etc is increasingly important.

But the web as the client interface? Network-aware native apps are trumping all over it. These aren't the desktop apps PG speaks of, they're not shipped in boxes and they're not static. They're downloaded instantly, updated easily, network enabled and fully responsive.

Convenience over all is the thing for users, and apps are just more convenient. They don't load themselves from network every time (Gmail, Twitter), they don't have UI elements that fill in slowly as their graphics load over the network (Posterous and a million others), they don't transform without warning (Facebook) and they don't pretend that a way of sharing research papers can support an interactive session without you noticing.

As for the size of the Market, I've already spent way more on desktop and mobile software than I've ever spent on Saas/site subscriptions and I don't see that changing. Where there's a native app I'll almost always prefer it.

Why? Because native apps are better software; a better experience. And when they're supported by (synced/cached) server-side data (and ideally a fall back to a web client if I find myself at some random terminal somewhere) I get the best of both worlds.

Re: It's Time for Server-Side Browsers

#40
post #11

Could someone translate what this is actually trying to talk about into something clear? This blog post reminds me of someone on weed trying to relate to you this profound idea to you and rambles on stream of consciousness style. He wants there to be no 'centralization' (that is, servers) and have things run on a cloud of people's web browsers, yet at the same time it still talks to mysql somewhere? We won't need any…

What I’m proposing is that we replace PHP with a web browser so that the code we run on the server could be the same code we run on the client. To make it so developers only have to learn one language, one set of technologies.

That will eventually lead to decentralised applications, but in the mean time will simply lay the groundwork for it whilst people continue with the centralised model.

There will always be a need for centralised systems, the world is just not going to simply change their entire toolset and paradigm overnight. We must make centralised apps use pretty much the same technologies as decentralised ones first, then coax developers over.

Post reply on HN