11 ms·

The more time goes by the more I feel crazy for missing whatever would motivate people to use js for anything more than is strictly necessary. Single threaded s

The more time goes by the more I feel crazy for missing whatever would motivate people to use js for anything more than is strictly necessary. Single threaded server??? I mean come on man, I understand you don't need parallelism for a lot of use cases but even if that fits your situation why javascript? It can't be that hard using a different language. I refuse to believe that.

lunchables 9y ago
I just tell myself it's because the sales pitch is so appealing: learn, and use, one programming language on the front end and back end of your web site. I've never written anything on node.js, but that's the only argument that's ever given me pause.
- alayek 9y ago
  You should try. I come from a traditional Java shop, and a year ago wouldn't have thought of doing anything serious with Node JS. Today, I do front-end React stuff as well as back-end servers with Node JS. I have been happy with it so far. With some type-system like Flow or TypeScript, you can manage huge projects in Node JS. I happen to like the community, CLI tools written in Node, and the plethora of open source libraries built on top of Node. This also has a downside. Your libraries can get outdated quite fast, you would have to keep up with new language syntaxes etc., and remember which syntax is supported by which version of Node etc. But so far, I think Node is headed in the right direction.
- falcolas 9y ago
  It honestly doesn't give me pause, since the impedance mismatch between JavaScript and backend programming is so great. To me, the fact that Node has to add a library with custom semantics just to allow a basic 'open' on a file handle is a huge warning flag to me.
  - todd3834 9y ago
    What does it warn you about? Not trolling, honest question.
    - falcolas 9y ago
      That JavaScript was not designed to work as a *nix (or Windows for that matter) server language. And that any attempts to make it work as a server language are going to include some major workarounds to fit that round peg into a square hole. You can still make it work; but you can script a web page's interactions in C as well. That doesn't make it the right thing to do.
      - ovao 9y ago
        I'm not a particular fan of JavaScript on the server these days, but when you have a large number of developers who know JavaScript from the front-end world and a language ecosystem that's quite large and relatively robust, I would argue that doing those "major workarounds" (which aren't so major, really) to make server-side JavaScript an accessible option at least very closely resembles the "right thing to do". Should we collectively eschew what's possible due to individual language gripes?
        fundabulousrIII 9y ago
        No. We should collectively evaluate competency and correctness of a developer and language for it's best purpose as in any adequately run job interview.
        ovao 9y ago
        > collectively evaluate competency and correctness of a developer I'm sorry, is this a dig at Ryan Dahl, or of JavaScript/Node developers in general? I'm having trouble understanding what point you're addressing with this comment. As for evaluating languages for their "best purpose", I think that's a very complex discussion that doesn't necessarily yield a best (or cost effective/productive) result. And certainly, as we've seen routinely evidenced, using a different language on the server is no panacea.
  - woah 9y ago
    Js is a scripting language that relies on the program being scripted to interact with the outside world. In browsers, this is the DOM and xhr APIs. On servers, this is the node stdlib which lets you interact with the system. The fact that this kind of modularity bothers you is bizarre.
    - thehardsphere 9y ago
      It is a modularity that is an unnecessary point of failure compared to other choices available, and involves poor abstractions for Javascript to use things it was not intended to use.
  - devnill 9y ago
    >To me, the fact that Node has to add a library with custom semantics just to allow a basic 'open' on a file handle is a huge warning flag to me What do you mean? The fs module shipped with node is pretty much just a wrapper for libc. Hell, it even links to the open(2) manpage in the docs for usage information.
  - deleted 9y ago
    [deleted]
  - ridiculous_fish 9y ago
    Favorite node / libc impedance mismatch is the stat() call. stat() returns an inode, which is a 64 bit integer. But JS doesn't have 64 bit integers, so it just gets rounded to the closest representable double. So node will sometimes identify two different files as the same file. https://github.com/nodejs/node/issues/12115 https://github.com/nodejs/node/issues/12115
  - collyw 9y ago
    Its been a while since I wrote and Java, but when I did you needed a page of code just to open a file.
  - Larrikin 9y ago
    Kotlin is slowly becoming s language that can do all of that. It's production ready for anything that uses java, js support is coming along great, and their slowly moving towards native.
- ashark 9y ago
  The front end/back end sharing argument never appealed to me. In practice, how much are you actually going to be able to share? No way it's worth it. What's finally got me writing way more Javascript than I'd like to is React Native. It's by far the easiest way I know of to share code between iOS and Android, it papers over a lot of Android's irritating/broken UI bits (introducing others, but overall improving the situation), and you actually can share much of your code (practically everything but the UI layer) with a web client—and even... spits... Electron. RN's performance isn't even terrible, especially compared to cross-platform mobile frameworks that have come before it (and to Electron spits) Hopefully Webassembly will save us in another couple years, and we'll be able to do the same thing in any of several much better languages. [EDIT] though definitely keep your sanity and use Typescript. I'd have probably jumped off a bridge by now if I were having to do all this in actual JS, of any flavor.
  - jtmarmon 9y ago
    the front/backend sharing stuff matters more these days with server side rendered apps, but I've used nodejs plenty for this lifetime and have no plans to touch the stuff again for serious applications
    - duderific 9y ago
      It's kind of funny how you say "these days with server side rendered apps". At one time not so long ago, there were only server side rendered apps.
  - Someone 9y ago
    I think most of what you share is the effort needed to learn the language. Also, it 'helps' if both server and client are single-threaded, because then, you can use similar solutions on both server and client (even if they sometimes aren't the most pleasant approach for solving your domain) I hope that Web Assembly will take of and get a decent interface to the DOM, allowing developers to pick other languages in the role that JavaScript now has.
randiantech 9y ago
Javascript as a language and ecosystem has evolved quite dramatically during the last years. Its not perfect though: it lacks features and ecosystem is still not in the level of maturity of other platforms, but is definitely going in the right direction. Regarding the single threaded server, its an architecture used before JS exists, and used by many other platforms/systems. Just to give you an example, Nginx workers are single threaded.
- johannes1234321 9y ago
  In Nginx you're not doing computation, just passing IO thru between file system, external processes (i.e. PHP via fpm) and the network. If Nginx ever is CPU bound there's something bad happening. As I mentioned PHP: In PHP each worker is single threaded, too, but you can scale by having more workers in isolation.
  - alayek 9y ago
    You've hit the bull's eye! Yes, and you're also not supposed to do much computation in Node JS code. Some addition, subtraction is fine. But Array iteration, JSON encoding-decoding and similar CPU bound tasks could block the event loop. You can perform them asynchronously, or forward the request to some remote service that's better at doing these computations for you and return results (maybe some service written in Python or a database)
  - TrickyRick 9y ago
    What computations do you do in a webserver which hosts a REST API? Most of it is simple CRUD connected to a database, possibly with an auth layer on top, which is pretty much what you describe, passing IO through to a database and back.
    - falcolas 9y ago
      Compression, hash computation, regular expression routing lookups, parsing text, building and serializing datastructures, reading and writing caches; I could go on. Sure, JavaScript (and Ruby and Python) are usually fast enough with modern hardware - but we can't pretend there's no cost.
sametmax 9y ago
Exactly. We got cancer on one major organ, why spread it ?
- sigzero 9y ago
  Too late! cough Electron cough
alayek 9y ago
Node is single threaded, in the sense that your code runs in a single thread. Your code assigns microtasks, to be executed later. Basically, if you write in Node JS, there's no concept of a thread. The thread API is not visible or accessible to the developer. This forces you to think from the ground up about asynchronous operations that would take some time to complete - file opening, network requests etc., and have you group all tasks dependent on that time-consuming task, separately. In Node, you are not supposed to block the event-loop that runs in that single thread and queues the tasks. Node JS has shown over the years that it scales well (maybe not as good as Go or Elixir, but enough for most use-cases). Node also offers lot of great tools, that can be easily added to your project via NPM / Yarn. The Node ecosystem has a solution for virtually any task you might need to do repeatedly in a project. Just to be clear, I am not saying Node or its ecosystem is perfect. There's always room for improvement. What I am saying is that what appears as an obvious flaw, is not really a flaw. The language allows other approaches to solve the problem.
- jcelerier 9y ago
  > In Node, you are not supposed to block the event-loop that runs in that single thread and queues the tasks. well, sure, but ten years ago it was already a given that one would just spawn one event loop per thread and have them communicate with messages, so why is it so hard for node ?
  - jononor 9y ago
    I/O is not going to be any faster by having more threads. More threads are not gonna give you more RAM either. And CPU-bound tasks are only faster if the OS you are running in exposes multiple CPUs. With VMs and containers with focus on horizontal scaling (many relatively small machines) that is not the case either. Effectively the message-passing communication between threads still exists, but has moved outside the service: done by a load-balancing HTTP router and/or a message broker like RabbitMQ. Another example is when using out-of-process persistence like with Redis.
    - fundabulousrIII 9y ago
mschuetz 9y ago
With ES6, JS became a really nice scripting language. Personally, I'm glad to see more and more projects that use javascript outside of web browsers and I've also added V8 to my most recent C++ project. The only major drawback in my opinion is, that it's not statically typed.
- randiantech 9y ago
  Indeed, although Typescript is a good solution to have more OOP based abstractions, like Generics, Abstract Classes and Interfaces.
- gmac 9y ago
  I agree. On the whole, I think JS is a middlingly-nice language. It has some good bits and some bad bits. ES6 brings a whole lot more good bits. I sometimes think we could do with a bit more thanking-our-lucky-stars that the language that got entrenched on the web wasn't, say, VBScript (which IE did use to support). For your major drawback, there's TypeScript.
- nerdwaller 9y ago
  The real issue with js (node) as a "scripting language" is the lack of a stdlib. A nice thing about writing a Python script is you know the stdlib is there on your remote machine (since some version of Python is on most systems by default other than windows).
- flavio81 9y ago
  The deeper problem is that JS is not strongly typed. Typescript gives you static type checks but the runtime is still weakly typed and will still do all sorts of weird type conversions.
  - monsieurbanana 9y ago
    Theoretically, to what extend could the weird type conversions be prevented with the use of a strict linter? My intuition would be all, but I haven't thought much about it.
tchaffee 9y ago
> whatever would motivate people to use js for anything more than is strictly necessary. If that's the primary language you are good at, from coding frontend apps, then it's pretty nice to be able to switch to writing backend code without having to do a language context switch. Muscle memory along with your memory about library methods all just continue to flow. > It can't be that hard using a different language. If I'm better at one language than another, it is at least somewhat harder. Why struggle when you can flow?
- rootlocus 9y ago
  > If I'm better at one language than another, it is at least somewhat harder. Why struggle when you can flow? If you're better with screwdrivers, why struggle with a hammer? JavaScript has a painfully slow runtime. Writing servers requires attention to performance and reliability, which javascript is very poor at. If you want to make a toy service and don't care about any of this, go ahead and use your favourite language. But when you want to make something incredibly fast and reliable (like nginx), you'll need to consider another technology.
  - coldtea 9y ago
    >If you're better with screwdrivers, why struggle with a hammer? Hammers and screwdrivers are not general purpose tools in the way that languages are. For most things, most languages are just as fine. It's not like JS is specialized in some very small niche by design -- like e.g. COBOL is. >JavaScript has a painfully slow runtime. I call BS. v8 is one of the fastest dynamic runtimes, at 2x of C or so for lots of tasks, and it totally obliterates Python, PHP, Ruby, and co in speed. And since some of the web's different properties are written in the latter 3, it's certainly not speed (which JS surpassed them far in) that's the issue. >If you want to make a toy service and don't care about any of this, go ahead and use your favourite language. But when you want to make something incredibly fast and reliable (like nginx), you'll need to consider another technology. Nobody writes "nginx" in JS. They write the kind of APIs and apps and services that people also used to write in PHP, Python, Ruby, Go and whatever lang.
    - 9y ago
coldtea 9y ago
>The more time goes by the more I feel crazy for missing whatever would motivate people to use js for anything more than is strictly necessary. Single threaded server??? So, like Nginx's model? Or 99% of Python servers? You can still run multiple processes...
- 52-6F-62 9y ago
  Yes, I'm surprised nobody has mentioned child processes or the Cluster module. https://nodejs.org/api/cluster.html https://nodejs.org/api/cluster.html There are a lot of knowledgable people commenting, but it's starting to seem like they haven't familiarized themselves with the tools available within the NodeJs base. To another point, I could put the time into writing a server and back end application in Go or Rust or C++ or whatever, but it would take (at least me) 10x as long to build out the application I need as it does to pull express into a project and build out a server, back end computations, file manipulation, authentication, and roll a MongoDB store with a fully-fleshed out front end (even if it's not so stylish). Mind you I work in an enterprise environment where these kinds of things are required to serve maybe twenty people and run on a single multi-cored machine at any given time and not tens of thousands users. It's a fantastic tool that works from small to mid-large projects, and would serve as an excellent prototyping and MVP-dev environment for even the naysayers who are probably more skilled than I am in other areas.
- gozur88 9y ago
  >You can still run multiple processes... The problem with Node is it's unsuitable for a whole class of server applications - you're going to run into trouble whenever you need to maintain serial access to a single resource. Whereas in Java you'd have some sort of token that gets "taken" by different threads, there's no clean way to do this in a multiprocess Node environment.
specialist 9y ago
My day gig is nodejs. I was interested in the problem space, didn't think too much about the stack. How bad could it be, right? Oops. The worst aspect of nodejs is code construction (craftsmanship). Whereas Bill Joy said of Java "Allows you to think both In The Big and In the Small, at the same time." With nodejs, not only is there no Right Way, there's not even a Good Way. You have to mind all the details, plus quite of a few new ones. Frankly, I'd rather just write 'C' again. If I have to care about the fiddly bits, I'd rather the language not fight back. My team spends a lot of time mitigating memory leaks and back pressure (bufferbloat due to thread/task starvation). I haven't done this kind of troubleshooting since my 'C' slinging days. And this is apparently acceptable. I find the current state of affairs (emperor has no clothes) appalling and baffling.
- dboreham 9y ago
  My take on this (I have had the same experience, fwiw) is that it is like the well-known story of bridges falling down due to experienced engineers retiring (Tay Bridge Disaster, Tacoma Narrows Bridge for example). A new generation of folks who actually believe that "Single Threaded is a benefit" arrive on the scene and make a bridge that falls down..
  - amorphid 9y ago
    I used to love to idea of a global interpretator and/or a single thread (coding without concurrency). It was great until it wasn't. Learning Elixir helped me get over that.
    - dboreham 9y ago
      The thing is : it isn't an "idea" at all. These projects ended up with a big lock, or not tolerating reentrancy due to history -- they were developed at a time, and in an environment where there were no threads (or where support for threads wasn't of interest to the developer). It's just a bug. Not an idea, not a benefit. All the talk of it being the best way is nonsense invented after the fact to try to justify something that's just broken.
    - 9y ago
ralusek 9y ago
For the millionth time: It is not accurate to refer to it as single threaded. The language is non-blocking, so any asynchronous tasks (DB read/writes, disc I/O, cache, http, etc) will immediately jump to processing the next request the moment it is not doing blocking computation. Non-blocking: [aa][bb][cc][/aa][/cc][/bb][dd][ee][ff][gg][/dd][/ff][/gg][/ee] Blocking-threaded: [aa]------------------------[/aa][ff]----------------------[/ff] [bb]------------------------[/bb][gg]----------------------[/gg] [cc]------------------------[/cc][ee]----------------------[/ee] [dd]------------------------[/dd] Depending on how many threads you can get going at once, you may be able to achieve comparable performance doing threading, but nonblocking is basically leaving 0 time on the core wasted and limited to the speed of the event loop. And then on top of that, clustering module is used to do the same thing on every core.
- thehardsphere 9y ago
  It is accurate to refer to it as single threaded, because it executes with a single thread. "Non-blocking" is an orthogonal concept to the number of threads being used. You can have "non-blocking" and multiple threads at the same time.
  - pier25 9y ago
    Isn't it actually 2 threads at the minimum? The V8/JS thread and the C++ thread? Doesn't the C++ part create threads in some cases when needed?
    - thehardsphere 9y ago
      I doubt that is accurate, but if it is, it is irrelevant; those "C++ threads" are not available to you to use in your program the way you see fit.
Arzh 9y ago
The argument that people always throw at me is that too hard for people to know two languages, well, for frontend devs to know two languages. Now in a perfect world the frontend people who just can't figure out two or more languages would never touch the backend but the world of software now is "that'll do" not "what is the right tool." It's a shame to me really but I'm not a frontend dev for a reason.
- tempodox 9y ago
  The argument that I'd throw back is that you're not a programmer if you only know one language or only one execution model.
- thehardsphere 9y ago
  If "frontend devs" are really, truly, genuinely capable of only holding one language in their heads, and that language is Javascript, then we should deprecate the term "frontend developer" and replace it. I would propose "person who can only be at most half-competent," except that is too wordy and probably too charitable.
- defined 9y ago
  > The argument that people always throw at me is that too hard for people to know two languages, well, for frontend devs to know two languages. This is ridiculous from the point of view any professional developer. I know that this is your point, and I'm just amplifying it. I (and many other professionals I work with) know - and use on a daily basis - so many more than 1 language that it's sincerely baffling to grok a world that promotes "One language fits all". That's without even considering the parlous state of npm and its libraries.
pan69 9y ago
Personally I have no real objections to JavaScript as a language but somehow I get the feeling that, in many situations, NodeJS is more a problem than a solution. I.e. JavaScript and NodeJS are two different things and I think they shouldn't be treated as the same thing (i.e. NodeJS is JavaScript and vica versa). NodeJS could have been shipped with a different language (Lua?) but I guess NodeJS surfaced around the same time Google released their V8 engine, so... To me it seems that NodeJS solves a very specific problem; handling many simultaneous persistent network connections (i.e. websockets). I can't help thinking of NodeJS as fundamentally being a programmable socket server. I.e. its purpose is to solve a network problem, not a business logic problem. The problem for me, when I work on large(r) apps that run in NodeJS, is that there is a certain "mental overhead" associated with it. NodeJS has this non-blocking IO, event driven architecture for a very specific reason which makes total sense when you solve IO problems (such as handling many simultaneous network connections) but this behaviour somehow seems to trickle down into business logic. With NodeJS I find myself writing non-blocking, event driven business logic because the environment in which my code runs dictates this. Somehow that doesn't make sense to me. To me business logic is inherently synchronous. Now there are some really clever ways to compensate for this such as the Promise and with never versions of JavaScript there are even new language features to help battle what was originally known as the "callback soup". However, no matter how clever and admirable each of these features are, to me they seem to compensate for a fundamental problem in the run-time environment (NodeJS) that actually makes it not really suitable for anything CRUD and beyond.

lunchables 9y ago

I just tell myself it's because the sales pitch is so appealing: learn, and use, one programming language on the front end and back end of your web site. I've never written anything on node.js, but that's the only argument that's ever given me pause.

alayek 9y ago
You should try. I come from a traditional Java shop, and a year ago wouldn't have thought of doing anything serious with Node JS. Today, I do front-end React stuff as well as back-end servers with Node JS. I have been happy with it so far. With some type-system like Flow or TypeScript, you can manage huge projects in Node JS. I happen to like the community, CLI tools written in Node, and the plethora of open source libraries built on top of Node. This also has a downside. Your libraries can get outdated quite fast, you would have to keep up with new language syntaxes etc., and remember which syntax is supported by which version of Node etc. But so far, I think Node is headed in the right direction.
falcolas 9y ago
It honestly doesn't give me pause, since the impedance mismatch between JavaScript and backend programming is so great. To me, the fact that Node has to add a library with custom semantics just to allow a basic 'open' on a file handle is a huge warning flag to me.
- todd3834 9y ago
  What does it warn you about? Not trolling, honest question.
  - falcolas 9y ago
    That JavaScript was not designed to work as a *nix (or Windows for that matter) server language. And that any attempts to make it work as a server language are going to include some major workarounds to fit that round peg into a square hole. You can still make it work; but you can script a web page's interactions in C as well. That doesn't make it the right thing to do.
    - ovao 9y ago
      I'm not a particular fan of JavaScript on the server these days, but when you have a large number of developers who know JavaScript from the front-end world and a language ecosystem that's quite large and relatively robust, I would argue that doing those "major workarounds" (which aren't so major, really) to make server-side JavaScript an accessible option at least very closely resembles the "right thing to do". Should we collectively eschew what's possible due to individual language gripes?
      - fundabulousrIII 9y ago
        No. We should collectively evaluate competency and correctness of a developer and language for it's best purpose as in any adequately run job interview.
        ovao 9y ago
        > collectively evaluate competency and correctness of a developer I'm sorry, is this a dig at Ryan Dahl, or of JavaScript/Node developers in general? I'm having trouble understanding what point you're addressing with this comment. As for evaluating languages for their "best purpose", I think that's a very complex discussion that doesn't necessarily yield a best (or cost effective/productive) result. And certainly, as we've seen routinely evidenced, using a different language on the server is no panacea.
- woah 9y ago
  Js is a scripting language that relies on the program being scripted to interact with the outside world. In browsers, this is the DOM and xhr APIs. On servers, this is the node stdlib which lets you interact with the system. The fact that this kind of modularity bothers you is bizarre.
  - thehardsphere 9y ago
    It is a modularity that is an unnecessary point of failure compared to other choices available, and involves poor abstractions for Javascript to use things it was not intended to use.
- devnill 9y ago
  >To me, the fact that Node has to add a library with custom semantics just to allow a basic 'open' on a file handle is a huge warning flag to me What do you mean? The fs module shipped with node is pretty much just a wrapper for libc. Hell, it even links to the open(2) manpage in the docs for usage information.
- deleted 9y ago
  [deleted]
- ridiculous_fish 9y ago
  Favorite node / libc impedance mismatch is the stat() call. stat() returns an inode, which is a 64 bit integer. But JS doesn't have 64 bit integers, so it just gets rounded to the closest representable double. So node will sometimes identify two different files as the same file. https://github.com/nodejs/node/issues/12115 https://github.com/nodejs/node/issues/12115
- collyw 9y ago
  Its been a while since I wrote and Java, but when I did you needed a page of code just to open a file.
- Larrikin 9y ago
  Kotlin is slowly becoming s language that can do all of that. It's production ready for anything that uses java, js support is coming along great, and their slowly moving towards native.
ashark 9y ago
The front end/back end sharing argument never appealed to me. In practice, how much are you actually going to be able to share? No way it's worth it. What's finally got me writing way more Javascript than I'd like to is React Native. It's by far the easiest way I know of to share code between iOS and Android, it papers over a lot of Android's irritating/broken UI bits (introducing others, but overall improving the situation), and you actually can share much of your code (practically everything but the UI layer) with a web client—and even... spits... Electron. RN's performance isn't even terrible, especially compared to cross-platform mobile frameworks that have come before it (and to Electron spits) Hopefully Webassembly will save us in another couple years, and we'll be able to do the same thing in any of several much better languages. [EDIT] though definitely keep your sanity and use Typescript. I'd have probably jumped off a bridge by now if I were having to do all this in actual JS, of any flavor.
- jtmarmon 9y ago
  the front/backend sharing stuff matters more these days with server side rendered apps, but I've used nodejs plenty for this lifetime and have no plans to touch the stuff again for serious applications
  - duderific 9y ago
    It's kind of funny how you say "these days with server side rendered apps". At one time not so long ago, there were only server side rendered apps.
- Someone 9y ago
  I think most of what you share is the effort needed to learn the language. Also, it 'helps' if both server and client are single-threaded, because then, you can use similar solutions on both server and client (even if they sometimes aren't the most pleasant approach for solving your domain) I hope that Web Assembly will take of and get a decent interface to the DOM, allowing developers to pick other languages in the role that JavaScript now has.

randiantech 9y ago

Javascript as a language and ecosystem has evolved quite dramatically during the last years. Its not perfect though: it lacks features and ecosystem is still not in the level of maturity of other platforms, but is definitely going in the right direction. Regarding the single threaded server, its an architecture used before JS exists, and used by many other platforms/systems. Just to give you an example, Nginx workers are single threaded.

johannes1234321 9y ago
In Nginx you're not doing computation, just passing IO thru between file system, external processes (i.e. PHP via fpm) and the network. If Nginx ever is CPU bound there's something bad happening. As I mentioned PHP: In PHP each worker is single threaded, too, but you can scale by having more workers in isolation.
- alayek 9y ago
  You've hit the bull's eye! Yes, and you're also not supposed to do much computation in Node JS code. Some addition, subtraction is fine. But Array iteration, JSON encoding-decoding and similar CPU bound tasks could block the event loop. You can perform them asynchronously, or forward the request to some remote service that's better at doing these computations for you and return results (maybe some service written in Python or a database)
- TrickyRick 9y ago
  What computations do you do in a webserver which hosts a REST API? Most of it is simple CRUD connected to a database, possibly with an auth layer on top, which is pretty much what you describe, passing IO through to a database and back.
  - falcolas 9y ago
    Compression, hash computation, regular expression routing lookups, parsing text, building and serializing datastructures, reading and writing caches; I could go on. Sure, JavaScript (and Ruby and Python) are usually fast enough with modern hardware - but we can't pretend there's no cost.

sametmax 9y ago

Exactly. We got cancer on one major organ, why spread it ?

sigzero 9y ago
Too late! cough Electron cough

alayek 9y ago

Node is single threaded, in the sense that your code runs in a single thread. Your code assigns microtasks, to be executed later. Basically, if you write in Node JS, there's no concept of a thread. The thread API is not visible or accessible to the developer. This forces you to think from the ground up about asynchronous operations that would take some time to complete - file opening, network requests etc., and have you group all tasks dependent on that time-consuming task, separately. In Node, you are not supposed to block the event-loop that runs in that single thread and queues the tasks. Node JS has shown over the years that it scales well (maybe not as good as Go or Elixir, but enough for most use-cases). Node also offers lot of great tools, that can be easily added to your project via NPM / Yarn. The Node ecosystem has a solution for virtually any task you might need to do repeatedly in a project. Just to be clear, I am not saying Node or its ecosystem is perfect. There's always room for improvement. What I am saying is that what appears as an obvious flaw, is not really a flaw. The language allows other approaches to solve the problem.

jcelerier 9y ago
> In Node, you are not supposed to block the event-loop that runs in that single thread and queues the tasks. well, sure, but ten years ago it was already a given that one would just spawn one event loop per thread and have them communicate with messages, so why is it so hard for node ?
- jononor 9y ago
  I/O is not going to be any faster by having more threads. More threads are not gonna give you more RAM either. And CPU-bound tasks are only faster if the OS you are running in exposes multiple CPUs. With VMs and containers with focus on horizontal scaling (many relatively small machines) that is not the case either. Effectively the message-passing communication between threads still exists, but has moved outside the service: done by a load-balancing HTTP router and/or a message broker like RabbitMQ. Another example is when using out-of-process persistence like with Redis.
  - fundabulousrIII 9y ago

mschuetz 9y ago

With ES6, JS became a really nice scripting language. Personally, I'm glad to see more and more projects that use javascript outside of web browsers and I've also added V8 to my most recent C++ project. The only major drawback in my opinion is, that it's not statically typed.

randiantech 9y ago
Indeed, although Typescript is a good solution to have more OOP based abstractions, like Generics, Abstract Classes and Interfaces.
gmac 9y ago
I agree. On the whole, I think JS is a middlingly-nice language. It has some good bits and some bad bits. ES6 brings a whole lot more good bits. I sometimes think we could do with a bit more thanking-our-lucky-stars that the language that got entrenched on the web wasn't, say, VBScript (which IE did use to support). For your major drawback, there's TypeScript.
nerdwaller 9y ago
The real issue with js (node) as a "scripting language" is the lack of a stdlib. A nice thing about writing a Python script is you know the stdlib is there on your remote machine (since some version of Python is on most systems by default other than windows).
flavio81 9y ago
The deeper problem is that JS is not strongly typed. Typescript gives you static type checks but the runtime is still weakly typed and will still do all sorts of weird type conversions.
- monsieurbanana 9y ago
  Theoretically, to what extend could the weird type conversions be prevented with the use of a strict linter? My intuition would be all, but I haven't thought much about it.

tchaffee 9y ago

> whatever would motivate people to use js for anything more than is strictly necessary. If that's the primary language you are good at, from coding frontend apps, then it's pretty nice to be able to switch to writing backend code without having to do a language context switch. Muscle memory along with your memory about library methods all just continue to flow. > It can't be that hard using a different language. If I'm better at one language than another, it is at least somewhat harder. Why struggle when you can flow?

rootlocus 9y ago
> If I'm better at one language than another, it is at least somewhat harder. Why struggle when you can flow? If you're better with screwdrivers, why struggle with a hammer? JavaScript has a painfully slow runtime. Writing servers requires attention to performance and reliability, which javascript is very poor at. If you want to make a toy service and don't care about any of this, go ahead and use your favourite language. But when you want to make something incredibly fast and reliable (like nginx), you'll need to consider another technology.
- coldtea 9y ago
  >If you're better with screwdrivers, why struggle with a hammer? Hammers and screwdrivers are not general purpose tools in the way that languages are. For most things, most languages are just as fine. It's not like JS is specialized in some very small niche by design -- like e.g. COBOL is. >JavaScript has a painfully slow runtime. I call BS. v8 is one of the fastest dynamic runtimes, at 2x of C or so for lots of tasks, and it totally obliterates Python, PHP, Ruby, and co in speed. And since some of the web's different properties are written in the latter 3, it's certainly not speed (which JS surpassed them far in) that's the issue. >If you want to make a toy service and don't care about any of this, go ahead and use your favourite language. But when you want to make something incredibly fast and reliable (like nginx), you'll need to consider another technology. Nobody writes "nginx" in JS. They write the kind of APIs and apps and services that people also used to write in PHP, Python, Ruby, Go and whatever lang.
  - 9y ago

coldtea 9y ago

>The more time goes by the more I feel crazy for missing whatever would motivate people to use js for anything more than is strictly necessary. Single threaded server??? So, like Nginx's model? Or 99% of Python servers? You can still run multiple processes...

52-6F-62 9y ago
Yes, I'm surprised nobody has mentioned child processes or the Cluster module. https://nodejs.org/api/cluster.html https://nodejs.org/api/cluster.html There are a lot of knowledgable people commenting, but it's starting to seem like they haven't familiarized themselves with the tools available within the NodeJs base. To another point, I could put the time into writing a server and back end application in Go or Rust or C++ or whatever, but it would take (at least me) 10x as long to build out the application I need as it does to pull express into a project and build out a server, back end computations, file manipulation, authentication, and roll a MongoDB store with a fully-fleshed out front end (even if it's not so stylish). Mind you I work in an enterprise environment where these kinds of things are required to serve maybe twenty people and run on a single multi-cored machine at any given time and not tens of thousands users. It's a fantastic tool that works from small to mid-large projects, and would serve as an excellent prototyping and MVP-dev environment for even the naysayers who are probably more skilled than I am in other areas.
gozur88 9y ago
>You can still run multiple processes... The problem with Node is it's unsuitable for a whole class of server applications - you're going to run into trouble whenever you need to maintain serial access to a single resource. Whereas in Java you'd have some sort of token that gets "taken" by different threads, there's no clean way to do this in a multiprocess Node environment.

specialist 9y ago

My day gig is nodejs. I was interested in the problem space, didn't think too much about the stack. How bad could it be, right? Oops. The worst aspect of nodejs is code construction (craftsmanship). Whereas Bill Joy said of Java "Allows you to think both In The Big and In the Small, at the same time." With nodejs, not only is there no Right Way, there's not even a Good Way. You have to mind all the details, plus quite of a few new ones. Frankly, I'd rather just write 'C' again. If I have to care about the fiddly bits, I'd rather the language not fight back. My team spends a lot of time mitigating memory leaks and back pressure (bufferbloat due to thread/task starvation). I haven't done this kind of troubleshooting since my 'C' slinging days. And this is apparently acceptable. I find the current state of affairs (emperor has no clothes) appalling and baffling.

dboreham 9y ago
My take on this (I have had the same experience, fwiw) is that it is like the well-known story of bridges falling down due to experienced engineers retiring (Tay Bridge Disaster, Tacoma Narrows Bridge for example). A new generation of folks who actually believe that "Single Threaded is a benefit" arrive on the scene and make a bridge that falls down..
- amorphid 9y ago
  I used to love to idea of a global interpretator and/or a single thread (coding without concurrency). It was great until it wasn't. Learning Elixir helped me get over that.
  - dboreham 9y ago
    The thing is : it isn't an "idea" at all. These projects ended up with a big lock, or not tolerating reentrancy due to history -- they were developed at a time, and in an environment where there were no threads (or where support for threads wasn't of interest to the developer). It's just a bug. Not an idea, not a benefit. All the talk of it being the best way is nonsense invented after the fact to try to justify something that's just broken.
  - 9y ago

ralusek 9y ago

For the millionth time: It is not accurate to refer to it as single threaded. The language is non-blocking, so any asynchronous tasks (DB read/writes, disc I/O, cache, http, etc) will immediately jump to processing the next request the moment it is not doing blocking computation. Non-blocking: [aa][bb][cc][/aa][/cc][/bb][dd][ee][ff][gg][/dd][/ff][/gg][/ee] Blocking-threaded: [aa]------------------------[/aa][ff]----------------------[/ff] [bb]------------------------[/bb][gg]----------------------[/gg] [cc]------------------------[/cc][ee]----------------------[/ee] [dd]------------------------[/dd] Depending on how many threads you can get going at once, you may be able to achieve comparable performance doing threading, but nonblocking is basically leaving 0 time on the core wasted and limited to the speed of the event loop. And then on top of that, clustering module is used to do the same thing on every core.

thehardsphere 9y ago
It is accurate to refer to it as single threaded, because it executes with a single thread. "Non-blocking" is an orthogonal concept to the number of threads being used. You can have "non-blocking" and multiple threads at the same time.
- pier25 9y ago
  Isn't it actually 2 threads at the minimum? The V8/JS thread and the C++ thread? Doesn't the C++ part create threads in some cases when needed?
  - thehardsphere 9y ago
    I doubt that is accurate, but if it is, it is irrelevant; those "C++ threads" are not available to you to use in your program the way you see fit.

Arzh 9y ago

The argument that people always throw at me is that too hard for people to know two languages, well, for frontend devs to know two languages. Now in a perfect world the frontend people who just can't figure out two or more languages would never touch the backend but the world of software now is "that'll do" not "what is the right tool." It's a shame to me really but I'm not a frontend dev for a reason.

tempodox 9y ago
The argument that I'd throw back is that you're not a programmer if you only know one language or only one execution model.
thehardsphere 9y ago
If "frontend devs" are really, truly, genuinely capable of only holding one language in their heads, and that language is Javascript, then we should deprecate the term "frontend developer" and replace it. I would propose "person who can only be at most half-competent," except that is too wordy and probably too charitable.
defined 9y ago
> The argument that people always throw at me is that too hard for people to know two languages, well, for frontend devs to know two languages. This is ridiculous from the point of view any professional developer. I know that this is your point, and I'm just amplifying it. I (and many other professionals I work with) know - and use on a daily basis - so many more than 1 language that it's sincerely baffling to grok a world that promotes "One language fits all". That's without even considering the parlous state of npm and its libraries.

pan69 9y ago

Personally I have no real objections to JavaScript as a language but somehow I get the feeling that, in many situations, NodeJS is more a problem than a solution. I.e. JavaScript and NodeJS are two different things and I think they shouldn't be treated as the same thing (i.e. NodeJS is JavaScript and vica versa). NodeJS could have been shipped with a different language (Lua?) but I guess NodeJS surfaced around the same time Google released their V8 engine, so... To me it seems that NodeJS solves a very specific problem; handling many simultaneous persistent network connections (i.e. websockets). I can't help thinking of NodeJS as fundamentally being a programmable socket server. I.e. its purpose is to solve a network problem, not a business logic problem. The problem for me, when I work on large(r) apps that run in NodeJS, is that there is a certain "mental overhead" associated with it. NodeJS has this non-blocking IO, event driven architecture for a very specific reason which makes total sense when you solve IO problems (such as handling many simultaneous network connections) but this behaviour somehow seems to trickle down into business logic. With NodeJS I find myself writing non-blocking, event driven business logic because the environment in which my code runs dictates this. Somehow that doesn't make sense to me. To me business logic is inherently synchronous. Now there are some really clever ways to compensate for this such as the Promise and with never versions of JavaScript there are even new language features to help battle what was originally known as the "callback soup". However, no matter how clever and admirable each of these features are, to me they seem to compensate for a fundamental problem in the run-time environment (NodeJS) that actually makes it not really suitable for anything CRUD and beyond.