Node.Js (Thoughts, Questions, ect)

Discussion in 'General Webmaster Support' started by rover2341, Jan 27, 2014.

  1. rover2341

    rover2341 Is riding a roller coaster...Wee!

    +114 / 0 / -0
    Ok So I have been hearing good things from node.js from my brothers friend. and I have kept iqnoreing him. in-till last night i decided to check it out.

    (Note I may be wrong this is my impression from a day or 2 of looking at videos on sites)

    What is Node.Js And what is its purpose
    • Server side Code in JavaScript
    • All Functions are async
    • Long Pooling (Only sends header once, keeps connection alive)
    • Single Thread (No Memory Sharing)
    • Free
    To use more then one thread you have to treat it almost as if it was on another computer. The plus is this forces you to get ready to use Multi-computing structure right away, and not allow the program to get complex to the point it may become more difficult to deal with multiple computers.
    Purpose: "
    easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices."
    Or in my words. scalable web api's that are async. minimum overhead and features that use long pooling.
    So.. To me that means... Its able to do many things, but its goal is to have a reduced structure, and a heavily focused goal. Its also suppose to be faster. not javascrpit vs java or javascrpit vs .Net. but for non heavy cpu tasks faster to use in place of a general purpose web api.
    • Due to its everything async attitude, it doesn't allow anyone to lock of the program on there function by adding lets say a 10 sec wait. Its all async.
    • Due to its single thread attitude, If you need to scale your program, your treating every thread like its on another computer so its design for scale is setup at the start. where it could get more complex. Not to say you couldn't do this with any other frameworks it just not forced.
    • Due to long pooling, speeds up sending data and getting data. Easier to deal with large files.
    • (Debate-able) Front end And Back End is in a single language so its more simple.
    • (I don't have enough proof on this, likely true though) Faster then doing the same type of solution on another framework like using single threads and long pooling.
    • Free
    • (I don't have enough proof on this, likely true though) Javascrpit in general is slower then other lanqaqes like Java or . Net. If you had a heavy cpu task it may become a problem, later down the road.
    • No intellsense
    • Debugging it is still being worked on, and not quite polished
    • Its JavaScript, a lose language, in my mind less safe then java/c#.
    Nearly all of the things it does can be done with other frame works. And other frameworks allows other options. So your not limited or forced to do it a certain way. But that's not necessarily a good or bad thing.
    Thoughts? Am i way off base? What do you think of Node.js Would you use it? Do you use it? why should/shouldn't you use it?


    The more i read on it people say... "The only purpose to Node.js is to have Javascript support as a runtime environment." so not sure if thats true. but if thats true then maybe i am way off base.
  2. monoVertex

    monoVertex I'm back!

    +459 / 0 / -0
    You have a bit of misguided view of Node.js. While it's true it allows you to implement a HTTP Server, it does much more.

    It's basically an environment that allows you to run JavaScript code on a machine, not only in the browsers. You can create an analogy with Python: you install the Python environment (Node.js), you can install various packages like VirtualEnv, Watchdog (LESS, CoffeeScript), etc.

    This means that you can also create terminal-based applications and virtually any application, just like you can with Python. I'm not sure if you can do GUI yet...

    This range of applications also encompasses HTTP Servers.

    This also changes a bit your async view. You can do the application however you want. JavaScript was created with async in mind, since the DOM events are async, but the application you create can be however you want.

    Now, if you implement a HTTP Server, then it's pretty obvious that you should use a number of workers (threads / processes) that will respond to requests in an async way. Now, nothing stops you from creating a single-threaded server (whether in JS, Python, C, whatever), but that will not be fast at all and it will bottleneck on every CPU-intensive task, unless there's a scheduler to switch the work from one task to another on that thread (like the OS does with threads, anyway).

    Now, Node.js uses a single thread and they probably achieve the async through such a scheduler, because you can't do multiple tasks on a single thread at the same time, that's just an illusion by the fast switches done behind the curtains. This means that you're getting async, but your tasks will not really be parallel, with the benefit that you don't have to worry about sharing memory between threads / processes. So you're trading something anyway.

    Now, on the topic of JS's usefulness, keep in mind that JS is not intended for this kind of work. It will be slow and it's not the best language to code a HTTP server in. However, it's great at other stuff, such as LESS / CoffeeScript / SASS compilers, documentation generators for JS and so on.

    While JS is not as fast as its counterparts, do note that JS is an amalgam of OOP, functional and imperative programming, so you can find some advantages in the way it does other stuff, or simply enjoy the async coding style. This is why I love JS, because I can do some constructs I can't do in other languages, especially when combining OOP and functional programming.

    Concerning Intellisense / debugging, that's still young. You do have a good debugger in Chrome, but that's only for web JS. Don't forget that Node.js started as an experiment and it will never prove to be a fair replacement for Python, Java, C, etc. when discussing heavier, more low-level tasks, such as implementing a HTTP Server.

    Finally, on the safe thing. The good thing with JS is that you'll never get a segfault :D (god, I dreaded those in C). It's an interpreted language and it's not strong typed, so it's your responsibility to ensure that you're using correct values. You see Java and C because they're compiled, but they are also low-level. You can't do meta-programming in Java and C (changing the code in run-time) especially because in this. However, in JavaScript you can (hell, you can change everything).

    I myself played a bit with Node.js HTTP server solution (can't remember the name), but I abandoned it quickly because it's clearly not suited for production, except maybe in some special cases. I use it for LESS and CoffeeScript compiling, also I'm using a crude HTTP-server package with creates a static HTTP file server in a certain directory and binds it on a port. When working on something that only runs in the Client (mock-ups or JS-only stuff), it's way faster to test in this way.
  3. rover2341

    rover2341 Is riding a roller coaster...Wee!

    +114 / 0 / -0
    k that helped Borden my view on it. Thanks.

    Only thing I may still be confused on is I understand more or less whats going on with it when everything is on a single thread that they must have some sorta scheduler "fast switches done behind the curtains".

    But a single threaded program (that happens to have everything async) vs a node.js is pretty much the same thing. Expect for the fact one is JavaScript and one is not. Right? as they both would have some sorta scheduler for the functions being ran async.

    But I think what your were geting at, and what i was missing. Is node.js brings JavaScript out of the broswer and on the computer, where it can be used for in theory at least for pretty much anything.

    And the fact that it is JavaScript, allows you to do many things that you can do with JavaScript but now on server. and due to the way JavaScript is designed it can for some purposes make the most sense to use. Its not meant be used in place of what exist. so its not so much A Vs B. But that it has been opened up now, and for some purposes make more sense to use.

    Also interesting that you use it for testing, with less or LESS and CoffeeScript compiling.

    Cool Thanks
  4. monoVertex

    monoVertex I'm back!

    +459 / 0 / -0
    No, there is no difference, at least that's how I understand it. But you also need a language that can handle async stuff without threads or processes.

    Not only servers, but personal computers as well.

    But, yes, generally JS was designed for DOM interaction. I mean, it didn't had file system interaction capabilities, for example. But for Node.js, they had to add that (d'uh, it's fairly necessary for a Web Server, to start with).

    Now, what I said was largely based on what information I gathered from reading here and there, what I experimented and what I know from Uni. I never actually benchmarked a Node.js Web Server, but I'm sure you can find such things on the net :).

Share This Page