Hacker News Reader

Comment by kerblang | Hacker News Reader

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.

View on HN

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

Agreed - I drive-by minor version updates at every opportunity that I can because I know if I don't, things will get pretty painful sooner or later.

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)

[1]: https://github.com/renovatebot/renovate

Oh nice - do you get many problems that slip through even though tests pass? I had a minor update to the Stripe SDK recently that broke something.

We do get very occasional issues in our React app, but not enough to outweigh the benefits of things staying up to date.

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

> completely skip their wrapper

Why use Spring Boot at all then?

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.

What don’t you like, if you don’t me asking? I was thinking of delving deeply into Spring.

There is quite some boilerplate and for someone inexperienced it is quite a big leap.

Ive been developing with spring for past 3 years and so far I freaking love it.

Ive gotten quite quick with it so I can do an mvp with auth, logging, microservice patterns really fast.

And when project grows in complexity it is very maintainable.

But if you are not expirienced and don't care about maintainability and want something fast then node& express is a way to go imho

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

> a lot of frameworks (I'm thinking of Spring here) devote most of their effort to creating "value add" wrappers

... that don't usually add any real value.

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

But Spring also saves you the time of putting those wrapped technologies together.

I wonder if Spring has caused more wasted time, configuring its grandiosity, than it has saved people, and I say that because I don't know the answer.

What do you think people waste most of their time on?

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.

I'm sorry, put the parent comment was talking a the Java framework Spring. My question was in regard to that framework.

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?

Sometimes it is.

Trying to find solutions to random errors is a big task because of all the layers and layers of classes.

A simpler and renewed architecture that covers all those parts that Spring solves would be beneficial for the users.

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.

Reply on news.ycombinator.com