5 ms·

I want to cite a answer from Quora by Michael Hanson(http://www.quora.com/Michael-Hanson http://www.quora.com/Michael-Hanson): The use of client-side JavaScrip

I want to cite a answer from Quora by Michael Hanson(http://www.quora.com/Michael-Hanson http://www.quora.com/Michael-Hanson): The use of client-side JavaScript is uncontroversial - most anybody who is targeting the web browser as their client platform will choose to use JavaScript to implement the client user interface and logic. Many client applications which required plugins or native code can now be implemented in JavaScript using advanced HTML5 features. I presume your question is actually… why server-side JavaScript? One language, one toolset The use of a single platform on the client and server means that developer skills will transfer more easily from client to server work. This can lead to more consistent project quality and easier developer scheduling. DOM and library portability By using JavaScript everywhere, it is possible to have the same functions on both the client and server, and to run them "close to the data" to avoid unnecessary latency and bandwidth costs. Using libraries like jsdom, it is even possible to write DOM manipulation code on the server, so that more capable clients can render the UI on the client while backwards-compatibility (with IE6, for example) is maintained through server-side rendering. Node.js and asynchronicity The use of server-side JavaScript is still quite new, however, and the critical development there is node.js. By using node.js, developers can implement fast, JIT-compiled, garbage-collected server logic, with libraries that enforce asynchronicity. Asynchronous servers are (usually) able to deliver more application throughput than threaded servers on the same hardware, but asynchronous (or "event-based", or "non-blocking") server programming has traditionally been very difficult and error prone. JavaScript, by the fact of being a highly dynamic functional language, tends to make writing event-based programs a bit simpler, or at least easier for the average programmer to comprehend. For more background on event-based server programming, read up on Twisted and libevent, and read the classic papers "Threads: Threat or Menace?", "Why Threads Are a Bad Idea (For Most Purposes)", and "Threads Considered Harmful". Source : http://www.quora.com/Why-would-someone-want-to-build-an-entire-application-using-only-JavaScript-client-and-server-side/answer/Michael-Hanson http://www.quora.com/Why-would-someone-want-to-build-an-enti...

thirsteh 13y ago
Threads are not a menace if implemented correctly. Note how almost every evented system is written in a language with horrible threads support, e.g. Python. Take a language like Go or Haskell, and threads become a highly performant (by virtue of transparently asynchronous I/O operations) means of writing code with many threads of control, and saves you from getting bundled up in callback spaghetti. (I love Twisted, but I really don't miss the callback spaghetti it inevitably causes. InlineCallbacks made it nicer, but it was still a pain.) If you absolutely want to use JavaScript, then yes, you'll be writing event-driven code using a continuation passing style. JavaScript is probably one of the better languages for doing so, since the language is fundamentally single-threaded, and so virtually everything is asynchronous. The biggest argument for this is that you don't have to worry about synchronization. But please don't imply that event-driven programming is The One Way, or even the right way at all. If you want to scale, then you will eventually need to consider threading of some kind, whether it be the poor man's kind that Python and Node use, spawning multiple processes, or the good kind, fibers that automatically multiplex onto OS threads, as the Go and Haskell runtimes implement. Even the async poster-boy, nginx, does this via its workers.
- techaddict009 13y ago
  Said it true.
- drorweiss 13y ago
  While it's true that threads are ok if implemented correctly, one needs to be smart to correctly work with threads, and still any concurrent code will be ~10x more expensive to write and maintain. In my perspective lack of threads is a blessing because it takes this complexity out of the equation. On the other hand, working with async callbacks also takes training and more careful thought of the bindings and closures. For me, after 6 months with node, I can say that I like it. It's superfast, ample modules to work with, and javascript is very convenient for working with data.
  - thirsteh 13y ago
    Yeah, like I said, running single-threaded, e.g. in Python with the GIL, or in JavaScript, saves you having to worry about synchronization. But that should be the only big argument for it, not performance and scalability.
bifrost 13y ago
> The use of server-side JavaScript is still quite new I'm not sure I'd say that, I talked with a few companies that were doing it in the early 2000s, but it wasn't exactly widespread. I vaguely remember at the time the only interpreter was available for Windows, and maybe not a *NIX-like platform so it wasn't really moving.
- TheZenPsycho 13y ago
  Ahem, http://en.wikipedia.org/wiki/Netscape_Enterprise_Server http://en.wikipedia.org/wiki/Netscape_Enterprise_Server note: version 1.0 is from 1994

thirsteh 13y ago

Threads are not a menace if implemented correctly. Note how almost every evented system is written in a language with horrible threads support, e.g. Python. Take a language like Go or Haskell, and threads become a highly performant (by virtue of transparently asynchronous I/O operations) means of writing code with many threads of control, and saves you from getting bundled up in callback spaghetti. (I love Twisted, but I really don't miss the callback spaghetti it inevitably causes. InlineCallbacks made it nicer, but it was still a pain.) If you absolutely want to use JavaScript, then yes, you'll be writing event-driven code using a continuation passing style. JavaScript is probably one of the better languages for doing so, since the language is fundamentally single-threaded, and so virtually everything is asynchronous. The biggest argument for this is that you don't have to worry about synchronization. But please don't imply that event-driven programming is The One Way, or even the right way at all. If you want to scale, then you will eventually need to consider threading of some kind, whether it be the poor man's kind that Python and Node use, spawning multiple processes, or the good kind, fibers that automatically multiplex onto OS threads, as the Go and Haskell runtimes implement. Even the async poster-boy, nginx, does this via its workers.

techaddict009 13y ago
Said it true.
drorweiss 13y ago
While it's true that threads are ok if implemented correctly, one needs to be smart to correctly work with threads, and still any concurrent code will be ~10x more expensive to write and maintain. In my perspective lack of threads is a blessing because it takes this complexity out of the equation. On the other hand, working with async callbacks also takes training and more careful thought of the bindings and closures. For me, after 6 months with node, I can say that I like it. It's superfast, ample modules to work with, and javascript is very convenient for working with data.
- thirsteh 13y ago
  Yeah, like I said, running single-threaded, e.g. in Python with the GIL, or in JavaScript, saves you having to worry about synchronization. But that should be the only big argument for it, not performance and scalability.

bifrost 13y ago

> The use of server-side JavaScript is still quite new I'm not sure I'd say that, I talked with a few companies that were doing it in the early 2000s, but it wasn't exactly widespread. I vaguely remember at the time the only interpreter was available for Windows, and maybe not a *NIX-like platform so it wasn't really moving.

TheZenPsycho 13y ago
Ahem, http://en.wikipedia.org/wiki/Netscape_Enterprise_Server http://en.wikipedia.org/wiki/Netscape_Enterprise_Server note: version 1.0 is from 1994