5 ms·

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 b

by winrid 7y ago

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 7y ago
"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.
- winrid 7y ago
  Maybe I should have said "... and has a good time." :)
- addicted 7y ago
  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 7y ago
    Where's your evidence for this?
steve_adams_86 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      I think I get your point.
freehunter 7y ago
>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 7y ago
  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. :)

by winrid 7y ago

cutler 7y ago

"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.

winrid 7y ago
Maybe I should have said "... and has a good time." :)
addicted 7y ago
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 7y ago
  Where's your evidence for this?

steve_adams_86 7y ago

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 7y ago
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 7y ago
  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 7y ago
    I think I get your point.

freehunter 7y ago

>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 7y ago
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. :)