DEV Community

It's All About NodeJS

🆖 Karan Oza on September 13, 2020

"One of the main reasons why NodeJS is popular is because it uses the JavaScript as their main application to create new application. Plus, JavaSc...

Read full post

David • Sep 14 '20

I'm not a fan of NodeJS at all, but it is a gateway to backend web for folks that are JS-inclined. Are you familiar with Ryan Dahl's latest project? Deno? He seeks to right all the wrongs in NodeJS.

Most of the former Joyent team is now Oxide Computing working heavily in Rust and firmware.

I'm sharing this just so people realize that while NodeJS currently has mind-share and popularity, it's momentum has certainly slowed and it is a platform with a lot of challenges that other language platforms don't have.

🆖 Karan Oza • Sep 14 '20

Yess David, Deno uses ES Modules as the default module system, whereas Node. js uses CommonJS.

And it's totally depends on Developers choice most of stacks are preferred Javascript as there first language so may be they either choose NodeJS or The one who comfortable with TypeScript go with the Deno as you mentioned...

Btw thanks for take your time and sharing this🤗🙏

Brian McBride • Sep 16 '20

I'm not sure I agree that NodeJS has lost momentum.
I would never use it as a tool for firmware. Rust is an alternative for C/C++.

When it comes to serverless, NodeJS is being picked up more and more from what I see. There are a lot of Java and .NET developers who are now leveraging Typescript + NodeJS for their back end services. There is just a lot less boilerplate and faster development time in many cases.

I would also be interested in "a lot of challenges that other language platforms don't have". Every platform has its challenges. Typically developers find the language they are used to less problematic than the one they don't use every day. I bad-mouthed Java when I was working in Objective-C. I talked bad about C# when I was working in Java. I swore that Node would never be a viable base for servers in production - and yet now most of my serverside code is Typescirpt + NodeJS.

David • Sep 16 '20

We can agree to disagree, but can we agree that Deno has a high likelihood of chipping away at Node looking forward?

Yes, Rust is an alternative to C and C++. It's staking a claim in the performance game. Deno is written in Rust. Rust is also getting some love at big companies including both Microsoft (GitHub as well) and Google. It is also being used at Discord.

I would also be interested in "a lot of challenges that other language platforms don't have". Every platform has its challenges.

Sure. Let me expound -- this is anecdotal and I've worked in Ruby, Node, Python, Golang, Elixir, and now Rust in production environments. I'm also speaking exclusively for backend web services, where most of my experience is. Of these, I default to Elixir (Erlang VM/BEAM). Operationally, probably the best platform to use for long-running services. Why? It comes out of the box with runtime introspection (observer) allowing an operator to go in and look at issues happening in real time, fault-tolerance built in (supervision trees) that provides "self-healing" that's great for avoiding some pages during the middle of the night, clustering and service discovery out of the box (granted that you're running on a cloud provider that supports it or VPC, but not Heroku). So while, every platform, including the BEAM has its challenges, it's less painful than that of Node. More often than not, because most of us know JS, we default to "easy to write" implicitly. Remember, though, that code is read more times than it is written, and maintenance has a cost. Node/JavaScript when compared to even the other language that I mention has many challenges that for me, and I'd imagine for others (if they're familiar with other platforms) would choose not to adopt. Node/JS isn't very good for numbers or mathematics. The package management is pretty gnarly (i.e. peek at node_modules lately?). You have to adopt the async model of programming -- which is much harder to debug and introspect -- compare this to Elixir where one can stick an IO.inspect into the middle of a pipeline/chain of function calls.

I don't make as bold claims and/or predictions as you do. Sometimes you're right and sometimes you're wrong. I'm simply citing an observation that is perhaps unique to the bubble/pocket of tech that I'm in (San Francisco). Maybe you've grown to love Node and TS and that's fine, because you and the others that are enjoying it will be its torch-bearers. And most of us will default to starting any project in something we're most familiar with or make choices from things we're familiar with. I'm not going to tell someone to go do Elixir or Rust while building a start-up or new project if they don't already know it. That would be signing up for zero productivity. For me, having worked in the platforms above, I would never choose Node. I still enjoy writing JavaScript and would leave it to just client-side/browser-specific applications. Would I mind reading someone's small project in it? No. However, I would take pause before I signed up to work in Node in production and most certainly wouldn't start a project in it. I would certainly explore Deno before Node if JS/TS is the language choice. I find Node/JS to have the most "footguns" of all the languages/platforms that I've listed.

I wrote my post simply to urge people to try new things -- explore. It opens one's world to the possibilities and what's been done about the parts you don't like in your language and platform. That's the message I would hope people are taking from it :)

Brian McBride • Sep 17 '20

Thanks for the excellent reply.

I wouldn't say I "love" Node/TS. I firmly believe pick the right tool for the right job. What I am saying is that if you want to build out a GraphQL server or even some serverless RESTful API endpoints - the Node/TS stack is currently my goto.

But, I will agree that that stack needs better debugging/testing/introspection tools. Some of the cloud vendors offer some drop-in libs. Async, threads, or any non-blocking style coding is going to be harder to debug for sure. My teams use strong linting rules and code formatters so that there is some guidance on how to structure code.

Anyway. I do appreciate your thoughts and I very much agree that people should explore :)

David • Sep 17 '20 • Edited

Yeah -- definitely. However, for some of us, we only have a single tool. Anything and everything that can be done in JavaScript, will be done in JavaScript. It's a double-edged sword -- it does open up the doors to areas that formerly weren't open before (e.g., hardware/IoT, ML, etc), because it is a pretty large undertaking to learn new languages and their ecosystems. JS certainly has served as the "gateway language" for many, including myself. It's hard to see how different things could be until we've actually experienced them. When I only did JavaScript, it was easy to just acknowledge the warts and work around them as a fact of life. You're also right about some of the drop-ins some providers have come up with to better the experience.

And no problem -- I thoroughly enjoy discussions around different technologies and reconfiguring my line of thought with the advent of new info and data points :)

Out of curiosity, though, being that you've worked in Java, do you like Java? If not, what about other JVM languages? I've never worked in Java in production, but have fiddled around with a few JVM langs.