The problem with the internet is that people now have the ability to affect a larger amount of opinions than ever before, for better or worse.
I think node is cool, and definitely has its place. I think it's a bit premature when people start talking about it being a full stack replacement. I certainly believe under some circumstances node really shines, but you need to pick your battles using the right tool for the right job. Stay educated and understand why something works to solve a particular problem well.
Whoa, who said anything about full stack replacement. I use a variety of stacks, I was simply pointing out that since I'm using Javascript all over the place anyway, I might start using it on the server side as well. Things I use Ruby for generally amount to one-off jobs or shell-scripts. I constantly have to remind myself of the syntax, since all I use all day long are variants of C syntax(C#, java, javascript). It'll take me 10 minutes to whip up what would take me 30 in ruby, simply because I don't use ruby often enough to internalize the syntax. node provides me with a way to write the same shell scripts in javascript.
That's true ramblerman, and actually I wrote some of this in the console window of Chrome. The real point I was trying to prove (mostly to myself) is that javascript can work as a server-side scripting platform to quickly create short scripts. Node is simply my interpreter for it (and more). That actually points out another bonus. I can POC something in javascript in a browser window, and if I want to graduate it to a server side script its mostly a copy-and-paste operation.
The post is mostly about convenience. I use javascript all the time. Now I can use it more. I love ruby, I just end up having to relearn it every time I use it because I don't use it often. Node is just the vehicle of that convenience.
The ability to share models/code between the client side and server side is magic at first. Javascript on every level with the data encoded in JSON? Yes, please.
Yes, we built [1]tilemill and [2]mapbox hosting using this technique. It's pretty awesome when it works, but can be quite tricky in other ways.
The first is a hybrid desktop/web application to design maps using a CSS like descriptor language. The desktop app downloads actually bundle a local node server in an os specific wrapper, with a web view. The application works just as well hosted and accessed by multiple user.
The latter is a cloud service that allows you to host rendered map layers and remix/share them. Foursquare recently switched to using mapbox for all their browser based maps.
I'd estimate at least 90% of the code is shared between the server and the client, with the server side generally only differing when you need to access resources not available to the client (databases, files on the server etc). The user interfaces can be rendered on either the client or the server (w/ jsdom) as needed.
I haven't in a huge way, but I have definitely shared constants, utility functions, and some application logic that are used identically server-side and client-side.
It's probably not a HUGE boost in productivity, but it does feel really, really nice. And just knowing you can take your server-side data structures, trivially insert them into client-side scripts with JSON.stringify() or Ajax calls, and have the same helper libraries you use server-side be able to operate on them client-side, makes it so easy and flexible.
(I'm working on a project that uses IcedCoffeeScript both server-side and client-side, which lets us use the same async event-handling model on both sides as well -- another plus.)
And furthermore, what are the security ramifications of doing this?
At first glance, it seems attackers would be able to forge JSON objects resulting in "mass-assignment" style vulnerabilities (unless there is lots of protection logic) when sending JSON objects back to the server side.
However, going in the other direction (sending JSON from server to client) is a very common pattern.
Who in their right mind does data validation on the client? However, there are (very easy) ways to store data on the client and be sure they haven't been tampered with. Just HMAC it along with a secret and check it next time.
My startup uses node to handle all database operations and essentially only serves JSON via AJAX, while the most HTML it sends is basically <script src="script.js"></script>. The entire app itself along with user-generated content depends on a few large (highly variable) objects sent as JSON where the DOM is manipulated based on this minified data.
As a bit of a backup measure (mainly to prevent XSS), the client-side javascript sanitizes (which is what I believe you partly mean by data validation) all objects sent to the client when as they receive it. So anyone using the intended client-side script should never be susceptible to XSS.
But if by "data validation" you were referring to concepts like whether or not a user has permission to access/modify some part of the database, of course that is checked server-side.
Well, because the same code runs in both places, you end up with a situation where you are _also_ running the validation (most of it) on the client.
The models can (and should) still be validated on the server before you actually save it, but this is child's play. There is a certain category of validation that can only happen on the server too, like 'has this username been taken already?'.
A friend who is wrapping up the last year of his computer science education asked me last night "so what's this node.js stuff all about?". I thought about it for a few seconds and then told him the value of writing a web-app in node was the ability to use 1 language from top to bottom.
In my experience, most of the detractors of node seem to miss the value that a homogenous programming environment can bring. I'm interested to see how your courtship with node pans out over the long term; good post :)
You can share fragments of code, but for reasons of both security and logic not much more. In my view, the evented nature of node negates most of the pluses of one language.
Additionally, javascript is a shitty language if what you want is a large amount of business logic. Python and ruby are much more concise and expressive. This is a huge win that a lot of people overlook.
Now, if you need to throw together a chat service or push service really quickly, I see the value, but that's about it. Of course for that, I'd just use clojure or java.
I suggest trying CoffeeScript with node for more conciseness and expressivity, and one of the async helpers to mitigate the complexity of the "evented nature of node" -- letting you avoid huge nested callbacks.
These two things together completely transform Node, so much that I can't even imagine coding without them.
i do node all day every day, but i've actually found it sub-optimal for shell scripts / one-off jobs. For me these tend to take the form of import scripts or batch files that have to process various different files and stick it in a database. There's a lot of conceptual overhead that comes with asynchronous IO for these kinds of tasks. However, some of the things that node allows you to do is kind of spectacular too.
On a recent project I had to parse data from a set of csv files, while pre-processing the data and pushing it into a Couch database. At the same time I needed to generate a sqlite database with spatially aware geographic indexes using parts of the data, so we could build maps from the data. I ended up having a situation where the data was streaming into the couch database waaaay faster than the sqlite db could write the records, which resulted in the process growing in memory bogging the entire application down (the csv files could be uploaded via a form as well).
The solution ended up being that because my csv parser was building on the stream classes in node, i could literally pause/resume the stream based on the state of the buffer(s). This is exactly the same technique you would use when building an http proxy or limiting the transfer rate of file uploads. This is some pretty low level stuff to have to get into for a simple import script, and if I were to do it in something other than JS I would probably have used temporary files or separate processes or whatever. Debugging and testing this kind of problem is not really straightforward either.
As always YMMV, but I have become more appreciative of plain bash scripting as of late.
The strange thing about this is that I've found that both make great additions to my toolbox, and when making my language choice I don't pick JS or Ruby so much as I pick Node or Rails/Sinatra and I don't do the same things with each stack.
I've long gotten past worrying too much about languages Ruby and JS are so close to each other that switching between the two is a frictionless process.
I don't know, I want to make an HTTP spider and I don't want to have one process per request, so the obvious thing was to use something asynchronous. Still, Python+gevent sounds better than node, so I don't see the advantages of using Javascript for that.
What does it get me over Python+gevent, which has a more natural asynchronous programming syntax?
Because unless you have an unusually high (>1000) concurrency level for your HTTP connections, threads are a more than adequate solution to the problem.
There are also threads, which are typically much easier to program for than an asynchronous system, but will still let you have more than 1 request per process.
I think node is cool, and definitely has its place. I think it's a bit premature when people start talking about it being a full stack replacement. I certainly believe under some circumstances node really shines, but you need to pick your battles using the right tool for the right job. Stay educated and understand why something works to solve a particular problem well.