Welcome to the Treehouse Community

The Treehouse Community is a meeting place for developers, designers, and programmers of all backgrounds and skill levels to get support. Collaborate here on code errors or bugs that you need feedback on, or asking for an extra set of eyes on your latest project. Join thousands of Treehouse students and alumni in the community today. (Note: Only Treehouse students can comment or ask questions, but non-students are welcome to browse our conversations.)

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and a supportive community. Start your free trial today.

JavaScript Build a Simple Dynamic Site with Node.js HTTP Methods and Headers Perfection Suggestions

Kevin Faust
Kevin Faust
15,353 Points

i dont understand why i would use Node

hi,

i just completed the Node: build a simple dynamic site with node.js

I am still not sure when to use node. i feel like what we did in this course could just be done with ajax. we simply got treehouse information by its api and then updated our website.

what is the point of creating a server, routing, etc? when would i use node over a normal webpage setup? (in this course we extracted the html into different files and did a bunch of seemingly overcomplicated things for such a simple task).

maybe im missing something but i just dont understand at all how i would incorporate this into say, a personal project.

thanks

Anthony c
Anthony c
20,907 Points

I feel like Treehouse should have all their classes revolve around building a social networking app (or some real-life app... not a todo list though!). Then you can see how different languages go about solving the same problems. Plus it also gives a common goal that the different tracks and courses can build towards... and more importantly a COMMON METAPHOR to use throughout every course.

And most production apps and places you would work at will be building something that uses one or more of the features you'd see on a social networking app...

In other words, I agree that sometimes I leave a class like "Okay... I know some concepts and vocabulary... but I would not be able to go jump on a software team using this technology to build a real app".

A lot of classes should start by explaining where in the "Stack" the given tech or language is used... the big picture. It would also help to point out some well-known libraries/options and also what the alternatives are.... so you can piece together what works with what VS. what is a substitute for what... like Jade/Ember/Angular/React are substitutes for each other.... PHP/Java/Node are substitutes for each other.... Jade is not a substitute for PHP.... this stuff is obvious now but is tough for beginners to just find the straight answer here.

3 Answers

Anthony c
Anthony c
20,907 Points

Hi,

Node is something that would replace PHP/Ruby/Java. These are "server-side" languages.

To oversimplify things, imagine you're building a social networking app:

  1. you have your front-end (html/css/javascript/jquery/angular/whatever it may be).
  2. Then you have the server-side languages
  3. Then you have your database.

It's like a little sandwhich with the server-side code in the middle:

FRONT-END CODE ---||--- SERVER-SIDE LANGUAGE ---||--- YOUR DATABASE

The server-side languages sit between your front-end code and your database. So PHP/NODE/Railes/Java are the languages that will update/delete/add/etc. to whatever database you use (SQL/Mongo whatever your choice is).

For example, the front-end of your social network app may have an "add post" button. When the user clicks it, some jquery/javascript is fired. That jquery/javascript is signaling to the server-side language. Then the server-side language is then interacting acting with the data.

and vice-versa, if your app requests some data, it is the server-side language (i.e. the code on the server) that talks to the database, and then the server-side language that will send the data to the "front-end" (or the "client" a.k.a. the user's browser window).

Bottom Line: If you are trying to interact with a database--- for instance if your personal website is a blog, or has a contanct form that saves user input or sends you an email--- then you will most likely need to have a server-side language that will sit in between your client-side (aka front-end code) and the database the form is being sent to.

That is where you have to decide if you want to use node or another language (ruby/java/PHP and many others).

Server-side languages can handle other stuff too-- as you saw: Like calling an API for data, handling security (for instance, handling sign up or log in if your app needs that), or again, acting on a database.

Other Notes: server languages also handle routing and sometimes rendering... that means, Node/PHP/Java will be the language you use to decide which HTML templates get sent/viewed based on the "route" the user is on. It also "renders" that html view... render is like compiling all the stuff onto one specific html page (or "view")... so it may compile (aka render) different components, JS, and data to create that specific user's view.

Warning: This is an over simplification of things.... but it gives you the high-level idea: the server languages sit between the database and your front-end code. They handle talking to your database and other things that you wouldn't want happening in your front-end code (mainly for security reasons-- but other reasons too).

In reality you unfortunately would have tons of other frameworks and libraries involved beyond just "front-end code" "server-side language" and "database"-- things like Grunt and Express and many others--- but they aren't important for the concept your question is looking to understand.

EDITED: corrected answer to refer to ruby as Kevin pointed out. Although you will most likely be hearing and using the more well-known framework Ruby on Rails (a.k.a. "Rails")

Kevin Korte
Kevin Korte
28,135 Points

I just want to clarify that Rails is NOT a language, it's a framework. You are probably aware of this, as later in your response you mentioned Ruby instead of Rails, but I feel strongly it's important to not confuse frameworks with languages.

Kirill Babkin
Kirill Babkin
19,940 Points

i guess another reason to use server side language for such tasks is that js can be disabled by user

that you wont be able to make req. or authenticate user.

Kevin Korte
Kevin Korte
28,135 Points

Client side js, correct. Server side js like node, the user can't disable.

A node js site would still work, handle requests, etc if the client disabled js. You have the exact same problem in this case as you would with any other server side language.

Kevin Korte
Kevin Korte
28,135 Points

Which by the way, I had the same initial though as you. I thought what happens if the client has js disabled. But it doesn't matter cause your browser will still send http resquests, and js on the server will still respond to them. :)