9 ms·

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

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.
- MrBuddyCasino 5y ago
  > 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 Also due to JS having a very small stdlib. Compare built-in functions to eg Kotlin, its a different world.
brailsafe 5y ago
If you can have a Java backend that's more or less totally decoupled from the frontend, great. Java and it's tooling are fine, and it's easy to be productive writing in Java. However, my only experience as a frontend dev with Java backend system has been truly nightmarish, because the backend processed all the frontend assets and rendered them. If anything, this is what helped me burnout, because everyone on my team writing Java was super productive and delivered on time, while I couldn't test my JS, CSS, or HTML changes without restarting Tomcat on my fucking useless 10lb HP laptop that the corp required me to use most of the time, because that's what all the Java developers used to get their Java working.
- secondaryacct 5y ago
  Yeah so the dev machine shit specs is something we fight SO HARD against in my bank. There s not many thing we can fight, but our 10 core SMT xeon with 128G of RAM for everyone in the team was a fight worth fighting. Yes, it took 2 years of them putting us on a new VM cloud systems after another before they gave up, us spamming them every say "intellij freezes", "I cant build in less than 10 minutes and the traders are getting nervous we spend our time daydreaming while it compiles" and other such trolls making the budget monkeys sweat. Other than that, there s probably a way for you to propose a change, ive worked on the same nightmare you describe and, well, I was lucky enough I guess I could make enough changes to both stack it was possible to get either a light java subset running just the frontend to test, or make the js independent for testing, yes with a yarn soup lol, which is how I learned it in the first place I guess.
  - brailsafe 5y ago
    I'm glad you won the fight you were fighting. I lost most of mine, and this was 5 years ago. A few things worth elaborating on. > 10 core SMT xeon with 128G of RAM for everyone in the team In our case, most frontend web devs realistically use macOS or some other unix env. Not only did our bunk-ass windows machines suck spec-wise, and in terms of physical dimensions, they also sucked because they were windows based. This was shortly before WSL, so it was a pain. The DevOps guy did have a crazy machine with tons of ram and so on. > I cant build in less than 10 minutes This was literally the case for me every time I made a change. Sometimes the previous result would be cached and I'd need to do it again. I was constantly fighting a stupid battle, and nobody really understood why things were the way they were or how to change them, including the java devs that had been working on it for years. I kind of won the dev machine battle, because the VPN wasn't really sophisticated and I just set up some system on my personal mac, against the wishes of management. When a designer came in, they got a mac, and had to ask me how to connect it to the VPN. > it was possible to get either a light java subset running just the frontend to test, or make the js independent for testing, yes with a yarn soup lol Someone had set up a node instance that attempted to replicate the output of the java system, but without some bits that I can't recall atm. The inconsistencies and trying to maintain a one-for-one replica was just as much of pain. If I remember correctly, that was in part because there would really have had to have been a deliberate time investment in creating a sustainable replica that involved communication when any data changed server side. It was a crap-shoot, and I should give myself more credit for lasting as long as I did, but less credit for not jumping ship way earlier. I ended up literally burning out, getting fired, and didn't find employment again for years. I have it on my resume that I did a few things successfully while I was there, but quite honestly I don't completely remember what those were, and am just guessing at this point.
kabes 5y ago
If you can't get reproducible builds the team doesn't know how to use lock files properly. Don't go blaming it on the stack.
- xcambar 5y ago
  What's your workflow with lock files? Do you force them in CI/prod only or also in dev? I'm tempted to enforce lockfiles at every stage of the product cycle, making upgrades an explicit action, rather than the side-effect/byproduct of another action. Does it make sense? What do you think?
  - TheAceOfHearts 5y ago
    Lockfiles get commited to the repo and used everywhere to avoid version differences. Upgrade dependencies as needed and have everyone reinstall when they change. I'm amazed anyone wouldn't do this, it's the only sensible course of action.
    - xcambar 5y ago
      Some things go without saying, yet go better with saying.
  - kabes 5y ago
    Basically what TheAceOfHearts said. Always use them everywhere, except when explicitly upgrading dependencies. It's also much faster to do a 'npm ci' than an 'npm i'
nuerow 5y ago
> 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. I'm not sure you're thought things through in your comment, and that you are being fair or reasonable. No one cuts "everything into mini dependendencies". You have dependencies you reuse. That's it. When one of those dependencies gets updated, say to fix a bug or a security issue, your package manager of choice handles it for you without any issue. Still, if you do not want to fix bugs or vulnerabilities in your code then you are free to pin them all and move on with your life. At most, the JavaScript or NodeJS crowd needs to have a serious talk about standard libraries and third party lackages, such as whether using packages such as rimraf is desirable. > and yarn/npm frontend projects that cant be even rebuilt two weeks later You only experience that sort of problem if you're incompetent in how you manage your dependencies. With npm you can a) pin major/minor/patch versions of specific packages, b) save your package-lock.json file which specifies exactly which dependencies you use. If you free-float any dependency then that's something you chose to do. With JavaScript/NodeJS + npm you only shoot yourself in the foot that way if you purposely aim at your foot, remove the safety, and press the trigger really hard. > And I m very against transpilers and linters which I try to avoid for sanity (...) Complaining about linters because they test your sanity is a major red flag on your approach to mundane coding tasks. This, and your casual criticism on everyone else's code, leads me to suspect that you really need to do some introspection. > 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... Based on your comment and on my experience with similar projects, I suspect you're either oblivious and/or leaving out important bits of the story just to continue plowing with your humblebrag, or you're succumbing the need to be hyperbolic. Frontend development has to deal with far more details and constraints and requirements than any backend task. Frontend is what both clients and PMs and executives look at, and the tiniest changes like resizing a button has deep implications on the business side of things. Furthermore, it's both harder to automate tests and their tests need to be more extensive. Thus any change, no matter how small, is a uphill battle. It's beyond me how someone who is so hard on their entire team ends up showing such weak understanding and insight of the problem domain. I know that on the internet no one knows you're a dog, but let's not get silly here.
lucumo 5y ago
> 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) Using Java 6 is major red flag. Even Java 8 should be red flag nowadays, if it weren't so extremely common. Both versions no longer receive any security updates or bug fixes. If an organisation doesn't care to put a system on a platform with active security updates that tells me one of three things: 1. The system is unimportant and is basically value-less. I don't want to work on systems like that. 2. The engineers are incompetent and lack even the most rudimentary learning skills (or will) to follow even the most basic updates on the tech they use every day. I don't want to work with people like that. 3. Engineering management is too incompetent to listen to very important messages from their team. The system likely has major issues and a fear of fixing even minor technical debt. I don't want to work in an environment like that. It's not seldomly more than one of these.
- gonzo41 5y ago
  Java 8, if you use corretto, is supported until 2026. It's totally fine to use and support. And java being java and jumping to 11 won't be that bumpy either.
  - lucumo 5y ago
    > Java 8, if you use corretto, is supported until 2026. Interesting, I was not aware of this. I've not seen people use Corretto either, but it seems OpenJDK has a separate project just to maintain Java 8. So that's indeed still fine to use. > And java being java and jumping to 11 won't be that bumpy either. The update from 8 to 9 was rather painful in the beginning, mostly due to libraries not working well with the module system. I'm not sure how it is nowadays, it could have gotten better. 9→10→11→12→13→14→15→16→17 were very painless. I don't foresee a lot of companies getting stuck on those, though it's too early to tell.
    - xenomachina 5y ago
      Yes, we held off on upgrading from 8 to 9 originally because a lot of our dependencies didn't work with 9's module system. A few months ago we jumped straight from 8 to 11, and it was easy, because all of those dependencies have since fixed their module system problems. (What finally pushed us to move to 11 was that some of our dependencies stopped supporting 8!)

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.

MrBuddyCasino 5y ago
> 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 Also due to JS having a very small stdlib. Compare built-in functions to eg Kotlin, its a different world.

brailsafe 5y ago

If you can have a Java backend that's more or less totally decoupled from the frontend, great. Java and it's tooling are fine, and it's easy to be productive writing in Java. However, my only experience as a frontend dev with Java backend system has been truly nightmarish, because the backend processed all the frontend assets and rendered them. If anything, this is what helped me burnout, because everyone on my team writing Java was super productive and delivered on time, while I couldn't test my JS, CSS, or HTML changes without restarting Tomcat on my fucking useless 10lb HP laptop that the corp required me to use most of the time, because that's what all the Java developers used to get their Java working.

secondaryacct 5y ago
Yeah so the dev machine shit specs is something we fight SO HARD against in my bank. There s not many thing we can fight, but our 10 core SMT xeon with 128G of RAM for everyone in the team was a fight worth fighting. Yes, it took 2 years of them putting us on a new VM cloud systems after another before they gave up, us spamming them every say "intellij freezes", "I cant build in less than 10 minutes and the traders are getting nervous we spend our time daydreaming while it compiles" and other such trolls making the budget monkeys sweat. Other than that, there s probably a way for you to propose a change, ive worked on the same nightmare you describe and, well, I was lucky enough I guess I could make enough changes to both stack it was possible to get either a light java subset running just the frontend to test, or make the js independent for testing, yes with a yarn soup lol, which is how I learned it in the first place I guess.
- brailsafe 5y ago
  I'm glad you won the fight you were fighting. I lost most of mine, and this was 5 years ago. A few things worth elaborating on. > 10 core SMT xeon with 128G of RAM for everyone in the team In our case, most frontend web devs realistically use macOS or some other unix env. Not only did our bunk-ass windows machines suck spec-wise, and in terms of physical dimensions, they also sucked because they were windows based. This was shortly before WSL, so it was a pain. The DevOps guy did have a crazy machine with tons of ram and so on. > I cant build in less than 10 minutes This was literally the case for me every time I made a change. Sometimes the previous result would be cached and I'd need to do it again. I was constantly fighting a stupid battle, and nobody really understood why things were the way they were or how to change them, including the java devs that had been working on it for years. I kind of won the dev machine battle, because the VPN wasn't really sophisticated and I just set up some system on my personal mac, against the wishes of management. When a designer came in, they got a mac, and had to ask me how to connect it to the VPN. > it was possible to get either a light java subset running just the frontend to test, or make the js independent for testing, yes with a yarn soup lol Someone had set up a node instance that attempted to replicate the output of the java system, but without some bits that I can't recall atm. The inconsistencies and trying to maintain a one-for-one replica was just as much of pain. If I remember correctly, that was in part because there would really have had to have been a deliberate time investment in creating a sustainable replica that involved communication when any data changed server side. It was a crap-shoot, and I should give myself more credit for lasting as long as I did, but less credit for not jumping ship way earlier. I ended up literally burning out, getting fired, and didn't find employment again for years. I have it on my resume that I did a few things successfully while I was there, but quite honestly I don't completely remember what those were, and am just guessing at this point.

kabes 5y ago

If you can't get reproducible builds the team doesn't know how to use lock files properly. Don't go blaming it on the stack.

xcambar 5y ago
What's your workflow with lock files? Do you force them in CI/prod only or also in dev? I'm tempted to enforce lockfiles at every stage of the product cycle, making upgrades an explicit action, rather than the side-effect/byproduct of another action. Does it make sense? What do you think?
- TheAceOfHearts 5y ago
  Lockfiles get commited to the repo and used everywhere to avoid version differences. Upgrade dependencies as needed and have everyone reinstall when they change. I'm amazed anyone wouldn't do this, it's the only sensible course of action.
  - xcambar 5y ago
    Some things go without saying, yet go better with saying.
- kabes 5y ago
  Basically what TheAceOfHearts said. Always use them everywhere, except when explicitly upgrading dependencies. It's also much faster to do a 'npm ci' than an 'npm i'

nuerow 5y ago

> 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. I'm not sure you're thought things through in your comment, and that you are being fair or reasonable. No one cuts "everything into mini dependendencies". You have dependencies you reuse. That's it. When one of those dependencies gets updated, say to fix a bug or a security issue, your package manager of choice handles it for you without any issue. Still, if you do not want to fix bugs or vulnerabilities in your code then you are free to pin them all and move on with your life. At most, the JavaScript or NodeJS crowd needs to have a serious talk about standard libraries and third party lackages, such as whether using packages such as rimraf is desirable. > and yarn/npm frontend projects that cant be even rebuilt two weeks later You only experience that sort of problem if you're incompetent in how you manage your dependencies. With npm you can a) pin major/minor/patch versions of specific packages, b) save your package-lock.json file which specifies exactly which dependencies you use. If you free-float any dependency then that's something you chose to do. With JavaScript/NodeJS + npm you only shoot yourself in the foot that way if you purposely aim at your foot, remove the safety, and press the trigger really hard. > And I m very against transpilers and linters which I try to avoid for sanity (...) Complaining about linters because they test your sanity is a major red flag on your approach to mundane coding tasks. This, and your casual criticism on everyone else's code, leads me to suspect that you really need to do some introspection. > 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... Based on your comment and on my experience with similar projects, I suspect you're either oblivious and/or leaving out important bits of the story just to continue plowing with your humblebrag, or you're succumbing the need to be hyperbolic. Frontend development has to deal with far more details and constraints and requirements than any backend task. Frontend is what both clients and PMs and executives look at, and the tiniest changes like resizing a button has deep implications on the business side of things. Furthermore, it's both harder to automate tests and their tests need to be more extensive. Thus any change, no matter how small, is a uphill battle. It's beyond me how someone who is so hard on their entire team ends up showing such weak understanding and insight of the problem domain. I know that on the internet no one knows you're a dog, but let's not get silly here.

lucumo 5y ago

> 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) Using Java 6 is major red flag. Even Java 8 should be red flag nowadays, if it weren't so extremely common. Both versions no longer receive any security updates or bug fixes. If an organisation doesn't care to put a system on a platform with active security updates that tells me one of three things: 1. The system is unimportant and is basically value-less. I don't want to work on systems like that. 2. The engineers are incompetent and lack even the most rudimentary learning skills (or will) to follow even the most basic updates on the tech they use every day. I don't want to work with people like that. 3. Engineering management is too incompetent to listen to very important messages from their team. The system likely has major issues and a fear of fixing even minor technical debt. I don't want to work in an environment like that. It's not seldomly more than one of these.

gonzo41 5y ago
Java 8, if you use corretto, is supported until 2026. It's totally fine to use and support. And java being java and jumping to 11 won't be that bumpy either.
- lucumo 5y ago
  > Java 8, if you use corretto, is supported until 2026. Interesting, I was not aware of this. I've not seen people use Corretto either, but it seems OpenJDK has a separate project just to maintain Java 8. So that's indeed still fine to use. > And java being java and jumping to 11 won't be that bumpy either. The update from 8 to 9 was rather painful in the beginning, mostly due to libraries not working well with the module system. I'm not sure how it is nowadays, it could have gotten better. 9→10→11→12→13→14→15→16→17 were very painless. I don't foresee a lot of companies getting stuck on those, though it's too early to tell.
  - xenomachina 5y ago
    Yes, we held off on upgrading from 8 to 9 originally because a lot of our dependencies didn't work with 9's module system. A few months ago we jumped straight from 8 to 11, and it was easy, because all of those dependencies have since fixed their module system problems. (What finally pushed us to move to 11 was that some of our dependencies stopped supporting 8!)