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

131–140 of 550 posts

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

#131

Post by idealmedtech »

Qwertious wrote: post #129
ar_lan wrote: post #72

Earlier quoted context omitted.

I thought the same exact thing, and had entered the article with a significant bias against the author based on the headline.

I didn't enter with a bias, I was just thinking "LOL, how are they going to justify this, this is gonna be good ." And then they had to be something completely different and yet completely justified. Darn.

One reading which might be valid is that testing on hardware that lives in the happy path will lead you to think your code has less issues than it actually has on real user systems.

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

#132

Post by default-kramer »

If you read far enough, this is the author's actual complaint: "Yet most frameworks come with all those details up-front and mixed up. They often make it very hard, if not impossible, to be isolated." I disagree. Very few of the frameworks I've used have made it difficult for me to write all the interesting parts of my app in a framework-agnostic way. A complaint I could agree with is "frameworks tempt people to write too much framework-dependent code", but a purely technical criticism does not match my experience with frameworks.

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

#133

Post by inopinatus »

Supermancho wrote: post #102
inopinatus wrote: post #76

Earlier quoted context omitted.

> perhaps all of them (every single one) have not actually experienced writing an application without a framework I actually have written software without a framework, so by this standard I feel qualified to comment. Not all software has an implied framework within it. Most Unix command-line utilities do not, for example, with only a few exceptions, and discounting the C standard library as something worthy of the la…

> Not all software has an implied framework within it. The definitions of "framework" are always a sticky issue. If you take "framework" at face value, it's minimally a set of idioms. "an essential supporting structure which other things are built on top of" - which necessarily includes a mental model of execution. This relates closely to why naming, in software development, is considered so difficult. All software h…

Well, I don't disagree, and we could almost label that "framework zero", and also hence the reference to Unix utilities and their assumptions regarding stdin/out, but I am also taking a contextual cue from the article linked at the top which is clearly taking aim at large pre-chewed boluses of code such as Rails, Django, Drupal and so forth.

I am just about old enough to have even toggled in a program on the front panel of a PDP-8 that my local university had kept around to occupy valuable floor space in their computing center. I wouldn't say I used a framework, but I was just a kid at the time, so it's possible that I did use a stepladder.

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

#134

Post by tbrownaw »

DrewADesign wrote: post #124
sbf501 wrote: post #109

Earlier quoted context omitted.

I think this argument is about free vs. not-free frameworks. Frameworks that are supported by a company and actively developed are far superior to the state of NPM open source right now (thinking of Qt vs Electron and my 7 year battle with both). It is no fun when an open-source framework pushes a new major version, then deprecates the version you were on, or dependencies fail to find matching version, and you beg gi…

I think some of your experiences can be explained by your citing NPM as representative of FOSS. Not that there's anything wrong with the astonishing breadth of functionality available in the NPM ecosystem, but stability isn't its strongest comparative suit. OTOH, Django, which was cited by the author, just doesn't have that kind of volatility in its base features.

> Not that there's anything wrong with the astonishing breadth of functionality available in the NPM ecosystem

There are at least two things wrong. One is those things is missing standard functionality (eg, leftpad), and the other is a failure to maintain appropriate hubris (eg, is_even).

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

#135

Post by googlryas »

SevenNation wrote: post #54

> Many people will argue that not using a framework means write everything yourself. This is a false dichotomy. We can use libraries and frameworks just fine. ... > But we should give them a clear, and well-isolated place in our project. ... There's an excellent, if older, presentation called "Architecture, the Lost Years" that addresses exactly this problem and gives very specific, actionable guidance on how to solv…

Isn't the problem here that your decouple framework requires data X,Y, and Z in the message across the boundary, so you plumb that data through right near boundary where the request is made. But later on, you want to switch out a different framework, but that framework requires U, V, W, X, f(y), and Z. So even on your apps side of the boundary layer, you still formatted your code and data flow to support the single framework you started with.

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

#137

Post by lucasfcosta »

I don’t fully agree. The author has quite a few excellent points, but when one says it may “harm” the “maintenance” of your software one must define which variables are used to measure “maintainability”. Is it MTTR, cycle times, bug density, or what?

Speaking of maintenance in broad terms makes the argument fuzzy.

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

#138

Post by Beltalowda »

Test0129 wrote: post #130
a4isms wrote: 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…

I've been burned by so many frameworks I am hesitant to use one unless the advantage is abundantly clear. Even something as mundane as an ORM can cause massive problems down the line if you're not careful, or you forgot to anticipate the case you need something more complicated than braindead CRUD. Frameworks force you into a paradigm. Yes, to spin up quicker, get new engineers onboarded quicker, etc a framework will…

I mostly agree with this, and also with the parent poster. I've seen framework become a big problem, and I've seen shitty ad-hoc frameworks for "framework-less" applications.

I've had fairly good success with what I like to call "framework libraries". That is, all or most of the functionality of a framework, but composed more as a library (or rather, a set of libraries) than a framework, giving you the best of both, mostly. ORMs are often given as an example, but I rarely found them as issue as most I've used have an "escape" to allow you to just use SQL if need be. The bigger problems with frameworks are when you want to compose some application in a way the framework doesn't really like (this can be a problem in Rails, for example).

I aggressively push things to libraries whenever I work on something; sometimes they can be made public, sometimes not, but even when private it helps a lot in mentality of people, especially with certain kind of devs.

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

#139

Post by henning »

This is what happens when you view your application as an abstract Platonic object, immortal and perfect, outside any actual concrete implementation. Making the app serve web requests is part of the problem to be solved. The problem is the problem. Looking up whether a user exists as part of handling a request is completely fine because that's the simplest way to make the app do what it needs to do.

If you have some stupid "clean architecture" layer bullshit where your own application doesn't know how any of the rest of it works and everything is absurdly decoupled via some hexagonal bullshit, you're going to get into shitty situations where e.g. you have to call the database repository to do N queries rather than just one because the "clean domain layer" is written that way and the "HTTP message delivery layer" is only an "implementation detail" that has nothing to do with the pure business domain. Then your product will fucking suck fucking shit and you haven't actually solved the problem.

Post reply on HN