19 ms·

I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people c

I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?

Scarbutt 9y ago
So I'm curious as to the reasons people chose Node.js Javascript of course ;) You can leverage the same language for server side stuff and browser programming.
- lasfter 9y ago
  But how valuable is that? I hear this a lot but is it really that much of an inconvenience to write backend code in a different language? Especially if there are different engineers working on the frontend and backend.
  - jdhawk 9y ago
    Language is never the problem. Languages (mostly) are easy. Frameworks are hard. Tooling can be hard (pick a language). Javascript is easy. Express, NPM, Bower, <insert framework of the month> are tough.
  - chrisco255 9y ago
    It's very valuable if you are bouncing back and forth between frontend and backend. There's no context switching as you do that. The cognitive overhead of context switching is higher than people generally accept. This is why stacks like the MEAN/MERN stack get used in hackathons. You've got a JSON-inspired database (Mongo) with a minimal server-side framework (Express) feeding a React/Angular front-end. You can use the same libraries client/server side like Mocha for unit testing, Lodash for collection manipulations, you can even share the same validation files for server & client.
    - mgkimsal 9y ago
      "There's no context switching as you do that" So, you just read/write to a database wherever? Or do you have to remember the context the code is running in? There may not be syntax switching, but I think you stil usually need to remember where the code in question will be executing (well... I need to, anyway)
binarez 9y ago
Check out Typescript!
- lasfter 9y ago
  I actually have, but it doesn't alleviate my biggest issue with Javascript, which is its async story. Also I've had experiences with Typescript code compiling with an error then immediately recompiling without any errors. Then errors when I switch to my browser. The immediate recompilation is probably just webpack but it doesn't inspire confidence when errors are non-deterministic.
  - koolba 9y ago
    Typescript plus async/await is a beautiful solution to both the async story and typing story.
    - lasfter 9y ago
      I don't think asnyc/await is a good solution to asynchronous programming. Lua, Go et al are more what I was thinking of as good examples of asynchronous programming. See http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... And I addressed some concerns with Typescript in a sibling comment. It is much better than plain Javascript, though.
    - pyrophane 9y ago
      The problem I experienced with async/await and Typescript was always the lack of built-in support for promises among the libraries I was using. Once I had to use something like promisifyAll() I lost any type information I had about the library in question. Is there any better workaround to that these days?
      - koolba 9y ago
        Not really but I also don't see it as that much of a problem. The libraries I use either provide a Promise based interface or I've written my own as a thin veneer atop a callback interface. Ditto for apply your own types atop the results. Most are already there and only a few edge cases need to be added.
garysieling 9y ago
There are a lot of negatives, but it is any easy language to make rapid progress writing code in, and ES6 or TypeScript have made it a lot better than it used to be. You can do a lot of prototyping in the browser REPL too (e.g. I like to go to the lodash docs, write out code on the site, then paste into my app). It's nice to be able to do server side rendering (i.e. run React there). Also you can run all the build tools in your application server during development which can be super convenient - Probably the most compelling example I've seen of this is Next.js.
SimeVidas 9y ago
I only know JavaScript (and I know it quite well). Why learn a whole other language, when Node gets the job done just fine?
- tambourine_man 9y ago
  Learning a new language will make you a better programmer. Especially one with different paradigms
  - SimeVidas 9y ago
    I’m not sure that being a “better programmer” is important in web development. And I don’t mean that term in the broad sense—obviously, we should write good code—but in the sense that understanding two programming languages makes a significant difference. I think in web development it doesn’t. Web development is about many things. HTML, CSS, performance, accessibility, security, networking, supporting different browsers, polyfills and workarounds, keeping up with new features, UX and usability. Then there are frameworks and build tools, which are all of course JavaScript-based. Only a small part of web development is actual programming, and the fact that frameworks most of the time lay out the patterns for you, makes the “programmming” aspect even less significant in the overall picture. So no, I don’t think that learning another programming language is a good way to spend your time if you’re a web developer.
- fwefwwfe 9y ago
  Because nto everyone suffers from Stockholm syndrome?
- rimliu 9y ago
  That makes me wonder, what number of "choose to use JavaScript" is compared to "have no real choice, because JS is the only language they know".
untog 9y ago
Being able to run the same code on the client and server is a boon for web sites - rendering views server side then hooking up client events is a lot more performant than only rendering on the client side. Also, context switching - the projects I work on tend to be front-end heavy, with a little API access and data storage on the backend. I find it a lot easier to do that backend work with the same language, tools and debugging environment as my client code.
partycoder 9y ago
JavaScript is a scripting language. So is Python and Ruby. As a scripting language, excluding all bindings (files, networking, etc), JavaScript is substantially faster than Ruby or Python. Now, in terms of bindings, bindings to libuv are also fast. So node is not so much of a problem in itself. However the problem is how the language is being used: To say you can write a serious library or server code because you know JavaScript, is the same as saying you can write a paper in cardiology research because you know English. You will find a lot of people that completely disregard the domain knowledge required to write safe, workable code. While this happens in many languages, JavaScript is the lingua franca for those kind of people. Because of this, be very careful of the libraries you use. You will most likely have to read the code to ensure there is some thought behind it. Then if you are hiring node developers, prepare to receive an avalanche of resumes from people without a degree expecting to learn on the job at your expense while receiving a 6 figure salary.
- hota_mazi 9y ago
  > As a scripting language, excluding all bindings (files, networking, etc), JavaScript is substantially faster than Ruby or Python. This makes no sense. They're all dynamically typed languages (avoiding the term "scripting languages" since it's pretty vague). The only reason for the difference in speeds between these languages is due to the quality of their interpreters, not the languages themselves.
  - goatlover 9y ago
    Yeah, since PyPy is V8 fast, LuaJit is faster, and Julia is even faster.
  - partycoder 9y ago
    If you have embedded or extended a scripting language it makes perfect sense. Repeating myself just for you: I was referring specifically to benchmarking language aspects excluding bindings to native code such as files, networking, processes, etc. e.g: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=python3 https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... Then sure, JavaScript has many implementations, so does Ruby and Python. I was referring to v8 (used by node), CPython and Ruby MRI in particular.
manyxcxi 9y ago
I've got over a decade of professional experience in C#, Python, and Java. I'd consider myself a Java developer before all else, yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement. Here's the major caveat, out of, say 100+ PoC/prototype projects I've ever done, I've taken two to 'production'. I put production in quotes because they were actually internal services as part of our build and delivery pipeline. It's a major pain in the butt to monitor and keep Node.js running production-like in even remotely similar ways you would with Java, .NET, Python, or even PHP for that matter. I don't expect such drastically different technologies to be exactly alike for production workloads, but there's usually analogous ways to do X, Y, or Z. You know where Node has been awesome? You land a project with a real tight deadline and its more of a fire and forget project (think interactive 'experience' at a major gaming conference for instance). It needs to run pretty well for a short period of time with a narrow scope of functionality, but some of that functionality is non-trivial. I absolutely love Node for that.
- thesmallestcat 9y ago
  Can you elaborate on the "major pain in the butt to monitor and keep Node.js running production-like" What sorts of issues did you face? Certainly .NET and Java have more tooling, but I haven't noticed a difference between keeping a Node process up as opposed to a Python one. Hard to compare to stateless PHP.
  - stickfigure 9y ago
    The default behavior for Node when there is an uncaught error is to crash the process, killing all requests in flight. Even if you go out of your way to stop this default behavior, errors still likely leave the process in an inconsistent state. Node can't just unwind a few stack frames like synchronous platforms. Do you read JSON from ajax post bodies? Do you access fields in that JSON without sanity checking it? Try passing JSON that's missing one of those critical fields (as, say, a griefer might do). What happened to your app?
    - m1sta_ 9y ago
ohstopitu 9y ago
I've used nodeJS at 3 of the past 4 startups I've worked at (currently using PHP). I had a hand in choosing it at all those 3 places and my main reasons boiled down to: 1. most devs know JS (so it's easier to hire & onboard new devs) 2. while everyone claims node's dependencies are hell, I love the choice available (although over time, it's tiring). 3. The community is generally awesome (helps during meetings, online etc.) 4. Developer Exp: With TS, Tslint etc, devx is not too bad IMO (and there's no dearth of opinionated articles around on the correct way to do things) 5. Finally - we can quickly churn out prototypes for features to production (but I guess that's more experience than the tools?). 6. In general, we'd be using JS on the frontend anyway (React), so it just made sense to use one language everywhere. 7. In general, most tools have JS SDKs and JS language support is always around (an exception I found was Tensorflow) - as an example, AWS Lambda supports Java, Python and JS.
- oddlyaromatic 9y ago
  I'm pretty much a beginner developer, doing a few small things but not employed as a dev. I like JavaScript, and when I wanted to do server side stuff (like automate schedule emails at my company), solutions were really available in PHP and it worked right away on my local machine with mamp and on my super cheap web hosting, whereas I seem to hit various setup pains when I try to do something with node. The PHP syntax was close enough for me to be much more comfortable than I expected to be. I recently worked on something that logs a user in to a mobile-unfriendly website, scrapes and parses a specific page that you would want to see on mobile, and presents a nice mobile view, with some extra relevant information. All the scraping is done in PHP and it just returns json that gets displayed with a handlebars template. It's just a demo right now, but my point is that even knowing a bit about JS, PHP feels so much more accessible than node for me, and I've done stuff that a year ago I never would have thought I could do. I feel like solutions are close and only require language and library research. Node solutions also require this other layer of knowledge that I haven't clicked with. How is PHP treating you at your current job?
- vacri 9y ago
  > while everyone claims node's dependencies are hell, I love the choice available (although over time, it's tiring). So... at one place I work, we use nodejs. There are so many modules added using so many files, that we ended up not being able to use our packaged application - extracting the package into a holding dir before moving into place meant that we ran out of inodes on the filesystem (stock 8GB ubuntu ext4 cloud image)! The filesystem could not hold two copies of our app, basically, due to inode exhaustion. The easy workaround was "increase the size of the disk", which seems silly given it's 80% free space. This has apparently been fixed in recent times with flatter npm structures, but watching the nodejs community run into every single packaging roadblock that has been solved before is just disheartening.
silviogutierrez 9y ago
I'm the biggest JS-on-the-server sceptic of them all, given my past experiences. But this was pre-typescript. If a TypeScript ORM with automatic schema migrations and decent expressiveness comes around, I'd be willing to give NodeJS another shot. But so far, nothing comes even close to the productivity of Django + ORM + Django Rest Framework. For your typical CRUD app, this will walk circles around any current JS solution. Even if the lack of static typing eventually becomes a bit of a pain.
- jcrben 9y ago
  Have you seen typeorm? https://github.com/typeorm/typeorm https://github.com/typeorm/typeorm
  - silviogutierrez 9y ago
    I have. It's a great improvement over other ORMs in the NodeJS space but pales in comparison to Django's ORM. At least for now. Relationships must be done manually, including joins, traversing, and many to many. Sometimes doing: w = Widget.objects.get(pk=2) w.category.author.name Is just all you need. And Django makes that trivial.
- Daishiman 9y ago
  I'm on the same boat. Django or Rails are so much more productive for me that I feel that most of the Node.JS love for this sort of domain comes from people who have never tried anything better.
  - throwanem 9y ago
    The operative words here being "for me".
- sametmax 9y ago
  This. Yes the site won't be as fast, and yes you don't have realtime. But if you need a regular web site, not a real time app with 100000 users, then nothing BEAT those techs. They are mature, stable, productive, and incredibly flexible. If you use anything else and you need something that is not "the typical hello world", you will have to write it by hand. With DRF ? You google it, you find a module and call it a day.
bspates 9y ago
I've been using NodeJs for about 4 years now. It really lends itself to the microservice paradigm. It makes great networking glue as you can handle many simultaneous connections without using many resources and since most web server operations are just fetching/updating data between databases or other services this works out well in NodeJs. The trick is to use it for this purpose only. Long running computations should be offloaded to the database or workers running in another process or machine. A lot of the problems mentioned in that article are the author misunderstanding libraries and not actual issues with NodeJs itself. For instance the problem with the Postgres library was that he didn't read the docs. The lib uses a session pool by default. You have to release the session when your done or else it will not become available again until the default session timeout is passed, which is quite large in Postgres. In respect to using Coffeescript "Classes", forcing JS to work like other languages will create unexpected behavior. It uses prototypical inheritance, not class inheritance.
JesseAldridge 9y ago
I've never run a javascript server in production, but if I do the main reason would be to take advantage of the huge ecosystem. Since js works on both the client and server side, you end up with a lot more programmers hacking on it. If you check http://www.modulecounts.com/ http://www.modulecounts.com/ you can see that npm has as many modules as all the other package repos combined. And it only seems to be gaining momentum. (screenshot: http://imgur.com/a/adqNJ http://imgur.com/a/adqNJ) Meteor has more stars on GitHub than any other web framework: https://github.com/search?p=3&q=stars%3A%3E1&s=stars&type=Repositories https://github.com/search?p=3&q=stars%3A%3E1&s=stars&type=Re... Nodejs, socket.io, and express all appear on the first few pages.
TheCondor 9y ago
V8 is a world class compiler. Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. (Pypy is a good match for it but it's not main street and you can't just use any module.) in terms of performance and popularity, v8/node stand pretty much alone as far as dynamic non-compiled environments. JavaScript has a lighter weight feel than Java and the jvm stack. Single threaded with a top notch event reactor. You can write just a few lines in node and have a web server serving some json. There are a ton of JavaScript coders. There is something to be said for having a common technology throughout your stack and you ui is almost certainly in js. It's easy to get something simple going quickly, there are tons of libraries and you're going to need to write go, Java or .net to out perform it. The big downsides, imho, v8 is designed for client side stuff. Both it and dart vm are limited to relatively small memory footprints (think 1GB) which just isn't good for some workloads and problems. Likewise a lot of server tasks can make good use of real threads, you're out of luck with node, you can have child processes and send messages but if they have to share big amounts of data the marshaling becomes a bit of a bottleneck. If you work is database crud, or light weight, or horizontally scalable, or able to be modeled as streams then node isn't that bad. Js feels kind of limited in how certain things are modeled, there isn't much data hiding or abstraction; the extreme simplicity almost creates more complexity for some things. There are lots of different opinions on basic code behavior, some node modules do work on import, some need explicit initialization, some alter prototypes and it's a concept that seems to be lost on many js devs; I've burnt hours debugging something because someone reordered the imports and it screwed init logic. And you'll completely screw yourself if you don't stay up to date with your depends, things change fast and sometimes they change a lot. Both node and dart vm seem really well equipped for tooling type things that are usually done in bash, Python or perl but that doesn't seem to be as popular. It's definitely not for everything but it's worth a look. It is really popular.
- lasfter 9y ago
  I see some merits. I am not sure I buy using JavaScript based on performance/dev speed ratio though. Lua is even faster, lighter weight and has clean, logical semantics. I guess I'm just trying to decide if having a large talent pool and tons of modules is good enough.
eropple 9y ago
So I felt this way until about...oh...a month ago. Because my JavaScript experience was mostly ES5. And ES5 is a roiling piece of shit that I wouldn't wish on my worst enemy. ES6, however? ES6 is tolerable. Getting it set up isn't as bad as you'd think and the language does as much as a Ruby or a Python in not shooting yourself in the foot. I'd trade async/await for actual threads, because I am capable of writing code with threads without hurting myself, but async/await are fine for get-it-out-the-door web services and that kind of thing. So I don't worry about it that much. I'd still go reach for the JVM and languages like Java or Kotlin if I was going to be hammering on a piece of code on an everyday basis for two or three years. But in 2017 (and probably 2016, but 2017 was when I got to it), it just became good enough to get it out the door with. (Regarding TypeScript: I feel like it's an incomplete thing and I'm happy that it exists, but for the stuff I use ES6 for I can hold the entirety of it in my head and I'm not worried about typing. For things that matter to me...well, I wouldn't be using ES6 in the first place.)
- cookiecaper 9y ago
  Sadly, I've been going through a similar experience after several commenters indicated that my complaints seemed to refer to "old" JavaScript and encouraged me to try ES6. Between ES6 fixing [0] many of the day-to-day warts that made JavaScript a joke language barely suitable for scripting DOM elements and V8's complete obliteration of other dynamic VMs in speed, I am being forced to accept that JavaScript is maturing into a serious platform, and starting to gradually introduce Node.js into my workflow. Just today I was discussing how hard it is to pull the stick out of my butt regarding JavaScript, but I think that the evidence is in favor of it. I'm having a strong impulse to try to use Dart instead just so I don't feel as dirty anymore. [0] http://es6-features.org http://es6-features.org
eel 9y ago
At a previous gig, without getting into specifics, we built a huge internal client-server system. The client was written in Node.js and ran as services on both Windows and Linux on a few thousand machines. The server was written in Node.js and ran as a Linux daemon. Node.js matched the developers' skill sets and gave us the ability to quickly write a server that could easily handle several thousand concurrent requests from the clients. On the client-side, Node.js gave us cross-platform support for nearly free (as well as being within our skill sets). Looking back, I do not think the project would have gotten off the ground in any other platform in that specific organizational environment. The server on Linux was particularly well-suited as it was architected to scale horizontally but still had room to scale vertically. On the client side, while we were able to get the Node.js service out pretty quickly, it eventually had performance and integration issues, particularly on Windows. It was super frustrating having to shell out to external processes or write native C++ modules to get access to some needed Windows APIs. In hindsight, I would have tried to rewrite the Windows client sooner in C++ or C#. On the plus side, it was a huge advantage that the entire Node runtime fit in a single executable (no dependencies on a huge JRE or other runtime). Overall, I would recommend it as an option to consider if most of the following is true: * Need to get to market quickly * Application is I/O intensive rather than CPU intensive * Dev team already knows JavaScript * Target environment is not Windows Personally, I decided to move away from Node.js and these days if I was faced with the same problem I would lean toward a JVM language or Elixir.
- sgift 9y ago
  > * Target environment is not Windows That one is still my main problem. I know, I know, Windows is evil and so on, but our customers use it. We are remarkably free in choosing our tools or whatever, but Windows is usually a constant (Intranet environments) and every day I crash against the absolute "Windows is a second class platform" problem of NPM modules. For an environment which is supposedly platform-agnostic the amount of "only on Unix" is astonishing.
  - jklepatch 9y ago
    Really? I think exactly the opposite. Compared to a lot of other tech, I found nodejs to work pretty well on windows. For example, recently npm switched from a nested to a flat directory organisation in node_modules. Windows has a limit on the number of nested directories, so this new organisation helped a lot. Maybe that you use a lot of modules with c dependencies?
erikpukinskis 9y ago
For me the question isn't so much why do I choose Node.js and Javascript over other languages, it's why do I choose NPM over other module libraries. I think the ergonomics of the libraries and command line tools we use have a much bigger impact on our coding experience than the language itself. And what I like about NPM is that there are a LOT of single file modules with a narrow, well defined scope. There are exceptions to this, like Ember or Angular, where they try to package up everything you might need. But there are also smaller frameworks like Vue.js and even smaller packages still, which do a single aspect of data binding or rendering or whatever. And it's those granular little packages where I think the NPM community ends up exploring just about every possible way to do get something done, and often comes up with a new idea that can teach me something. The organizational and software complexity behind an interface like Rails or iOS or Ember I think discourages app developers from questioning the interfaces they are using, and participating in shaping the landscape under them. I think that's a shame. The NPM community does it better.
ralusek 9y ago
NodeJS has a handful of things that tend to get brought up. Callback soup and difficult error handling. Both are resolved by promises. Once you get the hang of promises, you are capable of doing concurrent asynchronous tasks in a manner that would be significantly more difficult in any other language. On top of that, NodeJS is very, very fast. Compared to Python or Ruby, straight computing is significantly faster, but that's not even where the meaningful gains come from. Because NodeJS is non-blocking, the core is IMMEDIATELY available to serve the next request once an asynchronous call is made (read from DB/Cache/HTTP call). Because of this, each core can serve thousands of simultaneous connections. Because JS is single threaded, in order to take advantage of multi core hardware, you just run the cluster module to effectively launch a concurrent instance of your application for each core. As far as the language itself, once I understood it, I loved it. At first, I thought it was terrible, but when I went to ES6 syntax, and fully groked how to write asynchronous code, it rocketed to my favorite language. I started with Java, moved to Python, and although it took me a while to come around to JS, I would absolutely never go back.
- jcrites 9y ago
  > Once you get the hang of promises, you are capable of doing concurrent asynchronous tasks in a manner that would be significantly more difficult in any other language. What languages are you comparing against? It seems like asynchronous code is more difficult to write in NodeJS than in C#, Go, or Rust, and about the same as Java. I can write code in Java in a style similar to promises using ListenableFuture (Google Guava) or CompletableFuture (Java 8) [0]. I should also clarify that I don't think promises are the optimal approach to asynchronous code. I think you can do better, and the primitive "await" is an example of how. Bob Nystrom (munificient) wrote an article called "What Color is your Function?" [1] that does a good job describing the difficulties of promised-based async, and how await improves on it, and how Go does even better. (From what I've read, JavaScript ES8 is supposed to include async/await, and NodeJS seems to have support for them. At that point you'll be able to program in standard JavaScript and use await, which will bring NodeJS up to parity with the first-tier languages.) > On top of that, NodeJS is very, very fast. Compared to Python or Ruby, Perhaps that's true compared to Python and Ruby, but not when compared to other high-performance runtimes like Java. The following three paragraphs are from a comment I previously wrote on this topic [2]. Folks might also be interested in the TechEmpower web framework benchmark [3]. The top Java entry ("rapidoid") is #2 on the benchmark and achieves 99.9% of the performance of the #1 entry (ulib in C++). These frameworks both achieve about 6.9 million requests per second. The top Java Netty server (widely deployed async/NIO server) is about 50% of that, while the Java Jetty server, which is regular synchronous socket code, clocks in at 10% of the best or 710,000 R/s. NodeJS manages 320,000 R/s which is 4.6% of the best. In other words, performance-focused async Java achieves 20x, regular asynchronous Java achieves 10x, and boring old synchronous Jetty is still 2x better than NodeJS throughput. NodeJS does a pretty good job given that it's interpreted/JITed while Java is compiled, though Lua with an Nginx frontend can manage about 4x more. NodeJS is handicapped by having to orchestrate everything from its single thread. I agree that asynchronous execution can provide an advantage, but it's not the only factor to consider while evaluating performance. If throughput is someone's goal, then NodeJS is not the best platform due to its concurrency and interpreter handicap. If you value performance then you'll chose another platform that offers magnitude better requests-per-second throughput, such as C++, Java, Rust, or Go according to [3] and [4]. But I'll grant it has better IO performance than many other dynamically typed languages. Asynchronous execution also does not necessarily require explicit async programming. Other languages have as good or better async support -- for example, see C#'s `await` keyword. [1] explores async in JavaScript, await in C#, as well as Go, and makes the case that Go handles async most elegantly of those options. Java has Quasar, which allows you to write regular code that runs as fibers [5]. The code is completely normal blocking code, but the Quasar runtime handles running it asynchronously with high concurrency and M:N threading (similar to Go). Plus these fibers can interoperate with regular threads. Pretty gnarly stuff (but requires bytecode tampering). If async is your preference over Quasar's sync, then Akka might be up your alley instead [6]. Lastly, high performance servers don't necessarily require asynchronous code at the application layer; performance sensitive logic can often live in the library or framework e.g. Netty, reverse proxy e.g. Nginx, or in the OS's context switching. > Because NodeJS is non-blocking, the core is IMMEDIATELY available to serve the next request once an asynchronous call is made (read from DB/Cache/HTTP call). Because of this, each core can serve thousands of simultaneous connections. This also describes regular synchronous code with many threads. Once your application makes a blocking call, the operating system context switches to another thread (process). This is how boring old blocking Java code running on Jetty outperforms NodeJS in request-per-second benchmarks [3]. And you could take advantage of this in NodeJS too if it weren't for the fact that JavaScript execution occurs in a single thread! For most typical applications, overall performance is more influenced by the efficiency of the runtime than it is by the concurrency/async strategy. [0] https://github.com/google/guava/wiki/ListenableFutureExplained https://github.com/google/guava/wiki/ListenableFutureExplain... and https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html https://docs.oracle.com/javase/8/docs/api/java/util/concurre... [1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... [2] https://news.ycombinator.com/item?id=12341886 https://news.ycombinator.com/item?id=12341886 [3] https://www.techempower.com/benchmarks/#section=data-r11&hw=peak&test=plaintext https://www.techempower.com/benchmarks/#section=data-r11&hw=... [4] https://news.ycombinator.com/item?id=12268988 https://news.ycombinator.com/item?id=12268988 [5] http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/ [6] http://akka.io/ http://akka.io/
danneu 9y ago
My reasoning: all of the dynamically-typed languages are more or less the same on the server for CRUD apps, so I might as well use Javascript.
- laser 9y ago
  Hmmm, that hasn't been my experience: http://www.phoenixframework.org/ http://www.phoenixframework.org/
  - danneu 9y ago
    I haven't used it, but it's still the same pseudocode: defmodule HelloPhoenix.UserController do def index(conn, _params) do users = HelloPhoenix.Repo.all(HelloPhoenixUser) render conn, "index.json", users: users end end For CRUD, I'm not too convinced it's much different than what you'd be doing anywhere else. For websockets, streaming, and other stuff beyond request -> database query -> response, then competing abstractions get more interesting.
- pbreit 9y ago
  It's interesting that JavaScript on the server has grown at the same time front & back ends have separated. Which in my experience has drastically reduced development speed.
- fulafel 9y ago
  I find there are really big differences between the dev experience in Python, Node, Clojure and Erlang. JS doesn't trap errors[1], so it's tedious to debug or to have confidence in correctness, and the callback hell APIs are high friction in interactive/REPL development. Node is a fine vessel for running ClojureScript though ;) [1] See eg the bit about NaNs in the article.
  - danneu 9y ago
    I agree that Node once felt tangibly worse. I used Clojure for three years to avoid Node until I had to use Node at work (nobody was going to learn Clojure) and I discovered Koa when it just released. Even back in Koa 1, co/yield/function* closed the gap for me. Nowadays it's much better with ubiquitous promise usage and async/await. I miss various things about Clojure like the editor-as-a-repl development cycle, but in my opinion, they still amount to small technical differences that play second fiddle to business concerns.
ReverseCold 9y ago
In one word: npm In one sentence: You can build anything with NPM + copy paste in very little time.
sjg007 9y ago
I mean, you only need one language for front end and back end now, so that can be seen as a win! However, I for one prefer strongly typed languages as much as possible.
flukus 9y ago
> but considering its popularity I'm wondering if I'm wrong I think places like HN are probably distorting your view of how popular it is.
- cookiecaper 9y ago
  I don't know. It's definitely not displacing huge amounts of performance-critical Java or .NET yet, but it seems to be gaining inroads in the Real World from where I sit. I think your average corporate developer is just trying to earn a paycheck and also has a petrified fear of meaningfully learning/using more than one language. Telling him "use this and you can use JavaScript everywhere!" sounds like a big difficulty improvement to him, especially since JavaScript is something he "already knows" and has been familiarized through years of being the exclusive client-side development platform. Since this type of dev cares only about keeping his career on cruise control until retirement, Node.js is engaged with enthusiasm. In fact, it's one of the most enthusiastic receptions by BigCo devs that I've seen.
jimmywanger 9y ago
I replied in a sister thread, but here are some new points that are specific to your questions. Node was decided upon before I joined the team, because some of the senior developers on the team were big members of the node team, and they also wanted to crank out something new in this greenfield project. In retrospect, and in my reading of the history, Node was sufficiently different and new enough that it was "ooh, shiny new toy". JS/Node might be nice for scripting up a new demo that doesn't need to be maintained. I'd use Python/Django or Ruby/Rails myself, but whatever. Small projects that don't need to be supported to me seem pretty language agnostic. Do it in whatever tools you're most familiar with, and don't worry too much about fit. For large production systems that need to be supported and maintained, it's awful. First, javascript is changing incredibly rapidly. It seems like every couple of months, you're updating your libraries and there's a new "best practice". You're faced with updating all your already written code to use the new canonical way of doing things, or you're stuck with a mishmash of ways to do things all in production, and new engineers have to constantly ask what the new hotness is. Stack traces are useless. Yes, this function got called with invalid argument values from the event loop. What function called it, and what arguments did it have? Javascript itself basically has objects that are just JSON objects. When you're passing them back and forth, you get the irresistible urge to add "optional" fields just to pass one extra parameter for a use case. You generally end up with a big ball of wax parameter object being passed around with fields with unclear purposes. Libraries are often half-baked. They work most of the time, and try to do the right thing, but sometimes just behave unexpectedly. I'm not quite sure whether to blame the people who wrote the libraries, or if it's the language itself that tends to encourage things like that. I'm guessing it's six of one, half a dozen of another. I can't stand NPM. A lot of times, two libraries that you want to include will depend on incompatible versions of another, shared library, and you can download a NPM dependency tree for each library to overcome that. Everything hangs together, sort of. It's very difficult to reason about code, and things are generally defined by convention, until they're not. The callback is generally the last argument passed to a function, except in async control functions where it's the second to last one, and the last one is an array of the results of previous clauses. Saying that using the same language for the front-end and back-end allows engineers to work on both parts is silly, IMO, as front-end and back-end work require two disjoint skill sets. Just because surgeons and chefs both use knives, it doesn't mean that you'd want a chef performing a liver transplant. Also, node.js actually reads a lot more differently than most front-end code I've seen. Back-end code written in Java and front-end code written in Javascript tend to have the same sort of data flow and control structure, as opposed to Node which is on an island all by itself. I could go on further, but you get the gist.
tannhaeuser 9y ago
Node.js being based on JavaScript was accidental I believe. What the developer was after was an asynchronous, evented, non-blocking/non-multithreaded server runtime for game servers and similar apps without Java et al.'s "synchronized" and "volatile" model. Of course, Node.js is only suited for I/O-scheduled but not CPU-heavy workloads.
dagw 9y ago
So I'm curious as to the reasons people chose Node.js For work that is almost entirely IO bound Node is really fast and easy with asyc concurrency that works really well. Compared to most other solutions out there will you get a very fast solution very quickly. For problems which basically reduce to -Wait for GET/POST request -query a bunch of databases based on request -return result of DB queries as JSON Node works really well.
z3t4 9y ago
If you are using a web framework, and are considering switching to a systems language, and your developers already have a lot of experience in JavaScript, that's when you should consider NodeJS! I had a lot of JavaScript experience before switching to NodeJS, but it still was a huge step, you have to learn systems architecture, and distributed systems (async programming). I think JavaScript is easier then Java and C/C++, but it's still hard to learn, having the same language for both front-end and back-end makes up for that though.
- dahauns 9y ago
  I have a hard time really seeing this as a net win. There are huge upsides to having the same language on both sides - but the big downside is that javascript simply isn't a very good backend language. Node.js/v8 is incredibly impressive for what it is. But it still has "shoehorned" written all over it. (For the record: I wouldn't consider Java the Language a pinnacle either.)
  - z3t4 9y ago
    I agree that JavaScript isn't very good, but what are the alternatives !? I can not think of any language where a non-engineer with little computer science knowledge, can get productive withing minutes. And it only gets better the more you use it. For example, the other day I wanted to take a screen-shot of a web page, make a visual diff, then email me if something changed with the changes highlighted. I basically glued three different NodeJS modules together, and it took less then a hour. Try to do that in any other language.
    - dahauns 9y ago
      > I can not think of any language where a non-engineer with little computer science knowledge, can get productive withing minutes. That's a big misconception there. I absolutely don't mean this in an elitist way - and I completely agree that some degree of accessibility is a must - but this is in no way a benchmark for a good backend language. This is how we got PHP. > [WebPage screenshot -> visual Diff -> send mail] > Try to do that in any other language. I fail to see what's so difficult about this. I'd wager that in the "heavyweight stacks" you'd not even have to use modules outside the runtime libraries for a basic variant, and if you want to, you'd have them at your disposal. Don't get me wrong, the large centralized ecosystem of NodeJS definitely is one of its biggest pluses. But - and yeah, now I'm sounding a bit elitist and jaded - I've heard a variant of "It's so much simpler in X" or "Try that in anything else than X" too often when it only meant "I'm actually not really proficient in anything else but X".
spion 9y ago
To use words from Yaron Minsky, JS is no OCaml but it has a surprisingly decent "dynamic range", even though it doesn't look like it. (Yes, I'm pretty sure I'll end up being ridiculed for writing that, but... hear me out) Its easy to quickly put up a prototype. There are a ton of libraries for everything, and most come with copy-pasteable examples. Yes, this is frowned upon, and with good reason - but for prototyping, its exactly what you want. The prototype you write will also work much better than your average dynamic language prototypes (except for Erlang). With generators and async/await the code became fairly pedestrian and un-convoluted. The only additional element in the mix are the few await/yield keywords sprinkled around. The language is flexible enough that you can also write code in FP style (higher order functions, combinators, etc). For example, RxJS code looks pretty natural. ES6 and above has all the modern bells and whistles: decent module system, classes, short lambda syntax, template strings... As a result code is pretty much as pleasant to write as Ruby or Python When your project grows large enough, you have the option to painlessly convert to TypeScript. Besides getting rid of one annoying JS flaw (implicit conversions), this will also improve development tooling tremendously. TypeScript again has a wide dynamic range: you can start out with a fairly lax type system that allows a lot and then turn the dial up by turning on more and more checks (no any types inferred, strict null checks, etc) TypeScript's type system is surprisingly powerful: generics, unions, intersections, type guards, discriminated unions, control flow analysis with exhaustiveness checks, string/integer literal types, "mapped types" - the list is quite large and growing: https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types.... . But what makes TS different is that it models and formalises idiomatic JavaScript well, so your existing code will not need to be adapted. TypeScript is where client/server code sharing starts to shine. Shared types enable end-to-end type-checking. You can arrange your code in such a way that data fetching is injectable, and use the same code with fetch on the client and direct method calls on the server (thanks to the same interface). If you have a very demanding client-side app, there will definitely be a lot of code reuse opportunities. (Nowadays I suppose this is also possible with Scala.js and bucklescript) The lack of threads is a mixed bag. Most people already covered the disadvantages very well so I'll mention some advantages. Its much easier to reason about stateful code, since you can treat each synchronous code chunk as uninterruptible, and the possible interleaving points are always obvious (e.g. await/yield keyword). There are also several techniques and libraries to work around the disadvantages (e.g. dnode for RPC to separate processes for intensive calculations) and while none of them are very convenient, they usually end up being what you have to do eventually anyway. Threads will only get you so far with servers running CPU intensive jobs - soon you will need more than one machine and then you can't take advantage of shared memory any longer. If all else fails, you can probably throw more processes at it and put a load balancer. Thats an interesting project, and AFAIK not yet solved (at least not in the node ecosystem). You would need a load balancer that is aware of the current state of the node processes - round-robin or random algorithms will be far from optimal to be helpful. I started some work on this here: https://github.com/spion/least-latency-balancer https://github.com/spion/least-latency-balancer but I'm sure that its not the best approach and that it can be improved a lot. Might be a good idea to look at what the OCaml folks have - I'm pretty sure they've been dealing with a somewhat similar problem due to the lack of multicore. Another way to attack this problem is to have better monitoring for long CPU-bound tasks e.g. https://www.npmjs.com/package/long-task-detector https://www.npmjs.com/package/long-task-detector But I will admit that in this regard, there are languages/runtimes where the situation is far better: Haskell, Go, Erlang to name a few.
reacweb 9y ago
I do not like javascript. I am using it on my server because of performances. It has about the same execution speed as java, a slightly smaller memory footprint, but with the async io, it ensures best use of cpu with none of the hassles of multithreads. No need of apache or nginx, with a single process, you can serve hundreds of simultaneous users with blazing performances
- hocuspocus 9y ago
  There are quite a few Netty-based web frameworks faster than Node.js
amelius 9y ago
If you want to run the same code on the browser as on the client (for example in a scheme where you want to reduce latency by optimistically running server-code on the browser), it is nice to have Javascript on the server. But you could also achieve this by transpiling another language to Javascript of course.
gbuk2013 9y ago
From some JavaScript training slides I am working on: Why use it: - Server and client side in the same language - Simple enough for you to feel free - Enough hammers not to forge your own every time - Fast enough - Good enough to structure larger programs - Browser is the only cross-platform GUI toolkit When to use it: - Web applications - Network clients and servers When not to use it: - Computation (CPU) heavy programs - Very high loads - Shell scripting - Raw packet requirement
overcast 9y ago
Biggest benefit, as a solo developer, is one language for everything. I can rip through the front end, and back end work for all my new venture projects, without changing gears.
rb808 9y ago
I'm a huge proponent of using the same language in front and back end. My best teams had C++ front & back, or C# front and back, even Java front and back. Even though one language/platform isn't ideal for both ends, the benefit of getting everyone on the same tools, libraries, processes and way of thinking is invaluable. So these days where most front ends are JS, it makes a lot of sense to have a JS back end too.
curun1r 9y ago
I can say why I chose it and why I no longer choose it anymore. For me, JavaScript was the price I had to pay for a number of other benefits. I don't like the language, but TypeScript, Coffeescript and the like can paper over some of the deficiencies well enough. But what Node is is more than just JavaScript. It's a fast, well-designed runtime written in C++ with the event loop as a central construct. It's an ecosystem where async is the default and you don't have to work hard to get performance and scalability in that area. And it has a fantastic package management tool. The quality of the packages that npm installs may not always be high, but the tool itself is so much better than pip, maven/gradle, gem, cpan, etc. I've moved on from Node because I've found nearly all the benefits of Node available in Rust. Rust has the performance of Node's C++ runtime, easy event loop with tokio, and cargo is the one package manager that I think betters npm. And with wasm, we're even starting to see the possibility of sharing code between the server-side and client-side. Add to that the ability to use it anywhere that Node can be used (I'm using Rust now with Lambda without a single line of JavaScript), and there's now no reason for me to put up with the hassles that using such a poorly-designed language as JavaScript imposes.
specialist 9y ago
You're not wrong. InterSystems Caché is easily the worst tool I've ever used. A typo in your code often caused the compiler to bork your entire runtime. Not kidding. Node is almost that bad. Stately as nicely as possible: it's syntactic vinegar for a type hostile flow of control obfuscation framework. If you have some irrational need to use libuv (callback hell vs actors, CSP, multithreaded NIO, or AIO thread per connection), you're much better off just using 'C'.
- lawik 9y ago
  A bit flame-baity but I liked your point for the description. Syntactic vinegar was new to me and type hostile felt novel. Also a good example of how it needs to be okay that some people just don't like Node. While also illistrating that they could also, arguably, be nicer about it ;) What area do you generally work in? That often influences the view of which tools are suitable.

Scarbutt 9y ago

So I'm curious as to the reasons people chose Node.js Javascript of course ;) You can leverage the same language for server side stuff and browser programming.

lasfter 9y ago
But how valuable is that? I hear this a lot but is it really that much of an inconvenience to write backend code in a different language? Especially if there are different engineers working on the frontend and backend.
- jdhawk 9y ago
  Language is never the problem. Languages (mostly) are easy. Frameworks are hard. Tooling can be hard (pick a language). Javascript is easy. Express, NPM, Bower, <insert framework of the month> are tough.
- chrisco255 9y ago
  It's very valuable if you are bouncing back and forth between frontend and backend. There's no context switching as you do that. The cognitive overhead of context switching is higher than people generally accept. This is why stacks like the MEAN/MERN stack get used in hackathons. You've got a JSON-inspired database (Mongo) with a minimal server-side framework (Express) feeding a React/Angular front-end. You can use the same libraries client/server side like Mocha for unit testing, Lodash for collection manipulations, you can even share the same validation files for server & client.
  - mgkimsal 9y ago
    "There's no context switching as you do that" So, you just read/write to a database wherever? Or do you have to remember the context the code is running in? There may not be syntax switching, but I think you stil usually need to remember where the code in question will be executing (well... I need to, anyway)

binarez 9y ago

Check out Typescript!

lasfter 9y ago
I actually have, but it doesn't alleviate my biggest issue with Javascript, which is its async story. Also I've had experiences with Typescript code compiling with an error then immediately recompiling without any errors. Then errors when I switch to my browser. The immediate recompilation is probably just webpack but it doesn't inspire confidence when errors are non-deterministic.
- koolba 9y ago
  Typescript plus async/await is a beautiful solution to both the async story and typing story.
  - lasfter 9y ago
    I don't think asnyc/await is a good solution to asynchronous programming. Lua, Go et al are more what I was thinking of as good examples of asynchronous programming. See http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... And I addressed some concerns with Typescript in a sibling comment. It is much better than plain Javascript, though.
  - pyrophane 9y ago
    The problem I experienced with async/await and Typescript was always the lack of built-in support for promises among the libraries I was using. Once I had to use something like promisifyAll() I lost any type information I had about the library in question. Is there any better workaround to that these days?
    - koolba 9y ago
      Not really but I also don't see it as that much of a problem. The libraries I use either provide a Promise based interface or I've written my own as a thin veneer atop a callback interface. Ditto for apply your own types atop the results. Most are already there and only a few edge cases need to be added.

garysieling 9y ago

There are a lot of negatives, but it is any easy language to make rapid progress writing code in, and ES6 or TypeScript have made it a lot better than it used to be. You can do a lot of prototyping in the browser REPL too (e.g. I like to go to the lodash docs, write out code on the site, then paste into my app). It's nice to be able to do server side rendering (i.e. run React there). Also you can run all the build tools in your application server during development which can be super convenient - Probably the most compelling example I've seen of this is Next.js.

SimeVidas 9y ago

I only know JavaScript (and I know it quite well). Why learn a whole other language, when Node gets the job done just fine?

tambourine_man 9y ago
Learning a new language will make you a better programmer. Especially one with different paradigms
- SimeVidas 9y ago
  I’m not sure that being a “better programmer” is important in web development. And I don’t mean that term in the broad sense—obviously, we should write good code—but in the sense that understanding two programming languages makes a significant difference. I think in web development it doesn’t. Web development is about many things. HTML, CSS, performance, accessibility, security, networking, supporting different browsers, polyfills and workarounds, keeping up with new features, UX and usability. Then there are frameworks and build tools, which are all of course JavaScript-based. Only a small part of web development is actual programming, and the fact that frameworks most of the time lay out the patterns for you, makes the “programmming” aspect even less significant in the overall picture. So no, I don’t think that learning another programming language is a good way to spend your time if you’re a web developer.
fwefwwfe 9y ago
Because nto everyone suffers from Stockholm syndrome?
rimliu 9y ago
That makes me wonder, what number of "choose to use JavaScript" is compared to "have no real choice, because JS is the only language they know".

untog 9y ago

Being able to run the same code on the client and server is a boon for web sites - rendering views server side then hooking up client events is a lot more performant than only rendering on the client side. Also, context switching - the projects I work on tend to be front-end heavy, with a little API access and data storage on the backend. I find it a lot easier to do that backend work with the same language, tools and debugging environment as my client code.

partycoder 9y ago

JavaScript is a scripting language. So is Python and Ruby. As a scripting language, excluding all bindings (files, networking, etc), JavaScript is substantially faster than Ruby or Python. Now, in terms of bindings, bindings to libuv are also fast. So node is not so much of a problem in itself. However the problem is how the language is being used: To say you can write a serious library or server code because you know JavaScript, is the same as saying you can write a paper in cardiology research because you know English. You will find a lot of people that completely disregard the domain knowledge required to write safe, workable code. While this happens in many languages, JavaScript is the lingua franca for those kind of people. Because of this, be very careful of the libraries you use. You will most likely have to read the code to ensure there is some thought behind it. Then if you are hiring node developers, prepare to receive an avalanche of resumes from people without a degree expecting to learn on the job at your expense while receiving a 6 figure salary.

hota_mazi 9y ago
> As a scripting language, excluding all bindings (files, networking, etc), JavaScript is substantially faster than Ruby or Python. This makes no sense. They're all dynamically typed languages (avoiding the term "scripting languages" since it's pretty vague). The only reason for the difference in speeds between these languages is due to the quality of their interpreters, not the languages themselves.
- goatlover 9y ago
  Yeah, since PyPy is V8 fast, LuaJit is faster, and Julia is even faster.
- partycoder 9y ago
  If you have embedded or extended a scripting language it makes perfect sense. Repeating myself just for you: I was referring specifically to benchmarking language aspects excluding bindings to native code such as files, networking, processes, etc. e.g: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=python3 https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... Then sure, JavaScript has many implementations, so does Ruby and Python. I was referring to v8 (used by node), CPython and Ruby MRI in particular.

manyxcxi 9y ago

I've got over a decade of professional experience in C#, Python, and Java. I'd consider myself a Java developer before all else, yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement. Here's the major caveat, out of, say 100+ PoC/prototype projects I've ever done, I've taken two to 'production'. I put production in quotes because they were actually internal services as part of our build and delivery pipeline. It's a major pain in the butt to monitor and keep Node.js running production-like in even remotely similar ways you would with Java, .NET, Python, or even PHP for that matter. I don't expect such drastically different technologies to be exactly alike for production workloads, but there's usually analogous ways to do X, Y, or Z. You know where Node has been awesome? You land a project with a real tight deadline and its more of a fire and forget project (think interactive 'experience' at a major gaming conference for instance). It needs to run pretty well for a short period of time with a narrow scope of functionality, but some of that functionality is non-trivial. I absolutely love Node for that.

thesmallestcat 9y ago
Can you elaborate on the "major pain in the butt to monitor and keep Node.js running production-like" What sorts of issues did you face? Certainly .NET and Java have more tooling, but I haven't noticed a difference between keeping a Node process up as opposed to a Python one. Hard to compare to stateless PHP.
- stickfigure 9y ago
  The default behavior for Node when there is an uncaught error is to crash the process, killing all requests in flight. Even if you go out of your way to stop this default behavior, errors still likely leave the process in an inconsistent state. Node can't just unwind a few stack frames like synchronous platforms. Do you read JSON from ajax post bodies? Do you access fields in that JSON without sanity checking it? Try passing JSON that's missing one of those critical fields (as, say, a griefer might do). What happened to your app?
  - m1sta_ 9y ago

ohstopitu 9y ago

I've used nodeJS at 3 of the past 4 startups I've worked at (currently using PHP). I had a hand in choosing it at all those 3 places and my main reasons boiled down to: 1. most devs know JS (so it's easier to hire & onboard new devs) 2. while everyone claims node's dependencies are hell, I love the choice available (although over time, it's tiring). 3. The community is generally awesome (helps during meetings, online etc.) 4. Developer Exp: With TS, Tslint etc, devx is not too bad IMO (and there's no dearth of opinionated articles around on the correct way to do things) 5. Finally - we can quickly churn out prototypes for features to production (but I guess that's more experience than the tools?). 6. In general, we'd be using JS on the frontend anyway (React), so it just made sense to use one language everywhere. 7. In general, most tools have JS SDKs and JS language support is always around (an exception I found was Tensorflow) - as an example, AWS Lambda supports Java, Python and JS.

oddlyaromatic 9y ago
I'm pretty much a beginner developer, doing a few small things but not employed as a dev. I like JavaScript, and when I wanted to do server side stuff (like automate schedule emails at my company), solutions were really available in PHP and it worked right away on my local machine with mamp and on my super cheap web hosting, whereas I seem to hit various setup pains when I try to do something with node. The PHP syntax was close enough for me to be much more comfortable than I expected to be. I recently worked on something that logs a user in to a mobile-unfriendly website, scrapes and parses a specific page that you would want to see on mobile, and presents a nice mobile view, with some extra relevant information. All the scraping is done in PHP and it just returns json that gets displayed with a handlebars template. It's just a demo right now, but my point is that even knowing a bit about JS, PHP feels so much more accessible than node for me, and I've done stuff that a year ago I never would have thought I could do. I feel like solutions are close and only require language and library research. Node solutions also require this other layer of knowledge that I haven't clicked with. How is PHP treating you at your current job?
vacri 9y ago
> while everyone claims node's dependencies are hell, I love the choice available (although over time, it's tiring). So... at one place I work, we use nodejs. There are so many modules added using so many files, that we ended up not being able to use our packaged application - extracting the package into a holding dir before moving into place meant that we ran out of inodes on the filesystem (stock 8GB ubuntu ext4 cloud image)! The filesystem could not hold two copies of our app, basically, due to inode exhaustion. The easy workaround was "increase the size of the disk", which seems silly given it's 80% free space. This has apparently been fixed in recent times with flatter npm structures, but watching the nodejs community run into every single packaging roadblock that has been solved before is just disheartening.

silviogutierrez 9y ago

I'm the biggest JS-on-the-server sceptic of them all, given my past experiences. But this was pre-typescript. If a TypeScript ORM with automatic schema migrations and decent expressiveness comes around, I'd be willing to give NodeJS another shot. But so far, nothing comes even close to the productivity of Django + ORM + Django Rest Framework. For your typical CRUD app, this will walk circles around any current JS solution. Even if the lack of static typing eventually becomes a bit of a pain.

jcrben 9y ago
Have you seen typeorm? https://github.com/typeorm/typeorm https://github.com/typeorm/typeorm
- silviogutierrez 9y ago
  I have. It's a great improvement over other ORMs in the NodeJS space but pales in comparison to Django's ORM. At least for now. Relationships must be done manually, including joins, traversing, and many to many. Sometimes doing: w = Widget.objects.get(pk=2) w.category.author.name Is just all you need. And Django makes that trivial.
Daishiman 9y ago
I'm on the same boat. Django or Rails are so much more productive for me that I feel that most of the Node.JS love for this sort of domain comes from people who have never tried anything better.
- throwanem 9y ago
  The operative words here being "for me".
sametmax 9y ago
This. Yes the site won't be as fast, and yes you don't have realtime. But if you need a regular web site, not a real time app with 100000 users, then nothing BEAT those techs. They are mature, stable, productive, and incredibly flexible. If you use anything else and you need something that is not "the typical hello world", you will have to write it by hand. With DRF ? You google it, you find a module and call it a day.

bspates 9y ago

I've been using NodeJs for about 4 years now. It really lends itself to the microservice paradigm. It makes great networking glue as you can handle many simultaneous connections without using many resources and since most web server operations are just fetching/updating data between databases or other services this works out well in NodeJs. The trick is to use it for this purpose only. Long running computations should be offloaded to the database or workers running in another process or machine. A lot of the problems mentioned in that article are the author misunderstanding libraries and not actual issues with NodeJs itself. For instance the problem with the Postgres library was that he didn't read the docs. The lib uses a session pool by default. You have to release the session when your done or else it will not become available again until the default session timeout is passed, which is quite large in Postgres. In respect to using Coffeescript "Classes", forcing JS to work like other languages will create unexpected behavior. It uses prototypical inheritance, not class inheritance.

JesseAldridge 9y ago

I've never run a javascript server in production, but if I do the main reason would be to take advantage of the huge ecosystem. Since js works on both the client and server side, you end up with a lot more programmers hacking on it. If you check http://www.modulecounts.com/ http://www.modulecounts.com/ you can see that npm has as many modules as all the other package repos combined. And it only seems to be gaining momentum. (screenshot: http://imgur.com/a/adqNJ http://imgur.com/a/adqNJ) Meteor has more stars on GitHub than any other web framework: https://github.com/search?p=3&q=stars%3A%3E1&s=stars&type=Repositories https://github.com/search?p=3&q=stars%3A%3E1&s=stars&type=Re... Nodejs, socket.io, and express all appear on the first few pages.

TheCondor 9y ago

V8 is a world class compiler. Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. (Pypy is a good match for it but it's not main street and you can't just use any module.) in terms of performance and popularity, v8/node stand pretty much alone as far as dynamic non-compiled environments. JavaScript has a lighter weight feel than Java and the jvm stack. Single threaded with a top notch event reactor. You can write just a few lines in node and have a web server serving some json. There are a ton of JavaScript coders. There is something to be said for having a common technology throughout your stack and you ui is almost certainly in js. It's easy to get something simple going quickly, there are tons of libraries and you're going to need to write go, Java or .net to out perform it. The big downsides, imho, v8 is designed for client side stuff. Both it and dart vm are limited to relatively small memory footprints (think 1GB) which just isn't good for some workloads and problems. Likewise a lot of server tasks can make good use of real threads, you're out of luck with node, you can have child processes and send messages but if they have to share big amounts of data the marshaling becomes a bit of a bottleneck. If you work is database crud, or light weight, or horizontally scalable, or able to be modeled as streams then node isn't that bad. Js feels kind of limited in how certain things are modeled, there isn't much data hiding or abstraction; the extreme simplicity almost creates more complexity for some things. There are lots of different opinions on basic code behavior, some node modules do work on import, some need explicit initialization, some alter prototypes and it's a concept that seems to be lost on many js devs; I've burnt hours debugging something because someone reordered the imports and it screwed init logic. And you'll completely screw yourself if you don't stay up to date with your depends, things change fast and sometimes they change a lot. Both node and dart vm seem really well equipped for tooling type things that are usually done in bash, Python or perl but that doesn't seem to be as popular. It's definitely not for everything but it's worth a look. It is really popular.

lasfter 9y ago
I see some merits. I am not sure I buy using JavaScript based on performance/dev speed ratio though. Lua is even faster, lighter weight and has clean, logical semantics. I guess I'm just trying to decide if having a large talent pool and tons of modules is good enough.

eropple 9y ago

So I felt this way until about...oh...a month ago. Because my JavaScript experience was mostly ES5. And ES5 is a roiling piece of shit that I wouldn't wish on my worst enemy. ES6, however? ES6 is tolerable. Getting it set up isn't as bad as you'd think and the language does as much as a Ruby or a Python in not shooting yourself in the foot. I'd trade async/await for actual threads, because I am capable of writing code with threads without hurting myself, but async/await are fine for get-it-out-the-door web services and that kind of thing. So I don't worry about it that much. I'd still go reach for the JVM and languages like Java or Kotlin if I was going to be hammering on a piece of code on an everyday basis for two or three years. But in 2017 (and probably 2016, but 2017 was when I got to it), it just became good enough to get it out the door with. (Regarding TypeScript: I feel like it's an incomplete thing and I'm happy that it exists, but for the stuff I use ES6 for I can hold the entirety of it in my head and I'm not worried about typing. For things that matter to me...well, I wouldn't be using ES6 in the first place.)

cookiecaper 9y ago
Sadly, I've been going through a similar experience after several commenters indicated that my complaints seemed to refer to "old" JavaScript and encouraged me to try ES6. Between ES6 fixing [0] many of the day-to-day warts that made JavaScript a joke language barely suitable for scripting DOM elements and V8's complete obliteration of other dynamic VMs in speed, I am being forced to accept that JavaScript is maturing into a serious platform, and starting to gradually introduce Node.js into my workflow. Just today I was discussing how hard it is to pull the stick out of my butt regarding JavaScript, but I think that the evidence is in favor of it. I'm having a strong impulse to try to use Dart instead just so I don't feel as dirty anymore. [0] http://es6-features.org http://es6-features.org

eel 9y ago

At a previous gig, without getting into specifics, we built a huge internal client-server system. The client was written in Node.js and ran as services on both Windows and Linux on a few thousand machines. The server was written in Node.js and ran as a Linux daemon. Node.js matched the developers' skill sets and gave us the ability to quickly write a server that could easily handle several thousand concurrent requests from the clients. On the client-side, Node.js gave us cross-platform support for nearly free (as well as being within our skill sets). Looking back, I do not think the project would have gotten off the ground in any other platform in that specific organizational environment. The server on Linux was particularly well-suited as it was architected to scale horizontally but still had room to scale vertically. On the client side, while we were able to get the Node.js service out pretty quickly, it eventually had performance and integration issues, particularly on Windows. It was super frustrating having to shell out to external processes or write native C++ modules to get access to some needed Windows APIs. In hindsight, I would have tried to rewrite the Windows client sooner in C++ or C#. On the plus side, it was a huge advantage that the entire Node runtime fit in a single executable (no dependencies on a huge JRE or other runtime). Overall, I would recommend it as an option to consider if most of the following is true: * Need to get to market quickly * Application is I/O intensive rather than CPU intensive * Dev team already knows JavaScript * Target environment is not Windows Personally, I decided to move away from Node.js and these days if I was faced with the same problem I would lean toward a JVM language or Elixir.

sgift 9y ago
> * Target environment is not Windows That one is still my main problem. I know, I know, Windows is evil and so on, but our customers use it. We are remarkably free in choosing our tools or whatever, but Windows is usually a constant (Intranet environments) and every day I crash against the absolute "Windows is a second class platform" problem of NPM modules. For an environment which is supposedly platform-agnostic the amount of "only on Unix" is astonishing.
- jklepatch 9y ago
  Really? I think exactly the opposite. Compared to a lot of other tech, I found nodejs to work pretty well on windows. For example, recently npm switched from a nested to a flat directory organisation in node_modules. Windows has a limit on the number of nested directories, so this new organisation helped a lot. Maybe that you use a lot of modules with c dependencies?

erikpukinskis 9y ago

For me the question isn't so much why do I choose Node.js and Javascript over other languages, it's why do I choose NPM over other module libraries. I think the ergonomics of the libraries and command line tools we use have a much bigger impact on our coding experience than the language itself. And what I like about NPM is that there are a LOT of single file modules with a narrow, well defined scope. There are exceptions to this, like Ember or Angular, where they try to package up everything you might need. But there are also smaller frameworks like Vue.js and even smaller packages still, which do a single aspect of data binding or rendering or whatever. And it's those granular little packages where I think the NPM community ends up exploring just about every possible way to do get something done, and often comes up with a new idea that can teach me something. The organizational and software complexity behind an interface like Rails or iOS or Ember I think discourages app developers from questioning the interfaces they are using, and participating in shaping the landscape under them. I think that's a shame. The NPM community does it better.

ralusek 9y ago

NodeJS has a handful of things that tend to get brought up. Callback soup and difficult error handling. Both are resolved by promises. Once you get the hang of promises, you are capable of doing concurrent asynchronous tasks in a manner that would be significantly more difficult in any other language. On top of that, NodeJS is very, very fast. Compared to Python or Ruby, straight computing is significantly faster, but that's not even where the meaningful gains come from. Because NodeJS is non-blocking, the core is IMMEDIATELY available to serve the next request once an asynchronous call is made (read from DB/Cache/HTTP call). Because of this, each core can serve thousands of simultaneous connections. Because JS is single threaded, in order to take advantage of multi core hardware, you just run the cluster module to effectively launch a concurrent instance of your application for each core. As far as the language itself, once I understood it, I loved it. At first, I thought it was terrible, but when I went to ES6 syntax, and fully groked how to write asynchronous code, it rocketed to my favorite language. I started with Java, moved to Python, and although it took me a while to come around to JS, I would absolutely never go back.

jcrites 9y ago
> Once you get the hang of promises, you are capable of doing concurrent asynchronous tasks in a manner that would be significantly more difficult in any other language. What languages are you comparing against? It seems like asynchronous code is more difficult to write in NodeJS than in C#, Go, or Rust, and about the same as Java. I can write code in Java in a style similar to promises using ListenableFuture (Google Guava) or CompletableFuture (Java 8) [0]. I should also clarify that I don't think promises are the optimal approach to asynchronous code. I think you can do better, and the primitive "await" is an example of how. Bob Nystrom (munificient) wrote an article called "What Color is your Function?" [1] that does a good job describing the difficulties of promised-based async, and how await improves on it, and how Go does even better. (From what I've read, JavaScript ES8 is supposed to include async/await, and NodeJS seems to have support for them. At that point you'll be able to program in standard JavaScript and use await, which will bring NodeJS up to parity with the first-tier languages.) > On top of that, NodeJS is very, very fast. Compared to Python or Ruby, Perhaps that's true compared to Python and Ruby, but not when compared to other high-performance runtimes like Java. The following three paragraphs are from a comment I previously wrote on this topic [2]. Folks might also be interested in the TechEmpower web framework benchmark [3]. The top Java entry ("rapidoid") is #2 on the benchmark and achieves 99.9% of the performance of the #1 entry (ulib in C++). These frameworks both achieve about 6.9 million requests per second. The top Java Netty server (widely deployed async/NIO server) is about 50% of that, while the Java Jetty server, which is regular synchronous socket code, clocks in at 10% of the best or 710,000 R/s. NodeJS manages 320,000 R/s which is 4.6% of the best. In other words, performance-focused async Java achieves 20x, regular asynchronous Java achieves 10x, and boring old synchronous Jetty is still 2x better than NodeJS throughput. NodeJS does a pretty good job given that it's interpreted/JITed while Java is compiled, though Lua with an Nginx frontend can manage about 4x more. NodeJS is handicapped by having to orchestrate everything from its single thread. I agree that asynchronous execution can provide an advantage, but it's not the only factor to consider while evaluating performance. If throughput is someone's goal, then NodeJS is not the best platform due to its concurrency and interpreter handicap. If you value performance then you'll chose another platform that offers magnitude better requests-per-second throughput, such as C++, Java, Rust, or Go according to [3] and [4]. But I'll grant it has better IO performance than many other dynamically typed languages. Asynchronous execution also does not necessarily require explicit async programming. Other languages have as good or better async support -- for example, see C#'s `await` keyword. [1] explores async in JavaScript, await in C#, as well as Go, and makes the case that Go handles async most elegantly of those options. Java has Quasar, which allows you to write regular code that runs as fibers [5]. The code is completely normal blocking code, but the Quasar runtime handles running it asynchronously with high concurrency and M:N threading (similar to Go). Plus these fibers can interoperate with regular threads. Pretty gnarly stuff (but requires bytecode tampering). If async is your preference over Quasar's sync, then Akka might be up your alley instead [6]. Lastly, high performance servers don't necessarily require asynchronous code at the application layer; performance sensitive logic can often live in the library or framework e.g. Netty, reverse proxy e.g. Nginx, or in the OS's context switching. > Because NodeJS is non-blocking, the core is IMMEDIATELY available to serve the next request once an asynchronous call is made (read from DB/Cache/HTTP call). Because of this, each core can serve thousands of simultaneous connections. This also describes regular synchronous code with many threads. Once your application makes a blocking call, the operating system context switches to another thread (process). This is how boring old blocking Java code running on Jetty outperforms NodeJS in request-per-second benchmarks [3]. And you could take advantage of this in NodeJS too if it weren't for the fact that JavaScript execution occurs in a single thread! For most typical applications, overall performance is more influenced by the efficiency of the runtime than it is by the concurrency/async strategy. [0] https://github.com/google/guava/wiki/ListenableFutureExplained https://github.com/google/guava/wiki/ListenableFutureExplain... and https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html https://docs.oracle.com/javase/8/docs/api/java/util/concurre... [1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... [2] https://news.ycombinator.com/item?id=12341886 https://news.ycombinator.com/item?id=12341886 [3] https://www.techempower.com/benchmarks/#section=data-r11&hw=peak&test=plaintext https://www.techempower.com/benchmarks/#section=data-r11&hw=... [4] https://news.ycombinator.com/item?id=12268988 https://news.ycombinator.com/item?id=12268988 [5] http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/ [6] http://akka.io/ http://akka.io/

danneu 9y ago

My reasoning: all of the dynamically-typed languages are more or less the same on the server for CRUD apps, so I might as well use Javascript.

laser 9y ago
Hmmm, that hasn't been my experience: http://www.phoenixframework.org/ http://www.phoenixframework.org/
- danneu 9y ago
  I haven't used it, but it's still the same pseudocode: defmodule HelloPhoenix.UserController do def index(conn, _params) do users = HelloPhoenix.Repo.all(HelloPhoenixUser) render conn, "index.json", users: users end end For CRUD, I'm not too convinced it's much different than what you'd be doing anywhere else. For websockets, streaming, and other stuff beyond request -> database query -> response, then competing abstractions get more interesting.
pbreit 9y ago
It's interesting that JavaScript on the server has grown at the same time front & back ends have separated. Which in my experience has drastically reduced development speed.
fulafel 9y ago
I find there are really big differences between the dev experience in Python, Node, Clojure and Erlang. JS doesn't trap errors[1], so it's tedious to debug or to have confidence in correctness, and the callback hell APIs are high friction in interactive/REPL development. Node is a fine vessel for running ClojureScript though ;) [1] See eg the bit about NaNs in the article.
- danneu 9y ago
  I agree that Node once felt tangibly worse. I used Clojure for three years to avoid Node until I had to use Node at work (nobody was going to learn Clojure) and I discovered Koa when it just released. Even back in Koa 1, co/yield/function* closed the gap for me. Nowadays it's much better with ubiquitous promise usage and async/await. I miss various things about Clojure like the editor-as-a-repl development cycle, but in my opinion, they still amount to small technical differences that play second fiddle to business concerns.

ReverseCold 9y ago

In one word: npm In one sentence: You can build anything with NPM + copy paste in very little time.

sjg007 9y ago

I mean, you only need one language for front end and back end now, so that can be seen as a win! However, I for one prefer strongly typed languages as much as possible.

flukus 9y ago

> but considering its popularity I'm wondering if I'm wrong I think places like HN are probably distorting your view of how popular it is.

cookiecaper 9y ago
I don't know. It's definitely not displacing huge amounts of performance-critical Java or .NET yet, but it seems to be gaining inroads in the Real World from where I sit. I think your average corporate developer is just trying to earn a paycheck and also has a petrified fear of meaningfully learning/using more than one language. Telling him "use this and you can use JavaScript everywhere!" sounds like a big difficulty improvement to him, especially since JavaScript is something he "already knows" and has been familiarized through years of being the exclusive client-side development platform. Since this type of dev cares only about keeping his career on cruise control until retirement, Node.js is engaged with enthusiasm. In fact, it's one of the most enthusiastic receptions by BigCo devs that I've seen.

jimmywanger 9y ago

I replied in a sister thread, but here are some new points that are specific to your questions. Node was decided upon before I joined the team, because some of the senior developers on the team were big members of the node team, and they also wanted to crank out something new in this greenfield project. In retrospect, and in my reading of the history, Node was sufficiently different and new enough that it was "ooh, shiny new toy". JS/Node might be nice for scripting up a new demo that doesn't need to be maintained. I'd use Python/Django or Ruby/Rails myself, but whatever. Small projects that don't need to be supported to me seem pretty language agnostic. Do it in whatever tools you're most familiar with, and don't worry too much about fit. For large production systems that need to be supported and maintained, it's awful. First, javascript is changing incredibly rapidly. It seems like every couple of months, you're updating your libraries and there's a new "best practice". You're faced with updating all your already written code to use the new canonical way of doing things, or you're stuck with a mishmash of ways to do things all in production, and new engineers have to constantly ask what the new hotness is. Stack traces are useless. Yes, this function got called with invalid argument values from the event loop. What function called it, and what arguments did it have? Javascript itself basically has objects that are just JSON objects. When you're passing them back and forth, you get the irresistible urge to add "optional" fields just to pass one extra parameter for a use case. You generally end up with a big ball of wax parameter object being passed around with fields with unclear purposes. Libraries are often half-baked. They work most of the time, and try to do the right thing, but sometimes just behave unexpectedly. I'm not quite sure whether to blame the people who wrote the libraries, or if it's the language itself that tends to encourage things like that. I'm guessing it's six of one, half a dozen of another. I can't stand NPM. A lot of times, two libraries that you want to include will depend on incompatible versions of another, shared library, and you can download a NPM dependency tree for each library to overcome that. Everything hangs together, sort of. It's very difficult to reason about code, and things are generally defined by convention, until they're not. The callback is generally the last argument passed to a function, except in async control functions where it's the second to last one, and the last one is an array of the results of previous clauses. Saying that using the same language for the front-end and back-end allows engineers to work on both parts is silly, IMO, as front-end and back-end work require two disjoint skill sets. Just because surgeons and chefs both use knives, it doesn't mean that you'd want a chef performing a liver transplant. Also, node.js actually reads a lot more differently than most front-end code I've seen. Back-end code written in Java and front-end code written in Javascript tend to have the same sort of data flow and control structure, as opposed to Node which is on an island all by itself. I could go on further, but you get the gist.

tannhaeuser 9y ago

Node.js being based on JavaScript was accidental I believe. What the developer was after was an asynchronous, evented, non-blocking/non-multithreaded server runtime for game servers and similar apps without Java et al.'s "synchronized" and "volatile" model. Of course, Node.js is only suited for I/O-scheduled but not CPU-heavy workloads.

dagw 9y ago

So I'm curious as to the reasons people chose Node.js For work that is almost entirely IO bound Node is really fast and easy with asyc concurrency that works really well. Compared to most other solutions out there will you get a very fast solution very quickly. For problems which basically reduce to -Wait for GET/POST request -query a bunch of databases based on request -return result of DB queries as JSON Node works really well.

z3t4 9y ago

If you are using a web framework, and are considering switching to a systems language, and your developers already have a lot of experience in JavaScript, that's when you should consider NodeJS! I had a lot of JavaScript experience before switching to NodeJS, but it still was a huge step, you have to learn systems architecture, and distributed systems (async programming). I think JavaScript is easier then Java and C/C++, but it's still hard to learn, having the same language for both front-end and back-end makes up for that though.

dahauns 9y ago
I have a hard time really seeing this as a net win. There are huge upsides to having the same language on both sides - but the big downside is that javascript simply isn't a very good backend language. Node.js/v8 is incredibly impressive for what it is. But it still has "shoehorned" written all over it. (For the record: I wouldn't consider Java the Language a pinnacle either.)
- z3t4 9y ago
  I agree that JavaScript isn't very good, but what are the alternatives !? I can not think of any language where a non-engineer with little computer science knowledge, can get productive withing minutes. And it only gets better the more you use it. For example, the other day I wanted to take a screen-shot of a web page, make a visual diff, then email me if something changed with the changes highlighted. I basically glued three different NodeJS modules together, and it took less then a hour. Try to do that in any other language.
  - dahauns 9y ago
    > I can not think of any language where a non-engineer with little computer science knowledge, can get productive withing minutes. That's a big misconception there. I absolutely don't mean this in an elitist way - and I completely agree that some degree of accessibility is a must - but this is in no way a benchmark for a good backend language. This is how we got PHP. > [WebPage screenshot -> visual Diff -> send mail] > Try to do that in any other language. I fail to see what's so difficult about this. I'd wager that in the "heavyweight stacks" you'd not even have to use modules outside the runtime libraries for a basic variant, and if you want to, you'd have them at your disposal. Don't get me wrong, the large centralized ecosystem of NodeJS definitely is one of its biggest pluses. But - and yeah, now I'm sounding a bit elitist and jaded - I've heard a variant of "It's so much simpler in X" or "Try that in anything else than X" too often when it only meant "I'm actually not really proficient in anything else but X".

spion 9y ago

To use words from Yaron Minsky, JS is no OCaml but it has a surprisingly decent "dynamic range", even though it doesn't look like it. (Yes, I'm pretty sure I'll end up being ridiculed for writing that, but... hear me out) Its easy to quickly put up a prototype. There are a ton of libraries for everything, and most come with copy-pasteable examples. Yes, this is frowned upon, and with good reason - but for prototyping, its exactly what you want. The prototype you write will also work much better than your average dynamic language prototypes (except for Erlang). With generators and async/await the code became fairly pedestrian and un-convoluted. The only additional element in the mix are the few await/yield keywords sprinkled around. The language is flexible enough that you can also write code in FP style (higher order functions, combinators, etc). For example, RxJS code looks pretty natural. ES6 and above has all the modern bells and whistles: decent module system, classes, short lambda syntax, template strings... As a result code is pretty much as pleasant to write as Ruby or Python When your project grows large enough, you have the option to painlessly convert to TypeScript. Besides getting rid of one annoying JS flaw (implicit conversions), this will also improve development tooling tremendously. TypeScript again has a wide dynamic range: you can start out with a fairly lax type system that allows a lot and then turn the dial up by turning on more and more checks (no any types inferred, strict null checks, etc) TypeScript's type system is surprisingly powerful: generics, unions, intersections, type guards, discriminated unions, control flow analysis with exhaustiveness checks, string/integer literal types, "mapped types" - the list is quite large and growing: https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types.... . But what makes TS different is that it models and formalises idiomatic JavaScript well, so your existing code will not need to be adapted. TypeScript is where client/server code sharing starts to shine. Shared types enable end-to-end type-checking. You can arrange your code in such a way that data fetching is injectable, and use the same code with fetch on the client and direct method calls on the server (thanks to the same interface). If you have a very demanding client-side app, there will definitely be a lot of code reuse opportunities. (Nowadays I suppose this is also possible with Scala.js and bucklescript) The lack of threads is a mixed bag. Most people already covered the disadvantages very well so I'll mention some advantages. Its much easier to reason about stateful code, since you can treat each synchronous code chunk as uninterruptible, and the possible interleaving points are always obvious (e.g. await/yield keyword). There are also several techniques and libraries to work around the disadvantages (e.g. dnode for RPC to separate processes for intensive calculations) and while none of them are very convenient, they usually end up being what you have to do eventually anyway. Threads will only get you so far with servers running CPU intensive jobs - soon you will need more than one machine and then you can't take advantage of shared memory any longer. If all else fails, you can probably throw more processes at it and put a load balancer. Thats an interesting project, and AFAIK not yet solved (at least not in the node ecosystem). You would need a load balancer that is aware of the current state of the node processes - round-robin or random algorithms will be far from optimal to be helpful. I started some work on this here: https://github.com/spion/least-latency-balancer https://github.com/spion/least-latency-balancer but I'm sure that its not the best approach and that it can be improved a lot. Might be a good idea to look at what the OCaml folks have - I'm pretty sure they've been dealing with a somewhat similar problem due to the lack of multicore. Another way to attack this problem is to have better monitoring for long CPU-bound tasks e.g. https://www.npmjs.com/package/long-task-detector https://www.npmjs.com/package/long-task-detector But I will admit that in this regard, there are languages/runtimes where the situation is far better: Haskell, Go, Erlang to name a few.

reacweb 9y ago

I do not like javascript. I am using it on my server because of performances. It has about the same execution speed as java, a slightly smaller memory footprint, but with the async io, it ensures best use of cpu with none of the hassles of multithreads. No need of apache or nginx, with a single process, you can serve hundreds of simultaneous users with blazing performances

hocuspocus 9y ago
There are quite a few Netty-based web frameworks faster than Node.js

amelius 9y ago

If you want to run the same code on the browser as on the client (for example in a scheme where you want to reduce latency by optimistically running server-code on the browser), it is nice to have Javascript on the server. But you could also achieve this by transpiling another language to Javascript of course.

gbuk2013 9y ago

From some JavaScript training slides I am working on: Why use it: - Server and client side in the same language - Simple enough for you to feel free - Enough hammers not to forge your own every time - Fast enough - Good enough to structure larger programs - Browser is the only cross-platform GUI toolkit When to use it: - Web applications - Network clients and servers When not to use it: - Computation (CPU) heavy programs - Very high loads - Shell scripting - Raw packet requirement

overcast 9y ago

Biggest benefit, as a solo developer, is one language for everything. I can rip through the front end, and back end work for all my new venture projects, without changing gears.

rb808 9y ago

I'm a huge proponent of using the same language in front and back end. My best teams had C++ front & back, or C# front and back, even Java front and back. Even though one language/platform isn't ideal for both ends, the benefit of getting everyone on the same tools, libraries, processes and way of thinking is invaluable. So these days where most front ends are JS, it makes a lot of sense to have a JS back end too.

curun1r 9y ago

I can say why I chose it and why I no longer choose it anymore. For me, JavaScript was the price I had to pay for a number of other benefits. I don't like the language, but TypeScript, Coffeescript and the like can paper over some of the deficiencies well enough. But what Node is is more than just JavaScript. It's a fast, well-designed runtime written in C++ with the event loop as a central construct. It's an ecosystem where async is the default and you don't have to work hard to get performance and scalability in that area. And it has a fantastic package management tool. The quality of the packages that npm installs may not always be high, but the tool itself is so much better than pip, maven/gradle, gem, cpan, etc. I've moved on from Node because I've found nearly all the benefits of Node available in Rust. Rust has the performance of Node's C++ runtime, easy event loop with tokio, and cargo is the one package manager that I think betters npm. And with wasm, we're even starting to see the possibility of sharing code between the server-side and client-side. Add to that the ability to use it anywhere that Node can be used (I'm using Rust now with Lambda without a single line of JavaScript), and there's now no reason for me to put up with the hassles that using such a poorly-designed language as JavaScript imposes.

specialist 9y ago

You're not wrong. InterSystems Caché is easily the worst tool I've ever used. A typo in your code often caused the compiler to bork your entire runtime. Not kidding. Node is almost that bad. Stately as nicely as possible: it's syntactic vinegar for a type hostile flow of control obfuscation framework. If you have some irrational need to use libuv (callback hell vs actors, CSP, multithreaded NIO, or AIO thread per connection), you're much better off just using 'C'.

lawik 9y ago
A bit flame-baity but I liked your point for the description. Syntactic vinegar was new to me and type hostile felt novel. Also a good example of how it needs to be okay that some people just don't like Node. While also illistrating that they could also, arguably, be nicer about it ;) What area do you generally work in? That often influences the view of which tools are suitable.