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

351–360 of 550 posts

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

#351

Post by fuzzy2 »

googlryas wrote: post #135
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 f…

If your message contains framework-dependent data, it wasn’t decoupled.

For example, in a typical web API, all the stuff concerning HTTP endpoints, JSON, OpenID Connect or whatever should be entirely separate from your domain logic. I’ve been doing this for years and it is very feasible.

Do you still have to write code where the framework dictates its structure? Absolutely. That’s the decoupling layer. Do you have to change this layer if you upgrade or switch frameworks? Also yes. However, you don’t have to touch the application core.

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

#352

Post by abirch »

another-dave wrote: post #294
throwaway284962 wrote: post #274

Earlier quoted context omitted.

I started using a framework for a task at work, was immediately tripped up by an obvious stupid bug in the config files, reported it and it was closed because "too many people already depend on this behaviour". So now I've in-sourced other companies legacy and taken on a huge liability in depending on the evolution of undefined number of other organisations and their code bases. And even worse when these frameworks a…

Build everything in-house or be beholden to some dude going backpacking is a false dichotomy. It'd be like saying I always make my own food from scratch — have you seen the state of the burger van down on the corner? You can't trust food made by others. All frameworks aren't created equal — as with any tooling, you choose something based on the features of the framework but also the longevity, reputation and ecosyste…

Thank you for this common sense reply. Can you imagine someone wanting to roll their own Flask? Their own React? It's like most people here seem to be siths and only deal in absolutes.

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

#353

Post by berkes »

ensignavenger wrote: post #70
couchand wrote: post #36

Earlier quoted context omitted.

The author carefully distiguishes precisely what type of framework they mean. The definition includes multiple parts, but the part that really stands out to me is that a framework dictates the overall flow of control. The suggestion in TFA is to ensure that you consume your dependencies in a decoupled fashion, a move toward utilizing libraries rather than following a framework. I've spent lots of development time in…

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…

Author here.

I use Django and Rails as examples. Both are, indeed, "just a bunch of libraries". But many of those libraries, and especially their bundled collection, enforce certain behaviour, shape and architecture.

When you inherit from base-classes offered by a library, you are tightly coupling against that: i'd then stop calling it a library and call it a framework instead. The alternative would be a library that you inject, or compose.

There's a big difference between (Rails)

`class Project and

class Project

  def initialize(project_repo) # Ruby has no interfaces, but this would be something that has at least an `.add(project)`

    @project_repo = project_repo

  end
end

The first inherits, couples tightly to a bunch of libraries (ActiveRecord::Base really is just a bunch of modules that you could pick and choose) the former injects behaviour which might come from libraries, or might come from your own code.

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

#354

Post by ChrisMarshallNY »

ChrisMarshallNY wrote: post #60
ativzzz wrote: post #57

Earlier quoted context omitted.

I shudder to think about what a formal specification of some of the full stack web projects I've developed would look like. They might take longer than the actual coding of it - especially because specifications change mid project as we build things and realize we actually want them different. Note this is a feature, not a bug, of "agile" development - you learn and adjust on the fly

I tend to make it up as I go along ([0], [1]). It works for me (I just finished up a new SDK, using this technique[2]). However, this would not work for many outfits. It’s just the way that I work. WFM. YMMV. [0] https://littlegreenviper.com/miscellany/forensic-design-docu... [1] https://littlegreenviper.com/miscellany/evolutionary-design-... [2] https://github.com/LittleGreenViper/LGV_MeetingSDK

Hmm… That’s interesting.

I seem to have upset people. I’d certainly be interested in knowing why, as my comment directly addresses the parent, and does not coarsen the discourse.

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

#355

Post by berkes »

tomcam wrote: post #28
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…

Agree completely. I’d like to add a couple of things. 6. Frameworks often handle the last 20% of a project that no one wants to do, such as handling compatibility or accessibility issues. 7. There’s a good chance that the framework has already had to deal with edge cases that you would otherwise learn the hard way

Both could be done with libraries.

Things that you (can) put away behind abstractions, layers or wrappers.

I'm the author and tried to convey clearly the difference between libraries and frameworks. Both allow code-reuse, both allow "standing on shoulders". But one allows you to do so with freedom of movement, independence and domain constraints (libraries) whereas the other locks you in, enforces architectures and designs and requires workarounds when your domain-requirements differ from what the framework dictates.

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

#356

Post by throwaway99593 »

oreally wrote: post #143
hocuspocus wrote: post #37

Earlier quoted context omitted.

13 years into my professional career I'm still seeing Spring everywhere.

Likely lockins. Spring is bloated as hell, last I tried it took full minutes to startup a server on default settings. This kills iteration speeds for fresh projects.

I don't have that experience. I have personally run many different services, and most of them starts in seconds. The exceptions are usually those that start some process at startup (like syncing jobs, leader elections, database migrations, waiting for database locks etc.), but that is not something specific to Spring.

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

#357

Post by berkes »

SkyMarshal wrote: post #142

This is a beautiful blog. Love the typography and layout and readability. Looks like Jekyll fwiw [1]. [1]: https://github.com/berkes/berkes.github.com

Yup. Jekyll indeed.

Though a really old one. I should really upgrade, but -being a static site- never felt an urgent need, all the security flaws in any of the dependencies are hardly relevant. :)

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

#358

Post by berkes »

epgui wrote: post #15

Am I the only one who thinks this is really hard to read?

In what sense? The design or contrast? Or the language used?

English isn't my first language, so I can imagine I could do better (I'm the author btw). If it's the design: I really need to tweak it a little further, but rather spend that time writing content than tweaking the blog itself :D

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

#359

Post by spion »

camgunz wrote: post #335
coldtea wrote: post #235

Earlier quoted context omitted.

If knowledge is on a single person alone, then your ex-company has bigger issues than framework or no framework. Not to mention that the interesting parts of your app should be the domain logic and workarounds and solutions used in it for business issues and historical layers of bussiness logic choices. And that a single person can take with them whether there's a framework or not.

These are generally just resource issues. Companies generally won't pay for engineering hours to build really good framework documentation. It's not in the critical path. Companies that know that documentation, as well as tests, compatibility guarantees, security policies, etc. are actually critical components would probably not ever make the decision to take on that engineering burden themselves unless it were a bus…

> In my experience this has been a point in favor of OTS frameworks

Its not guaranteed. I've seen many developers spend lots of time trying to get the framework they're working in to cooperate or dig through bad documentation. Framework authors are fallible too and general-purpose software is really hard to get right.

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

#360

Post by berkes »

hinkley wrote: post #184

I will just sit over here nodding along and not making any eye contact with anyone who mentions unit testing frameworks...

Unit testing libraries are very valuable.

A unit-testing framework? What does it really do? It has a test-runner. But running software isn't some black magic, its easy and solved. It has naming conventions. But those are really just something a team can pick and never look back. It has ways to call functions based on those naming conventions. But that is really an extension to the test-runner.

Now, all the assert_contains, has_called_x, those are valuable. But easily offered as library.

Post reply on HN