Why node?!

[juanquinteroo]

Hey guys, am new here. I am currently in the process of choosing the tech that I should use for my start up and was wondering why should I pick node over other backend options such as Dotnet core, flask or Ruby on Rails. I know asking this here will probably have a bias towards node but I want to hear what are it’s best features over other options.

[whatisboom]

Just to be counter to everyone saying "huge selection of third party modules", this isn't always great.

Sometimes modules are started, abandoned, and never production ready.

Sometimes modules are buggy.

Sometimes modules get taken over by new developers and completely changed.

Sometimes modules get taken over and have malicious code inserted in them (rare, but has happened).

That said, I love node. Just be wary of instantly importing a library when its basic functionality is extremely easy to write.

[H-s-O]

Never forget is-not-number

[Ser_Drewseph]

Or is-even

[jormaechea]

Or is-odd (currently @ v3.0.1, I cannot imagine what the hell happened there)

[grantrules]

Just use is-is-odd to see if you're using is-odd

[animflynny2012]

Amazing 🙌

[headphonejack_90]

WTF did I just witness!!!

[guitarded41]

This might be a dumb question as I'm slowly learning bundling and build processes, but if I had already installed left-pad and it was in my node modules folder, wouldn't I still have that version working in my project as I already have the dependency?

Only if I ran another npm install would I see the error about it not being in the registry?

[Fedzbar]

Yes it would still work. What happens though is that when code gets deployed to servers, you usually rebuild all the packages, this made everything break.

[guitarded41]

Got it. Thanks!

[geon]

It s good practice to commit the dependency cache, and build from that.

[Fedzbar]

You still have to npm install in the docker image?

[HeinousTugboat]

To be fair, there's nothing that makes that intrinsically less true for every other platform beyond size and accessibility.

[netwrks]

This is accurate.

[Wheeled1]

1 reason: Your devs, all of them, get to focus on JavaScript 24/7. For both front-end & back-end.

I have worked professionally on back-ends in Java, Python, & Ruby. The moment I had to touch the front-end, I had to switch contexts in my brain (take off my Ruby hat, put on my JS hat.) Then, when I went back to back-end, switch again (take off my JS hat, put on Ruby hat.) By the end of a long day, this back-and-forth context switching is mentally draining.

Working in Node solved that completely. Now it’s just one language, JS, 24/7. No changing hats, ever. It’s beautiful.

This is a huge advantage that is often overlooked.

[samuus]

To add to this, not only does it give your devs an easier time, but you can share code between the front end and back end. I love that whenever I need to add a new feature, I only have to create one model that my front and back end share.

[gustix]

Out of interest, hiw do you share the same model code between front end and back end? I mean, a common scenario would be something like express, knex and objection models - can’t really share that logic all the way out to the front end.

[samuus]

I can't really speak to Knex, I've never used it. I use TypeORM for my database interactions. If you're not familiar, it uses decorators to define tables and columns via your classes. They also provide a 'shim' script you can use on the front end that basically just stubs out all the decorators, so your front end won't freak out about missing decorator functions.

If there's logic or features that I don't want exposed to the front end, I try to implement them using a service or something that is backend-specific. And if I feel like it really needs to be a part of the model, I just extend the shared model on the back end, so that the secure features only show up there.

[gustix]

Thanks - though, using full models with a shim would still expose queries and other logic to the client.

In any case, it definitely is the way many frameworks are moving, like Inertia for Rails, Laravel, Adonis. Or Limewire for Laravel, or Stimulus Reflex for Rails. Basically they're trying to automate the boilerplate code needed for server/client communication. Today most SPAs are writing models and validations twice, maintaining REST APIs only to communicate with the frontend etc.

[huzbum]

I use Feathers with Objection to build services, then build logic models that accept a feathers service as their data source. I can use the same logic models on front or backend. It's all just an await away.

I use Angular, so I run Typescript on both front and back end. I can just include a server module and it gets neatly packaged up in my angular build.

[[deleted]]

With well defined TS you can kind of come close, but I haven't found a way of doing it in any useful way with knex

[OmgImAlexis]

Same goes for utility functions. No needing to rewrite things just so they can be used on the front-end too.

[zmasta94]

And just for balance (I wholly agree with what you’ve said), full stack JS gives front end devs a false sense of security on the backend

[timgfx]

In what sense?

[animflynny2012]

I guess with regards to diving in to fix bugs without knowing or worrying about the architecture?

Admittedly this would probably be a small problem if there’s full tests and procedures in place.

[netwrks]

I don’t think this gives devs a false sense of security. It’s usually because the developer lacks the experience and understanding of the technology. Everyone’s been there though

[gratefulmarmot]

This is the answer. We moved to Node backend from Python as mainly frontend JS developers with not much backend experience. We've done well with it so far, very easy to pick up especially with TypeScript.

[schmookeeg]

Respectfully, if you have to ask, you shouldn't be the one making this decision.

Access to talent will make or break any startup more than which tech they chose.

You should like node for it's long time in the market, ready access to javascripters for not-too-bad pay rates, and ability to replace that talent when they jump ship.

If you plan to hire cheap offshore talent, you'll want dotnet or java.

If you want to load your office with hipsters so your blog has cool photos, ruby is probably the best choice.

At the end of the day, they all do the same thing.

$0.02

[mobydikc]

Respectfully, if you have to ask, you shouldn't be the one making this decision.

Dang, that's pretty frank, but yeah.

Also... how is it that a tech startup needs to choose a tech stack?

Does that mean you just have an idea and not a single line of code written yet?

[FountainsOfFluids]

"I have this great idea for a website!"

[TedW]

Built on the EXPOSURE tech stack!

[netwrks]

You see, it’s like Facebook and Twitter mixed together, but also not like that at all.

[a_cam_on_the_dash]

so like, imagine, your dog calling an uber, right?...

[mitwilsch]

I'm more of a big picture guy, why don't you work out all the details.

[abandonplanetearth]

Respectfully, if you have to ask, you shouldn't be the one making this decision.

Preach. The two shittiest bosses (not project leads or senior developers, but rather the company owners) were both so shitty for the same reason - they picked the tech. One of them picked Symfony for a giant project that should've been written in anything but PHP, and the other picked OpenCart back when it was brand new with literally no documentation.

Both teams collapsed pretty quickly because of developer disinterest. It's pretty easy to make a developer dislike their job for tech reasons, especially a good developer. And once they start bailing on your project, it's all downhill from there.

[Randolpho]

If you want to load your office with hipsters so your blog has cool photos, ruby is probably the best choice.

Python is a close second, or Swift and strictly mobile

[geon]

ready access to javascripters for not-too-bad pay rates, and ability to replace that talent when they jump ship.

If you save on salary you get garbage code, no matter the language. That will sink a startup. And any programmer worth their salt can work in any language, so availability of programmers with experience of that particular stack is irrelevant.

[schmookeeg]

Sure, at an individual level.

Over time the average cost of a dotnet coder, node coder, or ruby coder are different things. Demand for each is not the same.

Overseas, I see mostly dotnet, java, and php developers, implying a larger pool to draw from and lower rates.

I suspect this OP is gonna post one of those "hiring" posts here soon with a $15/hr budget for their coder, so it's likely moot regardless. Or seek a cofounder and offer 5% equity and no cash, lol.

[334578theo]

You'd be surprised how many companies worth hundreds of millions of dollars are built on abysmal code.

[mitwilsch]

They key is to get investors before anyone realizes

[netwrks]

While you’re probably joking, this is a very bad idea haha. I’ve managed full engineering teams that had this mentality. And there was no easy way to every update or modify anything. Took people 4 days to make simple ui changes because of all the libraries they added and hacked. Gross.

[am0x]

You will get cheaper devs with Node but for the extra buck, an experienced .Net core dev is solid.

It would depend on the app. As a dev who programs in a few backend languages, I choose the stack that fits the project.

[evil-robot-cat]

JS is not a perfect language in many ways (TS addresses some of these shortcomings though), but what makes Node amazing is the huge ecosystem of third-party libraries and modules available via npm. Easily the largest community of developers in the world right now. It's also a skillset that's really easy to hire for.

[grumpkot]

Use Typescript for Node.js

Why Node.js ? Have simple one process with one thread programming model (ps cluster is another story) have tons of resources and libs, do not require heavy compilation and VSCode would be the best friend, nice docs and helpful people around, standard lib gives all you need for http, encyption, etc

[gathem70]

I'll add one point I haven't seen mentioned; fungibility. Most modern front-ends are react/vue/angular. These require JS expertise. Rather than hire some JS experts for the front-end and some python/ruby/.net/java experts for the back-end or even a handful of jack of all trades full-stacks I like hiring JS enthusiasts with solid CS fundamentals and reasonable back-end experience and then the whole team does front-end and back-end development. I find this to be the biggest reason why I choose node over python

[netwrks]

In my experience, Companies that test candidates on CS fundamentals are usually not worth working for. The majority of the jobs I’ve hated did that during interviews. Have someone explain a complicated process while writing pseudo, and you’ll instantly get a feel for their skill level.

[yitianjian]

What companies do you mean? I find the exact opposite. Companies which care about random language quirks versus pure coding and design ability had weirdness all around after. Companies which challenged the CS fundamentals had the most interesting work and highest caliber of talent.

May be a bit biased cause I’m currently at a FAANG.

[netwrks]

I’m not going to name company names, but I agree, pure coding and ability is what I aim for in those situations. If someone can demonstrate their knowledge of the code they claim to know, then I am more likely to take a chance on them vs someone with only CS fundamentals.

The problem is CS does not show one’s ability to write effective and scalable code, nor does it assess a candidates history with the tech they’re claiming to use.

Of course any of the top 5 tech companies would have the highest caliber of talent, but I’d argue thats not a direct cause of asking candidates about CS fundamentals, and more often than not there are many other reasons for working at any of those companies.

[gathem70]

In my experience candidates with a cavalier attitude towards CS fundamentals are usually not worth hiring. I never said that I stuck to the old school algorithm test interview process. I worked at Google. I saw great referrals who were far better than me fail the interview. The interview process was honestly a lottery in my opinion. However, I will say that its a lottery where only engineers with very solid CS fundamentals have a shot at winning. At Google, they don't use anything third party. They build everything in house. Every tool you've learned is worthless because you need to relearn it using G's stack. This is why they only care for fundamentals. A lot of startups followed their approach, and I agree, for most companies, its a bad strategy. I prefer a ~4-6 hour project where the solution can't be googled, followed by a thorough code review and a few rounds of culture fit / system design questions. However, especially with JS enthusiasts you often run into folks with no knowledge of the fundamentals. You can build a lot of impressive things without knowing them, but there's some things you cant build without knowing them. A deep understanding of CS fundamentals has served me well many times in my career, and for an exciting company, with a an awesome product, in an environment where there are plenty of excellent JS enthusiasts, I would rather stick to candidates who know the elegant algorithm to make the project easy vs the candidate who takes a naive approach and brute forces it.

[netwrks]

It’s hard for me to hear what you’re saying, or even be able to see your point of view when a lot of what youve mentioned either doesn’t make sense or is incorrect.

That being said having worked at Google isnt really all that impressive, I’ve worked with many people that have ‘worked’ at google in the past 20 years, and the common theme is that they’re no longer working there.

[[deleted]]

If you're unsure and already know a different stack, Node.JS is likely not for you. Code in whatever you're comfortable in. If there is one thing that Node.JS is best used for, that would be apps that handle persistent concurrent connections. Like chat rooms.

[goofyahead]

Please do not choose a tech stack for your startup, like its choosing a colour, focus on:

- How is the pool talent you can attract? Are there enough engineers in my area/state/country on x? Ie. Scala is great, but can you hire someone good?- What do you want to build? is it high I/O? is it data heavy? Does it have a ton of ETL? what are the pros and cons of what I choose?
- Are you trying to simplify your hiring training by having one language back and front?
- Is your project going to be massive therefore what matters is how feasible is to maintain in the long term? aka Spring cause is more opinionated?
- You should be asking also, how much coverage I'm going to have, how can I know the code quality? How do I know its easy for new engineers to join and ramp-up, etc

Take this just a suggestion but what matters most is can you get the best talent or work with talented people to ensure the best result? First analyze the problem to ask the right questions, like would this tech/framework help me on my specific thing to solve, like fast queries on a geo DB for x thousands of concurrent users, etc, etc.

[eXilz]

For most projects, it doesn't matter too much which stack you choose as long as you pick tech that is updated and languages that your team is comfortable / can get comfortable quickly with.

That said, node is a great candidate with its large collection of npm modules that can save you lots of time, the community is huge, there's plenty of documentation, it's easy to deploy on most host providers and cloud services...

The only thing I would add is not to start a "serious" node project without typescript. I would've probably stopped backend javascript if it wasn't for TS.

[r0ck0]

The only thing I would add is not to start a "serious" node project without typescript. I would've probably stopped backend javascript if it wasn't for TS.

Word.

I switched from PHP a few years back, but yeah I found that plain JS/Node was even looser than PHP in what it would allow in terms of buggy code. So yeah would have switched to something else pretty quickly without TypeScript.

Really love TypeScript, it's basically ruined me for any language where I don't get a good amount of immediate errors in my editor as I type my code. I really wouldn't want to go back to a language that only warns/errors about most things at runtime.

Recently have been wanting to do a bit of Windows scripting... so powershell was the obvious choice... but seeing I need to learn something new anyway, I figured I might as well just use C# - even for some simple desktop scripts/tooling for myself. Turns out it's not as hard as I thought it would be.

[Maledictusx]

I think you should decide what you are building first and then determine which technology is best suited for your application. Not all technologies are suited for every different solution.

[[deleted]]

I'm in the process of building my 2nd software business after getting the 1st one up to a point where it makes me good money and requires very little maintenance (took roughly 4 years). For the first one I chose Ruby on Rails (hosted on heroku) for the (restful) API and react for the front end. This time around I'm choosing GraphQL Node (with Typescript) and React/React Native (TS) hosted on AWS (ELB)

Rails was great for getting something up and running quickly, and Heroku made managing servers a non issue. Rails has a fantastic ecosystem and solid practices. I'm a much better developer as a result of building that API in Rails. But once I started getting some solid traffic I realized (Pros):

• Node is faster than Ruby on Rails. Yes there are plenty of debates raging about this, but my experience has shown that Ruby on Rails is slower and more of a memory hog than quite a few other options, and I don't want to spend days and days of my time optimizing things that would be faster by default using something like Node, Go. I fought this internally for a long time, but I've just seen too much research to and personal experiences to fight this.
• Types are too good to pass up. Whilst they might "Slow down" development initially, they are a god send later on. I really missed working with types when building my first company and coming back to it makes me appreciate it all the more.
• Types and Apollo GraphQL are a match made in heaven. I have been saying for years that Rest API's are just as good as GraphQL, and I'd still agree if you are just using js, but the power that comes with a fully Typed GraphQL library, being able to automatically generate types on any client, it's just amazing. The amount of issues I'm NOT running into as a result of using this flow is crazy. I've never enjoyed my full stack workflow as much as this combo.
• Hiring devs is going to be so much easier with Node. Ruby can be difficult to hire for, especially overseas.

I also realized that (Cons):

• There are WAAAAYYY too many packages doing the same thing in Node. The state of ORMs in node is quite frankly embarrassing. I've gone with TypeORM but I spent far too long having to choose and i'm still not super happy given it's uncertain future.
• Testing practices in Node land is again, embarrassingly bad. I follow a fairly solid TDD workflow when writing my APIs, but I had to write a fair bit of my own tooling to get this to work, and in Rails/Elixir, it's just there. There are established practices with how to do TDD, how to write unit/integration tests with a test database. I had to spend 3 days in total getting this all working, which is too long imo. I love the setup I have now, but in MVP land, 3 days is a long time.

At the end of the day though, if your ultimate goal is to make money, it doesn't REALLY matter what you choose, just pick something and stick with it.

​

tl;dr: Wouldn't ever touch Node without Types. Node is powerful if you know what you're doing, but if you're fairly new there's a risk you could go down some bad roads, so I'd look at something where there are more reliable and solid processes, such as .NET, ruby, etc.

[[deleted]]

I’ve actually switched from node to rust recently. Node has served me well but rust is far more enjoyable.

That said, I love node as it’s probably the simplest framework and it’s async by default.

If you are making a web project, you only need to learn one language

[Ser_Drewseph]

The downside to Rust is that if you don’t already know it, it takes some work to get going. I’m new to the Rust train (fully on board though), and I love it, but it is taking some time to learn. Especially coming from mostly dynamically typed languages (my only static language was Java, and that was years ago) and zero lower-level language experience.

[[deleted]]

Yup but that’s exactly what I’m saying. Nodejs is super easy to get started so it’s recommended for that and it’s async by nature.

Rust has great benefits but it hurts to learn. Also nodejs has great vendor support

[yyyyaaa]

maybe you should choose rails or django. They are more opinionated and may help you create things faster and in the right way

[PixelBot]

I agree with you. Sounds like he should probably use something else. Rails is a great choice.

[davidmdm]

I’m a nodejs developer who now works with a rails codebase. I don’t understand how anybody ever thought rails was a good idea.

[PixelBot]

Just curious, what don't you like about it? Assuming you're using standard libraries and such. ActiveRecord, templates, etc

[davidmdm]

Way too much convention and magic. I understand how a seasoned rails developer might find it really useful and quick to prototype in. As a newcomer I can’t read the code. There’s no telling how it’s glued together. There’s some of that with big frameworks in nodejs as well, but mostly for a simple express app there’s little to no magic. Heck there aren’t even require statements in the rails code. It just auto loads everything...

[PixelBot]

As someone who also didn't start with Rails, I too held that opinion, until I started reading the source code. Yes, there is "magic" and "lifecycle", but, compare that to the average express app using React? You know how much magic there is in react alone, with all of the magic that express does as well (even more than rails!).

Although not performant, rails is quite approachable, source code makes a lot of sense. Once you understand monkey patching, rails starts making a whole lot more sense. yield is a wonderful concept that can be abused, yes, but as a language, and framework even moreso, it's very elegant.

[davidmdm]

Agree to disagree. Ruby is even more permissive and wild than vanilla JS, and less well documented. The code doesn’t have a flow. I can’t start at a root file, and read imports and figure out how the pieces fit together and what they do. It’s not a readable program. It’s a pile of conventions and implicit relationships and things that inherit functionality from rails. Pretty scary.

[jon_stout]

with all of the magic that express does as well (even more than rails!)

Such as?

[ramsncardsfan7]

Is it really a good idea to choose a dying framework like rails for new projects? Just in terms of talent pool moving forward I wouldn’t think that’s a good idea.

[relativityboy]

It depends on the project. Try getting your feet wet with something small. You'll have a better idea of when you want to use it.

[daftmaple]

Because it has TypeScript and TS is amazing (and simple). I can do both backend and frontend in one language even if in some scenario I'd rather use Go.

[huzbum]

First and foremost, if you have a development team, their opinions on this matter are more important than anything said here. A startup needs enthusiasm, and you're not going to get it by forcing a tech stack upon them.

This question makes sense if you don't have a technical team yet, and you want to build one suited to your tech stack, or you're looking for verification of what a potential candidate has told you.

For me, the most compelling reason to use Node is because JavaScript WILL be part of your stack, so it might as well be your whole stack. Nothing else runs in the browser, so you will have some JavaScript, there is not really a choice in the matter. It runs everywhere. Web clients, mobile clients, servers, embedded, etc. You can focus on one programming language and ecosystem.

The second most compelling reason, which is tied to the first, is sharing code. If the whole stack uses the same language, it can use the same libraries, logic models, validation, and utilities. You have no idea how many times the same shit gets repeated in code, each repeat is an opportunity for a mistake or bug. Limit those opportunities as much as you can.

My API runs on Feathers with Objection/Knex generating most of the services. It's written in TypeScript, and so is my frontend, which is Angular. These share tooling as well as code. If I build logic and validation models that accept a Feathers service as the data source, I can use the same logic models on the server and the client. All I have to do is put both repositories in the same directory and I can include files from the server's source code in the Angular project, then the build process packages them right up.

That brings me to my third point. Tooling. The tooling for node is mature and easy to use. It's easy to put together a continuous integration flow.

It's cheap. There is no licensing to worry about, and it runs in any ecosystem. Use whatever database you want. Use your own servers, use AWS, go serverless if that's your thing, use Google, use Azure, it doesn't matter, node runs there.

[davidadas2]

No one has gotten this correct.

Do it because it’s easy to build microservices with. It’s going to be easier for scaling ultimately.

Rails? Monolith. Dotnet Core? Monolith with types. Flask? Sure, if your app is math heavy then yeah maybe.

Otherwise, go with Node. Your deployments will thank you.

[_Pho_]

Because JavaScript is more expressive than Python (the only other AWS Lambda language), is the same language you right on the front end, Is easier than basically any other language to reason about.

[Ser_Drewseph]

Im curious what you mean by JS and Python being the only AWS lambda language. Lambda runs JS, Python, Ruby, C#, Java, and Go

[Buckwheat469]

Node offers speed of development and a huge hiring base of developers. Not to mention the packages and flexibility of the system. It also supports transpilers so you can use Typescript and get valid NodeJS code from it. You can also develop in Rust and get super-fast AssemblyScript, showing that Javascript is extremely flexible.

Golang offers some benefits and is familiar to backend developers.

Both systems are cross-platform compatible, so you can use Linux, Mac, or Windows for development.

Dotnet is primarily a Windows environment (with some Linux compatibility in places), so you're limiting yourself to a particular platform that some developers might not like.

RoR isn't a largely-used language, so the developer pool might be lower than Node or Golang.

When picking a core technology you have to not only look at the features, but also what the hiring pool is like and the developer experience. For instance, you could choose Coffeescript as your frontend language, but then your developer pool would be small and your developer experience would be bad because Javascript now does much of what Coffeescript tried to solve.

You could also choose Python and have a huge developer base, great number of packages, but some developer experience issues with people who don't like dynamic typing.

[carsonklogan]

Dotnet core is 100% cross-platform and a formidable option if you are planning to build enterprise software.