Node.js - Convincing the boss guide(nodeguide.com)
nodeguide.com
Node.js - Convincing the boss guide
http://nodeguide.com/convincing_the_boss.html
17 comments
"Excitement and enthusiasm for something new" was left off that list for a very good reason: it's a terrible reason to pick a technology like node (or anything else).
In fact, I'd go so far as to say that enthusiasm for mere new-ness is one of the more pernicious, counter-productive parts of modern hacker culture. Rich Hickey implied this at his RailsConf keynote when he talked about how great we are at judging benefits, but terrible at judging trade-offs. Here's a man who's certainly not afraid of newness itself (I mean, he single-handedly released a new JVM hosted LISP) but I think he has his head in the right place about the cost of new, and what something must provide to justify that cost.
For example, it makes absolutely no sense to use Node and then layer on top of it a web framework that is an isomorphism from some other environment.
Last but not least, I think the key reason we have different perspectives is age. Hickey and I are about the same age. I assert that anyone who trumpets the inherent value of "new" hasn't been around long enough to understand that there is a never-ending stream of new things and that, as Teddy Sturgeon famously quipped, 90% of everything is crap.
The real market for technology adoption should fueled by demand for simplicity, rather than demand new-ness (something else Hickey strongly implied in his talk).
In fact, I'd go so far as to say that enthusiasm for mere new-ness is one of the more pernicious, counter-productive parts of modern hacker culture. Rich Hickey implied this at his RailsConf keynote when he talked about how great we are at judging benefits, but terrible at judging trade-offs. Here's a man who's certainly not afraid of newness itself (I mean, he single-handedly released a new JVM hosted LISP) but I think he has his head in the right place about the cost of new, and what something must provide to justify that cost.
For example, it makes absolutely no sense to use Node and then layer on top of it a web framework that is an isomorphism from some other environment.
Last but not least, I think the key reason we have different perspectives is age. Hickey and I are about the same age. I assert that anyone who trumpets the inherent value of "new" hasn't been around long enough to understand that there is a never-ending stream of new things and that, as Teddy Sturgeon famously quipped, 90% of everything is crap.
The real market for technology adoption should fueled by demand for simplicity, rather than demand new-ness (something else Hickey strongly implied in his talk).
I carefully avoided making the statement you've just deconstructed. Nothing in my original post mentions newness.
The point I made is that enthusiastic and excited developers are valuable. Developers tend to find learning exciting. They could be interested in learning Rails or Django for the first time, trying out Sinatra when a full Rails app seems overkill, or exploring Node for a small and non-critical part of your architecture. Hell, they might be excited about learning PHP.
Allowing people to explore their curiosity brings material benefits. It doesn't have to involve new technology, and I didn't suggest that it does.
As an aside:
> The real market for technology adoption should fueled by demand for simplicity, rather than demand new-ness
I think part of node's mass appeal is that it has introduced an element of simplicity to a generation of developers who have grown up around bloat.
The point I made is that enthusiastic and excited developers are valuable. Developers tend to find learning exciting. They could be interested in learning Rails or Django for the first time, trying out Sinatra when a full Rails app seems overkill, or exploring Node for a small and non-critical part of your architecture. Hell, they might be excited about learning PHP.
Allowing people to explore their curiosity brings material benefits. It doesn't have to involve new technology, and I didn't suggest that it does.
As an aside:
> The real market for technology adoption should fueled by demand for simplicity, rather than demand new-ness
I think part of node's mass appeal is that it has introduced an element of simplicity to a generation of developers who have grown up around bloat.
If only a group of more than 5 developers were enthusiastic about the same thing! Your enthusiasm for node is another persons pain. I've got 1 coder enthusiastic about node, another for clojure, and another for scala. Should every project be a different language and ecosystem? What happens when programmers move around in an organization.
"I think part of node's mass appeal is that it has introduced an element of simplicity to a generation of developers who have grown up around bloat."
Who are you talking about? Right now I'm dealing with a generation of programmers that came up on ruby. Node isn't simpler than sinatra. In fact, we just tried to use node for a "small and non-critical part of your architecture". You know what happened? It took much much longer to finish because it needed to talk to an API that uses digest authentication and node's http library doesn't support that so we had to roll our own.
"I think part of node's mass appeal is that it has introduced an element of simplicity to a generation of developers who have grown up around bloat."
Who are you talking about? Right now I'm dealing with a generation of programmers that came up on ruby. Node isn't simpler than sinatra. In fact, we just tried to use node for a "small and non-critical part of your architecture". You know what happened? It took much much longer to finish because it needed to talk to an API that uses digest authentication and node's http library doesn't support that so we had to roll our own.
Does node let you use things like libcurl? I only ask because there are libraries which already have that implemented. I don't use node so I have no idea if it can hook into system-level stuff like that.
The difference is that it's a 5 minute thing in ruby with any of the major http libraries. Is libcurl evented? No matter how you slice that cake, it's a lot more than 5 minutes of effort.
>I carefully avoided making the statement you've just deconstructed.
Perhaps you carefully avoid it, but you also strongly implied it. Consider:
>You're lucky enough to live at a time where there are numerous production-ready tools with which to do your job. If you choose a tool that you're excited to explore, with an active and fast-moving ecosystem, your excitement and enthusiasm will make you happier and more likely to do a better job.
You're optimizing for programmer excitement. There's a famous graph of programmer excitement curves floating around on the net, with a peak at "new and shiny" stage.
>Developers tend to find learning exciting. They could be interested in learning Rails or Django for the first time, trying out Sinatra when a full Rails app seems overkill, or exploring Node for a small and non-critical part of your architecture. Hell, they might be excited about learning PHP.
I'm not arguing the truth of what you're saying - it's obviously, painfully true that developers absolutely love trying out the new hotness (sometimes even if it's just new to them). I'm simply asserting that this is bad.
Perhaps you carefully avoid it, but you also strongly implied it. Consider:
>You're lucky enough to live at a time where there are numerous production-ready tools with which to do your job. If you choose a tool that you're excited to explore, with an active and fast-moving ecosystem, your excitement and enthusiasm will make you happier and more likely to do a better job.
You're optimizing for programmer excitement. There's a famous graph of programmer excitement curves floating around on the net, with a peak at "new and shiny" stage.
>Developers tend to find learning exciting. They could be interested in learning Rails or Django for the first time, trying out Sinatra when a full Rails app seems overkill, or exploring Node for a small and non-critical part of your architecture. Hell, they might be excited about learning PHP.
I'm not arguing the truth of what you're saying - it's obviously, painfully true that developers absolutely love trying out the new hotness (sometimes even if it's just new to them). I'm simply asserting that this is bad.
> You're optimizing for programmer excitement. There's a famous graph of programmer excitement curves floating around on the net, with a peak at "new and shiny" stage.
I at no point said that this should be the overriding factor. I said that the need to consider developers' personal goals is often understated, and is one of many pieces of information worth weighing when making a decision.
I at no point said that this should be the overriding factor. I said that the need to consider developers' personal goals is often understated, and is one of many pieces of information worth weighing when making a decision.
This wasn't what I got from Rich Hickey's talk. I understood him to be saying that, while of course you shouldn't use something just because it's new, you should use whatever will make your code simpler, even if there's a learning curve.
That to me was the point of his "easy" vs. "simple" dichotomy. Using the tools you happen to be familiar with is doing what's easy for the developer. Hickey argued that you should instead accept a bit of a learning curve if it will simplify your program in the end.
Now, I've never used Node, so no idea if it simplifies or complects web programming. (My current projects are in Haskell/Snap; so you can guess how I feel about learning curves.)
That to me was the point of his "easy" vs. "simple" dichotomy. Using the tools you happen to be familiar with is doing what's easy for the developer. Hickey argued that you should instead accept a bit of a learning curve if it will simplify your program in the end.
Now, I've never used Node, so no idea if it simplifies or complects web programming. (My current projects are in Haskell/Snap; so you can guess how I feel about learning curves.)
Here's a man who's certainly not afraid of newness itself (I mean, he single-handedly released a new JVM hosted LISP)
Though, I note that at the time, those were two mature and and well pedigreed technologies.
I assert that anyone who trumpets the inherent value of "new" hasn't been around long enough to understand that there is a never-ending stream of new things and that, as Teddy Sturgeon famously quipped, 90% of everything is crap.
A big reason for that are "pop cultures," which are defined as cultures/sub-cultures whose rate of change far outraces their rate of actual progress. Unfortunately, programming as a whole is one of those things.
Though, I note that at the time, those were two mature and and well pedigreed technologies.
I assert that anyone who trumpets the inherent value of "new" hasn't been around long enough to understand that there is a never-ending stream of new things and that, as Teddy Sturgeon famously quipped, 90% of everything is crap.
A big reason for that are "pop cultures," which are defined as cultures/sub-cultures whose rate of change far outraces their rate of actual progress. Unfortunately, programming as a whole is one of those things.
As as boss, I understand that happy employees are a good thing for everyone, but similarly it is not enough to convince me to use what I see as a seriously substandard solution.
From my point of view, Node.js is shaping up to be the php of 2012. It's proponents claim it's easy and fun and it's in a language that they are comfortable with. Meanwhile it's detractors see no real advantage over existing or other upcoming languages. Don't get me wrong, I'm not claiming it's quite as bad as php as that's something very hard to achieve, but equally I feel there are much better solutions.
I'm not at all against new languages, but I'd sooner invest in a new language that brings something more serious to the table. Perhaps the language is more concise so that we can write less code. Perhaps it's really clean with high performance and a steller C FFI. Maybe it leverages exiting mature eco-systems of software such as the .Net or JVM stack. Do you not find Scala, Python, or Clojure fun? I would hope you do!
From my point of view, Node.js is shaping up to be the php of 2012. It's proponents claim it's easy and fun and it's in a language that they are comfortable with. Meanwhile it's detractors see no real advantage over existing or other upcoming languages. Don't get me wrong, I'm not claiming it's quite as bad as php as that's something very hard to achieve, but equally I feel there are much better solutions.
I'm not at all against new languages, but I'd sooner invest in a new language that brings something more serious to the table. Perhaps the language is more concise so that we can write less code. Perhaps it's really clean with high performance and a steller C FFI. Maybe it leverages exiting mature eco-systems of software such as the .Net or JVM stack. Do you not find Scala, Python, or Clojure fun? I would hope you do!
The majority of my free time goes into the Ruby/Rails ecosystem, but I decided to finally jump into javascript for real and force myself to grok things like closures and context (still strugglin'!) the past month.
Node isn't a new language. It's javascript. Node just gives javascript the rest of the web stack, conventions, and a package manager that feels like Ruby gems. Javascript already is the best solution for all the problems we're currently forced to use javascript for. It's the language the browser understands.
I'm not here to be Node's white knight, but Node isn't just Yet Another Thing or Yet Another Language. It's javascript and, to me, it's making javascript into a language with an ecosystem similar to what I'm used to with Ruby. Javascript is already out there in the wild solving problems that Ruby/Python/Clojure can't.
Node isn't a new language. It's javascript. Node just gives javascript the rest of the web stack, conventions, and a package manager that feels like Ruby gems. Javascript already is the best solution for all the problems we're currently forced to use javascript for. It's the language the browser understands.
I'm not here to be Node's white knight, but Node isn't just Yet Another Thing or Yet Another Language. It's javascript and, to me, it's making javascript into a language with an ecosystem similar to what I'm used to with Ruby. Javascript is already out there in the wild solving problems that Ruby/Python/Clojure can't.
[deleted]
Javascript is already out there in the wild solving problems that Ruby/Python/Clojure can't.
Examples?
Examples?
The entire front end side, for starters
Most companies already use multiple language, and for good reason as not all languages are suitable in all cases. The idea of having a single language everywhere is nice, but in practice this forces you into substandard solutions in some contexts. This is not a compelling argument for me.
However, if you really do insist on having one language everywhere, you can also compile Clojure down to Javascript using a subset of Clojure called ClojureScript.Unlike Coffeescript, ClojureScript uses Clojure semantics and is not just a different syntax for Javascript.
This doesn't save you from all the odd performance edge cases of Javascript, but at least it gives you conciseness and semantics of Lisp in the one situation where you have no choice of language: the browser.
However, if you really do insist on having one language everywhere, you can also compile Clojure down to Javascript using a subset of Clojure called ClojureScript.Unlike Coffeescript, ClojureScript uses Clojure semantics and is not just a different syntax for Javascript.
This doesn't save you from all the odd performance edge cases of Javascript, but at least it gives you conciseness and semantics of Lisp in the one situation where you have no choice of language: the browser.
After reading all the posts in this thread I found another thing that is fascinating with node:
The community
It feels like Rails in its beginning—so many talented folks providing great solutions. Just check Express and related npms like Jade, Stylus, etc. They look like similar Ruby gems but if you look into the details you see people that go further and pushes the boundaries.
Some examples: just check how beautiful designed the Express error messages are—nothing crucial but it feels good working with people who are passionate. Or check how lean Stylus is compared to SASS, LESS, SCSS or how Jade goes beyond HAML with mixins etc.
It's hard for me to articulate this enthusiasm I have with node but as much as I appreciate the Rails world I don't feel passionate with Rails anymore (it feels like my Cobol class in university).
The community
It feels like Rails in its beginning—so many talented folks providing great solutions. Just check Express and related npms like Jade, Stylus, etc. They look like similar Ruby gems but if you look into the details you see people that go further and pushes the boundaries.
Some examples: just check how beautiful designed the Express error messages are—nothing crucial but it feels good working with people who are passionate. Or check how lean Stylus is compared to SASS, LESS, SCSS or how Jade goes beyond HAML with mixins etc.
It's hard for me to articulate this enthusiasm I have with node but as much as I appreciate the Rails world I don't feel passionate with Rails anymore (it feels like my Cobol class in university).
> Don't underestimate the value of enthusiasm - especially if you're a boss.
With the flip side of that being ....? Hurry up and build it in whatever's new and cool before their enthusiasm for it fades and everyone's on to the next next thing?
I too, as a hacker, like to experiment with new stuff, and find that it's motivating, but thinking about how to manage a project for the long term is also worth considering.
With the flip side of that being ....? Hurry up and build it in whatever's new and cool before their enthusiasm for it fades and everyone's on to the next next thing?
I too, as a hacker, like to experiment with new stuff, and find that it's motivating, but thinking about how to manage a project for the long term is also worth considering.
> Don't underestimate the value of enthusiasm - especially if you're a boss.
Indeed, and your advice is wisely directed at bosses. However, it's a bit harder (though not impossible) for a developer to use this argument successfully: "Let me use Node because I'll be more excited about the project."
Indeed, and your advice is wisely directed at bosses. However, it's a bit harder (though not impossible) for a developer to use this argument successfully: "Let me use Node because I'll be more excited about the project."
ASP.NET core it not terribly well-designed, but it has has peripheral things like Razor, design-by-contract, PEX, Moles and there are tons of other interesting technologies from MS research. A lot of those things are genuinely new in some way, and allow you to do something that was completely impossible before.
I can't muster any enthusiasm over Node, because it's really more-of-the-same-but-better. With an attitude like this it's perfectly reasonable to ask "why exactly it's better"? Unsubstantiated enthusiasm in IT is evil.
I can't muster any enthusiasm over Node, because it's really more-of-the-same-but-better. With an attitude like this it's perfectly reasonable to ask "why exactly it's better"? Unsubstantiated enthusiasm in IT is evil.
All the great new features of ASP.NET and C# aren't exactly new, but Microsoft have created a genuinely fun platform that a lot of people are starting to use outside of the famed "stuffy, corporate environments".
We use it at a digital agency and it's been fantastic. I'm a big fan of what both Python and ASP.NET are doing at the moment, and although I have tried Ruby and Node.js I really couldn't see myself wanting to use them for a real project.
We use it at a digital agency and it's been fantastic. I'm a big fan of what both Python and ASP.NET are doing at the moment, and although I have tried Ruby and Node.js I really couldn't see myself wanting to use them for a real project.
To the best of my knowledge, stuff like PEX is new outside of academic environments. Moreover, it's highly non-trivial. Here is a collection of other interesting projects from their research department:
http://rise4fun.com/
http://rise4fun.com/
PEX4fun could become a better FizzBuzz than FizzBuzz.
Excellent points!! Always keep an eye open towards the advantages and disadvantages of anything new. Don't immediately dismiss something because it is new, just as you wouldn't immediately start using something new. Research and learn.
It's not a black/white situation here. Being the boss, I know sometimes (most of the time, to be honest) we need to stick to proven and tested stuff, as economic times are not the prettiest and clients that would pay for the extra mile don't just sit around.
What happens when you assign 2 developers on a project that they are very passionate and enthusiastic about because you allowed them to use, say, node.js.
Only to discover in a month or two that they spent 200 hours more that they would if they used something proven and tested. That's several k$ out of the window and maybe milestone not met.
Sometimes it's worth it, sometimes it's not.
What happens when you assign 2 developers on a project that they are very passionate and enthusiastic about because you allowed them to use, say, node.js.
Only to discover in a month or two that they spent 200 hours more that they would if they used something proven and tested. That's several k$ out of the window and maybe milestone not met.
Sometimes it's worth it, sometimes it's not.
It's a typical developer vs business mindset. They rarely sit on the same page for a good reason.
Couldn't upvote this more.
And regarding Node: it rocks, just try it and you see what eye opener you missed before.
And regarding Node: it rocks, just try it and you see what eye opener you missed before.
"Just Try It" is not enough for Node to be quite frank.
Some people tried it and still couldn't see what they missed. I wouldn't call them blind afterward either. If it fits your taste bud then great, if not... no biggie.
Some people tried it and still couldn't see what they missed. I wouldn't call them blind afterward either. If it fits your taste bud then great, if not... no biggie.
Don't use Node if you have a lot of CRUD, because you'll still have to do a lot of stuff manually. Node's ecosystem is relatively young which means you'll have to do a lot of manual labor (as opposed to something like rails and mature, production-ready gems) and stitching of components. It cat get messy rather quickly, so my advice is "the right tool for the job".
These guys nailed my point pretty good: http://www.perfectline.ee/blog/optimizing-ruby-on-rails-appl...
These guys nailed my point pretty good: http://www.perfectline.ee/blog/optimizing-ruby-on-rails-appl...
I have to disagree. I understand that you can get quickly the feeling that you have to do a lot of stuff manually with node because node packages (gems in node) are more kind of atomic and not full-blown like rails. You can quickly setup a rails-like-environment with node packages. There are different web frameworks which are a refreshing take compared to rails and provide same or better functionality. ORMs like ActiveRecord for SQL DB are available as well. Deployment is easy and the overall ecosystem reflected by npm (node packet manager) is very advanced and brings some innovation into this space (compared to rvm/rbenv).
Prove it:
What is node equivalent of: "rails g resource User email:string password:string"? AFAIK there is none. At least not one that would take care of migrations, validation, security, logic and views.
And if I want to use postgres? Sure, there's a npm package. But it's for queries, I still need to define models and validation manually.
....
What is node equivalent of: "rails g resource User email:string password:string"? AFAIK there is none. At least not one that would take care of migrations, validation, security, logic and views.
And if I want to use postgres? Sure, there's a npm package. But it's for queries, I still need to define models and validation manually.
....
as spyder posted there are npms providing this functionality. there are 8,000 packages for all your needs.
But the point is another: the npm world is much more modular than the Rails mononblock, there is much less magic involved. You setup your own stack which is simpler than setting up Rails, rvm, gems. Rails isn't bad—it's great but getting off track or looking behind the magic can get a tedious task ...
But the point is another: the npm world is much more modular than the Rails mononblock, there is much less magic involved. You setup your own stack which is simpler than setting up Rails, rvm, gems. Rails isn't bad—it's great but getting off track or looking behind the magic can get a tedious task ...
There really isn't a Rails vs Node dichotomy, though. More like Sinatra vs Express -- you can write glue code in the Ruby ecosystem as well if that's what you want to do.
You use Rails because you want and understand the magic, not because it's magical. You might be initially allured by the terseness of Rails, but the learning curve of what Rails is doing is why you use robust frameworks in the first place -- because you want shortcuts and optimize away from trivial things like form parameter passing and route generation. Learning what `resources :topics` does is "tedious" in a much different way than the tedium of scoping out:
...And then another part of the community will complain that it's "too magical" while I do the Jackie Chan 'wtf' gesture because there's a crystal clear API and they'd rather form a Cloud Chorus against alleged "magic" than humbly accept that they might not appreciate the same things that other people appreciate.
You use Rails because you want and understand the magic, not because it's magical. You might be initially allured by the terseness of Rails, but the learning curve of what Rails is doing is why you use robust frameworks in the first place -- because you want shortcuts and optimize away from trivial things like form parameter passing and route generation. Learning what `resources :topics` does is "tedious" in a much different way than the tedium of scoping out:
app.get '/topics'
app.get /topics/:id'
app.del ...
...
app.namespace '/topics', ->
app.get '/', ->
app.get '/:id', ->
app.resources 'topics'
...And then another part of the community will complain that it's "too magical" while I do the Jackie Chan 'wtf' gesture because there's a crystal clear API and they'd rather form a Cloud Chorus against alleged "magic" than humbly accept that they might not appreciate the same things that other people appreciate.
Yeah but let's compare two relatively popular solutions for authentication in each frameworks: Rails has devise, Node.js has passportjs. They both support numerous 'strategies' (local, facebook twitter, openid...). They also both support the login/logout functionality. They are both ok documented too (there's always room for improvement there).
As far as passportjs goes, that's pretty much it.
On the other hand, devise handles A-Z when it comes to auth: it sets up models, routes, views, validation, different built in plugins like remember me, different encryption types, retry limits on failed logins,...
Googling for tutorials also reveals the true situation. There are like 2-3 good tutorials on passportjs. On the other hand there's hundreds of articles/posts on how to use devise, how to implement it, how to use it with omniauth...
I could make a comparison like this for almost every gem/module and I bet 95% of times, rails gems will win over npm modules in terms od popularity, completeness, community support and in-the-wild usage.
I'm not trying to bash node.js here. It's a wonderful tool and I use it. almost on a daily basis. But only where it makes sense to me.
Oh and about the 'magic'. You have two options:
1: start with bare language and proceed to magic as you learn
2: start with magic and dig into nitty gritty as you learn :)
Which of the two produces results faster? To me it's 2.
As far as passportjs goes, that's pretty much it.
On the other hand, devise handles A-Z when it comes to auth: it sets up models, routes, views, validation, different built in plugins like remember me, different encryption types, retry limits on failed logins,...
Googling for tutorials also reveals the true situation. There are like 2-3 good tutorials on passportjs. On the other hand there's hundreds of articles/posts on how to use devise, how to implement it, how to use it with omniauth...
I could make a comparison like this for almost every gem/module and I bet 95% of times, rails gems will win over npm modules in terms od popularity, completeness, community support and in-the-wild usage.
I'm not trying to bash node.js here. It's a wonderful tool and I use it. almost on a daily basis. But only where it makes sense to me.
Oh and about the 'magic'. You have two options:
1: start with bare language and proceed to magic as you learn
2: start with magic and dig into nitty gritty as you learn :)
Which of the two produces results faster? To me it's 2.
Doing what anybody else would do after looking at those two projects, I googled "railwaysjs vs towerjs" and found the question on Stack Overflow with an incredible comparison made by the creator of towerjs:
http://stackoverflow.com/questions/9897017/railwayjs-vs-towe...
http://stackoverflow.com/questions/9897017/railwayjs-vs-towe...
Now show me a couple of sites/applications that have at least 100k users and rely solely (ok, mostly) on node.js
LinkedIn's iOS apps
I don't understand what value that would offer, much less what it would prove. This was a thread about accomplishing `rails g resource` with Node. What am I missing?
I use my own migration utility using `psql < 01-up.sql`. Too obvious really.
Yes Rails does all that for you automagically but you can use a lightweight ORM like FastLegS. A model is as simple as this:
UserDao = FastLegs.Base.extend({ tableName: "users", primaryKey: "id" });
To expose it:
app.get("/user/:id", function(req, res) { UserDao.find(req.params.id, function(err, result) { res.json(result.rows[0]); }); });
Let's not forget about unit tests. I can run well over 100 test cases in just over ONE second! Rails is PAINFULLY slow at this.
I've done enough Rails to know how productive it is, and there are many things I miss. I'll argue though I'm more productive with node.js since we do most GUI with Backbone on the client. I can share code between client and server, for example validations.
Yes Rails does all that for you automagically but you can use a lightweight ORM like FastLegS. A model is as simple as this:
UserDao = FastLegs.Base.extend({ tableName: "users", primaryKey: "id" });
To expose it:
app.get("/user/:id", function(req, res) { UserDao.find(req.params.id, function(err, result) { res.json(result.rows[0]); }); });
Let's not forget about unit tests. I can run well over 100 test cases in just over ONE second! Rails is PAINFULLY slow at this.
I've done enough Rails to know how productive it is, and there are many things I miss. I'll argue though I'm more productive with node.js since we do most GUI with Backbone on the client. I can share code between client and server, for example validations.
I completely agree, and wrote an article on this while I was frustrated with a node.js project at work that was trying to throw node, backbone, require, mustache, mocha, and dynamoDB.
http://rakeroutes.com/blog/the-problem-with-completely-clien...
http://rakeroutes.com/blog/the-problem-with-completely-clien...
Thanks for the link. I definitely agree. I've never used Node, but didn't want to dismiss any recommendations without fully researching the technology. Perhaps building the API in Node and leaving the CRUD to our existing server-side stack is an option.
This is the route I've gone. The core CRUD part of the app is PHP, and the real-time chat and document collaboration aspect of my app is node. Works beautifully. I've had so much fun working with node for the last few days.
Why is non-blocking IO radical? Tons of libraries and frameworks offered it much before node, including twisted, Java's NIO, and the entire System.Net namespace in .NET.
Other than that, surprisingly sensible advice.
Other than that, surprisingly sensible advice.
It's not radical, it's just occasionally more confusing than blocking io to implement, and doesn't really have any performance benefits in the multicore world.
I'm actually using node for a side project right now as part of re-learning web development (been back-end the last few years), and using javascript as a client language, server language, and db query language via mongo is a neat environment. Also, npm rocks. But don't listen to anyone who tells you they use node+mongo to handle their WEB SCALE PERFORMANCE. If they really had that problem, they'd be better off using the java ecosystem or, if they really wanted to go hardcore, using a lot of C. But Java's unfashionable and C's ridiculous to write a web app.
I'm actually using node for a side project right now as part of re-learning web development (been back-end the last few years), and using javascript as a client language, server language, and db query language via mongo is a neat environment. Also, npm rocks. But don't listen to anyone who tells you they use node+mongo to handle their WEB SCALE PERFORMANCE. If they really had that problem, they'd be better off using the java ecosystem or, if they really wanted to go hardcore, using a lot of C. But Java's unfashionable and C's ridiculous to write a web app.
>doesn't really have any performance benefits in the multicore world
AFAIK, Node's cluster API, which can spawn workers for each of a machine's cores, will, when delegating requests to a worker, factor in OS-level core utilization info.
AFAIK, Node's cluster API, which can spawn workers for each of a machine's cores, will, when delegating requests to a worker, factor in OS-level core utilization info.
From what I could tell, that spawns actual child processes and communicates with them over pipes. Fine from an architectural standpoint, but a penalty compared to shared memory from a performance standpoint. And it still has the problem of a single heavy CPU request on a given worker blocking all the requests behind it on that worker.
Again, I'm not saying node sucks, I'm using it and I like it. I'm just saying if you really need to crank out performance, use java.util.concurrent, or maybe Go. They both offer event-driven i/o if you really want it, and have better threading models.
Again, I'm not saying node sucks, I'm using it and I like it. I'm just saying if you really need to crank out performance, use java.util.concurrent, or maybe Go. They both offer event-driven i/o if you really want it, and have better threading models.
Not only is node non-blocking but all of its libraries are, unlike Python, Java, and .NET. I wouldn't call that radical per se, but distinguishing yes.
It was radical when Erlang did it. Nowadays it is still moderately distinguishing, but that distinction is definitely fading rapidly.
Go seems to me to provide the benefits of Node's non-blocking IO with a much easier programming model and a much less warty language. But I haven't actually built anything real in either language yet.
Anyone with experience in both care to contrast them? Their problem domains seem to overlap quite a bit.
Anyone with experience in both care to contrast them? Their problem domains seem to overlap quite a bit.
We did some bake-offs with node and Go (and other languages of course). Go won pretty much across the board, except in the time to write category.
The other big downside to Node is hiring. You have two types of "JavaScript" developers. People good with JQuery, and people who have written JavaScript books. There is extremely little middle ground from which to hire good to awesome developers.
Go is the C replacement. Node.js is going to be a Ruby replacement one day.
The other big downside to Node is hiring. You have two types of "JavaScript" developers. People good with JQuery, and people who have written JavaScript books. There is extremely little middle ground from which to hire good to awesome developers.
Go is the C replacement. Node.js is going to be a Ruby replacement one day.
Interesting. My own limited experience with Go suggests that it requires more time to write but less time to test and debug and tune so it might b a wash overall. Where did you find you were spending most of your time?
What I meant was that Node is super fast for cranking out proof-of-concept stuff, and that was its big win. When it got down to trying to close the performance gap between Node and Go (an order of magnitude requests/sec) we sunk a lot more time into Node unfortunately.
That jibes with my intuitions after looking briefly at both of them. Node seems like it would be quick for quickly banging out prototypes but I can imagine that all the other metrics might tilt pretty quickly towards Go.
I've recently rediscovered the joys of static typing so that alone inclines me much more toward go.
I've recently rediscovered the joys of static typing so that alone inclines me much more toward go.
> Bad Use Cases: CPU heavy apps
I wouldn't say that Node (i.e. V8) is a bad use case for CPU-heavy apps. In math/statistics for example, V8 stacks up well against other scripting alternatives. See e.g. the benchmarks here:
http://julialang.org/
Of course it's still not as fast as C++, but not terribly off either. Expect dramatic improvements here thanks to the push for making web apps faster.
I wouldn't say that Node (i.e. V8) is a bad use case for CPU-heavy apps. In math/statistics for example, V8 stacks up well against other scripting alternatives. See e.g. the benchmarks here:
http://julialang.org/
Of course it's still not as fast as C++, but not terribly off either. Expect dramatic improvements here thanks to the push for making web apps faster.
In that example, V8 javascript was 400x slower than the alternatives for matrix multiplication. That's because it's not binding to the BLAS libraries like the 'real' statistical languages. Of course, node supports calling out to C APIs, but that's not an argument for javascript, dynamic languages will naturally be terrible at math compared to C.
More to the point: Node does nonblocking i/o but cpu work is in fact blocking. This means that a CPU-heavy request queues up all requests behind it, waiting to get access to the CPU. You're better off using a threaded architecture for CPU-heavy work.
More to the point: Node does nonblocking i/o but cpu work is in fact blocking. This means that a CPU-heavy request queues up all requests behind it, waiting to get access to the CPU. You're better off using a threaded architecture for CPU-heavy work.
That's silly. No one in their sane mind would serve web requests AND do heavy processing in the same thread - no matter what language.
In Node, you would have a process responding to web requests, and launch a separate process -- via a convenient child_process with built-in pipe communication -- for doing the heavy CPU work.
The only case where that wouldn't make sense is if you need BOTH a ton of concurrency AND heavy CPU work. In that case, threads would make sense as they would be cheaper memory-wise. But my point remains: CPU-heavy applications don't necessarily rule out Node as a feasible alternative.
PS: V8 was 40x slower, not 400, in that one benchmark result you picked.
In Node, you would have a process responding to web requests, and launch a separate process -- via a convenient child_process with built-in pipe communication -- for doing the heavy CPU work.
The only case where that wouldn't make sense is if you need BOTH a ton of concurrency AND heavy CPU work. In that case, threads would make sense as they would be cheaper memory-wise. But my point remains: CPU-heavy applications don't necessarily rule out Node as a feasible alternative.
PS: V8 was 40x slower, not 400, in that one benchmark result you picked.
Well, in Java I serve rpc requests and doing heavy processing from the same thread all the time, and it works great.
What would we have to do in node to get the same level of performance? We'd need a front end instance delegating requests to 8 back-end instances for each core? Writing all these bytes over internal pipes and blowing L1/L2 cache all the time as the data moves across cores? At a certain point, isn't it just way easier and more effective to have one thread spinning an accept loop and a threadpool handling the requests, all within one process bound to a port?
As I said upthread, I'm using node for a side project right now and I'm liking server-side js for a variety of reasons, but squeezing every cycle out of the CPU is not one of them.
What would we have to do in node to get the same level of performance? We'd need a front end instance delegating requests to 8 back-end instances for each core? Writing all these bytes over internal pipes and blowing L1/L2 cache all the time as the data moves across cores? At a certain point, isn't it just way easier and more effective to have one thread spinning an accept loop and a threadpool handling the requests, all within one process bound to a port?
As I said upthread, I'm using node for a side project right now and I'm liking server-side js for a variety of reasons, but squeezing every cycle out of the CPU is not one of them.
"That's silly. No one in their sane mind would serve web requests AND do heavy processing in the same thread - no matter what language"
Sure you could, depends on what you are doing.. In many cases it's fine that the request takes a second to complete, but blocking the entire server for 1 second is not.
Guess you define "heavy processing" a little differently, but in event driven you can't do any (blocking) processing
Sure you could, depends on what you are doing.. In many cases it's fine that the request takes a second to complete, but blocking the entire server for 1 second is not.
Guess you define "heavy processing" a little differently, but in event driven you can't do any (blocking) processing
So far I don't see any benefit in node.js over mature enterprise frameworks.
That's funny, cause I'd prefer literally anything that isn't called an enterprise framework.
Bash cgi?
The whole point of node.js and it's ecosystem is to avoid anything that looks like an 'enterprise framework', rather it's a collection of lots of little modules that each do one thing and one thing well and that can build on top of each other (turtles all the way down).
That sounds like a lot of fun to maintain and keep version control on, especially when they're written by different people with different motivations.
Lately my problem has been convincing my boss NOT to use Node on every little project. Don't get me wrong, Node is versatile and fun, but not the most appropriate choice for systems work and your usual DevOps tools.
To him, any little one of script written by the team (except his own) must be re-done in Node. Then, the code being "his", he'll upload it to his own personal github account. Meanwhile, we have to reimplement the new Node written tool.
To him, any little one of script written by the team (except his own) must be re-done in Node. Then, the code being "his", he'll upload it to his own personal github account. Meanwhile, we have to reimplement the new Node written tool.
"So don't try to build hard realtime systems in node, that require consistent response times. Erlang is probably a better choice for these kinds of applications."
Erlang is actually suited for soft realtime systems as well. I've never seen it recommended for hard realtime systems.
Erlang is actually suited for soft realtime systems as well. I've never seen it recommended for hard realtime systems.
I love that this started with bad use cases.
We're running a nodejs+nosql+js-heavy-client project right now. While evaluating any stack component is an important task, it is certainly more so important in this environment.
This guide is OK, but it's insufficient. If you're going to do a technical evaluation of the node/nosql/js-client stack for risk assessment, you're going to need to get much more granular than what this guide offers. This is a fine guide for a project lead, but this is somewhat useless for the system designer.
For example, in reference to "nosql+node+buzzword+bull$#!t", the advice is to use nosql when you "really" know it, otherwise stick with mysql/postgres. While the devil-you-know-vs-devil-you-dont is a fine project mitigation strategy, it's not a very good technical strategy. Maybe the guide's author assumes one would do so, but the nosql/rdbms comparison exercise is not trivial and requires you to do your homework. Understanding and contrasting the finer points of comparing nosql operations vs. relational data stores is much more useful than a blanket comment.
Like I said, it's a fine guide, but it's much more useful for those who aren't necessarily responsible for determining the stack's applicability to a given project.
This guide is OK, but it's insufficient. If you're going to do a technical evaluation of the node/nosql/js-client stack for risk assessment, you're going to need to get much more granular than what this guide offers. This is a fine guide for a project lead, but this is somewhat useless for the system designer.
For example, in reference to "nosql+node+buzzword+bull$#!t", the advice is to use nosql when you "really" know it, otherwise stick with mysql/postgres. While the devil-you-know-vs-devil-you-dont is a fine project mitigation strategy, it's not a very good technical strategy. Maybe the guide's author assumes one would do so, but the nosql/rdbms comparison exercise is not trivial and requires you to do your homework. Understanding and contrasting the finer points of comparing nosql operations vs. relational data stores is much more useful than a blanket comment.
Like I said, it's a fine guide, but it's much more useful for those who aren't necessarily responsible for determining the stack's applicability to a given project.
JavaScript seems to be having the same problem that other languages have developed over usage time. It becomes increasingly difficult to know what package does what and more importantly information of the pros and cons of the package. Does anyone know of a link to something similar to what I'm talking about? Say something meaningful about the top N (where N might be 10 or so) packages---what they do, the good and the bad?
Check out the Node Toolbox: http://toolbox.no.de/
It doesn't seem as fleshed out as the Ruby Toolbox (https://www.ruby-toolbox.com) and could use a bit more editorial for your purposes, but it's a good place to start.
It doesn't seem as fleshed out as the Ruby Toolbox (https://www.ruby-toolbox.com) and could use a bit more editorial for your purposes, but it's a good place to start.
Thanks a ton for posting that. I'm new to Node, and it's a great help.
Of course, it'll never go anywhere until whomever is maintaining it either allows for crowdsourcing of the data or tries harder, because the first couple of packages I looked at had very poor descriptions.
Coffeescript, for example, is defined as "Unfancy JavaScript". CS is one that I happen to know about, and by that definition, I'd have never ever switched to it.
Of course, it'll never go anywhere until whomever is maintaining it either allows for crowdsourcing of the data or tries harder, because the first couple of packages I looked at had very poor descriptions.
Coffeescript, for example, is defined as "Unfancy JavaScript". CS is one that I happen to know about, and by that definition, I'd have never ever switched to it.
Peteris Krumins had a nice series of Node.js modules you should know about: http://www.catonmat.net/category/nodejs-modules
Some of my favorites:
Some of my favorites:
- async -- flow control
- stitch -- packaging client side scripts
- express -- web framework
- redis -- great Redis client
- stylus -- css preprocessor
- request -- HTTP client
I seriously think Node.js is one of those things that get's overhyped. Yes it's fun to code...until the nested callbacks get's too much. For me personally I will stick production code with ruby/sinatra and eventmachine and play with node for personal projects.
[deleted]
Somone is proposing Node.js for a project and I was wondering if the advantages/disadvantages in this article are still current. This is for a web application with lots of CRUD, but will also require a custom JSON API.
There are tons of existing fast, mature existing options that do great CRUD, JSON APIs (they might call it "REST"), and even have some integration between the two. There's no compelling reason to go with something like Node if that's your use case. That's not so much because Node is intrinsically bad at such things as that the things that it was relatively good at were not that, so the focus hasn't been on that use case. Displacing the existing incumbents in that space would be an incredibly tall order.
The usecase of building JSON api servers are often used. Can someone give some examples of node JSON api implementations?
I recently built SAJAK (Simple Authenticated JSON API Kit) to suit my own needs: https://github.com/jed/sajak
Good name.
Do you mean companies using it? Look for SimpleGeo. Do you mean librairies? Look for Express or Restify.
The table of contents at the top of this article makes it look 10 times more intimidating than it really is.
this is great. in general, need more of these sorts of 'convincing x' guides ...purely for need for the right 'language'/points to convey benefits without getting lost in tech/trendspeak.
As a web developer, you sit on the intersection of engineering, design and art. You're lucky enough to live at a time where there are numerous production-ready tools with which to do your job. If you choose a tool that you're excited to explore, with an active and fast-moving ecosystem, your excitement and enthusiasm will make you happier and more likely to do a better job.
Someone down the thread said this:
> So far I don't see any benefit in node.js over mature enterprise frameworks.
If I was only allowed to work in ASP.NET, I'd be looking to change careers pretty fast.
Don't underestimate the value of enthusiasm - especially if you're a boss.