There are two situations where I'd start another project in Node.js:
1) there's an unusual amount of logic shared between browser and server
2) a web layer needs to be isomorphic
Node hits a sweet spot for these, but it's not my choice any more for non-web servers like the micro-services that back up mobile and single page apps.
I abandon Node.js after a first project years ago because of the callback soup. I came back when promises promised an alternative. Now I run into situations where promises cascade up from a few async calls and affect every API built on top of them. Perhaps async/await will improve the situation.
If you have a synchronous function that suddenly needs to do something asynchronous, then everything that uses that function needs to become async too.
I spent a lot of time with Docker in its early days, and now I work a lot with documentation. I dream of providing my readers with live, on-demand sandboxes they can use to play with our sample code before trying to run it locally.
Lots of services have cropped up in recent years to try and make this dream a reality. Unfortunately, most either require user registration or are defunct, and I suspect it's because preventing abuse and fraud are extremely difficult.
HyperDev is by far the best attempt I've seen yet. It's functional, doesn't require user registration, and provides a full URL I can use with other web APIs.
However, it may be challenging to build a full application based only on what you find in this book. I strongly recommend to get familiar with lodash, bluebird, jsdoc and learn to organize your code before writing web servers.
node is not a fuzzy warm friendly technology. Unlike web browsers in which your JavaScript is fully sandboxed and babyproofed, node is not. And many people learning node today do not learn what the event loop is, and how it is YOUR responsibility to not block it.
The golden rule of learning node is: trial and error might be fine while learning, but not for professional work. If you reach a point in which things seem to work, FORCE YOU TO UNDERSTAND WHY IT IS WORKING. If you don't follow this simple rule you will get yourself into REAL problems.
I worked through the Node Beginner Book by Manuel Kiessling some years ago and enjoyed it. I'll probably look through it again to see what has changed. But I'm increasingly (and approaching permanently) disillusioned with the Node/js space.
It just seems like a real mess. In general tooling needs more work than anything, for all languages but JS is a good conversation piece on what's wrong.
I understand this is just a dummy example, but to make the code easier to read and understand you should inline functions that are only used once, unless it has a lot of reusability. There's a fine line between abstraction and obscurity.
I've been using Node.js for 4 years now and it's my favourite runtime (I've been programming for 13 years).
I have a broad background with experience in Java, C/C++, Python and I've done AVR microcontroller programming in assembly and C so I know what I'm talking about.
I've found that most people who complain about Node.js tend to lack experience.
I think it's one of the best runtimes/languages for building web applications - In the same league as Tornado (Python) and Go.
Personally, I like it more than the others because I like JavaScript and it makes it easy to context switch between frontend and backend work.
People who have a background in statically typed languages tend to dislike JavaScript because it gives you more flexibility (and more ways to introduce issues into your app if you're not careful).
If you're just starting programming or you started with another dynamically-typed language, then I would highly recommend learning Node.js.
- Node.js's "callback hell" async paradigm is probably the worst of any popular language/framework today.
- Ignoring the fact that JavaScript lacks static typing, its inconsistencies make it a pain even compared to Python or Ruby. It's so bad that entire applications are written in CoffeeScript and transpiled just to avoid JavaScript.
- NPM is an absolute clusterfuck. It's a matter of "when," not "if" your application will break because a dependency violated semver. Oh, and good luck developing offline.
- The over-engineered UI frameworks and tooling have bled over and poured gasoline on the clusterfuck.
- A community with the attention span of a goldfish
- Scaling is a pain in the ass.
I've found that most people who think Node.js is a good platform lack experience.
If you're just starting programming or you started with another dynamically-typed language, then I would highly recommend learning literally anything other than Node.js. For a HTTP server, try Python+Flask, Ruby+Sinatra, Go+Gorilla,Gin,Goji,etc., Scala+Akka-HTTP, Java+Dropwizard, C#+Nancy, C+libonion, ...
The second anybody mentions callback hell, I know for certain that they have never come close to seriously developing in Node. Callback Hell is completely negated by using promises, which any developer who seriously works with Node is already doing.
Javascript lacks static typing in the same way that Python and Ruby do. If you want static typing, TypeScript is stronger than any tool that exists for either of those languages.
Good luck developing offline? What are you talking about?
Over engineered UI frameworks...what does this have to do with NodeJS applications. Most server applications these days have absolutely nothing to do with the UI whatsoever.
Scaling is a pain in the ass? How do you figure? The entire concept of scaling in NodeJS is based off of replication in a cluster, it could not be easier to scale. You linearly add more instances of your application to a cluster of infinite scale.
If you want scaling, NodeJS is probably not the best choice.
Even tho it may be based of replication in a cluster, Go and most HTTP Framework it uses are trimmed for microservice clustering, concurrency and safety.
The standard library already includes most things you need for making simple webservers, including a generic SQL interface, HTTP and HTTPS framework, cryptographic functions, inter-machine communication protocols like RPC, JSON and XML en and decode, fairly good logging framework and finally a very expressive templating system that can hold it's own against a lot of other templating systems.
Go comes with batteries included. All this compiles in under 10 seconds on my machine. It also compiles without any dependencies except the stdlibc, so it runs basically everywhere you have a target binary format for and ported the stdlibc too (and os-specific libraries if used). Thanks to newer developments it even runs on "baremetal" VMs with only a stub hypervisor kernel for management.
Bigger files for a portability that runs circles around NodeJs.
On NodeJs that's probably a couple dozen packages. I'm currently developing something using Node and I have about 570 packages (only top level) in my nodes_modules folder from a default ember.js setup. It actually breaks my system after a few minutes to use live reload due to the sheer number of files in there.
All Go libraries I have installed consume are only 9700 files, including binaries, personal pet projects and various "try-and-forget" libraries. The single nodejs app I develop has 45000 files only in the node_modules folder, and I stopped counting my project after 96000 files (after ls failed to enumerate the tmp folder within a few minutes)
Scaling? Go or Erland wins by miles with time to spare. NodeJs is struggling downhill.
Is it called node because of its inode usage?! Jokes aside, it's just crazy how big node_modules can become for a simple app! I was kind of surprise the first time I got a "no space left on device" error and df shows < 50% of usage :/
Promises introduce their own pain points. In particular, promise-laden code can be very confusing and difficult to read, especially for those who only need to look at it sometimes (like me). Error handling in promises is strange and often a promise chain will "succeed" even if an internal function failed, because the implementor forgot to put in a `.catch()`. Promise chains also make stack traces either nonexistent or illegible. Furthermore many promises are created by "promisifying" an async function with callbacks, which once again reduces readability. Also if you try to use something which isn't a promise inside of a chain, you get silly errors like ".next() is not a function" or whatever.
Python and JavaScript are both dynamically typed, but python's type system is much better thought out, easy to understand and leads itself to mostly robust code with error messages that make sense. JavaScript's type system is the Wild West with prototype inheritance, no classes (how do I tell what type this object is? Maybe I could use `typeof`, one of the most pathetic duck typing tools one can imagine...), nonsensical operators ("1" + 2, ===, etc), both "null" and "undefined" (really?). Also one of the worst design decisions, which was to have accessing a non-existent attribute just return `undefined` rather than throw an error, or that the number of function arguments isn't checked in JavaScript. These two things account for tons of "undefined is not a function" and similar errors that have probably cost developers combined centuries of time debugging.
Let's not forget that Python has a huge and incredibly useful standard library while JavaScript's is almost non-existent, which is one of the factors leading to the ballooning dependency trees for npm packages.
Advocating TypeScript is besides the point. It's a different language; you can't argue in favor of JavaScript if you're telling people to use a different language. Not to mention that TypeScript has its own issues.
I don't have many responses to the other points because I'm not familiar, but I would set myself on fire rather than write full-time in JavaScript.
I've read both sides of these arguments everywhere, leading me to believe both sides must hold some degree of truth. The problem with these "arguments" is they are mostly from experience. It's difficult to argue with experiences which are true if they happened. The bottom-line is node has the capacity to be awesome and to suck. The only option is to find out where you and your project fall after trying node for yourself, but if one thing is for certain, node will do better focusing on minimizing bad experiences no matter how they happen. Now most new frameworks recruiting users begin their pitch with promising a better experience (than node).
> Doing a series of asynchronous tasks would at WORST look like this
...that paste is still pretty close to callback hell. Spend a month working with Scala Futures and then tell me you want to go back to chaining a bunch of .then()s.
> Javascript lacks static typing in the same way that Python and Ruby do.
I'm aware of the lack of static typing in the other languages which is why I said "ignoring the fact..." The point is that JavaScript still sucks more which is why things like TypeScript and CoffeeScript even exist. There are too many gotchas even for basic operations like 'if (typeof(foo) === "undefined")' vs 'if (foo === null)' vs 'if (foo == null)'.
> Good luck developing offline? What are you talking about?
NPM was written with the assumption that the user would have an active internet connection and the application would be packaged in the same environment in which it would be run, like someone might build for a small project with a basic manual deployment. I ran into a real-world issue attempting to distribute a Node.js application to customers who would then run it in an air-gapped environment on a platform over which I had no control. (Trivial for Java, C/C++, C#, etc). There was no way to pre-package dependency sources and then run the compilation step as a part of the installation to ensure they were built for the right architecture against the available system libraries. These days there are a few tools like npmbox, but they are poor band-aids.
> Over engineered UI frameworks...what does this have to do with NodeJS applications.
Not sure why you're surprised by this. Redux and Electron are both pretty common use-cases for Node these days. It's not uncommon to be subjected to the torture of grunt/gulp/bower along with NPM.
> Scaling is a pain in the ass? How do you figure?
Scaling has gotten better recently, but servers like Unicorn/Gunicorn that don't require any code modifications or manual process management to scale worker processes on a single box are preferable IMO.
> NPM was written with the assumption that the user would have an active internet connection and the application would be packaged in the same environment in which it would be run, like someone might build for a small project with a basic manual deployment. I ran into a real-world issue attempting to distribute a Node.js application to customers who would then run it in an air-gapped environment on a platform over which I had no control. (Trivial for Java, C/C++, C#, etc). There was no way to pre-package dependency sources and then run the compilation step as a part of the installation to ensure they were built for the right architecture against the available system libraries. These days there are a few tools like npmbox, but they are poor band-aids.
You can use `file:` in your `package.json` to point to your dependencies too if you don't have Internet connection. Also, there's nothing stopping you from including `node_modules` in your project. In fact you can just copy/paste the node packages from one machine to another and have it be portable unless it's a native module.
Checking in node_modules has the same problem as copy/pasting for native modules (on which I was relying, hence the compilation issues). Using file: is a better solution that wasn't around when I first encountered this solution, but still has the problem of requiring you to manually manage every dependency (which can grow to obnoxious proportions in Node). There's no clear way to create the equivalent package of a fat shaded JAR or a statically linked binary.
- The callback hell is easily avoidable with promises, and promises usually interoperate with callbacks using the node callback convention very well.
- If you seek to solve the type safety problem of JavaScript, CoffeeScript is absolutely the worst possible choice. CoffeeScript is to JavaScript what stenography is to typing. TypeScript might be a better choice.
- npm is not the problem, the npm package ecosystem is.
- Scaling is not painful. You can scale horizontally as long as you are not doing something dumb like blocking your event loop.
I think you didn't address the real problems node has.
I rarely comment for the amount of hours spent parusing HN but this is one to many shoddy node bashes.
I take a pragmateic approach to this (maybe its cause im now predominantly a JS developer).
It does feel like every man and his dog want to build a website and putting together some resemblance of a webpage with HTML, CSS and JS (and maybe a one click install) is not actually a steep learning curve for the majority.
From experience of interviewing I know this is the start of a lot of Front End/Node Developer careers, this is cool, but i think it also mean the quality of JS developer is across a spectrum is more weighted to lower side, most having none or very little knowledge of patterns or "production" level coding. Because of these the JS world is full or gists, blog articles and NPM packages at a similar lower level of quality. Something very easy to bash.
I also feel there are developers from other languages that try Node and fall into patterns that rubbish articles say, panic cause it wrong and bash publicly Node.
For example....
- Node.js's "callback hell" async paradigm is probably the worst of any popular language/framework today.
Yes, as cool as it is that you can pass a function (with context) around between another function for hours, some people sadly use it wrong. Promises, Async, Generators, Redux Saga all solve these issues.
- Ignoring the fact that JavaScript lacks static typing, its inconsistencies make it a pain even compared to Python or Ruby. It's so bad that entire applications are written in CoffeeScript and transpiled just to avoid JavaScript.
Yep, I been using JS in many forms, including coffeescript for 15 years, it lacks static typing, you either love it or hate - its not a hindrance. I love using ES7 over coffeescript now.
- NPM is an absolute clusterfuck. It's a matter of "when," not "if" your application will break because a dependency violated semver. Oh, and good luck developing offline.
Yep this public package manager has some rubbish in it and yep people "could" screw you over with package versions.
Putting the correct version numbers in your package.json and having your own NPM repo like Nexus get rid of these issues.
- The over-engineered UI frameworks and tooling have bled over and poured gasoline on the clusterfuck.
I can say, after doing this for 17 years - I love Webpack.(Finally my folder structure of a website is poetry, and my CSS has all the right browser prefixes when required). Tools like webpack, gulp and grunt help with this. Yep it can go crazy, but for me it really does not take that long to setup tooling to the exact what i want.
- A community with the attention span of a goldfish
Yeah probably, but can not actually see why this effects me.
- Scaling is a pain in the ass.
What?
- I've found that most people who think Node.js is a good platform lack experience.
I have 17 year experience from Perl, Python, C#,Java, ASP, Ruby, PHP and more. I have worked for one of the big tech companies. I dont lack experience, Node JS comments like yours do though.
- If you're just starting programming or you started with another dynamically-typed language, then I would highly recommend learning literally anything other than Node.js. For a HTTP server, try Python+Flask, Ruby+Sinatra, Go+Gorilla,Gin,Goji,etc., Scala+Akka-HTTP, Java+Dropwizard, C#+Nancy, C+libonion, ...
If any good programmer does not choose the right tools for a job then your not good. Node does not solve everything.
> Promises, Async, Generators, Redux Saga all solve these issues.
I'm aware of all of these and group them in with "callback hell." "Solve" is being overly generous. Generators are the best but still feel shoe-horned in and clunky.
> you either love it or hate - its not a hindrance. I love using ES7 over coffeescript now.
Yet another example of a language that you can't actually write a Node.js application in without transpiling...
> Putting the correct version numbers in your package.json and having your own NPM repo like Nexus (live Java) get rid of these issues.
So basically "don't use the system as intended" lol
> What?
Scaling is a pain in the ass.
> If any good programmer does not choose the right tools for a job then your not good.
This is an oft parroted phrase (usually by over-zealous project managers) to justify using some trendy new technology as though people hadn't been able to write HTTP servers until last year. There is more in common with all of those options I listed than there is difference. Twitter was serving millions of users before migrating away from Ruby on Rails. Instagram and Pinterest are in the top 50 most visited sites in the world and still both use Python+Django. If any programmer can only get the job done with a single tool, then they probably aren't that good.
>> - Node.js's "callback hell" async paradigm is probably the worst of any popular language/framework today.
Now we have Promises, so this argument has become completely invalid.
Even before Promises, avoiding callback hell was relatively easy - You could just define your functions one above another (even if you used callbacks) - nesting anonymous functions was NEVER necessary in JS - People just did it because they were too lazy to actually declare the function before using them.
>> - Ignoring the fact that JavaScript lacks static typing, its inconsistencies make it a pain even compared to Python or Ruby. It's so bad that entire applications are written in CoffeeScript and transpiled just to avoid JavaScript.
A lot of the main concepts from CoffeeScript have since been introduced as part of ES6. A lot of JS developers never understood the purpose of CoffeeScript - It was merely a gateway to encourage stubborn Python developers to switch JavaScript (and was very successful). A lot of CoffeeScript developers who did not like JS now like it thanks to ES6.
>> - NPM is an absolute clusterfuck. It's a matter of "when," not "if" your application will break because a dependency violated semver. Oh, and good luck developing offline.
The main problem was that some people wrote modules which had very wide dependency version ranges and this caused issues when a dependency would be updated behind the scenes in a non-backwards-compatible way.
npm has always allowed you to specify strict version numbers for your dependencies - I have always followed this approach but a lot of developers didn't. Since this issue came to light, you'll find that most popular modules now use proper semantic versioning or strict version numbers when referring to dependencies.
>> - The over-engineered UI frameworks and tooling have bled over and poured gasoline on the clusterfuck.
I'm sure that some projects are 'over-engineered' but you'd be surprised how often topics like 'the Linux philosophy' comes up in discussions between Node.js developers. Many Node.js developers are really conscious about complexity.
>> - A community with the attention span of a goldfish
I agree with that, the community is all over the place. I think part of the reason is that no consensus has been reached regarding a lot of things. That said, it has settled a lot in recent years. I don't think this is such a bad thing; better be unsure than forcing everyone in the same (wrong) direction.
>> - Scaling is a pain in the ass.
Moreso than Go, but I wouldn't call it a pain in the ass - I think it's a good thing. Node.js tries to stay small and compact so that it can easily fit into any architecture - This makes Node.js a really good match for third-party process managers and containers/Docker orchestration systems like Kubernetes/Swarm/Mesos.
It would be terrible if Node.js had its own scaling mechanism - It would probably conflict with those of orchestrators which have their own way of doing things.
I think that the Node.js community intentionally decided not to deal with scalability and to offload that concern to external process managers and orchestrators. I think as the Docker/Kubernetes ecosystems evolve, the decisions made by the Node.js community will really start to pay off.
I'm using Node.js with Kubernetes/Docker now to build auto-scalable stacks and it's mind-blowingly excellent.
> Even before Promises, avoiding callback hell was relatively easy
Promises & proper callback definitions don't solve the fundamental issue of forcing code to be structured based on the type of calls being made rather than the logical units of work. If I'm making three database lookups that rely on the results of the previous call, in Node I'm stuck with three callbacks or .then()s or whatever. In a framework like Scala+Spray, I can work entirely with Futures as though they are real objects and return a response with a single onComplete at the very end. In Go, its runtime schedules goroutines around blocking I/O similar to Node's event-loop so the waiting isn't even something the programmer (usually) needs to know about.
Maybe this is the JavaScript Stockholm Syndrome talking, but I've come to really like structuring code based on the type of calls being made. It guides me to extract the synchronous parts and cover them in unit tests. The async parts of my programs are usually talking to a database, a service, or the file system, which are all things that I'd naturally want to exclude or mock in unit tests anyways. I wind up with fast, simple unit tests for the parts of my program that are heavy on branching and calculation.
90% of the time, the programs I'm writing do not logically branch as a result of async calls. I might have to handle errors and abort a process gracefully (which promises and/or the async library do quite elegantly), but those cases feel different than deciding what to do based on the result of an async operation. Because there are few logical branches in these parts of my programs, I get a lot of coverage just by writing one or two integrated tests that exercise all those external systems and verify that they are hooked up correctly.
This idea of a functional core that can be tested with unit tests and an imperative shell that can be tested with integrated tests comes to me from Gary Bernhardt: https://www.destroyallsoftware.com/talks/boundaries. The 90% figure could be dumb luck or inexperience, but so far so good.
I think the problem is with the javascript mentality and not the language or runtime. Simply put you don't put time into fully understanding the problems and implications of a particular implementation, you either download a third party library off npm with minimal inspection (which pulls in a dozen other libraries that get NO inspection) or you write a new library with what you think is a solid test suite but because it is a new library by its very virtue it is not battle tested in any way shape or form.
Compounding these observations together you get an environment where you don't know what's going on which is something many developers wish to avoid at all costs when building large, complex, high-performance/scalability, systems.
I get that you're making a joke (I think?), but this is hardly useful advice. You may not like Node.js, but it's a pretty useful skill to have given its current popularity.
I'm more interested in knowing why you'd give this advice to beginners (genuinely curious).
It (re)enforces bad programming habits due to its (and JavaScript's) inconsistencies. Its async primitives suck. The tooling is an over-engineered clusterfuck. There are many better options out there for learning-purposes or actual real-world implementations.
Might be one of those things that is popular mostly on the coasts. Here in NYC I spent little to no time jobless after I learned Node. Not sure how it is elsewhere.
I agree with this statement completely. Nodejs allows (often encourages) beginner programmers to make terrible design mistakes and fail to teach how software actually works. Need something done? npm install, import, done. No you can't learn by doing that.
I don't understand this. How is making things easier fault of the tool? Isn't it programmer's responsibility to learn how to code than tool teaching you how to? You can program in node in lower level too. It doesn't have to always be npm install.
