Hacker News Reader

Comment by naikrovek | Hacker News Reader

amazing. This used to be called /cgi-bin/ with templates and XMLHttpRequest (a Microsoft invention initially supported only in IE then adopted by everyone) and now it's suddenly a new technology/approach but with a new name so you're not ridiculed for using it?

I gotta give them credit for revisiting server-side page assembling though; moving application logic and templating mostly to the front end was a HUGE mistake. JS is very fast now, but it's still absolutely glacial in its speed compared to server-side code written in compiled languages.

View on HN

> and now it's suddenly a new technology/approach

I don't think I've ever seen DHH or the Basecamp crew advertise any of this type of stuff as some groundbreaking new approach that nobody has ever tried before. On the contrary, I usually see them talking about how those old ways of doing web development were actually better in many ways, which is why they're pushing to move away from the current "everything is an SPA" approach.

And all this new tooling makes the experience much better than it ever was in the past.

>I don't think I've ever seen DHH or the Basecamp crew advertise any of this type of stuff as some groundbreaking new approach that nobody has ever tried before

Not disagreeing with the rest of the stuff. But they literally call it "NEW MAGIC" per DHH's tweet.

Yeah that's fair

cgi-bin didn’t give you the ability to update a chat page across several different windows in near real-time.

It did if you used XMLHttpRequest.

If you type a chat message in your browser, how does it automatically show up in my browser with XMLHttpRequest?

In old school chat rooms, this was usually done by polling for new messages every X seconds, or doing a refresh / reload of an IFrame containing the chat.

I know, I wrote many of those, it’s a much worse solution than this.

Long Polling is how we used to do it. The web page opens a request to the server but the server does not reply. Once the event happens on the server, the server replies to the old request and the client opens a new request.

Yup, this is much better than that, and nicely integrated for you.

I think in Netscape 4 you could also make a request in an iframe which the server responded to with Content-Type: application/javascript and Transfer-Encoding: chunked. Then every time the server got an event it would write one chunk of javascript, which the client would execute immediately. This script could then call a callback in the parent frame.

> cgi-bin didn’t give you the ability to update a chat page across several different windows in near real-time.

Servers could maintain an open connection and stream new data to the browser.

That was a much worse solution, and even worse with cgi-bin.

Sometimes worse is better.

in no way elegant, but yes, with js, it's possible with netscape 3 and up, possibly with 2.

html, http, js, css are pretty thorough in their design, and it shows.

all the features described here are possible without any frameworks, this is merely a much easier way to build it than from scratch.

Yes, but I was replying to someone who said that we got all of this with cgi-bin. That’s like saying, “I can code a modern app in assembly, therefore there’s been no progress here”.

Reply on news.ycombinator.com