Anyone using this at all?


I want to start messing around with it. Advice? Best practices?

4/12/2011 2:39:02 PM

i've kept up with a lot of the chatter about it over the last year or so but haven't done anything with it other than the basic walkthroughs.

4/12/2011 2:42:27 PM

Same here - there seems to be a lot more talk about it recently



I'm wondering if it's the new Ruby, though

4/12/2011 2:49:21 PM

Watching the intro video now. I've come to the realization that things invented by people named "Lars" are going to be over my head forever.

4/12/2011 2:51:48 PM

Quote :

"I'm wondering if it's the new Ruby, though"

that's funny, i was gonna say something along those exact same lines

4/12/2011 2:57:54 PM

TONS OF HYPE


LITTLE PRACTICAL APPLICATION

4/12/2011 3:09:07 PM

so it creates a temporary webserver written in javascript?

wut?

4/12/2011 6:41:33 PM

From what I've seen I'm still trying to wrap my head around how this isn't a crazy resource hog.

Also, ^^ this.

4/12/2011 7:20:49 PM

so apparently it's supposed to be more efficient because it only utilizes resources on-demand.

it's event-driven and based on the V8 js achitecture, which leads me to believe that there will be some cool things to come out of it...


but it's still very young, and honestly I've yet to see one practical application of it.


here's a link:


http://gigaom.com/cloud/node-js-and-the-javascript-age/



but basically the point of me making this thread was to see if anyone had actually used it for anything, and thus far the replies indicate that you're all in the same boat as me

4/13/2011 12:02:16 AM

Basically the node executable is just a dumb socket listener/dispatcher with an integrated Javascript engine. Guess who gets to write all the application-specific request dispatching and response writing code? You do. In Javascript.

It's set up this way in the name of performance -- you're writing "to the bare metal" and the server does absolutely minimal processing itself. You can basically do minimal header processing, etc. if you want to. The Javascript engine is persistent for the life of the server-side application. You get the idea.

The biggest drawback is that you've got to do all that behind-the-scenes dispatching, messing with headers, keeping connections alive, etc. stuff that you normally don't have to mess with when writing apps with enterprise application servers, RoR, and so on. I'm not really convinced that those servers can't do the mundane stuff efficiently. So now on top of normal application logic, you're basically coding a webserver and worrying about all the things that can go wrong there. And you have to do it in Javascript. I don't doubt that the V8 Javascript engine is fast, but I don't think it'll blow the doors off say, Java.

The biggest draw, theoretically, is that you can leverage your client-side Javascript talents on the server-side and cut in half (at least) the amount of language proficiency required to develop an application.

Long story short: pointless academic exercise.

[Edited on April 13, 2011 at 1:46 AM. Reason : That will make someone very rich.]

4/13/2011 1:33:53 AM

^^gems from that article:

Quote :

"This decision was driven by a realization: the LAMP stack is dead"

Quote :

"The Javascript age brings us closer to a web that is not a global digital library, but a global digital nervous system, whose implications we are only beginning to apprehend."

Uh huh.

^What you said on cutting language proficiency in half makes sense

Quote :

"For both of these roles, node.js is an ideal serving architecture. Since we’re currying Javascript functions on the server-side, we ought to write in Javascript. We can shift computation from server to client with little impedance (for example, we no longer need to maintain two sets of our custom string formatting libraries)."

4/13/2011 8:22:49 AM

I, too, use Zite.

4/13/2011 9:24:56 AM

Quote :

"This decision was driven by a realization: the LAMP stack is dead"

wat

4/13/2011 4:48:40 PM

^yea really. I definitely checked out there.

4/13/2011 6:09:27 PM

but you guys, it's dead!

4/13/2011 7:22:40 PM

Quote :

"Watching the intro video now. I've come to the realization that things invented by people named "Lars" are going to be over my head forever."

I understand the concept of replacing a snare drum with a trashcan lid, I just don't like it.

4/13/2011 8:23:10 PM

this thread has brought me much funny

4/14/2011 12:59:50 AM

I built a javascript chart renderer just as a proof of concept. It was blazing fast and could do 40 or so times the load as other server side chart solutions. Ryan is mega fucking smart and its a brilliant idea with a lot of movement.

Non blocking IO ftw.

Quote :

" And you have to do it in Javascript. I don't doubt that the V8 Javascript engine is fast, but I don't think it'll blow the doors off say, Java."

Yeah it does actually... by orders of magnitude. It doesn't have the overhead of the thread per request model.

The biggest draw is that javascript isn't a shitty language and the IO model is a huge paradigm shift. It's like the difference between git and svn.

[Edited on April 25, 2011 at 11:44 PM. Reason : a]

[Edited on April 25, 2011 at 11:44 PM. Reason : a]

4/25/2011 11:38:40 PM

interesting


tell me more

4/26/2011 12:17:20 AM

I was watching this talk on a javascript game engine. Apparently, they were using node.js... like a year ago.

Quote :

"Javascript on the server is nearly as fast as C."

well, shit

http://youtu.be/_RRnyChxijA

[update] GODDAMNIT. it got bought up by zynga in september.

http://www.insidesocialgames.com/2010/09/24/zynga-acquires-dextrose-aves-engine-html5/

[Edited on May 13, 2011 at 4:40 PM. Reason : asfasdf]

5/13/2011 4:33:24 PM

I was at this talk:

http://ontwik.com/javascript/server-side-javascript-with-node-connect-express/

It's pretty high level with some good hello world examples.

[Edited on May 15, 2011 at 3:05 PM. Reason : a]

5/15/2011 3:00:38 PM

Quote :

"but it's still very young, and honestly I've yet to see one practical application of it."

HP webOS 2.1 and 3.0 services are built on node.js, it's an outstanding example of it working well.

As far back as August was one of the first official announcments:
http://almaer.com/blog/node-is-our-turtle-shell-node-js-now-powers-services-on-webos

5/16/2011 9:29:36 AM

...isn't webOS dead, though?

5/16/2011 2:50:03 PM

It's probably the best phone OS there is.

So logically, yes, it's dead.

(Ok, it's not really dead, but it's not very popular though maybe the Pre3 and Touchpad will fix that)

[Edited on May 16, 2011 at 3:39 PM. Reason : .]

5/16/2011 3:39:03 PM

the non-blocking IO advantages of node.js aren't as frequently beneficial to what i do, but I did learn about coffeescript from node.js, which further introduced me to sass and lesscss, and i really like those ideas. they are scripting languages to write javascript and css in a simpler syntax, and providing variables, operators, functions etc and it all gets compiled down to traditional js and css

here's some LESS, which illustrates how it works. how many times do you run into this problem

@color: #4D926F;

#header {
  color: @color;
}
h2 {
  color: @color;
}

5/17/2011 12:36:15 PM

Microsoft officially helping create a Windows port

http://blog.nodejs.org/2011/06/23/porting-node-to-windows-with-microsoft%E2%80%99s-help/

6/23/2011 11:55:38 AM

Quote :

"they are scripting languages to write javascript and css in a simpler syntax, and providing variables, operators, functions etc and it all gets compiled down to traditional js and css"

Allow me to derail for a second and just say I feel that something like this is without a doubt the biggest omission from CSS3.

It's 2011 and we still can't just define color variables without going to some external library/script/whatever?

6/23/2011 12:05:45 PM

^ Agreed - but give it time. I think that the entire community moves quite a bit faster now than it used to. You're starting to see common sense creep into things, like HTML5 becoming a living spec, and dropping the "5" instead of tying any given featureset to one release.


With the bleedover from the development community, and SaaS becoming a more and more prevalent, I think a lot of the really backwards-ass things we've seen over the past few years are going to disappear.

6/23/2011 1:32:30 PM

Most of my current development is in:

http://jashkenas.github.com/coffee-script/

We are doing primarily backend dev with it but you can do front end as well, which can be problematic when you debug in firebug. It's a python like language that compiles to JS, and is all Node based.

6/24/2011 8:16:51 PM

so another *.js framework that's been getting a lot of chatter recently is knockout.js, which is client-side Model-View-ViewModel pattern



now that's pretty slick

[Edited on January 13, 2012 at 3:28 PM. Reason : .]

1/13/2012 3:27:03 PM

Backbone.JS is another front end client like Knockout, but works quite a bit different. Node.JS is server side.

I use Backbone and Node for most everything at the moment. Node can be a mother fucker and can get pretty messy. I can't wait to see what maintaining it in the future is like.

1/13/2012 5:15:14 PM

Lots of people, including me, seem to be using Angular.JS. I know a couple of people at Space X and heard they are using it as well.

It is a lot easier to keep the view logic in the view without rat holing on if this.model.prop make view css this class. Kind of forces into best practices.

1/30/2014 12:24:14 PM

i'm slowly starting to find myself pulled toward node. especially with grunt and bower being node-based tools

i doubt i'll be using node for heavy server side applications any time soon, but being a bit more comfortable with that community and knowing what capabilities are surfacing there has been useful to me as a web developer

1/30/2014 2:25:05 PM

I keep hearing that I need to get into some kind of framework. I've been building a web app using ASP.NET MVC, and I've been able to do just about everything I set out to do using that and Javascript/jQuery. How does using something like Node.js or Angular.js make my life easier or improve site performance?

1/30/2014 3:07:20 PM

ASP.NET MVC is a framework, so you're already using one

a benefit of node.js is that you're writing javascript on the server instead of C# (or java, ruby, python, php, etc). javascript as a language gets a lot of hate so this may not actually be a benefit. but, if you're a web developer who know how to write javascript for the browser, node is an easier way to dip your toes into backend development. another reason to use node (in some cases) is benefiting from node's event driven model.

a benefit of angularjs is that more of your application runs in the browser. that means less processing power needed on the server = easier to scale up. we've already been able to do that for a long time with AJAX, but until the last couple years that meant using jQuery and tightly coupling your javascript to your CSS and DOM. inevitably you end up with unmaintainable spaghetti mix of javascript logic and jquery UI logic. angular almost forces your into using proper separation of concern principles

ASP.NET MVC is still a good framework though. C# as a language, .NET as a framework and the productivity strengths of Visual Studio are very compelling. ASP.NET MVC primarily is modeled around server-side rendering of the views though, so you don't get the responsiveness that in-browser javascript view templating gets you (though there are certainly decent ways to achieve that). not every app needs or benefits from that.

in my case, i'm using server-side ASP.NET MVC for the view layouts plus some portions of the page that don't need to be refreshed through ajax calls, and angularjs for all the portions of the pages that do benefit from better responsiveness and richer interaction, so it's certainly possible to use multiple technologies and frameworks at once.

[Edited on January 30, 2014 at 3:32 PM. Reason : .]

1/30/2014 3:29:20 PM

Quote :

"a benefit of node.js is that you're writing javascript on the server instead of C#"

Haha, nope. That sounds awful.

Quote :

"a benefit of angularjs is that more of your application runs in the browser. that means less processing power needed on the server = easier to scale up. we've already been able to do that for a long time with AJAX, but until the last couple years that meant using jQuery and tightly coupling your javascript to your CSS and DOM. inevitably you end up with unmaintainable spaghetti mix of javascript logic and jquery UI logic. angular almost forces your into using proper separation of concern principles"

Sounds kinda like what I'm headed towards. I've tried my best to keep my code organized, but it's only going to get worse in the future.

1/30/2014 3:44:55 PM

^

The largest benefit is if your app is IO vs CPU heavy. Let's say you are contacting your database, soundcloud, and twitter to return a response to the user. Most traditional methods block using resources while the CPU is waiting for the information to come back over the network. In node it doesn't do that, it makes the request then continues on to do work until the data comes back. You can do that in .NET and Java with async/defer/threads, but it's more error prone and complicated.

Javascript sucks as a language, but you can only say that if you know it and at least one other language.

I've never seen anyone successfully keep the UI code from turning into spaghetti without angular. I'm sure it's possible, but have my doubts.

[Edited on January 30, 2014 at 4:24 PM. Reason : a]

1/30/2014 4:23:51 PM

so, packages like promises, futures, etc. - crap that allows some synchronous workflow: any recommendations to look at? If it plays nice with express that'd be swell.

5/2/2014 4:03:53 PM

https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript

5/2/2014 4:09:51 PM

^^

You can do some creative things with composing functions together if you keep everything light. If you get more than a few callbacks deep there is usually a better way. A while ago I composed a router, handled url params and packaged into arguments, for a controller, which handled any business logic, to a dao.

We still use async a lot where I am now.

https://github.com/caolan/async

The startup I worked at started looking into Iced CoffeeScript, but I had moved on so don't have that much 1st hand experience.

http://maxtaco.github.io/coffee-script/

When node supports generators it's going to get much better:

https://github.com/visionmedia/co

I've already written a few api examples with co in our code with harmony enabled and it's much better.

5/2/2014 4:58:12 PM

I'm actually really pleased that node did not turn out to be the next ruby.


also, for those of you still stuck with .NET architecture.... http://tjanczuk.github.io/edge/#/

[Edited on May 2, 2014 at 6:37 PM. Reason : .]

5/2/2014 6:36:21 PM

This is another classic Destroy All Software talk: https://www.destroyallsoftware.com/talks/wat

5/2/2014 7:17:21 PM

What view engine do you guys use for Node.js web apps? Coming from Razor views in ASP.NET MVC, Jade (which seems to be pretty popular) is a big disappointment/step down.

7/12/2014 4:52:50 PM

We use EJS, but don't really do much server side templating. Just looking at Razor, it looks pretty equivalent to EJS.

After using Node for about 3 years for 3 different projects I've seen some of the pretty serious warts up close. There are some parts of the new JS versions that fix a lot of the async problems, but error handling is all over the place and a lot of non-intuitive behavior for noobs (like try catch not firing when there is something async in the try). Recently, a stream we had randomly stopped calling finish recently leading to a nasty production bug. System callbacks can fire more than once for the same process.



[Edited on July 13, 2014 at 2:07 PM. Reason : a]

7/13/2014 1:54:48 PM

i don't like jade either. too much of a departure from real html

we use handlebars these days, but only mostly because we use angular on the front end which uses the same binding syntax

we used to use ejs on the front end before we switched to angular (from canjs and javascriptmvc before that) but it reminded me too much of WebForms binding syntax which always felt very awkward for me to type.

i really do like the verbosity of razor syntax though and wish node and angular both supported it or something like it

7/13/2014 5:01:55 PM