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

Using a framework will harm the maintenance of your software

berk.es

Post reply on HN
Print view View original

511–520 of 550 posts

Re: Using a framework will harm the maintenance of your software

#511

Post by 8n4vidtmkvmk »

onion2k wrote: post #249
8n4vidtmkvmk wrote: post #146

I'm experiencing this with Laravel. I'm stuck on 5.2 while they're on v9 now because the author thought it would be a good idea to arbitrarily change some method signatures because he regretted his decisions earlier, while not providing any additional value and I don't have the time to hunt all these down and refactor everything, and I feel unmotivated when he's made it clear he's a bad steward. He refused semver for…

I don't have the time to hunt all these down and refactor everything Yes you do. You're just choosing to spend that time on other things rather than pay off some of the technical debt (that the framework introduced rather than you). Your decision to just live with the old version will prove to be a bad one in the long term: you'll find it frustrating, your skills will stagnate, new hires will find it frustrating (and…

Sure. Every time someone says "I don't have time" they really mean "I'm prioritizing other things higher".

I don't have any employees yet =) And I do firmly believe launching a few more features is worth more than eliminating some tech debt.

Re: Using a framework will harm the maintenance of your software

#512

Post by itake »

jonwinstanley wrote: post #183
itake wrote: post #166

Earlier quoted context omitted.

I am getting bit in the butt right now for using the ionic framework for building a multi-platform mobile app. If I want to build a mobile app in JS, but not use a framework (ionic/cordova/react native), how do I proceed? While I admit framework-driven cross platform mobile apps are bad, even native code is vulnerable to OS updates shifting the ground from underneath them. How do you use a library in mobile app dev?

Surely in this situation a framework is pretty much your only choice? Trying to do this yourself would be very complex and stop you from writing your actual app?

I agree. I feel like OP's advice is heavy handed.

Re: Using a framework will harm the maintenance of your software

#513

Post by vidarh »

pjmlp wrote: post #498
vidarh wrote: post #492

Earlier quoted context omitted.

And yet almost everyone would still agree that "GCC C" is also C, so this is entirely irrelevant to what was being discussed.

Yeah, that is why plenty people then show up on Stack Overflow with questions that prove how much they know C, versus "whatever my compiler did when I tried it out".

And this has even less to do with what was being discussed.

Re: Using a framework will harm the maintenance of your software

#514

Post by pjmlp »

vidarh wrote: post #513
pjmlp wrote: post #498

Earlier quoted context omitted.

Yeah, that is why plenty people then show up on Stack Overflow with questions that prove how much they know C, versus "whatever my compiler did when I tried it out".

And this has even less to do with what was being discussed.

What was being discussed was that C without the CRT is a dialect of ISO C.

Re: Using a framework will harm the maintenance of your software

#515

Post by berkes »

cbsmith wrote: post #510
berkes wrote: post #447

Earlier quoted context omitted.

> And even then, whats really a "framework"? I've tried to answer that in the article. Anything that I should have clarified even more? Do note that I make an explicit distinction between libraries and frameworks. I'm not expecting a one-man-show to write the SSL libs or even the HTTP routing: there are perfect libs for that. When this HTTP library lives on the side of your app, abstracted away behind e.g. ports&adap…

I'll take advantage of the fact that you commented here to point out something unrelated that I found concerning in the article's reasoning: """ Companies that have.. A team that defines the standards, processes, practices, frameworks or architectures that other teams must follow. ...are amongst the lowest performers. Reversed: companies that lack this, amongst the high performers. In other words: enforced standardis…

> What they are intended for is cases where using Django may be a perfectly fine tool for what your team is doing, BUT if you used Flask instead it really wouldn't matter that much

This is a good summary of my entire article, really. What I said is that on one axis, frameworks are a very bad trade-offs. There always are trade-offs. The axis being "maintainability".

That does not mean one should always avoid frameworks. Nor does it mean that without a framework, software magically turns maintainable. But it does mean that the benefits a framework bring, come at a cost. Make the tradeoff, weigh the cons and pros, and then decide if a framework, company-wide standardisation, team-knowledge etc. weigh up to the downsides of that framework. One of which being that it puts limitations on how well maintainable you can shape the software.

Re: Using a framework will harm the maintenance of your software

#516

Post by abracadabra_ »

42e6e8c8-f7b8-4 wrote: post #409
abracadabra_ wrote: post #302

Write small, well tested services in the easiest to use framework you can find. If the service becomes hard to maintain then replace it. This should be a simple job guided by the tests.

People talk about services like libraries aren't a thing. That exact same statement with `s/services/libraries/`. "Write small, well tested libraries..." If you have a library with a solid, small public interface and you carefully maintain compatibility on that interface with great testing, you can be decoupled. Plus you don't have 2 network interfaces and the internet injected into a call to the interface.

Yes, this applies almost equally well to libraries as well. With the slight exception that you are not just bringing the library into your code but all of its dependencies as well. This makes it _slightly_ harder to wholesale change a library compared to a service.

Re: Using a framework will harm the maintenance of your software

#517

Post by abracadabra_ »

willsmith72 wrote: post #320
abracadabra_ wrote: post #302

Write small, well tested services in the easiest to use framework you can find. If the service becomes hard to maintain then replace it. This should be a simple job guided by the tests.

Not everything should be a small service

Maybe not, but the larger it is the harder it is to change.

There are pros/cons to both sides.

Re: Using a framework will harm the maintenance of your software

#518

Post by camgunz »

spion wrote: post #501
camgunz wrote: post #490

Earlier quoted context omitted.

> Other things are very straightforward, especially when you don't have to deal with 1000 other people's use cases but only your own. > ... fighting a 3rd party framework ... Can you give some examples of this? I'm personally finding it hard to come up with examples where this is a significant problem. The closest I can get is I worked on a Django REST Framework project where we went all-in on serializers, but then r…

- Fighting webpack (its plugin system makes it a "build framework"). Lots of configuration complexity to support thousands of possible tool configurations, when you need only one combination. - Angular v1. Scope, transclusion, watchers, directives, DI and things randomly breaking. - Almost all of the modern devops configuration tools. Would be easily replaced by some very basic typescript functions / libraries and De…

Yeah, I definitely see what you're saying here--I think a lot of people have had really frustrating experiences with these tools (even though I might quibble about them being frameworks).

But is it a reasonable alternative to build an alternative to webpack yourself? Or Angular? I would bet some people have tried/done this, and also have some frustrating experiences.

My point is I think you have to be _very_ careful when deciding to take on a big engineering project, like making your own JS build tool. Will the improvements in devex really outweigh the engineering hour investment? IME the answer is almost always no, what usually happens is you get a half-baked, non-documented/tested system, and reading through this thread, I'm not sure any of the anti-framework people have shown convincing examples where they did better than an OTS framework.

Or if they did, they released it! Django is famously one such instance, or your Bazel example. It seems like they bet right, or did a lot of off-hours work (pretty sure that's the case w/ Django haha) to get it going.

Re: Using a framework will harm the maintenance of your software

#519

Post by twhitmore »

I've had extensive experience on both sides of the fence -- working on apps within existing frameworks, and also maintaining custom frameworks & libs for apps using those. Unfortunately I find this article of very little value.

The author's claimed idea of "decoupling from the framework" is generally ineffective & impractical. It leads to extra layers of adapters & SPI with high cost and almost always zero value.

These sure add bloat & make the codebase pointlessly difficult to navigate, but are improbably unlikely to ever add value in allowing the framework to actually be changed.

Difficulties include mismatched abstractions, endless adapter layers, parameter types for methods also all needing to be abstracted, restricted capabilities, difficulty conveying behaviour/ dynamism rather than static values, and -- of course -- poor performance.

Results are severe choke-points hindering functionality, broken abstractions where stuff actually had to be done, and 90% of the SPI abstractions turning out worthless if you ever did try to migrate to another framework.

I'm an architect. I've seen people's non-portable abstractions so many times. The article's advice just seems so unlikely to help.

Pick a framework that offers long-term maintainability and lets you separate out your domain model & business logic, and just code directly in it.

Rather than railing against bad frameworks from limited experience (perhaps in rickety languages too), the author should perhaps spend some time to find a good one. Spring is fine for many purposes. The MVC is coupled at the front, but your domain model need not & should not be. Focus on that, which should be your business value.

Re: Using a framework will harm the maintenance of your software

#520

Post by rbanffy »

inopinatus wrote: post #201
valenterry wrote: post #153

Earlier quoted context omitted.

> or some wiser developer refactors substantial parts of the interface, business logic, persistence, and runtime configuration, effectively creating a framework within that application That's not what people commonly understand as a "framework". Nor is it a helpful definition because then where does "abstracting things" and "framework" start and end? No, the main difference between frameworks and what you describe is…

Sorry, I don't accept this very mechanical definition; not only is it a needlessly narrow one, it's downright meaningless in some paradigms, such as when implementing coroutines via continuations, but that doesn't mean you can't have frameworks in Scheme. Conversely, we could describe tuplespaces (a la Linda), or many event- or interrupt- driven systems (like an Ethernet port), as an inversion of control, but whether…

> this very mechanical definition

One of the most useful definitions I found was from Luciano Ramalho, the author of Fluent Python (and so many other cool things). According to his insight, a framework is something that calls your code. A library is something your code calls. Frameworks are more rigid things that force structure on your functionality. If the structure it imposes is good, then your code will be good.

Their scope is also tailored to the languages they support. As you pointed out, different languages will have different needs.

Post reply on HN