Live data from Hacker News

Interview with Ryan Dahl, Creator of Node.js

mappingthejourney.com

21–30 of 235 posts

Re: Interview with Ryan Dahl, Creator of Node.js

#21
post #15
post #3

Earlier quoted context omitted.

Agree. It takes a lot to walk away from something and say you were wrong. But, sadly, part of the saga of nodejs could have been avoided by people looking at the history of computing. If you look at Go's concurrency model it was entirely mapped out in the 1970s in CSP. There wasn't really any need for go the 'single thread, non-blocking' route that nodejs took and evangelize it as nirvana. There was a ton of distribu…

> If you look at Go's concurrency model it was entirely mapped out in the 1970s Isn't that Go's problem, though — that there isn't a single thing in the language that wasn't entierly mapped out in the 1970s?

Using ideas from history isn't a problem. And Go is unique in that it combined all these learned lessons into something new.

Re: Interview with Ryan Dahl, Creator of Node.js

#22
post #3
post #2

> That said, I think Node is not the best system to build a massive server web. I would definitely use Go for that. And honestly, that's basically the reason why I left Node. It was the realization that: oh, actually, this is not the best server side system ever. Really interesting. I can imagine others would refuse to give up on the thing they'd worked so hard on. But Dahl has the self-awareness to just step back an…

Agree. It takes a lot to walk away from something and say you were wrong. But, sadly, part of the saga of nodejs could have been avoided by people looking at the history of computing. If you look at Go's concurrency model it was entirely mapped out in the 1970s in CSP. There wasn't really any need for go the 'single thread, non-blocking' route that nodejs took and evangelize it as nirvana. There was a ton of distribu…

You couldn't have got CSP from writing a web server API to run with V8.

To get CSP you needed green threading built into the runtime, and that's a much taller order.

So it's hard to say that the not-critizing-directly Dahl should have learned from the past. We'd probably never have heard of him if he'd set out to build a new esoteric CSP language or runtime, just like we haven't heard of anyone around that time other than the golang team.

Re: Interview with Ryan Dahl, Creator of Node.js

#23
A serious problem with Node was the callback pyramid of doom.

This means deeply nested callbacks such that the indentation wanders steeply to the right. When you do loops or have exceptions programming got very confusing. In effect you have to do a continuation passing transform. It's not difficult but the results are utterly unreadable. For example a simple for loop could be transformed into recursive function because this way it is easier to keep state between callbacks. It's a nightmare.

What I found surprising in the early years of Node that some people in the mailing list had a «Real programmers don't use Pascal» attitude.

Bruno Jouhier's developed streamline to simplify and automate the continuation passing transform. One could almost program in a «blocking» style. I found his work really amazing. However for that Bruno got attacked in the mailing list.

Then Marcel Laverdet developed fibers. A different and equivalent way to solve the callback pyramid are fibers, coroutines and generators. This way we don't need the continuation passing transform. But the reception in the mailing list was at best only lukewarm. Anyway, the developers of Meteor saw the potential and decided to base the server side of the platform on fibers.

And now JavaScript has generators and async/await. And lo and behold: with these official solutions the hard core programmers swayed and accepted «Pascal».

In my opinion, Ryan Dahl has missed an opportunity. Node was by large not ready and finished when he left. He should have tried to convince the community to find a solution for the callback hell.

I think I understand people like him. They are always on the lookout for fresh ideas.

Re: Interview with Ryan Dahl, Creator of Node.js

#24
post #14

Earlier quoted context omitted.

The fact that Node survives as a platform for Fullstack JavaScript shows how serendipity works in invention: he set out to build a high performance network server and ended up building one of the largest platforms for building web applications. The reasons it ended being very big are clear in hindsight but are hard to predict: - Sharing code between server and client - Server side rendering - Lower barrier to entry t…

What do people mean when they keep saying "server side rendering" in this specific Javascript/Node.js context? I ask because I've seen quite a few people tout that term as a recent innovation. It was my understanding that "server side rendering" was the way the web worked since the beginning, with the server generating the markup that is provided to the browser to render the page. Nobody called it "server side render…

It means you take your client side JavaScript code and render it on the server for performance and SEO.

Previously you had to either duplicate the code in different languages or pick one or the other (either use angular or rails).

Re: Interview with Ryan Dahl, Creator of Node.js

#25
post #2

> That said, I think Node is not the best system to build a massive server web. I would definitely use Go for that. And honestly, that's basically the reason why I left Node. It was the realization that: oh, actually, this is not the best server side system ever. Really interesting. I can imagine others would refuse to give up on the thing they'd worked so hard on. But Dahl has the self-awareness to just step back an…

Well he does work for Google. We don't know if there is any pressure for him to be be a Govangelist .

I see what you mean, but as a similar example, I never thought anyone at Google wouldn't use Google for search, but some use DuckDuckGo -- https://news.ycombinator.com/item?id=15068047

Plus, he said he was using Go before he joined Google.

Re: Interview with Ryan Dahl, Creator of Node.js

#26
post #24

Earlier quoted context omitted.

What do people mean when they keep saying "server side rendering" in this specific Javascript/Node.js context? I ask because I've seen quite a few people tout that term as a recent innovation. It was my understanding that "server side rendering" was the way the web worked since the beginning, with the server generating the markup that is provided to the browser to render the page. Nobody called it "server side render…

It means you take your client side JavaScript code and render it on the server for performance and SEO. Previously you had to either duplicate the code in different languages or pick one or the other (either use angular or rails).

Not just that, but to accomplish it means that you need to provide the correct client-side APIs on the server side, so that your code renders the same in both places. Doing this nicely is a lot of work.

Re: Interview with Ryan Dahl, Creator of Node.js

#27
post #24

Earlier quoted context omitted.

What do people mean when they keep saying "server side rendering" in this specific Javascript/Node.js context? I ask because I've seen quite a few people tout that term as a recent innovation. It was my understanding that "server side rendering" was the way the web worked since the beginning, with the server generating the markup that is provided to the browser to render the page. Nobody called it "server side render…

It means you take your client side JavaScript code and render it on the server for performance and SEO. Previously you had to either duplicate the code in different languages or pick one or the other (either use angular or rails).

Running the same language on the client and the server also has some deeper implications. Like, it becomes easy to imagine an app that runs in a hybrid way with computations shared between the client and server, i.e., "offline mode". This is a pretty big deal, and it's one of the major benefits mostly ignored by the vocal critics of "single-page apps," as seen in the latest article on the HN front page.

Re: Interview with Ryan Dahl, Creator of Node.js

#28
post #14

Earlier quoted context omitted.

The fact that Node survives as a platform for Fullstack JavaScript shows how serendipity works in invention: he set out to build a high performance network server and ended up building one of the largest platforms for building web applications. The reasons it ended being very big are clear in hindsight but are hard to predict: - Sharing code between server and client - Server side rendering - Lower barrier to entry t…

What do people mean when they keep saying "server side rendering" in this specific Javascript/Node.js context? I ask because I've seen quite a few people tout that term as a recent innovation. It was my understanding that "server side rendering" was the way the web worked since the beginning, with the server generating the markup that is provided to the browser to render the page. Nobody called it "server side render…

They're referring to the ability to execute the same code on the client and server and get the same output, which can provide a great deal of flexibility when optimizing for performance.

Re: Interview with Ryan Dahl, Creator of Node.js

#29
post #14

Earlier quoted context omitted.

The fact that Node survives as a platform for Fullstack JavaScript shows how serendipity works in invention: he set out to build a high performance network server and ended up building one of the largest platforms for building web applications. The reasons it ended being very big are clear in hindsight but are hard to predict: - Sharing code between server and client - Server side rendering - Lower barrier to entry t…

What do people mean when they keep saying "server side rendering" in this specific Javascript/Node.js context? I ask because I've seen quite a few people tout that term as a recent innovation. It was my understanding that "server side rendering" was the way the web worked since the beginning, with the server generating the markup that is provided to the browser to render the page. Nobody called it "server side render…

Potentially a better term is "isomorphic", a label which is specifically applied to setups where you run the same rendering code client-side and server-side. That's still a comparatively new concept, at least as something that's actively supported by frameworks and reasonably straightforward to implement.

Re: Interview with Ryan Dahl, Creator of Node.js

#30
post #17
post #15

Earlier quoted context omitted.

> If you look at Go's concurrency model it was entirely mapped out in the 1970s Isn't that Go's problem, though — that there isn't a single thing in the language that wasn't entierly mapped out in the 1970s?

It is only a problem to someone whose thought process dictates anything old is bad and anything new is good.

> It is only a problem to someone whose thought process dictates anything old is bad and anything new is good.

What do you call new? generic programming, nullable types, type classes? all pioneered around 1973? Can you explain what "new" is?

Post reply on HN