Interview with Ryan Dahl on node.js | Hacker News Reader

Interview with Ryan Dahl on node.js

dailyjs.com

66 pointsolegp18 comments

If node.js were just another framework, it wouldn't be very interesting. But from what I've seen so far, it's more exciting: an abstraction over the OS that factors out the machine-your-own-screws details of C while otherwise leaving the model intact. That is, instead of a top-down design that replaces the OS's low-level ways with something else and then maps between the two, it's a bottom-up design that attempts not to change anything important about the way the lower level works. This I think is what Ryan means when he says he's suspicious of abstraction. The result is something more like "the ability to write C programs in Javascript" than "a better web framework". This strikes me as powerful and capable of evolving in some interesting directions.

Bottom-up design is not common. But it should be. Done well, it's a way to have your cake (abstraction) and eat it too (performance).

Every time you roll a DSL you're doing bottom-up design. The real problem underlying all of this is that our DSL of choice (HTML) sucks at being used to build user interfaces with.

I'm not sure if it is possible to extend HTML to the point where you could do what you can do with javascript (or even if that would be desirable) though.

That depends on what you mean by DSL. The term is overused, poorly defined, and I haven't seen very many interesting instances of it anyway. I certainly wouldn't describe HTML as a DSL. It doesn't suck for building UIs to such an extent that it didn't take over the world. Who on earth would want to turn HTML into JS? And what does this have to do with Node? There, I've disagreed with everything you said!

> There, I've disagreed with everything you said!

To me a domain specific language is a language that has been created on top of another in order to get 'closer' to the problem that is to be solved. HTML is layered on top of XML so I think that warrants calling it a DSL. It also is domain specific in a secondary sense in that it is targeted specifically at communicating layout to a terminal. (layout being the domain). Today that's handled partly by css by I think the principle remains. Javascript has become popular because of being embedded in HTML, now we see it ported to the server side.

> It doesn't suck for building UIs to such an extent that it didn't take over the world.

That's a lot of negations. It is used for building UIs in the same way that we use C to build operating systems, so far we've yet to find something that does a much better job. But javascript feels like a hack to make the browser do things that HTML currently can not, and to see it on the server feels a bit weird (even though it has obvious advantages, one less language to worry about).

With every new iteration of the HTML standard lots of stuff that previously was only possible using javascript hacks becomes part of the HTML spec. I can imagine for instance a 'validchars' property of an input field that would immediately validate characters typed in and would refuse characters illegal for that field. But I think that right now the only way to do that is to use a bit of javascript, and that may be disabled.

What it has to do with node is that node is yet another way of extending the capabilities of the brower, but this time in concert with server side code in a non-standard way that would be better handled by finding a generalized method.

I spent a lot of time building a javascript powered chat environment that would show users as avatars on other peoples website (so you could go 'group surfing' as well as to give guided tours and to interact with other public visiting a website) only to find it broken beyond repair in the next browser iteration.

Most HTML is here to stay and things that are deprecated are usually easily fixable.

I'm not saying 'node' will break beyond repair next week (it's server side after all) but I've learned my lesson (that was 4 months work down the toilet) well enough to be a bit more weary now, JS is an environment that is still very much in development.

It's fun to play with, that's for sure.

Part 2 of the interview is now online: http://dailyjs.com/2010/08/11/ryan-dahl-part-2/

I don't really know much about node.js other than casual reading about it. Is there a use case for it for developers who know Twisted / EventMachine well? In other words, can it provide something those frameworks can't?

Node and its ecology of libraries are asynchronous from the ground up. With Twisted or EventMachine, you'll eventually call a library that performs blocking I/O (probably sooner than later) and that will be your bottleneck.

With Twisted at least there are usually asynchronous versions of commonly needed libraries. Given that, it sounds like they're probably fairly analogous then, right? I assume Node will have the same problem the moment someone grabs a package that's meant for a Javascript framework that isn't explicitly asynchronous.

That is correct.

There aren't really Javascript frameworks that aren't explicitly asynchronous.

- The browser-based APIs are all asynchronous

- The other serverside JavaScript libraries will rely on blocking APIs that aren't supported in Node.JS, so they won't work.

Performance aside, being able to write both client and server code in the same language has a lot of advantages. After seeing how well the NodeChat worked at twich.me, I am definitely interested in trying it out. I think building a real-time networked game entirely in JS would be kinda fun.

Here's a link that might interest you then. Real-time Node.js Asteroids, written in CoffeeScript.

Lazeroids.com: http://lazeroids.com/

Here's the source:

http://github.com/gerad/lazeroids-node/blob/master/views/app...

>being able to write both client and server code in the same language has a lot of advantages.

Instead of html + css + sql + js + (python, ruby, [FotM]) its just html + css + sql + js? I would not be surprised to see html + css + sql + js (dom manipulation) + js (server side). The only benefit I see is that one could re-use their input validation.

Are there any examples of this in the wild? I have heard many claim that using JS on both sides is a big win, but have yet to come across anyone actually doing it (genuine question, it is something I would like to take notes from).

http://twich.me (based on http://chat.nodejs.org/) was the first live Node app that I've seen.

There is also tempalias by one of the HNrs.

http://tempalias.com/#/

A very handy app indeed.

I use it on both sides (client and server). There's some code sharing between server and client side, but it's not a huge productivity boost that one should switch to a language they may not be comfortable with on the server side.

Organizing your code into smaller modules is probably more important in Node.js than most other frameworks if you want to keep your sanity. Otherwise you'll end up with crazy arrow code due to all the callbacks.

The speed that you gain from sharing the same language, you lose in the inability to write shorter code (Python/Ruby) and debugging callbacks. I think it's good to be language agnostic and have some sort of http rpc interface system to communicate between the languages.

I have some experience with sharing js libraries between server side and client side. It can be nice but comes at a price:

you'll bring all the problems of client side javascript to the serverside without any of the nice client side js-frameworks that makes cross-browser coding more sane.

We're using rhino serverside with the latest CSV version giving us full ECMAScript 5 compatibility on the serverside - but for the parts that are also used clientside we can forget about all the nice features of Rhino. For our clientside code we're using jQuery, but again, when sharing with the server we can forget about all of jQuery's utility methods and so on...

It's worth doing but it is not at all as smooth as it could be...

I'm using Rhino + jQuery + env.js + Postgres for processing html and it works great. None of the code will ever need to run on the client so being in total control of the environment is liberating.

Oddly, jslint.js is just fine on either end of the spectrum, but probably isn't intended for your end-user.

Reply on news.ycombinator.com