React: Finally, a great server/client web stack

You're absolutely correct that browser-based applications offer some very compelling advantages: they're run-everywhere (or at least, many wheres), they're rapid-deploy, they're particularly well-suited to data presentation and interaction tasks (which constitutes a large fraction of all apps), and rather importantly for small development shops, they offer a compelling path out of legacy support hell. These are all true.

So are my critiques. In particular, that the Web alternatives aren't as fast or light as native apps.

Purely native apps haven't "lost the war". They are the battleground for the most part on mobile devices, as you note, though you omit the observation that these typically operate via an API, which is in fact the direction I'm leaning as a hybrid browser/app model. Fully native apps retain crucial advantages in many spaces.

I'm curious as to what aspects of this you consider to be FUD? I'm reporting actual memory utilization for apps doing comparable tasks, at least as far as rendering raw information is concerned. If you want to consider graphical presentation, I've also got a number of PDF files open using xpdf and evince, both of which perform full graphical rendering including images. The maximum RSS for these is 14 MB, and the 20 or so processes running here have far less system impact than my chromium child processes.

The train wreck I'm describing is precisely that. Light websites are generally not an issue, but the full-fledged app instances, again, Google+, Gmail, and the like, cause wild amounts of swapping and instability, to the point that I make minimal use of them, and where possible find alternatives. The RSS/Atom readers I mention aren't doing the full work of a Web browser, but that's precisely the point: for keeping me informed of an information stream, they're far more than sufficient, and require far fewer resources. I can open an item in a console-mode browser (and yes, that's old-school and an acquired taste), or pop over to a browser and read the item. It's far less overhead than keeping the stream in my browser at all times, and as I noted, the RSS readers offer hooks to perform other local actions if I choose.

I've written recently of the frustrations I'm increasingly having with browsers in general: they serve neither the needs of application users nor of content readers particularly well. Quoting myself:

"It's neither a good reading environment -- for that you'd want something like Readability, Pocket, Instapaper, or an eBook management tool such as Moon+Reader, Kindle, or (bad as it is) Calibre -- nor a decent applications environment: it's bloated, crash-prone, slow, full of security holes, and underfeatured relative to native applications.

"However in both cases the browser's ability to load and display or run arbitrary content makes it convenient."

https://news.ycombinator.com/item?id=7062219

I see a few possible directions things could head:

⚫ Continue down the current path. This is the course of least resistance.

⚫ I don't know where the HTML working group(s) are headed, but continuing the pattern of HTML5 of offering highly semantic markup and leaning in the direction of an API model of HTML rather than a designer model (or in addition to) could be useful.

⚫ We now have and . How about a as I described, and perhaps native features which could present graphics based on realtime data updates? Again, a huge class of applications now essentially consists of "poll regularly for new data, update stream, present graphics, respond to user inputs".

⚫ A content-oriented browser which strips out virtually all distractions, and provide vastly improved content management and referencing capabilties (see: zotero). Readability, Instapaper, Pocket, etc. approach this. I presently have a local "unstyled.css" stylesheet which I apply to many sites. It works best on bare-naked pages (without any native styling or table/frame based page layout) but works pretty well on most minimally-styled pages. And it is, for my purposes at least, almost always a huge improvement over native presentation. In other cases I've extensively modified how pages present themselves. See: http://www.reddit.com/r/dredmorbius/comments/1tniu3/user_sit...

⚫ An application-development platform based on (mostly) standard APIs and an HTML/SHTML transport back-end. This would be the area you're most interested in.

I'm not convinced this is the way things should go, but it seems it would resolve some of the present tensions in Web development and use.

The main one is the ability to reuse code on server and client. It's not something to be sniffed at.