6 ms·

Not all use cases are equal. Static pages might work great for static content, but what about something like GitHub? Wouldn't it be nice to see the issues list

Not all use cases are equal. Static pages might work great for static content, but what about something like GitHub? Wouldn't it be nice to see the issues list refresh live when somebody else closes one?

PavlovsCat 13y ago
I find such stuff annoying, at least using it everywhere just because you can. Imagine you're reading hackernews, and halfway through reading a comment, it gets deleted. Or, say, you want to compare a page with the changed page one hour later -- easy, just open it in a new tab (and maybe do a hard refresh), right? Well, if everything is "real-time", that's not even possible. Yes, there are use cases for it. But doing it just because you can, because it's supposedly "cool", is also hurting other use cases.
ForHackernews 13y ago
> Wouldn't it be nice to see the issues list refresh live when somebody else closes one? Maybe a tiny bit. I guess. Really, I'd just reload the page if I wanted to see recent changes.
andrewflnr 13y ago
That's actually a perfect use-case for this render-serverside-update-clientside paradigm.
dredmorbius 13y ago
What are the cases for that feed role? Why not deliver an RSS/Atom feed with the page and a standard feed reader within HTML that could present the content, polling at specified intervals. In the same way that HTML finally standardized on HTML5 semantic page markup (not that HTML1.0 was grossly inadequate), and we're finally getting integrated video / multimedia support (though lacking the ever crucial "off" switch), once you dig through all the bullshit and hype, most of Web 2.0 corresponds to "we can update the page you're looking at while you're looking at it". Some client-side capabilities to sort and filter content would finish off about 90%+ of the use cases. Good enough. And you'd end up with far fewer monstrosities such as Facebook, Gmail, G+, etc., in which a simple content stream has a client-side footprint of 1-2 GB. SRSLY? Yes, the standard problem of having users upgrade their client software to support the featureset remains, but there are still huge numbers of what are effectively Web 1.0 sites (Craigslist comes to mind) that are phenomenally useful and successful. I've had a very late and passionate come-to-Jesus love affair with RSS/Atom feeds. Taking Craigslist, for example I can get an RSS feed of any given category search: http://www.craigslist.org/about/rss http://www.craigslist.org/about/rss Remember "Web agents", you know "a personal online assistant that would scour the Internet for you"? Well, this is it. Combine that feed with rsstail and multitail, and you can track items of interest in a console window. Find something particularly useful? Fire off an email alert to yourself. http://www.reddit.com/r/dredmorbius/comments/1udv6i/further_adventures_in_rss_chrome_reader_extension/ http://www.reddit.com/r/dredmorbius/comments/1udv6i/further_... I've got Chromium running on my Thinkpad T520i, sucking down about a gig and a half of RAM. newsbeuter tailing 85 feeds is around 300 MB (a single Chromium browser tab), and rsstail weighs in at about 145 MB resident. Since they're only intermittently active, they swap out with very little performance overhead. The existing Web design model is a fucking trainwreck waiting to happen. The browser-as-app-platform metaphor has its advantages, mostly in rapid development, though that's also a weakness (users HATE change), and it's a bastardization of two competing uses (content vs. app). Much of the design and feature set serves advertisers and NSA water-carriers far more effectively than it does users. Sadly, that's where the funding comes from, so it's no real surprise. Be careful what you incent for, you'll get it.
- antihero 13y ago
  With the amount of inane FUD you're spreading I can't work out if you're genuine or a troll. Your text only/image minimal feed reader is using less RAM than a browser designed to load hundreds of images and get the most out of the RAM available to it? Shock and horror! And this "train wreck" you're referring to... I don't see it. I see happy clients that can pay once and get an application that is useable on any platform, from anywhere in the world, is as fast as a native application, and can be seamlessly scaled up to meet demand. Where is the downside in that? Game over, purely native apps, you lost the war (except for specific things that need to operate locally). Sure there are native phone applications, but they are essentially thin clients for web applications anyway.
  - dredmorbius 13y ago
    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 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 <header> <article> <aside> and <video>. How about a <stream> as I described, and perhaps native <plot> 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_site_restyling_multicolumn_vs_fullwidth/ 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.

PavlovsCat 13y ago

I find such stuff annoying, at least using it everywhere just because you can. Imagine you're reading hackernews, and halfway through reading a comment, it gets deleted. Or, say, you want to compare a page with the changed page one hour later -- easy, just open it in a new tab (and maybe do a hard refresh), right? Well, if everything is "real-time", that's not even possible. Yes, there are use cases for it. But doing it just because you can, because it's supposedly "cool", is also hurting other use cases.

ForHackernews 13y ago

> Wouldn't it be nice to see the issues list refresh live when somebody else closes one? Maybe a tiny bit. I guess. Really, I'd just reload the page if I wanted to see recent changes.

andrewflnr 13y ago

That's actually a perfect use-case for this render-serverside-update-clientside paradigm.

dredmorbius 13y ago

What are the cases for that feed role? Why not deliver an RSS/Atom feed with the page and a standard feed reader within HTML that could present the content, polling at specified intervals. In the same way that HTML finally standardized on HTML5 semantic page markup (not that HTML1.0 was grossly inadequate), and we're finally getting integrated video / multimedia support (though lacking the ever crucial "off" switch), once you dig through all the bullshit and hype, most of Web 2.0 corresponds to "we can update the page you're looking at while you're looking at it". Some client-side capabilities to sort and filter content would finish off about 90%+ of the use cases. Good enough. And you'd end up with far fewer monstrosities such as Facebook, Gmail, G+, etc., in which a simple content stream has a client-side footprint of 1-2 GB. SRSLY? Yes, the standard problem of having users upgrade their client software to support the featureset remains, but there are still huge numbers of what are effectively Web 1.0 sites (Craigslist comes to mind) that are phenomenally useful and successful. I've had a very late and passionate come-to-Jesus love affair with RSS/Atom feeds. Taking Craigslist, for example I can get an RSS feed of any given category search: http://www.craigslist.org/about/rss http://www.craigslist.org/about/rss Remember "Web agents", you know "a personal online assistant that would scour the Internet for you"? Well, this is it. Combine that feed with rsstail and multitail, and you can track items of interest in a console window. Find something particularly useful? Fire off an email alert to yourself. http://www.reddit.com/r/dredmorbius/comments/1udv6i/further_adventures_in_rss_chrome_reader_extension/ http://www.reddit.com/r/dredmorbius/comments/1udv6i/further_... I've got Chromium running on my Thinkpad T520i, sucking down about a gig and a half of RAM. newsbeuter tailing 85 feeds is around 300 MB (a single Chromium browser tab), and rsstail weighs in at about 145 MB resident. Since they're only intermittently active, they swap out with very little performance overhead. The existing Web design model is a fucking trainwreck waiting to happen. The browser-as-app-platform metaphor has its advantages, mostly in rapid development, though that's also a weakness (users HATE change), and it's a bastardization of two competing uses (content vs. app). Much of the design and feature set serves advertisers and NSA water-carriers far more effectively than it does users. Sadly, that's where the funding comes from, so it's no real surprise. Be careful what you incent for, you'll get it.

antihero 13y ago
With the amount of inane FUD you're spreading I can't work out if you're genuine or a troll. Your text only/image minimal feed reader is using less RAM than a browser designed to load hundreds of images and get the most out of the RAM available to it? Shock and horror! And this "train wreck" you're referring to... I don't see it. I see happy clients that can pay once and get an application that is useable on any platform, from anywhere in the world, is as fast as a native application, and can be seamlessly scaled up to meet demand. Where is the downside in that? Game over, purely native apps, you lost the war (except for specific things that need to operate locally). Sure there are native phone applications, but they are essentially thin clients for web applications anyway.
- dredmorbius 13y ago
  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 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 <header> <article> <aside> and <video>. How about a <stream> as I described, and perhaps native <plot> 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_site_restyling_multicolumn_vs_fullwidth/ 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.