Lately, I’ve been writing lots of Python and Go, but if you know anything about me, you’d know . Recently, when I’ve had to stretch my fingers to write a quick “life hack” or number crunching script to speed up my day, I haven’t been thinking of JS, so I definitely can’t call it my go-to language anymore. That said, since I once did, I believe I have the right to criticize it… so, let’s get started. I was once a major Node.js advocate Standard Library Node’s standard library is as minimal as can be. Though this is a great way to encourage the community to build libraries, it also makes it harder to standardize and further, compose anything. But, don’t get me wrong- after working in and , I’m strongly against vast, deep standard libraries. Instead, I prefer standard libraries like that of Go and Java that are vast yet shallow. The difference is these standard libraries provide all the tools you need to solve the most common case and bindings needed to expand beyond, whereas Node’s standard library only provides all the (mostly native) bindings needed to build the tools to solve the most common case. Instead of , we develop the standard implementation in a way that’s reusable practically everywhere. Ruby Python yet another HTTP client ways to enhance Error Handling Joyent on “Error Handling in Node.js” post If the above snippet isn’t enough, take a peek at the following: function onError(err) {log.fatal({code: 1,err}, 'process exit');process.exit(1);} process.on('unhandledException', onError);process.on('unhandledRejection', (p, err) => onError(err)); Exception bubbling lets errors that should be handled at call-site propagate endlessly instead, and catch-all handlers are just a workaround for poor language constructs. It’s much harder to realize the impact of your changes when the control flow of an _n_th degree call-site of a crucial function can affect the overall error handling scene without notice. More importantly, subclass-able _Error_s promote . asserting errors for type, not behavior Synchronous Code Though async I/O is important, it’s not . If anything, I’d say forgetting this is Node’s biggest downside by far. Node forces you to think about concurrency everywhere, whereas Go, Lua, Python (though there are other problems there), and other languages allow you to incorporate it in as needed without switching paradigms. everything To clarify, you can — and I like to believe that I have — achieved this in Node with newer constructs like and , but they’re never first-class, and they require loads of tribal knowledge in order to effectively utilize amongst . If you don’t believe me, try teaching all this from scratch. generator-based coroutines Async/Await all the other paradigms the community follows And Beyond! Now, I’m not saying Node.js is an awful platform; I’m just saying give other platforms a shot and see how things compare! When I was stuck in Node land, I’d often assess other platforms by staring at examples and laughing along, and I’ve seen a lot of (but not all!) fellow JavaScript developers do the same, but, by stepping out of my comfort zone, I’ve learned that it’s impossible to effectively criticize something without developing a strong relationship with it, which for languages, includes debugging, working around abnormalities, and learning ins and outs. What I’m really trying to point out here is some of the trade-offs that come with Node.js and what I’m excited to see more of built in and moreover, (specifically in terms of tooling) other platforms. on top of is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories
