I keep saying it again and again: Dependencies strangle dev teams to death. A massive framework tangle of interlocking dependencies is enough to default most teams to never-never-upgrade-land, even when struggling to compensate for a too-early release's flaws.
And I'll add that a lot of frameworks (I'm thinking of Spring here) devote most of their effort to creating "value add" wrappers around technologies that work more than well enough without, and that create even more problems for a dev who now has to understand both original and wrapper's attempt at enhancement. Enough wrapping! Create something real, just once.
> A massive framework tangle of interlocking dependencies is enough to default most teams to never-never-upgrade-land, even when struggling to compensate for a too-early release's flaws.
I definitely agree that the attitude of never upgrading dependencies doesn't work! But I've seen plenty of teams using dependencies successfully that took the opposite approach of updating them regularly (say, spending an hour updating versions every couple of weeks - perhaps a bit longer if there is a major release of an important dependency). This might not work if you require mission-critical stability, but it can work out to a huge time saving if you don't.
I used to do this before I discovered renovate [1] - now we spend time working on major upgrades but minor are generally automatic (assuming they pass tests)
Well with spring boot you can use spring wrappers but there are always (atleast in my expirience) ways to override their way of doing things or just completely skip their wrapper and just use whatever is under the hood
Because it provides commodity functionality that most developers with Spring experience can understand quicker, along with the Java philosophy of customization over convention.
I don’t like Java or Spring, but I understand their benefits and why people like them.
I don’t understand why people use Spring. Having worked in more than enough Spring projects, your frankly better off without any framework than using Spring.
Thanks for your insight. I agree with your comment about the trade off between the time it takes to fully learn the framework vs the productivity that you will get. I think that’s true for all frameworks. There’s also Javelin if you need something smaller and quick to pick in Java that is similar to Express.js.
Imo if you’re doing Java, you need some inversion of control framework like Spring of Guava. You can’t avoid it especially for larger projects
what I really hate is that it focuses on configuration & customization over convention. At the same time, it is a strength for certain projects and teams.
> Imo if you’re doing Java, you need some inversion of control framework like Spring of Guava. You can’t avoid it especially for larger projects
I completely disagree. I’ve worked on more than my fair share of Spring projects, and as far as I’m concerned, dependency injection frameworks tend to make projects more complex than they need to be. In some ways I think Spring projects end up being much larger than they need to be because of Spring. Not to mention that it turns compile-time checks into incredibly hard-to-debug runtime checks.
I've been struggling with this for years in the front-end / JS space, to the point where I just want out and live happily in my reasonable Go dependency management / aversion space.
It's a convoluted mess. A while ago I made the move to migrate to Yarn 2 / 3, because it uses less disk resources (dependencies are in .zip files). But because most tools still expect a node_modules folder, it required a lot of workarounds. And now I'm in some kind of dependency hell where one library needs version X of another lib while the other needs version Y, and they're not compatible or don't work well in my editor. It just keeps giving. Sigh.
FWIW my experience is that Yarn 2/3 work great, as long as you stick with the `node_modules` linker (which works the same way Yarn 1 and NPM always have, by extracting all packages to disk) instead of the "Plug 'n Play" option (which keeps all packages zipped up, and requires that Yarn own all filesystem access to decompress files on the fly).
Debugging and finding tiny mistakes in the new hot JS framework of the month. That and maybe trying to do something with CSS the wrong way, but not looking up how it should be done and reworking their DOM to make that happen.
Debugging is one. I’ve spent and enormous amount of time debugging problems that never would have occurred without Spring, and even more debugging things that would have been much easier to debug without Spring.
And even if I didn’t have to spend all that extra time debugging, I don’t think Spring actually added any real value.
Thanks for your comment. What best practices do you recommend so that people don't hit these debugging problems? Also, what other framework/library would you use instead of Spring?
I think it's language dependent - no team i've been on has been strangled by dependencies, they've largely amplified development; and the tradeoff to address breaking changes when they come is worth it.
But if you add dependencies, and don't make time to keep them up to date... you're going to have a bad time.
And I'll add that a lot of frameworks (I'm thinking of Spring here) devote most of their effort to creating "value add" wrappers around technologies that work more than well enough without, and that create even more problems for a dev who now has to understand both original and wrapper's attempt at enhancement. Enough wrapping! Create something real, just once.