Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Problem with Frameworks

plbrault.com

Post reply on HN
Print view View original

41–50 of 111 posts

Re: The Problem with Frameworks

#41

Post by lnxg33k1 »

From an overview it seems more likely solvable with proper coding and tools, I love the fact that for example symfony/php makes you use a framework but you have the proper tools in order to forget that you're using the framework, you can have controllers, entities, repositories (and services with right extensions of framework services?), not depends on symfony, but also like if you use a framework and you go all in in getting it into your way, you would always end up by not being able to change stuff easily, even if it was your code, so I always make sure that I don't depend on things I can't change and have a set of interfaces layer in between "Depend on things you can change and not on things you can't", unless you made it perfect the first time and never end up changing it, but I think most likely this post is just junior point of view, with all due respect, I don't know the person, so maybe he's one of the best developers around, but just only considering this blog post, it seems very bad

Also I think the issue is more relevant with Python and django and ruby as they lack abstract classes and interfaces? in the context of making things incrementally changeable they're quite useful, so maybe there is something that is like that?

Re: The Problem with Frameworks

#42

Post by berkes »

dundarious wrote: post #7
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?

Ideally you would choose dependencies with minimal dependencies of their own ( very few if any common dependencies), so you have a manageable number of versions and near complete freedom of choice of those versions.

And ideally, you'll wrap them too. In what is often called "Anti-Corruption-Layers". Often very simple Proxies or Adapters. Consequentially, this makes testing (in isolation) far easier too.

Which also means you'll choose libraries that are decoupled by design because the others are really hard to write such wrappers for.

Re: The Problem with Frameworks

#43

Post by lnxg33k1 »

bjarneh wrote: post #5

Most frameworks (web-frameworks at least) get you from 0 to 80% in very little time. Nice layout/css etc, but they require you to learn how they want to do everything; which can be both cumbersome and time consuming. Frameworks also gives management false expectations of how long it takes to make something. "It looks like you're 80% done with the web-page already, and we've just started - great!" — Management

I mean, yeah but that seems like a good investment? Like how many times you want to learn that remaining 20%? And how many times customisations are not reusable? Of course you either learn a framework and reuse it, or go something that is bespoke, and does it have the same unit test coverage? Same documentation? Same ability to hire people with common knowledge? Same ability to google issues? I am not sure, but I see only pros about frameworks (in terms of maintainability but I guess not in terms of resource usage :D) and cons in the context of people not understanding / knowing how to protect themselves from frameworks

Re: The Problem with Frameworks

#44

Post by berkes »

Ask yourself: Are you building a Rails, Django, Spring app, or are you building a coffee-comparison-app, a facebook-for-dogs or a inventory-management-system (or anything, really).

This alone implies that what matters is your domain. Not the framework. This is also an important point that many seniors in the industry keep repeating. Eric Evans wrote a giant book about it (DDD), Robert Martin named his company after it (and keeps bringing it up on any conference). Dave Farley keeps repeating it in his youtube channel and his books. And so on.

My take is that development speed does not come from quick scaffolding like `rails generate CreditCard` but from having a clean, well-maintainable, loosely coupled, well-tested CreditCard Service or Aggregate, or DomainBoundary or whatever. Rapid time to market is not achieved with `curl fancyframe.work/in.sh | sudo bash` or `pip install django`. Rapid time to market is achieved with an architecture that allows easy rewrites, fast pivots and rapid swapping of dependencies.

Frameworks often hamper such loosely coupling. They get in the way, in the long run. Sure, chances are >50% that what you are building now fill be replaced or have failed within years. But for the off-chance of having something that you'll be maintaining over years, decades even, be sure you have something that does not get in the way. Edit: and on that timescale, the time-wins that the framework initially gave you, are often neglecatable anyway.

> So my strategy is to keep frameworks like Spring, Hibernate, and Rails at arm’s length; behind architectural boundaries. I get most of the benefit from them that way; and I can take ruthless advantage of them.

>

> But I don’t let those frameworks get too close. I surrender none of my autonomy to them. I don’t allow the tendrils of their code to intermingle with the high level policy of my systems. They can touch my peripheral subsystems; but I keep them away from the core business logic. The high level policies of my systems shall never be touched by frameworks. - Robert C Martin https://blog.cleancoder.com/uncle-bob/2014/05/11/FrameworkBo...

Re: The Problem with Frameworks

#45

Post by _fat_santa »

thomascgalvin wrote: post #23

> According to that definition, React is not a framework, but Gatsby is. I dislike articles like this. The vast majority of people would consider React a framework, and if you need to redefine such a basic word in order to make your point valid, there's probably an issue with your argument, not the definition.

I get the argument the author is making. React is a Javascript framework, but Gatsby is a React framework. So you have a situation where you have a framework for a framework.

Having worked with both, React isn't just an "opinionated way of writing JS", it uses Javascript under the hood but there's a ton it does uniquely, that is there is no JS equivalent, this is a thing that only React has (hooks, context, etc).

Re: The Problem with Frameworks

#46

Post by Cthulhu_ »

toddmorey wrote: post #25

Ok, I'll take the counterpoint and offer a few challenges I've seen with libraries. In a sense, you are often assembling your own framework. No judgement there--just good to know what you are getting into. - There's the potential for quite a bit of choice paralysis along the way as you assemble your stack - It's harder to seek help: as you've likely assembled a unique collection of tools (and therefore encountered un…

> There's the potential for quite a bit of choice paralysis along the way as you assemble your stack

True, but I feel (gut feel, no facts) that this is a matter of not fully understanding either the problem or the pros and cons of the options. If it's a choice you'll be stuck with for an extended period of time, it's worth writing up an Architecture Decision Record, or some other form of semi-formal design document; writing it proves to yourself and / or your team that you and/or your team understand the problem, have reviewed the options, and know the consequences of picking that particular solution.

And it gives you, your team, and future developers a handhold why library X was picked over library Y, and a basis to challenge the decision on. If they challenge it, they need to show they understand the cost of changing as well (working hours, retraining time, chance of new issues, etc).

> It's harder to seek help: as you've likely assembled a unique collection of tools (and therefore encountered unique challenges)

Each library on their own - thinking of mainly JS libraries here - will have their own website and community; I haven't found many instances where an issue was specifically about the combination of libraries X and Y, but your mileage may vary.

> It's harder to onboard other developers

I acknowledge this is a potential issue. You can probably find Django developers more easily than "developers with experience in x, y and z". It's a trade-off. That said, I do feel like every nontrivial application and development team will need to come to terms with the fact that training and education is an important aspect of onboarding new team members, and even if they may be familiar with e.g. a framework, they still need to learn the quirks of your particular application and domain.

> Smaller libraries often have a smaller community and a shorter lifespan

A library's community size and longevity is one of those factors to keep in mind in this architecture decision record I mentioned above. Sometimes it'll be better to pick the library with more known future proof than the sexiest one. Compromises all around. I picked React because I'm confident we'll be able to find developers in 5 years time, but I also went for a cleanly separated client-server application in case we need to rebuild the front-end (which for some reason ends up happening anyway every 5-10 years).

Re: The Problem with Frameworks

#47

Post by berkes »

toddmorey wrote: post #25

Ok, I'll take the counterpoint and offer a few challenges I've seen with libraries. In a sense, you are often assembling your own framework. No judgement there--just good to know what you are getting into. - There's the potential for quite a bit of choice paralysis along the way as you assemble your stack - It's harder to seek help: as you've likely assembled a unique collection of tools (and therefore encountered un…

To counter some of your counters, or, actually, to give some advise that I've learned along the way:

> - There's the potential for quite a bit of choice paralysis along the way as you assemble your stack

Yes. Which is why it is crucial to know software patterns, be able to research architectures and have (someone close, with) experience in making those choices - and seeing them fail. Frameworks are not a real answer to this, as they don't take away the need to make such fundamental choices: they just pull them forwards: it's the first thing you'll have to choose. At a moment when you lack all information and insight to make that choice.

> - It's harder to seek help: as you've likely assembled a unique collection of tools (and therefore encountered unique challenges)

If you stick to well-known patterns, mostly, there's enough help. Apply patterns to encapsulate, decouple and isolate all pieces. This way you avoid having to go to SO and asking "my Wordpress in a Docker with both FooFormsUltra(plus edition), EcommerceBarEasy, the MegaThemePlus with BootBulma subtheme, gives an error when I click on a red button". Instead your problems are either about what patterns to apply (which is high-level, well-documented) or with code in isolation (which means you can ask the library devs).

> - It's harder to onboard other developers

Again, well-known patterns can help. Counter is that even a senior hardened Rails dev will have a tough time on that legacy Rails project. In fact, to keep your Rails (ReactBoilerplate, Django) app onboardable over time, strict application of design patterns are the best solution. You'll need to spend time on this regardless.

> - There's often more bespoke glue code

This one I agree. In fact, if you Do It Right, your app will be mostly glue code. Especially the "boring parts" (like database setup, connecting, http handling etc). This is stuff that matters not for your domain and is best kept out of the way anyway. You really don't want the CLI-opt-parsing to get in the way of what your CLI app is doing anyway.

> - Smaller libraries often have a smaller community and a shorter lifespan

Maybe I misunderstand. But why does "no framework" imply "smaller libraries"?

Re: The Problem with Frameworks

#48

Post by Cthulhu_ »

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…

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.

Re: The Problem with Frameworks

#49

Post by sumtechguy »

gwbas1c wrote: post #22

I generally agree with this article. (Great explanation of the tradeoffs, BTW.) One edge case: Situations where the language itself has a major, breaking change between versions. IE, .Net Framework 4 -> .Net 5 (based on .Net Core,) or Python 2 -> Python 3. A simple codebase might easily move from Python 2 to 3; or .Net Framework 4 to 5; but once there's a lot of libraries, there's a good chance that you'll need a new…

Also sometimes you have to go 'backwards' for whatever reason. You find the exact same issues.

Not as bad as it used to be but also just moving between platforms and staying on the same framework and things would act different. Because something in the OS layer was different. I ran into this quite a bit in python 2.x. Where windows and linux methods would be slightly different just because of underlying assumptions about how things like files were opened. That was when I learned your code is only as good as the std lib your platform provides. Take for example c++. The language itself is not terribly big. But that stdlib that goes with it (whew). Then you wonder would c++ be worth anything if that lib was not there?

Re: The Problem with Frameworks

#50

Post by mattgreenrocks »

berkes wrote: post #44

Ask yourself: Are you building a Rails, Django, Spring app, or are you building a coffee-comparison-app, a facebook-for-dogs or a inventory-management-system (or anything, really). This alone implies that what matters is your domain. Not the framework. This is also an important point that many seniors in the industry keep repeating. Eric Evans wrote a giant book about it (DDD), Robert Martin named his company after i…

The discourse around how to build software is just terrible in general. This is sound advice and yet it's seen in many circles as tilting at windmills. Meanwhile, devs are happy to write off days/weeks with the makework of upgrading their apps to stay up-to-date with frameworks. Productivity is confused with a feeling of power.

I suspect some people value frameworks more highly because they perceive them as coming bundled with a community (e.g. support). This consideration outweighs the architectural damage done in their minds. I'm not disparaging this. But as devs mature and age, they gain confidence, and eventually realize that every project doesn't need to automatically start out with a framework.

Post reply on HN