

Interview with Ryan Dahl on node.js - olegp
http://dailyjs.com/2010/08/10/ryan-dahl-interview/

======
gruseom
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).

~~~
jacquesm
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.

~~~
gruseom
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!

~~~
jacquesm
> 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.

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

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

~~~
dstein
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.

~~~
mdg
>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).

~~~
bobfunk
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...

~~~
mdg
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.

