[winrid]

You're comparing a runtime environment to a framework.

Use Angular on the client and something server side in Node and you're set.

Use Typescript and you'll be able to refactor easily too.

Nobody uses just React+Express w/o TS for something serious.

[cutler]

"Nobody uses just React+Express w/o TS for something serious." Hardly. Just search for "(react.js or reactjs) (nodejs or node.js)" on indeed.co.uk. 441 results. Now append "-typescript" to the same search. 378 results. It appears Typescript hasn't yet taken over the world.

[addicted]

Most companies using typescript don’t advertise for typescript developers and will simply look for JS decelopers, because the belief is that anyone should be able to transition from JS to TS so why limit your scope.

[cutler]

Where's your evidence for this?

[winrid]

Maybe I should have said "... and has a good time." :)

[freehunter]

>You're comparing a runtime environment to a framework

Yup. Because there is no Rails-like framework in NodeJS.

>Use Angular on the client and something server side

That "something server side" is the entire problem. In 2006 if you're writing a web app, the answer was Ruby on Rails. In 2019 the answer is "Angular or React or Vue on the front end and something server side". No generators, no scaffolds, no auto-generated migrations, no opinions, no ORM, no standardized way of doing anything, no naming scheme, no guidance. Just "something server side".

If I said "use Ruby to create a web app" you'd load up Rails. If I said "use Python" you'd load up Django. If I said "use NodeJS", you'd just... list all your NPM packages?

[winrid]

Yeah, you're right. I don't know why that is. You can properly engineer stuff in Node but there are no "rails" to guide you so I get that more projects will be a mess as compared to Rails or Django.

To be honest I wouldn't suggest Node as a solution for your backend which is probably why I said "something server side" because when I think Node I just think of a thin API wrapper that uses an RPC to call your Java services or what-have-you. The only reason you even do that is to give the FE people something to mesh data together from services for their clients while you can keep backend APIs generic. Luckily graphql will start to replace that convention.

Makes me want to build such a framework in TS... but why would I do that when I can just use Spring. :)

[steve_adams_86]

If you just use TS without really understanding how it can help you and your particular problems you're solving, it can be more of a burden to refactoring than a saviour. Type systems are not a panacea for refactoring difficulties.

[winrid]

How so? I wouldn't use it for a tiny app, but for something where you're thinking far into the future I would.

Keep in mind, at my current company we don't use it (giant 5 year old AngularJS codebase) but I would love to.

You don't even have to use it fully. Just mark your function arguments and you're already saving headaches.

[steve_adams_86]

I agree that TypeScript is great, but I've seen it used to establish its own kind of technical debt is what I'm trying to say. If you establish types for your poorly designed application it will only entrench bad design deeper. So, throwing a type system at that problem isn't actually helpful at all in cases like that.

I agree though that using TS and not worrying about actually defining types can be great. I do think you can run into sort of wandering inference bugs or cases where other peoples' types can be poorly defined, but that's a rare problem in my experience and well worth the benefits you get otherwise.

Anyway, I'm definitely not trashing TypeScript or suggesting no one should use it or anything. I almost always start new projects with it.

[winrid]

I think I get your point.