Hacker News Reader

Comment by gaius | Hacker News Reader

Err, what are you supposed to do when you edit a file on your webserver and want to see how it looks? HTTP is not NFS!

But you are mostly right, software has far, far too many pointless layers of abstraction now, requiring vast resources just to do trivial tasks. There's nothing 99% of people use a wordprocessor or a spreadsheet for that you couldn't do on an 8-bit micro in the 80s. Games these days are just not fun, whereas the 8-bit days were a golden era of creativity. We need to take it back to the old school.

View on HN

On automatic website refreshing:

See guidelines 97 and 98 from Jakob Nielsen and Marie Tahir's book 50 Websites Deconstructed [1] for the primary reason why there has been little interest in removing the "refresh" button from browsers.

Technical limitations don't really exist (and if they do exist it'd be fairly easy to solve). Server-sent events[2] and WebSocket[3] are already implemented in the latest versions of popular browsers. Modules or implementations within popular HTTP servers already exist for doing HTTP push (they tend to use older AJAX-like techniques though).

If usability was no concern (or very carefully handled) it'd be fairly easy to write your own nginx module or "WebSocket server"[4] that uses inotify to check for file system changes. For each change that impacts an open WebSocket connection, a "refresh this page" notification can be sent to the browser (which then uses JavaScript to force a page refresh). There is a potential for smarter refresh mechanisms in browsers that maintain the current scroll state, field values, etc but you'd still be frustrating the user with severe usability problems.

[1] http://www.useit.com/homepageusability/guidelines.html

[2] https://en.wikipedia.org/wiki/Server-sent_events

[3] https://en.wikipedia.org/wiki/WebSockets

[4] http://altdevblogaday.com/2012/01/23/writing-your-own-websoc...

Yes but none of these things existed in 1993. You can call it "lazy" I suppose that TBL didn't implement all the features you take for granted 20 years later before releasing the first browser(!)

It's lazy when your platform still has mandatory polling decades after interrupt driven programming was invented.

Interrupts are not without drawbacks. There are valid reasons to not implement them, particularly on the web.

So, WebSockets are a mistake then?

Websockets are like airplanes: useful, but not for daily commuting.

So do you have any technical points to make, or just more dumb excuses? If you don't want interrupts, you just use them to implement polling.

Interrupts are stateful on the server side; that creates problems in terms of scalability, both due to increased memory usage and by being less flexible (either you have each user "locked" to a single process, or you have to implement state sharing, which adds overhead).

It can also be extremely wasteful - if I leave a tab open for hours or days, you'll have to waste your resources and mine to keep pushing me stuff I won't see, while now I just hit refresh when I want to see new content.

In terms of usability, it's often jarring to watch content change when you're interacting with it - that's why even sites that implement real time notifications often have a link or button that you have to press to update the UI. In many cases, doing that completely negates the benefits of pushing.

Also, see the thesis on "Architectural Styles and the Design of Network-based Software Architectures": http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Polling is a good default for the web; it fits most use cases (content that rarely changes) in a simple and economical way. WebSockets are useful for the exceptions.

It fits most cases.. except that web applications are _constantly_ polling for information. Which may be fine, but you can implement polling with interrupts. What part of that do you not understand? Are you aware that the OS is using an interrupt-driven system to poll the server? It's just hidden from you, so you have no choice. This is just dumb engineering. And to say that it's good for "most things" is just lazy thinking. "Most things" are that way precisely because of the crappy architecture. Rationalisations.

It fits most cases.. except that web applications are _constantly_ polling for information.

Web applications are a very small part of the web as a whole.

you can implement polling with interrupts

But why would you?

Are you aware that the OS is using an interrupt-driven system to poll the server?

Yes. So? In that case, interrupts are a great fit. In others, they aren't.

This is just dumb engineering.

Why?

And to say that it's good for "most things" is just lazy thinking.

It's not good: it's better for most things. There's nothing lazy about evaluating the options and choosing one.

"Most things" are that way precisely because of the crappy architecture. Rationalisations.

Sure, everyone who implemented this shit is dumb and lazy. It couldn't be that they have good reasons for doing what they did.

I see you criticized me for not providing technical points, yet now you refuse refute them. I don't see the point of this conversation anymore.

You haven't made any technical points. You just waffled nonsense about scalability. I see you're bowing out of the argument because you have no case. Once you have interrupts on a platform, you have polling. If you're stuck with polling you can't recover interrupts. Which is why we have websockets decades late. The truth is there is not tension between interrupts and polling. Interrupts are plainly superior, since you can opt out of them trivially. But the platform should not opt out ahead of the developer. This turns out to be inadequate, so we get polling implemented inside interrupts and then a separate mechanism for interrupts. And the interrupt driven stuff has stupid reload buttons and so forth on the GUI. It's dumb engineering because increases complexity and leads to bad results for the user. You have no case. Polling is dumb. And if you think software engineers ever needed "good reasons" to add a bunch of pointless complexity to things, then you simply have no clue on the history of software development.

Notice how the posts that are downvoted have no replies, because the downvoters cannot argue their case. How sad.

I had not downvoted you, but I thought about it - because you are making ranty, ad hominem attacks ("lazy thinking", "dumb excuses"), and you appear to be ignoring or handwaving away all the actual points anyone makes. I have no interest in engaging you in any discussion for these reasons, and I expect that other people feel the same way: hence, downvotes and lack of replies. Feel free to do what you wish with this information.

"HTTP is not NFS" is a technical challenge that is potentially solvable. With single page apps the reload button is becoming increasingly irrelevant anyway though.

Writing desktop apps within a browser running on a desktop is what's crazy... Pointless layers of abstraction.

It's only pointless because we are still using the "Desktop" model. I'm not advocating one over the other but as we see Mozilla try boot to gecko and Google trying Chrome OS we are seeing the early stages of the "webtopbrowserthing" being refined. We are in that transition state where we are trying to figure out what platform is where the money is.

Those of us who have been around for a while look at what Google are doing with a sense of deja vu

http://en.wikipedia.org/wiki/NeWS

And NeWS was better in the sense that it used PS for everything rather than an unholy mess of JavaScript, CSS, HTML, etc etc.

It just goes to show that market forces do not care about technical merit and ultimate purpose in the least. NeWS never got traction, yet the advance of the web is inexorable. Why?

Well the web is supported everywhere because it was simple. The fact that it is available everywhere (which is actually pretty amazing and unique in the entire history of media if you stop and think about it) meant people kept pushing the boundaries. The limitations caused standards to be pushed forward. Wide use of the standards means no platform can break free from supporting it (Microsoft did their best for almost a decade!).

Obviously it looks like a Frankenstein monster from an engineering perspective, but it doesn't matter because that's where the investment is going. The good news is it will evolve and improve, and soon enough the grey beards who remember that there could have been a better way will all be dead; a lot like UNIX actually ;)

edit: I'd appreciate if bitter GUI developers would respond rather than misdirect their anger at the down vote button.

Well. You're getting downvoted for wishing death on people you've never met.

>The good news is it will evolve and improve, and soon enough the grey beards who remember that there could have been a better way will all be dead; a lot like UNIX actually ;)

That sounds like some sort of evil plot. For that matter my beard isn't anywhere close to being gray and I know that things could have been better. And if you didn't have +8000 karma I would think you were trolling.

That you're not just makes it worse.

Who's wishing death on anyone? It's just a colorful way of saying that people will soon enough take the web heritage of apps for granted.

>The good news is...soon enough the grey beards...will all be dead... ;)

You're the one who asked. If thats what I got out of it it's probably what the people downvoting got out of it too.

For what it's worth maybe the intended message would have come through better if you were saying it in your voice with tone and inflection rather than the way I read it as words on the screen.

What are the practical issues you're concerned about? Dev time? performance / reliability?

Dev time, you say. Well let me tell you a story. I am quite into 8-bit, I like buying micros from the 80s as junk and fixing them up. Recently, my old lady and I wanted a spreadsheet to track days off, vacations and so on. I could have done it on the quad-core, 8G Mac in Excel or online with Google Docs... But I actually did it in ViewSheet on a BBC Micro.

So dev time, well the last THIRTY YEARS of dev time haven't gotten me any anything I didn't have already.

I would personally not put up with a spreadsheet where the GOTO cell function is rather awkardly hidden on function key number seven.

And today I walked a mile from my grandmother's to my house. The last HUNDRED YEARS of car manufacturing haven't gotten me any anything I didn't have already.

A car could get you there faster, or dryer in the rain, or carrying more stuff. But there's not much Excel can do for the vast majority of users who just want a table with a few dozen records, that ViewSheet (or the granddaddy of them all VisiCalc) can't. Same with wordprocessing.

Except many of those users don't want just a table with a few dozen records - they want that plus a couple of small features. And the real problem is that they don't want the same couple of features. Hence, you end up with huge beasts to support each combination.

For example, what if you want to use your spreadsheet when you're not home? Never happened to you? Well, it happened to others.

ViewSheet delivered a basic spreadsheet + sample code in BBC Basic to manipulate it. It could do anything Excel + VBA can do today.

Yes, as long as you can code; but in that case, so can raw assembly. Most people can't code, so that doesn't help them if they want something more. Excel, on the other hand, has features they can actually use.

Or to use my previous analogy, you're essentially saying that because you can build your own custom designed car from parts, pre-built cars are useless.

People should simply design something small that satisfies a niche. If it doesn't have enough features for some person, rewrite it. When software is small you can rewrite as much as you want. Software engineers labour in the delusion that their creations are so fantastic and amazing that it can only accomplished through huge complexity.

Reply on news.ycombinator.com