7 ms·

"When your company won't be the first to market, because about 20% of your total development capacity needs to spent on keeping up" In the world of JS and Type

"When your company won't be the first to market, because about 20% of your total development capacity needs to spent on keeping up" In the world of JS and Typescript this ratio looks more like 80%. I swear that node hipsters at my last job spent four out of five of their working days wrangling with dependencies or their transpilers, linters, packagers, bundlers and whatever the hell else needs to happen to actually make a node program run. Meanwhile the geezers that worked on Java services reliably pushed new versions of their code sprint after sprint, no heroics, no drama required. What the fuck happened to those "modern stacks" that babysitting them takes the vast majority of developers time? It's a nightmare.

sul_tasto 5y ago
This is why I don’t understand the approach of golang and rust to keep their APIs so lean and rely on 3rd party dependency management for (IMO) basic enterprise functionality.
auslegung 5y ago
I’m not a TS, JS, or node fan. But if you really believe that it takes 80% of a dev’s time, week after week, to wrangle dependencies etc in ANY stack, you are either incredibly naive or really bad at math. And if developers at your company got away with that, I’d be leaving that company ASAP.
- abraxas 5y ago
  I'm no longer with that company and it's possible that those devs were incompetent or always chased the next shiny framework or possibly both. But irregardless their output on the whole was about 20% that of those devs who used uncool old tech like Java/Spring and dotNET.
andrei_says_ 5y ago
This is why I can’t use anything too complicated. I’m just not smart enough to wrangle complex configurations and dependencies. So I keep producing Rails apps that get the job done without the bells and whistles and without much polish. I wish I could hire a config expert for half an hour and have them create the setup I want. Because I will never get my masters in webpack/rollup/postcss/stimulusjs/mystery sauce working config du jour.
- distalx 5y ago
  Checkout meteor.js, it takes care of all the tooling.
  - xet7 5y ago
    No, Meteor does not take care of all. If someone would help me to upgrade to newest Meteor etc dependencies, it would be very welcome: https://github.com/wekan/wekan/issues/3881 https://github.com/wekan/wekan/issues/3881
- noduerme 5y ago
  Same. I just compile TS modules with UDP, run it all through r.js, uglify, and deploy over SFTP. Roll out server side patches straight onto the servers, when I update a local file. SCP or even just edit the files in a shell if something breaks. I'll be damned if I'm going to spend days tooling deployments for the latest flavor of packaging. This whole conversation only pertains to people who work in large companies, on salary, who both need to follow standardized procedures and have the time to spend days doing so. I always find it interesting, because it illuminates an entirely different set of priorities and a completely different universe of tools versus what an individual or 2-3-person team needs to focus on to get things running.
secondaryacct 5y ago
Having always been fullstack even in my current large traditional bank, I see both codebases in Java 6 and maven poms that are a paradise to change (and a java 8 upgrade is often trivial and sufficient to get most of the nice candies you really need), and yarn/npm frontend projects that cant be even rebuilt two weeks later, everyone insanely writing auto updating version descriptor (^2.0.4 with the ^). I cannot understand what idiot thought it d be fancy cutting everything into mini dependencies that update every day without you knowing made by amateurish hipsters who transitive depend on each other like their life depended on it. Yes you can lock but every build script I ve seen forgot this detail and resolve anew the dependencies !! Why !?!? Yes it s a pain to move up a version sometimes in Java, but we decide to do it for a reason, spend a few days tops fighting it if we must and it's done. You re right that in JS I cant even teach my more backend colleagues how the fuck it works and how I can navigate it. And I m very against transpilers and linters which I try to avoid for sanity but sometimes you inherit a hero's code and you re like omfg a vue js to typescript to js hacky build chain that worked 2 years ago on bower and now bower is gone and yarn wont build it. And you re 2 weeks well into it before you start building and discussing what you actually wanted to change :D What kills me the most is when someone in management calls the java backend that is ultra optimized, instant to change, a dream to deploy "legacy" and the yarn soup that is coded by 200 successively burnt out juniors, does 40k binding function calls on a non moving DOM (you know, to "hydrate" it with whatever framework du jour was fancy 5 months ago), and we cant redeploy without a full budget proposal, that people do everything to be assigned out of "modern" grrr I kid you not we have an entire team in charge of one small frontent management tool for a pretrade backend, they literally spend 99% of their time justifying why they wont change it, and 1% begging me to join for a week to reorder their column or put a new button... and THEY re in charge of it argl, and I cannot for the life of me spend more than 30 minutes teaching them before they snooze "I dont get it, let s pick our battles and change that one thing with you and promised it s the last time" ...
- d4mi3n 5y ago
  The small dependency thing is a sad artifact of the days when most JavaScript libraries were built to run on the browser. In that context, prior to the days of mature tools to do things like tree-shaking to remove unused code, the easiest way to make things smaller was to make JS modules as small as possible so code could opt-in to subsets of a library it wanted to use. Fast forward 5 or 8 years and we have a very fragmented ecosystem of NPM modules—some built to be used on the web, some not—built on a legacy of tiny modules and deep dependency trees. Add on to all that the pace at which the JS and browser ecosystem moves and it’s not too surprising that things have ended up the way they are. Teams don’t need to build projects with deep dependency trees, but it’s pretty hard to avoid them with the NPM registry in the shape it’s in.
noduerme 5y ago
I'm still building new frontend UI with Typescript 2.x, Bootstrap 4 alpha, Pixijs 3.x. I don't particularly care about flags in code dependencies, and if they're a problem to upgrade I'll use the old version too. Does it matter? A UI just needs to work, ideally forever, and it's all javascript in the end anyway. It'll work the exact same 10 years from now. Serverside code is a different beast and you can't avoid upgrading Node or PHP, or migrating to MySQL 8. But only very occasionally does this present the opportunity or sufficient reason to upgrade frontend code.
TranquilMarmot 5y ago
As a full stack dev who leans heavily towards the frontend... yes, honestly, some weeks 80% is a realistic number and WOW is it exhausting to fix Webpack or Babel or some random npm package for the nth time. I do feel like I run into issues less often today than I did about five years ago, there are really only a few packages where upgrades are a massive pain. TypeScript makes these upgrades a lot easier. That being said, I still have way more fun writing TypeScript and React code _when it works_ than I do writing yet another Java API. Might just be personal preference but the amount of fun that I have doing it makes dealing with the tooling hell all the more worth it.
- dimaor 5y ago
  _have way more having fun writing.._ - pretty much seems to be the culprit here.
DeathArrow 5y ago
In .NET I've spent maximum 1 hour updating major versions. Usually is almost nothing to be done.
otabdeveloper4 5y ago
> I swear that node hipsters at my last job spent four out of five of their working days wrangling with dependencies or their transpilers, linters, packagers, bundlers and whatever the hell else needs to happen to actually make a node program run. Like they say - a cushy job if you can get it.
kabes 5y ago
I do both java and node backend dev and I wrestle way more with maven and java dependencies than with node and npm. The project lead also always wants to try the latest java stuff (quarkus when it just came out, latest java versions, ...) which has lead to many days of obscure bug tracing. So it's really more of developer attitude then about the stack
ranguna 5y ago
Where I work, its quite the opposite, every microservice is built with js/ts and we have a big monolith built in java. The java service releases every month or so, the microservice, on average, release every week, sometimes more. You can build bad software with any tool, it all depends on how you use it.
Aeolun 5y ago
Do your Java geezers work with Maven? Give me NPM (well, yarn, or pnpm) any day of the week.
- kaba0 5y ago
  Nah, maven is definitely not a modern tool, but it does what it has to. And java’s package situation is in orders of magnitude better health than the critical vulnerability each week js one. Like, maven repo was the only one not affected by that quite big attack last time as well.
avidphantasm 5y ago
At some point, there is an irreducible level of complexity. At this point, adding tools simply results in pushing complexity around like an air bubble trapped under a plastic film.
stackbutterflow 5y ago
Am I doing typescript wrong? Setting up a new project is a 5 minutes task. Npm init, then install express, typescript and some useful middleware. Install eslint then eslint --init and choose airbnb style guide, and I'm off to go. And if I take over an existing codebase it just takes npm install then npm run dev <script name> and I can start adding bugs. With react and vuejs it's even easier with nextjs/nuxtjs. I never fight dependencies. Yet I sometimes read stories like yours while typescript/nodejs has only been the smoothest experience I've ever had.
- 5e92cb50239222b 5y ago
  Of course you won't have any problems with an empty hello world. Now develop it into a medium to big real-world project and let it sit for a year or two, then try to update dependencies (because you need new functionality or to fix some vulnerabilities). It's never easy. For some projects it took me about a week to do this (because of a breaking change in some library that's used everywhere that you are forced to update). I just spent another two hours fighting with breakage because of a library that shall remain nameless. The author introduced yet another major breaking change in a minor release. I'm thinking of migrating to a hand-rolled solution, it probably makes sense in the long run. Edit: just for comparison, the backend for this project is written in Java/Spring. I recently updated it from a five year old Spring version (plus a dozen dependencies from the same time frame), and it took less than an hour to fix everything. This is simply unthinkable in the JS world.
SergeAx 5y ago
This is not "modern stack", this is frontend frameworks niche.
ByteJockey 5y ago
The best experience I ever had with js was on an api that didn't use anything special. No typescript. No import syntax. Nothing extra. It was magical. The entire build stage was npm install && node app.js Admittedly, once or twice a quarter, we'd update the dependencies and we'd spend a few hours fighting it, but the rest of the time it just worked.

sul_tasto 5y ago

This is why I don’t understand the approach of golang and rust to keep their APIs so lean and rely on 3rd party dependency management for (IMO) basic enterprise functionality.

auslegung 5y ago

I’m not a TS, JS, or node fan. But if you really believe that it takes 80% of a dev’s time, week after week, to wrangle dependencies etc in ANY stack, you are either incredibly naive or really bad at math. And if developers at your company got away with that, I’d be leaving that company ASAP.

abraxas 5y ago
I'm no longer with that company and it's possible that those devs were incompetent or always chased the next shiny framework or possibly both. But irregardless their output on the whole was about 20% that of those devs who used uncool old tech like Java/Spring and dotNET.

andrei_says_ 5y ago

This is why I can’t use anything too complicated. I’m just not smart enough to wrangle complex configurations and dependencies. So I keep producing Rails apps that get the job done without the bells and whistles and without much polish. I wish I could hire a config expert for half an hour and have them create the setup I want. Because I will never get my masters in webpack/rollup/postcss/stimulusjs/mystery sauce working config du jour.

distalx 5y ago
Checkout meteor.js, it takes care of all the tooling.
- xet7 5y ago
  No, Meteor does not take care of all. If someone would help me to upgrade to newest Meteor etc dependencies, it would be very welcome: https://github.com/wekan/wekan/issues/3881 https://github.com/wekan/wekan/issues/3881
noduerme 5y ago
Same. I just compile TS modules with UDP, run it all through r.js, uglify, and deploy over SFTP. Roll out server side patches straight onto the servers, when I update a local file. SCP or even just edit the files in a shell if something breaks. I'll be damned if I'm going to spend days tooling deployments for the latest flavor of packaging. This whole conversation only pertains to people who work in large companies, on salary, who both need to follow standardized procedures and have the time to spend days doing so. I always find it interesting, because it illuminates an entirely different set of priorities and a completely different universe of tools versus what an individual or 2-3-person team needs to focus on to get things running.

secondaryacct 5y ago

Having always been fullstack even in my current large traditional bank, I see both codebases in Java 6 and maven poms that are a paradise to change (and a java 8 upgrade is often trivial and sufficient to get most of the nice candies you really need), and yarn/npm frontend projects that cant be even rebuilt two weeks later, everyone insanely writing auto updating version descriptor (^2.0.4 with the ^). I cannot understand what idiot thought it d be fancy cutting everything into mini dependencies that update every day without you knowing made by amateurish hipsters who transitive depend on each other like their life depended on it. Yes you can lock but every build script I ve seen forgot this detail and resolve anew the dependencies !! Why !?!? Yes it s a pain to move up a version sometimes in Java, but we decide to do it for a reason, spend a few days tops fighting it if we must and it's done. You re right that in JS I cant even teach my more backend colleagues how the fuck it works and how I can navigate it. And I m very against transpilers and linters which I try to avoid for sanity but sometimes you inherit a hero's code and you re like omfg a vue js to typescript to js hacky build chain that worked 2 years ago on bower and now bower is gone and yarn wont build it. And you re 2 weeks well into it before you start building and discussing what you actually wanted to change :D What kills me the most is when someone in management calls the java backend that is ultra optimized, instant to change, a dream to deploy "legacy" and the yarn soup that is coded by 200 successively burnt out juniors, does 40k binding function calls on a non moving DOM (you know, to "hydrate" it with whatever framework du jour was fancy 5 months ago), and we cant redeploy without a full budget proposal, that people do everything to be assigned out of "modern" grrr I kid you not we have an entire team in charge of one small frontent management tool for a pretrade backend, they literally spend 99% of their time justifying why they wont change it, and 1% begging me to join for a week to reorder their column or put a new button... and THEY re in charge of it argl, and I cannot for the life of me spend more than 30 minutes teaching them before they snooze "I dont get it, let s pick our battles and change that one thing with you and promised it s the last time" ...

d4mi3n 5y ago
The small dependency thing is a sad artifact of the days when most JavaScript libraries were built to run on the browser. In that context, prior to the days of mature tools to do things like tree-shaking to remove unused code, the easiest way to make things smaller was to make JS modules as small as possible so code could opt-in to subsets of a library it wanted to use. Fast forward 5 or 8 years and we have a very fragmented ecosystem of NPM modules—some built to be used on the web, some not—built on a legacy of tiny modules and deep dependency trees. Add on to all that the pace at which the JS and browser ecosystem moves and it’s not too surprising that things have ended up the way they are. Teams don’t need to build projects with deep dependency trees, but it’s pretty hard to avoid them with the NPM registry in the shape it’s in.

noduerme 5y ago

I'm still building new frontend UI with Typescript 2.x, Bootstrap 4 alpha, Pixijs 3.x. I don't particularly care about flags in code dependencies, and if they're a problem to upgrade I'll use the old version too. Does it matter? A UI just needs to work, ideally forever, and it's all javascript in the end anyway. It'll work the exact same 10 years from now. Serverside code is a different beast and you can't avoid upgrading Node or PHP, or migrating to MySQL 8. But only very occasionally does this present the opportunity or sufficient reason to upgrade frontend code.

TranquilMarmot 5y ago

As a full stack dev who leans heavily towards the frontend... yes, honestly, some weeks 80% is a realistic number and WOW is it exhausting to fix Webpack or Babel or some random npm package for the nth time. I do feel like I run into issues less often today than I did about five years ago, there are really only a few packages where upgrades are a massive pain. TypeScript makes these upgrades a lot easier. That being said, I still have way more fun writing TypeScript and React code _when it works_ than I do writing yet another Java API. Might just be personal preference but the amount of fun that I have doing it makes dealing with the tooling hell all the more worth it.

dimaor 5y ago
_have way more having fun writing.._ - pretty much seems to be the culprit here.

DeathArrow 5y ago

In .NET I've spent maximum 1 hour updating major versions. Usually is almost nothing to be done.

otabdeveloper4 5y ago

> I swear that node hipsters at my last job spent four out of five of their working days wrangling with dependencies or their transpilers, linters, packagers, bundlers and whatever the hell else needs to happen to actually make a node program run. Like they say - a cushy job if you can get it.

kabes 5y ago

I do both java and node backend dev and I wrestle way more with maven and java dependencies than with node and npm. The project lead also always wants to try the latest java stuff (quarkus when it just came out, latest java versions, ...) which has lead to many days of obscure bug tracing. So it's really more of developer attitude then about the stack

ranguna 5y ago

Where I work, its quite the opposite, every microservice is built with js/ts and we have a big monolith built in java. The java service releases every month or so, the microservice, on average, release every week, sometimes more. You can build bad software with any tool, it all depends on how you use it.

Aeolun 5y ago

Do your Java geezers work with Maven? Give me NPM (well, yarn, or pnpm) any day of the week.

kaba0 5y ago
Nah, maven is definitely not a modern tool, but it does what it has to. And java’s package situation is in orders of magnitude better health than the critical vulnerability each week js one. Like, maven repo was the only one not affected by that quite big attack last time as well.

avidphantasm 5y ago

At some point, there is an irreducible level of complexity. At this point, adding tools simply results in pushing complexity around like an air bubble trapped under a plastic film.

stackbutterflow 5y ago

Am I doing typescript wrong? Setting up a new project is a 5 minutes task. Npm init, then install express, typescript and some useful middleware. Install eslint then eslint --init and choose airbnb style guide, and I'm off to go. And if I take over an existing codebase it just takes npm install then npm run dev <script name> and I can start adding bugs. With react and vuejs it's even easier with nextjs/nuxtjs. I never fight dependencies. Yet I sometimes read stories like yours while typescript/nodejs has only been the smoothest experience I've ever had.

5e92cb50239222b 5y ago
Of course you won't have any problems with an empty hello world. Now develop it into a medium to big real-world project and let it sit for a year or two, then try to update dependencies (because you need new functionality or to fix some vulnerabilities). It's never easy. For some projects it took me about a week to do this (because of a breaking change in some library that's used everywhere that you are forced to update). I just spent another two hours fighting with breakage because of a library that shall remain nameless. The author introduced yet another major breaking change in a minor release. I'm thinking of migrating to a hand-rolled solution, it probably makes sense in the long run. Edit: just for comparison, the backend for this project is written in Java/Spring. I recently updated it from a five year old Spring version (plus a dozen dependencies from the same time frame), and it took less than an hour to fix everything. This is simply unthinkable in the JS world.

SergeAx 5y ago

This is not "modern stack", this is frontend frameworks niche.

ByteJockey 5y ago

The best experience I ever had with js was on an api that didn't use anything special. No typescript. No import syntax. Nothing extra. It was magical. The entire build stage was npm install && node app.js Admittedly, once or twice a quarter, we'd update the dependencies and we'd spend a few hours fighting it, but the rest of the time it just worked.