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

531–540 of 550 posts

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

#531

Post by camgunz »

robertlagrant wrote: post #399
camgunz wrote: post #343

Earlier quoted context omitted.

By this definition everything is a framework. You're never the one calling code, it's always the BIOS, the bootloader, the kernel program loader, etc. I don't want to go all ad-reductio, but this is one of the points I have against the anti-framework people: the code you write is actually a pretty small percentage of the total code that makes up your system/application. Good engineering is working to make sure that c…

> You're never the one calling code, it's always the BIOS, the bootloader, the kernel program loader, etc. I don't want to go all ad-reductio I don't think you're even being reductive; it's just irrelevant. The saying is to do with the software you're writing right now - do you include a framework (e.g. Django, Ruby on Rails, Spring) or do you include libraries that you could swap out (e.g. Flask - which terms itself…

> I don't think you're even being reductive; it's just irrelevant.

The arguments here are:

"With libraries you call the code; with frameworks they call your code"

"This isn't a good distinction because there are lots of things we wouldn't consider frameworks that call your code"

That seems relevant to me.

> I'll spend a lot more time and money on making my application than I will thinking about how the Linux kernel works.

That means the kernel is doing its job, and if you swap out "Linux kernel" with "Django", that would also mean Django is doing its job. Without the kernel, you'd have to do a lot more work talking to hardware and scheduling other processes to run. Without Django, you'd have to do a lot more work wrangling HTTP and SQL.

It feels like peoples' issue with frameworks are that they force a way of thinking on you. But everything in software does that, the semantics of processes, pages, threads and so on are entirely made up, just like model view controller is.

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

#532

Post by camgunz »

vidarh wrote: post #346
flohofwoe wrote: post #318

Earlier quoted context omitted.

The overall program flow in this case is: shell => CRT => main(argc, argv) => exit code => shell (to me, the CRT and C standard lib are not strictly separate, although that's debatable of course)

Except none of these steps are dictated by the C standard library (some may be dictated by some libc's) EDIT: To expand on this: You can call the code from stuff other than a shell; I'm assuming you mean "C runtime" by CRT, and some libc's may have issues without them, though usually only access to argc/argv and atexit(), and you can certainly write C without linking with the initialisation code; and while you'll of…

The kernel loads your program, and schedules its execution. This is basically the same as using an async framework and sending the entry point to your application.

If you're willing to extend a little, there are also signal handlers, or setting up callbacks in pthreads.

Again this isn't to be reductive, but to say this is a super common method of encapsulating irrelevant stuff. It doesn't seem to be a significant differentiation between "I'm a library" and "I'm a framework".

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

#533

Post by hinkley »

Joel_Mckay wrote: post #193
hinkley wrote: post #179

Earlier quoted context omitted.

One of my goals this winter is to clear my head of as much OOP dogma as I comfortably can, fill it with as much DevEx thinking as possible, and read Christopher Alexander, A Pattern Language, from that frame of reference. My very hot take is that we will start referring to everyone who bought first editions of the Design Patterns book as the Lost Generation, because we have completely misinterpreted Alexander's work,…

I usually recommend "Designing Elixir Systems with OTP: Write Highly Scalable, Self-Healing Software with Layers" (2019 James Edward Gray, II, Bruce A. Tate) One may also find it interesting how Elixir/Phoenix-framework uses the OTP to greatly simplify implementation. =)

I think the missed or perhaps unspoken observation in this thread is that if the language provides it, and you're using it, you're tying yourself to the language, which tends to last a lot longer than frameworks.

Switching languages obviously requires a rewrite. But you aren't also rewriting the framework integration too. Some languages have work-alike frameworks, but they aren't ever exactly the same behavior and semantics. There are always subtle but important differences.

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

#534

Post by Joel_Mckay »

hinkley wrote: post #533
Joel_Mckay wrote: post #193

Earlier quoted context omitted.

I usually recommend "Designing Elixir Systems with OTP: Write Highly Scalable, Self-Healing Software with Layers" (2019 James Edward Gray, II, Bruce A. Tate) One may also find it interesting how Elixir/Phoenix-framework uses the OTP to greatly simplify implementation. =)

I think the missed or perhaps unspoken observation in this thread is that if the language provides it, and you're using it, you're tying yourself to the language, which tends to last a lot longer than frameworks. Switching languages obviously requires a rewrite. But you aren't also rewriting the framework integration too. Some languages have work-alike frameworks, but they aren't ever exactly the same behavior and se…

A clean pattern does not emerge naturally with a polyglot stack, as multiple languages with many library dependencies only lead to maintenance issues, duplicated code, and kludges.

I guess my point was that while it is sometimes necessary to pipe messages though multiple languages & platforms under special circumstances (see BSON over AMQP post above alluding to decomposing multiple hardware-dependent programs/codecs into a standardized cluster API.) In general, it is cleaner to have a simple distributed framework that hides the fact it is _not_ a monolith from _most_ developers.

We can agree to disagree on this matter, as everyone's use-case differs. =)

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

#535

Post by Fire-Dragon-DoL »

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…

Something I keep observing that seems to be passed over, coming from a Rails background, is that by using a known framework, the company is also accepting the "population" that comes with it, as well as the known problems.

I observed many Rails developers and many apps (purely anecdotal, I wish I could run a real study), but the problems are the usual, the ones on top of my mind right now:

    - database changes affect directly UI code, so a change in the DB requires changing code in a million places
    - Rails devs don't know SQL as much as they should (often just don't know it), for a framework that so SQL-centered, it's weird
    - hidden logic (callbacks)
These are very common problems with this framework and are well known to hinder company growth and ability to iterate.

Would a home-grown framework be better? I cannot tell, but surely if the list of downsides when choosing a framework was written in the splash page, I would be way more scared. "If you use this framework, your db will 100% be coupled with your frontend" is a terrifying statement.

Given that, framework should be evaluated for their downsides too, but there isn't even a list of known issues.

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

#537

Post by berkes »

fuzzy2 wrote: post #351
googlryas wrote: post #135

Earlier quoted context omitted.

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…

I too have been doing the same. It's surprisingly simple and elegant. I prefer 'ports and adapters, aka hexagonal architecture', but there are many alternatives.

This is what prompted me to write this article: the simplicity, elegance and maintainability of those codebases that had domain logic separated from delivery and storage mechanisms.

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

#538

Post by a4isms »

Fire-Dragon-DoL wrote: post #535
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…

Something I keep observing that seems to be passed over, coming from a Rails background, is that by using a known framework, the company is also accepting the "population" that comes with it, as well as the known problems. I observed many Rails developers and many apps (purely anecdotal, I wish I could run a real study), but the problems are the usual, the ones on top of my mind right now: - database changes affect d…

100% worthy observation from my career experience.

Choice of a framework both attracts a certain type/subculture, and repels another.

Example: You have an old app that uses Backbone+CoffeeScript for the front end. If you stick with that, it will absolutely impact your hiring. But what about switching?

If you pick React, that will have one impact. If you pick Ember, that will have a different impact. And so forth…

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

#539

Post by a4isms »

a4isms wrote: post #538
Fire-Dragon-DoL wrote: post #535

Earlier quoted context omitted.

Something I keep observing that seems to be passed over, coming from a Rails background, is that by using a known framework, the company is also accepting the "population" that comes with it, as well as the known problems. I observed many Rails developers and many apps (purely anecdotal, I wish I could run a real study), but the problems are the usual, the ones on top of my mind right now: - database changes affect d…

100% worthy observation from my career experience. Choice of a framework both attracts a certain type/subculture, and repels another. Example: You have an old app that uses Backbone+CoffeeScript for the front end. If you stick with that, it will absolutely impact your hiring. But what about switching? If you pick React, that will have one impact. If you pick Ember, that will have a different impact. And so forth…

Also, speaking very specifically about Rails, every architecture is composed of design choices that make some things easy, and other things hard.

The default "Rails Way" has a particular dynamic around REST and CRUD that makes it very easy to "Extrude the implementation into the interface," and, "Extrude the implementation into the API." It's what accelerates building a thing the first time, but later on it can work against you.

JM2C about this, but it's what I have observed and have lived through refactoring on multiple occasions...

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

#540

Post by spion »

camgunz wrote: post #518
spion wrote: post #501

Earlier quoted context omitted.

- 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…

> But is it a reasonable alternative to build an alternative to webpack yourself?

Before code-splitting, yes, it was quite easy (not much harder than building a makefile). Webpack is difficult and complex because it has to cater to literally thousands of tools (https://www.npmjs.com/search?q=webpack%20plugin). An individual project can choose to use a simple js-only bundler and a copy command for static assets.

There was nothing to release there, however - we just wrote the equivalent of a makefile. It was not a big engineering project at all.

Would I do the same thing today? No, because of code splitting and because there are simpler, faster bundlers out there already (esbuild).

> 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.

This is, where I think we differ. I think much more often than not, we already have half-baked, poorly documented systems which we insist on trying to use, even if the team is quite capable of building something better. This is also one of the reasons we have JS fatigue - its not because the language or even the browser somehow prevents something better from being built, its because we keep insisting on using poorly designed tools or tools designed to solve problems that large companies have but we don't really have.

Post reply on HN