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

Avoid Mini-Frameworks

laike9m.com

Post reply on HN
Print view View original

51–60 of 119 posts

Re: Avoid Mini-Frameworks

#51

Post by layer8 »

oncallthrow wrote: post #23
oncallthrow wrote: post #21

This. This. This. I currently work in a codebase where so much code has been abstracted away for “cleanliness” that it’s impossible to understand what code is actually running. The worst is when three lines of completely standard code (immediately understandable to anybody inline) get „helpfully” lifted out into a utility function.

By the way, the reason behind all of this, like so many ills of our industry, is the completely broken promotion culture.

While I agree that the promotion culture appears to be broken in the US, I can assure you that these kinds of over-abstractions happen completely regardless of promotion culture.

Re: Avoid Mini-Frameworks

#52

Post by ka_veli »

adpatersbad wrote: post #45
barrkel wrote: post #5

> real and only difference between a library and a framework, is whether it introduces new concepts This isn't what is normally understood in software engineering by those terms. A library is something you call. A framework is some kind of application scaffolding that normally calls you. You can use more than one library. You normally only have one framework in-process. I found the blog post a little hard to parse. I…

> Wrapping libraries makes a lot of sense The best assumption to start with is that adapters are bad by default, because they are an unnecessary layer to maintain (and potentially a point of failure and bottleneck depending on what they are and do). Then, make the argument for the adapter as a guilty until proven innocent case. If you can make a solid case for it, fine. There are many solid cases for adapters, e.g. d…

A potential counter point here is that wrappers help reducing churn if the library being wrapped is actively developed - this can apply to both external libraries and ones developed by other internal teams. A wrapper limits the surface area that needs updating and can make some otherwise quite painful upgrades easier, at the cost of maintaining the wrapper itself. As ever, it’s a situational thing of course!

Re: Avoid Mini-Frameworks

#53

Post by huqedato »

I don't really understand the concept. What is the definition of "mini-framework" ? The author should have given a few examples.

I have the impression that he confuses "obscure" with "mini". Either framework or library..

Re: Avoid Mini-Frameworks

#54

Post by iammrpayments »

jodrellblank wrote: post #46
simonw wrote: post #32

Earlier quoted context omitted.

A hill I will die on is that React is a framework.

React's homepage says "The library for" and "Go full-stack with a framework. React is a library. It lets you put components together, but it doesn’t prescribe how to do routing and data fetching. To build an entire app with React, we recommend a full-stack React framework like Next.js or React Router." and "React is also an architecture. Frameworks that implement it let you..." React's Wikipedia page says "React ...…

The meta about us page also says it is a privacy first company.

Re: Avoid Mini-Frameworks

#55

Post by aefalcon83 »

christophilus wrote: post #3

Basically, premature abstraction / abstraction at the wrong boundaries coupled with the political power to force adoption of the bad abstraction. Yep. That’s an annoying attribute of working at a big corp. I prefer working in tiny teams and companies for this and many other reasons.

Oh, I know a small company that is affected by this problem, but your description of the cause is spot on.

Re: Avoid Mini-Frameworks

#56

Post by simonw »

jodrellblank wrote: post #46
simonw wrote: post #32

Earlier quoted context omitted.

A hill I will die on is that React is a framework.

React's homepage says "The library for" and "Go full-stack with a framework. React is a library. It lets you put components together, but it doesn’t prescribe how to do routing and data fetching. To build an entire app with React, we recommend a full-stack React framework like Next.js or React Router." and "React is also an architecture. Frameworks that implement it let you..." React's Wikipedia page says "React ...…

> Why die on a hill that it "is" something it says it isn't?

Because I think they're wrong about that.

If you'd prefer a different metaphor this is windmill I will tilt at.

To provide a little more of a rationale: React code calls the code I write - the JSX and the handlers and suchlike.

It's also pretty uncommon to see React used at the same time as other non-React libraries that handle UI stuff.

Most importantly, the culture and ecosystem of React is one of a framework. You chose React at the start of a project and it then affects everything else you build afterwards.

Re: Avoid Mini-Frameworks

#57

Post by k__ »

barrkel wrote: post #5

> real and only difference between a library and a framework, is whether it introduces new concepts This isn't what is normally understood in software engineering by those terms. A library is something you call. A framework is some kind of application scaffolding that normally calls you. You can use more than one library. You normally only have one framework in-process. I found the blog post a little hard to parse. I…

It's the same with app, application, program, software, tool, etc.

Re: Avoid Mini-Frameworks

#58

Post by gethly »

Frameworks promised faster development cycle, lest code and uniform codebase. But over the years, this proved to fail to deliver except in certain minority of cases.

I think modern programmers nowadays understand that it is much better to take the path of libraries than frameworks as it provides them with the same functionality of a framework(which is just a bundle of libraries), but with the freedom of implementing their code however they want, unlike wit ha framework, which forces certain structure and style as frameworks had to made certain decisions for the programmer in order to be a functional and comprehensive tool. This lack of freedom will usually bite most programmes LATER, when it is too late to go back and refactor code or change style and whatnot.

And that inherently also makes small frameworks even less usable than the larger ones.

YMMV, but not really.

Re: Avoid Mini-Frameworks

#59

Post by erkok »

Having been around in the industry for a while I'm seeing abstractions being misused all the time. Being guilty of it myself also when I was younger.

For me, the only purpose of an abstraction is to reduce complexity, but often times I'm seeing it being used to reduce repetitiveness, which often times replaces well understood more verbose code with less understood less verbose and less flexible alternative. For me, as a team lead, easy to read code is far more important than subjectively perceived elegant abstraction that everyone then has to learn how to use, and potentially fight with.

In many cases I have noticed people jumping into abstracting away a complexity right away, often times ending up with a leaky or inflexible abstraction. To those people I say, do that painful thing at least 10 times, then think about abstracting it away, since then you probably have some level of understanding about the pain you're trying to alleviate and all the nuances that comes with that domain.

Re: Avoid Mini-Frameworks

#60

Post by sunir »

It’s a simple math problem. And it is also Conway’s law that says all software design follows the organization that built it—that is all software design is political.

A framework calls you. You call a library.

A framework constrains the program. A library expands the program.

It’s easier to write a library that is future proofed because it just needs to satisfy its contract.

It’s harder to write a framework because it imposes a contract on everything that depends on it.

Just like it is hard to write tort law without a lot of jurisprudence to build out experience and test cases, it is hard to write a framework from only one use case.

No one likes lawyers because they block you from doing what you want. This is the problem with frameworks.

However the government likes laws because they block you from doing what you want. Same with whomever is directing engineering that wants all other programmers to work in a consistent way.

Post reply on HN