Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interview with Ryan Dahl, Creator of Node.js

mappingthejourney.com

Post reply on HN
Print view View original

11–20 of 235 posts

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

#11

Post by peterbraden »

jgrahamc wrote: post #3
s_kilk wrote: 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…

While I agree that non-blocking isn't a panacea, I think that your attitude that it was an unnecessary experiment is a little dismissive.

The fact is that green threads aren't a panacea either, and exploring the callback based pattern led to some really interesting development, evidenced by the explosion of javascript on the server .

At the time that node took off, a huge amount of server code was python with the GIL, and there needed to be something to shake up the status quo.

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

#12

Post by [deleted] »

jgrahamc wrote: post #3
s_kilk wrote: 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…

[deleted]

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

#14

Post by amasad »

jgrahamc wrote: post #3
s_kilk wrote: 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…

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 than other platforms (learn once write anywhere)

- Well-designed package system

It was also helped by the fact that folks decided to write JS tooling in JS, be it minifier, transpilers, or test runners, without nodejs we would've built then on top of something else.

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

#15

Post by erokar »

jgrahamc wrote: post #3
s_kilk wrote: 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…

> 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?

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

#17

Post by geodel »

erokar wrote: post #15
jgrahamc wrote: 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?

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

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

#19

Post by dsacco »

I find it interesting that he ended up at Google Brain working on deep learning research after writing Node. There seems to be a trend in the industry of taking people who are exceptional in one area and putting them on AI problems (e.g. Chris Lattner). I wonder how effective that cross pollination is.

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

#20

Post by thehardsphere »

amasad wrote: post #14
jgrahamc wrote: 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…

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 rendering" until we had "client side rendering", where Javascript executed in the browser provided the markup instead of whatever program was running on the server.

I'm not trying to lecture or be snarky here; I'm genuinely confused as to what people mean when they say "server side rendering" as a new thing. Like, is there something novel that I'm missing because the term is overloaded with a definition I don't know?

Post reply on HN