Live data from Hacker News

Using a framework will harm the maintenance of your software

berk.es

431–440 of 550 posts

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

#431

Earlier quoted context omitted.

The author uses Django as an example of a framework... but Django doesn't really fit the definition used. Django does not dictate the flow of your code. It provides some libraries and there are common patterns, but Django is more or less just a set of Python modules you can import and use as you want (A bit of configuration is done for you if you follow common layouts, but you don't have to and can manually do the co…

Ok, let's use Django with Flask and web2py then, since Django apparently doesn't dictate the flow of your code?

There was a talk a couple years back at Djangocon where a company was using both flask and Django together. It was a transition for them from flask to django, but it wasn't hard to do. Probably doesn't make a lot of sense for most projects, but it is possible because Django doesn't get in the way.

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

#432
Complexity. Specifically the complexity of the framework vs the complexity of your need.

Often frameworks/libraries solve the whole problem. For example Oauth. If you want to provide "login with {Google, Amazon, Apple, Facebook, Instagram, etc}. then you must deal with the differences and oddities of each implementation of the service. And all the different modes of "login with" and then keep up to date with changes.

The difference is the same as that between buying a shovel and an excavator. Excavators are fun - at least until you have to fix them - so if you can afford one there is a temptation.

Complexity in software is the product killer. The cost of maintaining ten excavator type solutions can kill your product and your productivity, and can require you to create a maintenance department.

Libraries and Frameworks are always a temptation and often are useful, but understanding the full cost and all the downsides increasingly makes what seems like an obvious choice not so good.

But what if you need only a very basic flow for Github? Do you need that complexity? You may need to expand your solution, so

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

#433
post #23

Earlier quoted context omitted.

> I think many, maybe most, companies that try to build loosely coupled and highly cohesive code bases end up failing and it ends up being a mess. Companies who try to build any type of codebase end up with a mess. Always. No exception. There is no reason to pretend software development's natural tendency to increase entropy is exclusive to a specific type of software architecture. In fact, some developers even go to…

> Companies who try to build any type of codebase end up with a mess. Always. No exception. I love how demonstratively wrong this is

You forgot to do the demonstrativeness, just saying it doesn't make it so.

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

#434
post #92

Earlier quoted context omitted.

Every single codebase doing anything nontrivial is mess. Show me a code base that you can marvel at it's beauty, elegance, and how neat and tidy everything is organized and one of two things will be true about it. 1. It has never touched the real world, real hardware, or real users. 2. All the mess is hidden in some dependencies that handle the integration points with the outside world. You cannot escape the fact tha…

I first thought to post some links to code bases that, in my eyes, aptly counter argue your claim. Then I realised that you have already solidly placed yourself in a corner and are bound to defend that corner no matter what I am going to post. Since there's no objective measure of what constitutes as a mess (in contrast to what is simply not perfect) it's also easy to convince yourself that the statement always remai…

> I first thought to post some links to code bases that, in my eyes, aptly counter argue your claim.

...but then you realized they weren't supportive of your baseless assertion, and arguably were a hot mess as well.

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

#435

Earlier quoted context omitted.

> Companies who try to build any type of codebase end up with a mess. Always. No exception. I love how demonstratively wrong this is

Where do you work?

Probably in a small close-nit team working on something for no more than a year or two that will be impossible to maintain once the authors move on to greener pastures.

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

#436
post #17

1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correc…

No post body was provided.

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

#437
post #10

The post is promoting building applications in a loosely coupled but highly cohesive manner. It mentions using libraries when appropriate and not duplicating code. I agree with this but it requires a lead who's good at architecting such a codebase. That person also needs to stay with the company for a long time because they're essentially replacing the "framework" with bespoke human logic. I think many, maybe most, c…

I'd rather wallow in my own mess than wade through someone else's though

The whole point is that there won't be a mess or at least as much of it if you use a framework. How is this so lost on people here so often!

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

#438
My main issue with the usage of frameworks is when they are used in a situation where they are clearly not needed. It seems common in my opinion that people who use npm, react etc. as a part of their work -- where we can assume for the sake of argument that it is necessary -- also use these same tools for minor hobby projects they're involved in, where it really wouldn't be necessary.

I've seen more than one "theme" for example for any generic site generator or blogging software that does nothing more than set up some CSS rules, define some views and use some very minor JS for interactivity, but still has a minified output ground through npm with the almost mandatory 200+ dependencies that of course break and cause security warnings over time.

I've also seen entire products written in a framework that seemed invincible in the day it was created, only to be a dinosaur everybody despises five years later when new functionality needs to be added. Frameworks inevitably makes me think of the poem "Ozymandias"[1], they accumulate as dead monuments over time, and it cannot be avoided.

So, what to do? Well, my humble and highly personal opinion is that two thoughts should at least be entertained:

1) Using less code and less infrastructure to "build" it may, for smaller projects, make them a lot more maintainable and robust over time

2) For larger projects, instead of hooking your cart to one framework for everything, focus on separating the functionality into different parts, so that at least when one of your frameworks need to be replaced five years down the road, you can keep using the other separate parts that work fine.

[1]: I met a traveller from an antique land,

Who said—“Two vast and trunkless legs of stone

Stand in the desert. . . . Near them, on the sand,

Half sunk a shattered visage lies, whose frown,

And wrinkled lip, and sneer of cold command,

Tell that its sculptor well those passions read

Which yet survive, stamped on these lifeless things,

The hand that mocked them, and the heart that fed;

And on the pedestal, these words appear:

My name is Ozymandias, King of Kings;

Look on my Works, ye Mighty, and despair!

Nothing beside remains. Round the decay

Of that colossal Wreck, boundless and bare

The lone and level sands stretch far away.”

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

#439
post #92

Earlier quoted context omitted.

Every single codebase doing anything nontrivial is mess. Show me a code base that you can marvel at it's beauty, elegance, and how neat and tidy everything is organized and one of two things will be true about it. 1. It has never touched the real world, real hardware, or real users. 2. All the mess is hidden in some dependencies that handle the integration points with the outside world. You cannot escape the fact tha…

I first thought to post some links to code bases that, in my eyes, aptly counter argue your claim. Then I realised that you have already solidly placed yourself in a corner and are bound to defend that corner no matter what I am going to post. Since there's no objective measure of what constitutes as a mess (in contrast to what is simply not perfect) it's also easy to convince yourself that the statement always remai…

I have a truly devastating reply that this website's comment length is too small to contain.

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

#440
post #17

1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correc…

> have not actually experienced writing an application without a framework

There are a lot of different types of organizations, and their needs for development vary. Using well known tools reduces onboarding time, and in a large organization with turnover, that's not an insignificant cost. You really think the documentation you wrote for your app is better than those of a popular open source framework?

Frameworks also bring community defined best practices and standards. There is support from tooling like test frameworks that make functional / unit testing easy, linting and code formatting tools, IDE support, autocomplete snippets, debugging tools, browser extensions. These things might not be important in a small team, but with 100 devs, they bring real benefits.

> I just put all my state data in one object, save it on each user interaction

The saying is any "sufficiently complex app", and your approach to state management speaks volumes about the scale and type of front end apps that you work on. If you've never had bugs in your state using this strategy, it's wonderful. But if there were 100 of you constantly adding to and changing this global object, do really think that would be manageable?

How much state are you dumping in this object? If you only reference it on page refresh, your app must not be very reactive. One UI component could have quite a bit of state associated with it. One complex dashboard SPA could have hundreds of different pieces of state that are being tracked. Modern frameworks are tackling that problem, and the fact that you don't have it doesn't mean nobody else does.

Post reply on HN