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

71–80 of 119 posts

Re: Avoid Mini-Frameworks

#71

Post by TOGoS »

baobun wrote: post #15
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…

If you look above the unorthodox library/framework distinction, I think the criticism is about birthing new (inadvertently leaky) abstraction layers with new semantics to capture the specifics of the domain. Often with either esoteric words attached to supposedly novel patterns, and/or unconventional usage of existing terminology. The promise is to simplify and unify things but as noted, such efforts often have the o…

> inadvertently leaky

I think this is the main problem.

I don't mind layers of abstraction when they work well and their components compose nicely. Like a well-designed programming language. These can actually be quite fun to work with.

Layers of abstraction where the boundaries between that layer and those around it are fuzzy to non-existent and where certain cases magically work and everything else is a janky mess because it was never designed to work are what give me headaches and want to throw my work laptop out the window on a regular basis.

Re: Avoid Mini-Frameworks

#72

Post by lpghatguy »

In my career, I've found that this problem crops up the most when a team is unable to make impactful changes to a system that they depend on. It's so much easier (and requires less collaboration and fewer approvals!) to build an abstraction over some core system than to actually fix the core system, even if fixing the core system is always the better choice.

I was very guilty of this as a young go-getter engineer! Why try to convince another team that something should be fixed if I can just paper over it?

Re: Avoid Mini-Frameworks

#73

Post by andoando »

wouldbecouldbe wrote: post #43
baobun wrote: post #15

Earlier quoted context omitted.

If you look above the unorthodox library/framework distinction, I think the criticism is about birthing new (inadvertently leaky) abstraction layers with new semantics to capture the specifics of the domain. Often with either esoteric words attached to supposedly novel patterns, and/or unconventional usage of existing terminology. The promise is to simplify and unify things but as noted, such efforts often have the o…

Yeah had so many discussion with senior developers in my life to argue for just keeping things simple, but my god they love abstractions. They are clearly always very smart and understand the code base well. Maybe it’s their intelligence wanting to be more utilised or maybe they are bored and trying to over engineer simple problems

But the whole software stack is built on abstractions on abstractions on abstractions. Its just a matter of finding the right ones

Re: Avoid Mini-Frameworks

#74

Post by laike9m »

erkok wrote: post #59

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

Exactly

Re: Avoid Mini-Frameworks

#75

Post by mircerlancerous »

I'm not sure I can accept the findings of this article. It seems to me that all the concerns and issues can be summed up to bad design. A mini framework should be designed to be easy to adapt and extend, and any layer on top should be just as easy to further adapt and extend. That to me is the crux of this, "avoid frameworks that are difficult to adapt and extend".

Re: Avoid Mini-Frameworks

#76

Post by daxfohl »

Yes, this little-known blog post from 2015 with a similar line of thought was one of the most influential of my career: https://tomasp.net/blog/2015/library-frameworks/

The modern variant of this is "platform vs service". At my previous company, it seemed like the only path to promotion was "platform" something something. So every org was in the middle of some way over-budget rewrite of their services as some big bloated platform thing, incompatible with every other team's platform, with less functionality than their old services offered. I don't know why leadership sees all these failures and seems to think "ooh, that's exactly what I want for my team too!" But you can't get a promotion if you're not platformizing.

Re: Avoid Mini-Frameworks

#77

Post by scott_w »

mircerlancerous wrote: post #75

I'm not sure I can accept the findings of this article. It seems to me that all the concerns and issues can be summed up to bad design. A mini framework should be designed to be easy to adapt and extend, and any layer on top should be just as easy to further adapt and extend. That to me is the crux of this, "avoid frameworks that are difficult to adapt and extend".

I feel like “bad design” is too reductive. The article is an attempt to explain why it’s bad. What are the practical problems it introduces?

I think it could go a little further in explaining what I think the root cause of the issue is: the people developing this mini framework do not have the time or focus to turn it into a full framework. Compare to Django, Rails, React who, whatever your opinion, clearly have time and mission to build, test and document a framework for others to use.

The very nature of working for a SaaS company means your true goal is to build shit for your customers. Any internal tooling has to overcome this large hurdle to get the attention it needs to be able to truly thrive. And rightly so.

Re: Avoid Mini-Frameworks

#78

Post by 0xbadcafebee »

This is one of the rare HN thinkpieces that's actually correct. You cannot remove essential complexity. You can shuffle it around, but it never goes away; you will have to deal with it. You can try to hand it off to someone else, like another team. But that actually makes it worse, because there's still some critical piece you depend on that's hidden behind the silo walls.

Rather than trying to hide things to "ease adoption", the correct answer is to educate people. Devs hate learning things. But once they learn the new thing, the pain goes away, and the results are better. The more you try to avoid it, the more problems you create later.

Re: Avoid Mini-Frameworks

#79

Post by willj »

This reminds me a bit of using LLM frameworks like langchain, Haystack, etc., especially if you’re only using them for the chat completions or responses APIs and not doing anything fancy.

Re: Avoid Mini-Frameworks

#80

Post by ozim »

foobarchu wrote: post #67
wouldbecouldbe wrote: post #43

Earlier quoted context omitted.

Yeah had so many discussion with senior developers in my life to argue for just keeping things simple, but my god they love abstractions. They are clearly always very smart and understand the code base well. Maybe it’s their intelligence wanting to be more utilised or maybe they are bored and trying to over engineer simple problems

I would narrow this down further. Programmers (myself guilty) live abstractions they control . It gives them the ability to tweak little things and feel like they've done it in a more maintainable way. Programmers HATE using other people's abstractions, which is why "mini frameworks" tend to tall apart after expanding to teams that don't have control over it. In my experience, this leads to new mini frameworks wrappi…

It is easier to write your own code than to understand someone’s else code.

It would be much better if we get more humble people who get down to work to understand why and how existing code or framework works instead of trying to work around it or simply throwing all away and writing their own code.

Thera are of course some exceptions - but those are like pro athletes - no you are not the one, learn existing code instead of making excuses about some edge cases you ran into so you have to rewrite all from scratch.

Post reply on HN