5 ms·

A Simple MVC Setup in Node.js

28 points by travisglines 16y ago

lwat 16y ago
Tell me again why we want to use Javascript server side?
- travisglines 16y ago
  Is that sarcastic based off of stuff I've said before? Or just a serious question? If its serious is basically boils down to event driven architectures (node,tornado etc) vs. thread driven (apache) and how they can typically handle concurrency better.
  - deleted 16y ago
    [deleted]
  - deleted 16y ago
    [deleted]
- Groxx 16y ago
  Javascript is fantastically flexible for its popularity. And then you get the advantage of doing all your coding in a single language. Out of curiosity: do you just generally dislike JavaScript as a language? And remember that Node doesn't run in a browser, so this would be ignoring any browser problems. I, personally, have been liking it a lot, and more-so as I go deeper down the rabbit hole.
- dstein 16y ago
  The JavaScript language isn't what's nice. What's nice is using one programming language to write an HTTP server, your server application, server templates, client-side application, client-side templates, communication code, database code, and be able to share your libraries and models between all contexts simultaneously. You fix one bug in one place, and you've fixed the bug in 7 or 8 different contexts immediately. In other words, your productivity skyrockets.
  - lwat 16y ago
    Maybe I just need to see it to understand it. Is there a non-trivial app on github or somewhere I can look at? One that shows the strong side of Node.js?
    - catch23 16y ago
      There are great non-blocking IO examples out there which are pretty easy to find (look at any database, file system, or networking library), but I think jsdom is a rather unique library that is hard to find in other languages: https://github.com/tmpvar/jsdom https://github.com/tmpvar/jsdom jsdom implements DOM level 2 so you could actually mimic the javascript run in webpages (ie it would actually properly evaluate document.write() embedded in script tags). Web page scraping libraries in other languages won't have this feature easily because other languages will need to include a javascript interpreter along with their DOM emulator. I believe there's a java library out there that makes use of rhino to do this (htmlunit) but it took them quite some time to get there (several years). Most of the hard work in jsdom was implemented in a few months.
      - deleted 16y ago
        [deleted]
  - r00fus 16y ago
    Not to mention, JavaScript unlike many other server-side languages, supports closures. It's quite an advanced language, once you get used to it's (many) peccadilloes.
  - Klonoar 16y ago
    You know, I'll just throw this out there: as someone who's written a lot of code with Node backing it, I've run into maybe one scenario where I've brought client and server side logic together. They are two separate models, and will most likely remain as such for the foreseeable future. While I can only speak for myself, I'd advocate using it because the language is indeed nice, and much more flexible overall than some of the alternatives. On top of that, it's got several large companies with a vested interest in its development, which is far more than can be said for some of its competition. Really, the point I'd like to counter here is this: your productivity does not skyrocket, and it's not necessarily the reason to want to use JS server side. For example, the JS syntax works incredibly well for event based programming, and is largely tried and true with its use client side. That's a reason to want JS on the server, and I really wish people would quit throwing around the reusability claim like they do.
- dspillett 16y ago
  My thoughts on that question: * The convenience of not needing to switch mind-sets so much between server and client side, if you are working on both (rather than being part of a large team so you are working on one and can pretty much ignore the other). Even if the environment is very different between client and server sides, you are at least not switching syntax all the time. Having a common data transfer structure (JSON) that is native to both client and server (so aside from input validation that you'd have to do on any structure, there is potentially less formatting and/or parsing code for you to write/debug) can be handy too. * The potential for shared code. For most simple cases this isn't significant (needing to map between the DOM and your server-side state or vice-versa cause more hassle than the code sharing saves), but if you have an app that has a lot of business logic client-side in order to reduce round-trips and so improve the user experience, you don't need to entirely reimplement input validation code (because you don't trust the client, right?) in a second language on the server, or the rest or the logic if you want to have a relatively-script-less screen-reader-friendly version fo accessibility reasons. I've not used node.js in anger (I keep updating the install I have on my personal server, in the hope I will one day soon have enough free time to play a little by implementing one of my daft-little-idea side projects in it), but I have used javascript server-side for these reasons professionally (under IIS with "classic" ASP a few years ago, before node.js or most of the other current SSJS implementations were in existence or known to me). I must say though that good opportunities to make use of this code sharing are a lot less common than some people make out. * Javascript itself is quite a nice language. Certainly not without its faults (end-of-line handling being one of my key gripes) but generally a language that I like working with, certainly more so than PHP or Perl. A lot of people conflate DOM and CSS related compatibility headaches with Javascript problems. "JavaScript: The Good Parts" is a book worth scanning for the things that make the language "right" (the book does have a chapter touching on the things that are less than right too). * node.js isn't just about Javascript - server-side JS has been around in various forms for quite some time (see http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaScript_solutions http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaS... for a list). Its event driven asynchronous nature is quite different to the thread or process based servers many people are used to, which piques people's interest (either purely academic interest, because of the memory/CPU efficiency this can give you if put to good use, or because they might prefer that way of working as it solves some other problem they've had with other approaches). How quickly node.js is growing from interesting curiosity to relative mature architecture also helps it garner interest (other server-side JS solutions have stagnated as the early adopters/experimenters moved on due to lack of progress), especially since it hit the magic critical mass needed to fuel an amount of self perpetuating coverage (people talk about it, so others learn about it, so they talk about it, ...). Of course it may be that none of the above applies to you or your projects in a useful way, in which case you don't want to use Javascript serverside and are likely to be better off sticking with (or learning) something else.
Detrus 16y ago
Article is pretty weak on the details. This guy http://nodetuts.com/ http://nodetuts.com/ has video tuts on using Express, Jade and Mongoose to make a simple web service.
- travisglines 16y ago
  I wanted to gauge interest. I think its pretty clear that people want a way more in depth tutorial/article and I'll put one together. I'll try and make it chock full of details this time around. The tutorials on nodetuts are solid.
  - schwabacher 16y ago
    This, along with the JSONloops stuff, inspired me to finally download and play around with node. I would definitely be interested in a more in depth tutorial, specifically more on setting up mongodb and connecting mongoose and on how to break controllers out from the main app.js file.
eaxitect 16y ago
I don't think node.js is a replacement for fully-fledged framework. Rather, i believe, it's a backend for high-performance parts like real-time streaming API or something. Although the setup is neat, and obvious, I believe it's way worse to develop at this stack.
- travisglines 16y ago
  I keep hearing this and am curious: Why don't you think node.js is a fit for a fully fledged dynamic website? What things is it missing? I know its been used as a high performance tool historically but whats holding it back from becoming more?
  - eaxitect 16y ago
    actually, I agree with you, but for now, node.js has to has more features like templating, UI flow, etc. injected into the way node.js handle requests. I've asked the same question for Sinatra earlier today, and got my answers.
    - travisglines 16y ago
      This is what the add on modules do such as jade. Check out jade-lang.com ... basically why I wrote the blog post was to show that with the use of a libraries node can compete with the best web frameworks.
- Charuru 16y ago
  3 months ago I would agree. But just recently many things have come together for node.js. uglify.js, mongoose, and stylus, just to name a few.

28 points by travisglines 16y ago

lwat 16y ago

Tell me again why we want to use Javascript server side?

travisglines 16y ago
Is that sarcastic based off of stuff I've said before? Or just a serious question? If its serious is basically boils down to event driven architectures (node,tornado etc) vs. thread driven (apache) and how they can typically handle concurrency better.
- deleted 16y ago
  [deleted]
- deleted 16y ago
  [deleted]
Groxx 16y ago
Javascript is fantastically flexible for its popularity. And then you get the advantage of doing all your coding in a single language. Out of curiosity: do you just generally dislike JavaScript as a language? And remember that Node doesn't run in a browser, so this would be ignoring any browser problems. I, personally, have been liking it a lot, and more-so as I go deeper down the rabbit hole.
dstein 16y ago
The JavaScript language isn't what's nice. What's nice is using one programming language to write an HTTP server, your server application, server templates, client-side application, client-side templates, communication code, database code, and be able to share your libraries and models between all contexts simultaneously. You fix one bug in one place, and you've fixed the bug in 7 or 8 different contexts immediately. In other words, your productivity skyrockets.
- lwat 16y ago
  Maybe I just need to see it to understand it. Is there a non-trivial app on github or somewhere I can look at? One that shows the strong side of Node.js?
  - catch23 16y ago
    There are great non-blocking IO examples out there which are pretty easy to find (look at any database, file system, or networking library), but I think jsdom is a rather unique library that is hard to find in other languages: https://github.com/tmpvar/jsdom https://github.com/tmpvar/jsdom jsdom implements DOM level 2 so you could actually mimic the javascript run in webpages (ie it would actually properly evaluate document.write() embedded in script tags). Web page scraping libraries in other languages won't have this feature easily because other languages will need to include a javascript interpreter along with their DOM emulator. I believe there's a java library out there that makes use of rhino to do this (htmlunit) but it took them quite some time to get there (several years). Most of the hard work in jsdom was implemented in a few months.
    - deleted 16y ago
      [deleted]
- r00fus 16y ago
  Not to mention, JavaScript unlike many other server-side languages, supports closures. It's quite an advanced language, once you get used to it's (many) peccadilloes.
- Klonoar 16y ago
  You know, I'll just throw this out there: as someone who's written a lot of code with Node backing it, I've run into maybe one scenario where I've brought client and server side logic together. They are two separate models, and will most likely remain as such for the foreseeable future. While I can only speak for myself, I'd advocate using it because the language is indeed nice, and much more flexible overall than some of the alternatives. On top of that, it's got several large companies with a vested interest in its development, which is far more than can be said for some of its competition. Really, the point I'd like to counter here is this: your productivity does not skyrocket, and it's not necessarily the reason to want to use JS server side. For example, the JS syntax works incredibly well for event based programming, and is largely tried and true with its use client side. That's a reason to want JS on the server, and I really wish people would quit throwing around the reusability claim like they do.
dspillett 16y ago
My thoughts on that question: * The convenience of not needing to switch mind-sets so much between server and client side, if you are working on both (rather than being part of a large team so you are working on one and can pretty much ignore the other). Even if the environment is very different between client and server sides, you are at least not switching syntax all the time. Having a common data transfer structure (JSON) that is native to both client and server (so aside from input validation that you'd have to do on any structure, there is potentially less formatting and/or parsing code for you to write/debug) can be handy too. * The potential for shared code. For most simple cases this isn't significant (needing to map between the DOM and your server-side state or vice-versa cause more hassle than the code sharing saves), but if you have an app that has a lot of business logic client-side in order to reduce round-trips and so improve the user experience, you don't need to entirely reimplement input validation code (because you don't trust the client, right?) in a second language on the server, or the rest or the logic if you want to have a relatively-script-less screen-reader-friendly version fo accessibility reasons. I've not used node.js in anger (I keep updating the install I have on my personal server, in the hope I will one day soon have enough free time to play a little by implementing one of my daft-little-idea side projects in it), but I have used javascript server-side for these reasons professionally (under IIS with "classic" ASP a few years ago, before node.js or most of the other current SSJS implementations were in existence or known to me). I must say though that good opportunities to make use of this code sharing are a lot less common than some people make out. * Javascript itself is quite a nice language. Certainly not without its faults (end-of-line handling being one of my key gripes) but generally a language that I like working with, certainly more so than PHP or Perl. A lot of people conflate DOM and CSS related compatibility headaches with Javascript problems. "JavaScript: The Good Parts" is a book worth scanning for the things that make the language "right" (the book does have a chapter touching on the things that are less than right too). * node.js isn't just about Javascript - server-side JS has been around in various forms for quite some time (see http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaScript_solutions http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaS... for a list). Its event driven asynchronous nature is quite different to the thread or process based servers many people are used to, which piques people's interest (either purely academic interest, because of the memory/CPU efficiency this can give you if put to good use, or because they might prefer that way of working as it solves some other problem they've had with other approaches). How quickly node.js is growing from interesting curiosity to relative mature architecture also helps it garner interest (other server-side JS solutions have stagnated as the early adopters/experimenters moved on due to lack of progress), especially since it hit the magic critical mass needed to fuel an amount of self perpetuating coverage (people talk about it, so others learn about it, so they talk about it, ...). Of course it may be that none of the above applies to you or your projects in a useful way, in which case you don't want to use Javascript serverside and are likely to be better off sticking with (or learning) something else.

Detrus 16y ago

Article is pretty weak on the details. This guy http://nodetuts.com/ http://nodetuts.com/ has video tuts on using Express, Jade and Mongoose to make a simple web service.

travisglines 16y ago
I wanted to gauge interest. I think its pretty clear that people want a way more in depth tutorial/article and I'll put one together. I'll try and make it chock full of details this time around. The tutorials on nodetuts are solid.
- schwabacher 16y ago
  This, along with the JSONloops stuff, inspired me to finally download and play around with node. I would definitely be interested in a more in depth tutorial, specifically more on setting up mongodb and connecting mongoose and on how to break controllers out from the main app.js file.

eaxitect 16y ago

I don't think node.js is a replacement for fully-fledged framework. Rather, i believe, it's a backend for high-performance parts like real-time streaming API or something. Although the setup is neat, and obvious, I believe it's way worse to develop at this stack.

travisglines 16y ago
I keep hearing this and am curious: Why don't you think node.js is a fit for a fully fledged dynamic website? What things is it missing? I know its been used as a high performance tool historically but whats holding it back from becoming more?
- eaxitect 16y ago
  actually, I agree with you, but for now, node.js has to has more features like templating, UI flow, etc. injected into the way node.js handle requests. I've asked the same question for Sinatra earlier today, and got my answers.
  - travisglines 16y ago
    This is what the add on modules do such as jade. Check out jade-lang.com ... basically why I wrote the blog post was to show that with the use of a libraries node can compete with the best web frameworks.
Charuru 16y ago
3 months ago I would agree. But just recently many things have come together for node.js. uglify.js, mongoose, and stylus, just to name a few.