4 ms·
I think part of the "problem" is that Node represents two different "radical" ideas together: first, using JavaScript on the server, and second, using evented/r
by tolmasky 14y ago
I think part of the "problem" is that Node represents two different "radical" ideas together: first, using JavaScript on the server, and second, using evented/runloop programming. As such, the discussions become kind of confused. For example, not being someone too excited about Node myself, I still found this particular article kind of strange: I see no issue at all with using JavaScript on the server and in fact think that's the best part about Node. I am on the end of the spectrum where I don't even understand the point of discussing what language "deserves" to be on the server.
However, due to the hyper success of Node, we were left in this strange place where Node became the defacto JavaScript platform, and you can't really use JavaScript on the server/desktop without it (you can I guess, but don't expect anyone else to be able to use your code easily). As such, I think part of the reason you have people who want to use Node "for everything", is that a lot of them just actually want to use JavaScript "for everything", which is a less contentious issue in my opinion. In a world where you had "JavaScript on the server", and the optional "Node library" where you could do evented programming, vs. a different Rail/synchronous style library, you'd have something that looks a lot more like the other programming worlds.
I for example want to use JavaScript as my ideal scripting environment on the desktop, which is not that well suited for the asynchronous model of Node (just reading a bunch of files, operating on them, and then spitting out a new file can be kind of tedious with this model -- I'm not really waiting on anything or trying to hold a million open connections simultaneously). JavaScript itself I think competes just fine against Python and Ruby for these tasks, but again we can't really compare them in this abstract way, we have to compare JavaScript in the particular way it exists in Node, which brings along a lot of opinionated asynchronous APIs.
- wtracy 14y agoIt seems odd to me that we had Javascript as pretty much the default server-side scripting language back in the Netscape days, then JS on the server pretty much disappeared as IIS and Apache took over, and now with Node Javascript on the server is "new".
- josephcooney 14y agoJavascript was popular-but-not-dominant as the server-side scripting language for 'classic' ASP (vbscript was also used), which died out a lot around 2002 with the release of .NET.
- apaprocki 14y agoWe adopted server-side Javascript at Bloomberg to build all of the applications for the terminal starting in 2006 using a custom environment built around Spidermonkey. So Node isn't that new a concept around here :)
- eurleif 14y agoV8 isn't really designed to run multi-threaded code, which makes sense, since it's designed to run JavaScript code for the browser, and browser JS is single-threaded (except for Web Workers, which are isolated, and isolation requires a different style of code just like asynchronicity does). Here's one effort to add multithreading to V8: http://code.google.com/p/v8-juice/wiki/ThreadingInJS http://code.google.com/p/v8-juice/wiki/ThreadingInJS However, it has limitations because V8 isn't really intended to be used that way. If you just want to write code in blocking style, you can use asyncblock with node.js: https://github.com/scriby/asyncblock https://github.com/scriby/asyncblock
- xtian 14y agoNode has synchronous file I/O APIs for the use case you mention.