Google tech talk on Node.js | Hacker News Reader

Google tech talk on Node.js

youtube.com

84 pointsmcantelon15 comments

I think this says a lot about Google, from the intro:

"The first time I heard about Node.js I thought, What a crazy guy he's trying to put JavaScript on the server when everybody is trying to put Java on the client"

Personally, I stopped trying to put Java on client in the mid-90s.

I think the comment was very Google specific. A couple of example projects there are GWT, which compiles Java into JavaScript, and Android, which uses the Java language compiled into Dalvik byte-code. In both cases, the Java language is being used although they aren't attempting to place or use Java (tm) VMs on the client site.

Node looks so promising. Every time I hear something about it I hit Google hoping that by now there's a Rails or Django for Node, but there always just seems to be a mass of 200-line projects, none of which I would be comfortable starting a project on.

EDIT: Look what I found: http://geddyjs.org/

Have you looked at Express[1]? It's a fairly complete and (by now) well fleshed-out framework, and it implements Connect[2], which is a middleware stack for Node.js. The only thing it lacks (and Geddy seems to have) is a way to manage models/validations.

[1] http://github.com/visionmedia/express

[2] http://github.com/senchalabs/connect

Have you gone through: http://wiki.github.com/ry/node/modules

I actually like the situation with node. Bunch of independent modules for middleware, ORM, routing etc that I can throw together myself. Less magic, more clarify of what does what.

I really don't see the point of using frameworks (libraries are fine). You should write your own. It's a lot easier than you think and you get full understanding and control of your request/response cycle. Learning and mastering somebody else's framework usually takes longer, and it may not solve your specific use case all the time.

It is nice for some things though, like static file server, gzip support, and other mundane things that you almost always want (or want the option to enable). I think a decent framework is unstructured (such as web.py) so you can write incredibly light quick and dirty apps or set up MVC for significant apps. It just helps you with the plumbing.

connect, geddy, and (fab) all look good for this purpose and I hope to look into them a bit more when I have a chance. For now I'm just gluing things together with node-machine at the core.

I really don't see the point of using cars (parts are fine). You should build your own. It's a lot easier than you think and you get full understand and control of your vehicle. Learning and mastering someone else's vehicle usually takes longer and it may not solve your specific transportation needs all the time.

Besides it being flat-out wrong that mastering a framework takes longer than building one (you will have to support it), the typical framework is a lot larger than the code of the applications built on top of them.

Building a framework is a bit like writing a DSL, a good framework abstracts out the work that would otherwise be duplicated many times over and will help to standardise the codebases of various projects and will help to allow integration of bits and pieces from different projects in a re-usable way.

There is a reason why rails, django, drupal and a bunch of others are wildly popular, they save people oodles of time.

Both the framework and no framework approaches have merit.

Choosing a framework limits your choices. If I'm using Django, it won't work (or work well) with a non-rel backend. If I'm using jQuery and I need to update one of the libraries (say jQuery UI) I might have to update jQuery as well, etc.

What you think saves oodles of times doesn't always. The odd bug, the odd crash etc that keeps popping up may have roots in the framework that you chose and that you're using without having knowledge of its internals. The framework might make your app much slower and cost you in terms of hardware.

Not using a framework is harder work initially, but with the right libraries it isn't that big of a leap. Picking up a smaller framework with libraries can be a surprisingly easy and a lot more flexible when your needs end up being different from what the framework intended.

Ofcourse, there is a flip side to it all and I understand your point :) Micro-frameworks are the best IMO, not the beasts that Rails/Django are.

This is awesome. There's also a great virtual panel on some of the most popular Node.js projects on GitHub. Here's the link: http://www.infoq.com/articles/nodejs-frameworks

The InfoQ panel gives a great overview. Thanks.

I'm all for the wild explosion of new tech, that said when the time rolls around to pick a toolset for building a new application I'll invariably do a step back and I'll pick something that has been around for a couple of years.

The reason is fairly simple, new stuff usually contains tons of bugs and it remains to be seen if it is still going to be around a few years down the road.

I'm a coward that way, but when my income is on the line I don't want to be beta testing someone else's code without having a very good chance that the problem I'm trying to find is mine and not some bug in underlying code.

For hobby stuff and learning I love to play around with new things, as soon as it is 'business' I'm a lot more conservative.

[ EDIT: Make sure you take node.js out for a little spin, you might like it :) ]

I agree with the general sentiment of playing it safe when your income is on the line, pecially because there's a lot of fanboyish hype around these projects.

However, its not just about "new tech", its about tech that works the way your mind works. Some things mature quickly and have the right mindset (Django, clojure, node.js, couchdb for me) and others have a longer/more painful learning cycle where the community struggles along with the leaders (rails (again, this is just my very personal understanding!)). Some things mature but don't align with what you think is right (php, java).

I've found node.js to be special. It has gained maturity relatively quickly, the libraries seem to be lightweight, good quality, its a language that will run both on the server and the browser (hello code reuse).

I'm somewhat involved in the development of Node. It's a fast-moving project, with the occasional bug and an API that is still in flux. You might not want to build your billion dollar enterprise on it and one could hardly blame you.

That being said, Node has a strong community and a lot of momentum. There are some big name companies like Yahoo and Plurk that use Node today to build stuff that matters.

Ok, I'll take it for a test drive.

Reply on news.ycombinator.com