Hacker News Reader

The browser is what it is because it's the camel designed by global committee. It's the place where competing interest groups fight one another to a standstill on a daily basis. Quite a lot of the stranger aspects aren't so much "features" as blast craters of past disasters.

For example, consider the five technologies for interactive, animated things in the browser: Java applets, ActiveX, Flash, Silverlight, and Javascript. Apart from Silverlight, which never really took off, they're all 20 years old. Only Javascript has survived the security wars; Java applets are dead, Flash gets a CVE bullet with its name on every few weeks, and ActiveX was killed long ago.

The near-death of NNTP is a story of spam cancels and cost allocation.

The browser covers all use cases and is available everywhere. That means it's necessarily horribly compromised compared to native solutions, but is an absolutely killer advantage for adoption. Incrementalism nearly always wins.

Furthermore, the unwillingness of people to pay directly for software leaves us with a continual problem of exploitative software. Everything from flashlight apps that steal your contact list to ads that steal your battery to connection-sharing apps that open you to liability for the actions of others. For the moment, we keep other people's software securely nailed shut in the browser.

Just want to add Unity WebPlayer[1] to the list of interactive technologies.

It is not as popular or generic as the five you mentioned but I do see it pop up a lot if you want to do some casual web gaming, which I don't like, because it is just another plugin you need to use the "open" web.

[1]: https://unity3d.com/webplayer

Unity's been working on bettering its HTML5/ASMjs exporting, so hopefully the need for a plugin goes away someday

> Quite a lot of the stranger aspects aren't so much "features" as blast craters of past disasters.

Cracked me up, very well said. In general I agree that the document-centric browser has been abused horribly. Then we get obscene beasts like node.js, because, well, the browser does it, so must we.

Node.js is interesting, and while it wouldn't be my first choice I can see how it came about. AJAX in the browser leading to Javascript developers evolving a callback-chaining style; realising that they could use the same language and style on the server; the inherent high efficiency of single-process nonblocking callback orientated servers.

Does anyone think that JavaScript could overtake PHP as the "go-to" language for server-side scripting with Node.js as the "go-to" runtime?

Despite my indifference to Node.js, I can see the unification of client-side and server-side scripting into a single language being incredibly valuable to the millions of PHP and JavaScript developers (both front and back-end) out there: most of whom beyond the realm of HackerNews and want to get it done.

Not only that, it would significantly reduce the barrier to entry for web scripting and disincentivize beginners from picking up all those nasty habits such as md5 password hashing and manually constructing SQL queries from raw input which are so worryingly accessible.

The only thing I can see preventing this are:

1. Lack of a mod_node for Apache. Perhaps this exists? 2. The upload and refresh workflow so many PHP developers are familiar with 3. A scheduler to prevent any one website from blocking the Node.js event loop on shared hosting

Is this completely bonkers, or is it quite sane?

Not quite correct--as memory serves, as far back as Netscape folks have offered server-side JS.

> In a hypothetical cyber-utopia or something, this could all just be a simple protocol (say, um, combining aspects of Direct Connect, BitTorrent, NNTP, Gopher, Bitcoin, GPG)

The article does mention p2p and decentralization, but the browser isn't whats holding that back. The client-server development paradigm is.

Currently, every dev making a p2p app has to roll their own platform because there's no standard (i.e. no LAMP, rails, or Heroku for deploying p2p apps). Some projects are working to change this, namely BitTorrent Maelstrom (which is a fork of Chromium with native support for magnet URLs, so it auto-renders an html/js package distributed via torrent); and http://ipfs.io (a sort of content-addressable p2p filesystem, or bittorrent on steroids).

Yeah, that's super interesting stuff... Also Etherium, which as I understand it is a way to do distributed algorithms in a very general way.

Or, in short, you want everything to run in an emacs interface. The world has moved on. We have mice now. Sorry. Google implemented keyboard navigation in their search results and apparently the uptake has not been great.

CPUs are there to be "wasted". You pay for that clock frequency to use it and make your life better. Most people don't want to do everything in a terminal. It's depressing.

Google hijacking the keyboard to only be able to navigate through their search results instead of letting the user scroll the page with keyboard as usual is indeed pretty annoying imho..

We had mice for a brief instant of computer history, then came the phones and tablets and e-readers and watches and TVs and voice interfaces and who knows what's next?

I worked on a web-based replacement for medical record software, and a primary complaint from users was that they wanted to be able to use the keyboard. These weren't Unix nerds or whatever, they were normal people who wanted to get stuff done effectively and ergonomically.

Nobody knows you can do keyboard navigation on Google, and anyhow that's just one website with a special custom JavaScript. Why keyboard navigation on the web is so horrible and embarrassing is an interesting question with lots of strands to investigate.

Why would CPUs be there to be wasted? Power efficiency is even an ethical imperative these days. If there are more efficient ways to do the basic tasks of computing and networking, that also allows CPUs to do more interesting and valuable things.

It's not about Emacs, that's just my personal idiosyncratic preference. Other people have other preferences, which is exactly the point. Note that Emacs works very well with many network standards, like email, Usenet, IRC, RSS, even BitTorrent. These are protocols that have enough semantic structure, openness, and simplicity to allow access with different clients that present the information in whatever way is optimal for the user.

As for most people not wanting to use terminals, how do you know? Maybe they just don't like the existing terminal interfaces. Unix commands are notoriously cryptic and shells don't help much. But if you showed a normal person a nice-looking shell where you could type "netflix breaking bad s3" and get a nice presentation back, would they really be depressed?

Lots of people including myself make heavy use of the mouse in Emacs. And pretty much the only time I use a terminal these years is to recover from having inadvertently messed up my .emacs file.

In fact, in at least one way, Emacs has better mouse support than either Firefox or Chrome do, at least on OS X: in Firefox or Chrome, even when the browser's window is right up against the right edge of the screen, the rightmost column of pixels does not belong to the browser's scroll bar, which makes it hard to interact with the scroll bar, particularly since OS X 10.7 or 10.8 when scroll bars got thinner. In contrast, in a properly-designed OS X app, like TextEdit or TextMate, whenever the right edge of the app's window is up against the right edge of the screen, the user can just jam the mouse cursor to the right and start interacting with the scroll bar without the need to get the cursor into a thin target region. Now most Macs these days come with trackpads, and the problem I just described doesn't apply to users who scroll by using (two fingers on) the trackpad, but if the Mac is a desktop Mac (i.e., not a MacBook) and the user prefers a mouse to an external trackpad, this is an important issue.

Emacs, particularly the Mitsuharu version of Emacs (which everyone who uses Emacs with a pointing device on OS X should be using because the FSF version often has bugs that affect Emacs's integration with OS X's graphical subsystems) gets this "rightmost column of pixels" issue right. (Sublime Text and Atom are 2 more apps that do not get it right.)

So in summary, although Emacs looks like an ncurses- or terminal-interface app and not a native GUI-based app and although many Emacs users are vocal pointing-device skeptics, not all Emacs users are mouse-haters, and Emacs actually has very good support for pointing devices.

As the author notes, Emacs was an example.

The browser interface is terrible. We use bug tracking software. JIRA. It's horrible. Click here, click there, this screen closes, that one opens, this thing is over here. Ugh. It is just a click fest. For this sort of thing I want an MDI interface. I read a report - it sounds like one a duplicate. I want to search for it. I want to go to a search window, do the search, and compare them side by side. Or I want to look at the backlog and the current sprint.

Sure, to an extent I can open multiple browser windows or tabs, etc. This is another example. - one windows for everything you are trying to do is often cumbersome and terrible. You are forcing UI design on me, the user, every. frigging. time. I. use. your. app. I don't want to open 5 tabs to the same site, maneuver them around, deal with "going back requires page resubmission" warnings, let alone deal with sites that don't understand my 5 tabs are all one session in my mind. Don't make the user solve that problem every day they use your product.

That's the entire point of semantic web