Case study: How & why to build consumer apps with Node.js | Hacker News Reader

Case study: How & why to build consumer apps with Node.js

venturebeat.com

50 pointsjolie15 comments

Come on, let's stop the Node.js ridiculous hype already.

1. It's JavaScript! JavaScript is a terrible language. The fact that you need to read "JavaScript: The GOod Parts" in order to use the damn thing is an indicator of that.

I don't care that it's supposedly "lispy."

2. Code re-use at every level

Does any project actually do this? Is there any sort of front-end library that actually works both in Node and in the browser? It seems like more of a pipe dream to me. An awesome idea, for sure, but never actually implemented in practice.

3. Strong, responsive and enthusiastic community

This is moot if there aren't good libraries available. There are, but other platforms have far better ones available and I wouldn't count this as a plus for Node.

Maybe you're talking about Reddit or HN headlines, though.

4. Large productivity gains in HTML & CSS using Jade & Stylus

Never used them, but finding a library or framework that works for you is awesome.

5. Wealth of hosting options: No.de, Joyent’s SmartMachine, Heroku, Nodejitsu

You can say the same thing about PHP too. That doesn't make it a good reason to use it.

6. Make your developers famous

Seriously?

7. Developer happiness

HN fame?

I too hate Javascript, but mostly because it is not a language suited to go above a few houndred lines of code -- it is awesome to quickly add some interaction to a website.

That said, Node.js is really well designed. I just wish it was done with some other less dynamic language.

JavaScript can easily go over a few hundred lines of code. Sure, you need to be organized about it, and if you aren't you quickly can devolve into a mess of nested callbacks and fragile function calls.

But with a little forethought as you write your code, you can write very complex programs with JavaScript and still have a very readable code-base.

I think that Node.js should have been implemented in a language that supports generators or coroutines as it's a more natural paradigm than callbacks.

I also think that rather than passing in callbacks, functions that do I/O should return Deferreds which allow for more elegant error handling and better flow control.

Regarding point 2: http://developer.yahoo.com/blogs/ydn/posts/2011/11/yahoo-ann... http://geddyjs.org/ and _many_ other diy projects (search for backbone code reuse, for eg).

The rest if it; yeah... well that's just like, your opinion, man.

re: #1 - JavaScript is a very accessible language, and as such, there is a TON of bad code and examples. The fact that people write bad code doesn't make it a bad language, that is your opinion of the language and you are entitled to that but I would argue that opinion. Many people write high-quality code using JavaScript every day, and it can be a very elegant language.

Sure, there are bad examples, but it is still a terrible language. It has a horrific type system, encourages the use of globals, is the epitome of TMTOWTDI to the point where there's still no standardized module/object system which impedes collaboration and lacks language features like operator overloading that are present in most mainstream languages today.

I'm not saying you can't write good, elegant code in JS, I'm just saying that you have to fight the language to do it.

With PHP and PostgreSQL we could scale up, but it felt really hard and gave us many sleepless nights. Using Node.js with a MongoDB backend scaling up is quick and easy; but because Node can handle more traffic, you don’t need to as quickly.

It's interesting to read an experience where Node's performance largely pays off when building traditional sites. I've often read that Node's performance really only pays off when building realtime apps. Maybe I misinterpreted, perhaps it was meant more as the large set of features provided by frameworks like Rails/Django transcend Node's performance boost?

In short, even "traditional" apps now actually have to do quite a lot of IO, and the ability to cram a large number of requests into a single process can have a dramatic increase in efficiency. If your ruby/php applications are memory bound, you might see a huge increase in availability by switching to node (or any shared-memory concurrency model).

There is no Rails equivalent in node, and in general I would say the community is focused on writing code at a slightly lower level than the high level frameworks you might be used to. But if you feel like you've internalized the RESTful MCV design, you may find the performance increase worth the lack of handrails.

We pivoted from being a Drupal shop to being a Node.js shop just over a year ago. I don't think a single one of us has regretted that decision.

Aren't Drupal and Node at vastly different levels of abstraction? I gather that Drupal is vaguely akin to a souped-up WordPress while Node is a fairly low-level server.

Did you start writing lower-level code, or are you using some sort of extensive stack on top of Node?

Having worked quite a bit in the Drupal world, since 4.6, I demand more info :)

Node and Drupal are completely different beasts. Did you write a new system built on Node, that duplicates what you get with Drupal? Is any of your code public, so others can look into it?

I'm not the parent, but I have a similar story. I know numerous drupal people who are now doing node.js work. There is a great desire to make a 'drupal for node.js'. Hasn't quite been accomplished yet, but I know many people who have something that might amount to smallcore for node. I know I do. It's very difficult to actually publish usable code though.

Are you the guys who created OpenAtrium?

Exactly the same move here. We created ~2 dozen drupal sites and went to node.js in early 2011. There was about 4-5 months of learning curve, where we almost went back to drupal. The low level of abstraction in node.js resulted in some loss of productivity during that time. But over that time we stitched together sufficient little pieces of CMS capability that we have now fully recovered. And the benefits of working with node.js and javascript over php is pretty huge.

Our only regret now is not having moved to node.js sooner.

Reply on news.ycombinator.com