The Problem with Frameworks • Hacker News Board

Re: The Problem with Frameworks

#11

Post by recursivedoubts » Tue, Feb 08, 2022, 2:03 PM UTC

I like the idea of a "curated" platform: putting together the best libraries in a somewhat opinionated way, but not writing a lot of additional code on top of it, and making sure that most of the curated glue code can be ditched if someone using the platform doesn't want or need something.

This would let people get going quickly and not have to make a thousand decisions or figure out all the integration points, but retains some of the benefits of the library-mindset (configurability, swappability, domain expertise, etc.)

Re: The Problem with Frameworks

#12

Post by nicoburns » Tue, Feb 08, 2022, 2:05 PM UTC

kerblang wrote: post #2

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…

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

Re: The Problem with Frameworks

#13

Post by Tomte » Tue, Feb 08, 2022, 2:06 PM UTC

recursivedoubts wrote: post #11

I like the idea of a "curated" platform: putting together the best libraries in a somewhat opinionated way, but not writing a lot of additional code on top of it, and making sure that most of the curated glue code can be ditched if someone using the platform doesn't want or need something. This would let people get going quickly and not have to make a thousand decisions or figure out all the integration points, but r…

I'm not a Java person, but I think Dropwizard advertises with basically that idea.

Re: The Problem with Frameworks

#14

Post by mattgreenrocks » Tue, Feb 08, 2022, 2:08 PM UTC

The paradox of frameworks: if you couldn’t write it yourself, then using it is a big risk if you hit a bug. But if you could write it yourself, you may not want to, as you have a better idea of what you want.

Personally, I only like frameworks that don’t fight me tooth and nail to encapsulate them into adapter layers (hexagonal architecture) when the time comes. There aren’t many of them. Some of them feel almost narcissistic in how much they want to assert themselves within your code.

The domain model is the most important thing. The framework is a detail that is not important.

Edit: forgot to mention, there’s a whole other argument here about how frameworks are not architectures. I suspect this is a big draw for many teams. But a commoditized architecture won’t serve you well over the long term.

Re: The Problem with Frameworks

#15

Post by random_kris » Tue, Feb 08, 2022, 2:08 PM UTC

kerblang wrote: post #2

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…

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

Re: The Problem with Frameworks

#16

Post by recursivedoubts » Tue, Feb 08, 2022, 2:09 PM UTC

Tomte wrote: post #13

recursivedoubts wrote: post #11

I like the idea of a "curated" platform: putting together the best libraries in a somewhat opinionated way, but not writing a lot of additional code on top of it, and making sure that most of the curated glue code can be ditched if someone using the platform doesn't want or need something. This would let people get going quickly and not have to make a thousand decisions or figure out all the integration points, but r…

I'm not a Java person, but I think Dropwizard advertises with basically that idea.

interesting, thank you for the pointer!

Re: The Problem with Frameworks

#17

Post by gorjusborg » Tue, Feb 08, 2022, 2:11 PM UTC

recursivedoubts wrote: post #11

I like the idea of a "curated" platform: putting together the best libraries in a somewhat opinionated way, but not writing a lot of additional code on top of it, and making sure that most of the curated glue code can be ditched if someone using the platform doesn't want or need something. This would let people get going quickly and not have to make a thousand decisions or figure out all the integration points, but r…

In the clojure ecosystem, Luminus (https://luminusweb.com/) is pretty much a curated set of libraries for web development.

I still think that relationship still creates friction. The framework itself has swapped out libraries in the past, and you are basically dragged along if you upgrade.

Re: The Problem with Frameworks

#18

Post by gwbas1c » Tue, Feb 08, 2022, 2:14 PM UTC

recursivedoubts wrote: post #11

I like the idea of a "curated" platform: putting together the best libraries in a somewhat opinionated way, but not writing a lot of additional code on top of it, and making sure that most of the curated glue code can be ditched if someone using the platform doesn't want or need something. This would let people get going quickly and not have to make a thousand decisions or figure out all the integration points, but r…

15 years ago, there was "LAMP:" Linux, Apache, MySQL, PHP.

Re: The Problem with Frameworks

#19

Post by fendy3002 » Tue, Feb 08, 2022, 2:15 PM UTC

I don't really consider ExpressJs as framework, but if it is, then it's the most suitable one for me.

It's very simple to setup, easy to extend and letting you to setup the structure whatever you want.

If only it's updated to use async await, better error handling and have modules to perform ssr for react (and vue), it'll be much better.

Re: The Problem with Frameworks

#20

Post by gwbas1c » Tue, Feb 08, 2022, 2:17 PM UTC

ziggus wrote: post #3

But at some point, isn't the hand-picked approach going to result in the same morass of version dependencies on any site of moderate complexity?

Yes, but the whole point is that you don't have to update all your dependencies at once.

Even if you do find yourself needing to update your dependencies, you can do them 1 at a time. This way you aren't stuck with a not building, completely broken codebase for days while you refactor to adapt to new changes.