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

81–90 of 119 posts

Re: Avoid Mini-Frameworks

#81

Post by CharlieDigital » 

    > Start fresh. Don't build a wrapper around the existing framework, build your own from scratch.
I don't know about this one. We have a mini-framework that's kinda GraphQL but not quite. REST-ish, but not quite. Weakly documented and constantly dealing with edge cases. Breaks all sorts of standard OpenAPI tooling because the schema returned is monstrous. Used to cause all sorts of issues with TypeScript and stack recursion. Requires a ton of code -- owned by one guy -- to make the OpenAPI doc generation to work correctly.

I keep thinking "Just use GraphQL" because it's basically GQL at this point...except jankier.

Re: Avoid Mini-Frameworks

#82

Post by skydhash »

ozim wrote: post #80
foobarchu wrote: post #67

Earlier quoted context omitted.

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

This view needs to be balanced. There's a lot of cases where the previous code didn't abstract the domain well, or the domain has changed (mostly at the application level). Fighting the ill-fitted abstraction is a real chore in this case and quickly lead to complex code.

I'm all for aggressive refactoring if it leads to something simpler.

Re: Avoid Mini-Frameworks

#83

Post by lostdog »

lpghatguy wrote: post #72

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

I also think the author is understating how bad the original framework was. I've seen some of these and the "itchy points" are real true problems. The team supporting the framework decides that fixing the pain won't get them promo because it doesn't show up in any metrics, and certainly they won't accept your submitted improvements. Your only choice is to wrap it.

Of course, since their thing is a framework, your wrapper must be a framework too. (Is it possible to wrap a framework into a library?)

The end of the story is even sadder. You work on your replacement and wrapper, and oh no, the framework you are wrapping has problems or slowness because of the framework it depends upon!

Re: Avoid Mini-Frameworks

#84

Post by lostdog »

The right number of frameworks in a company is log10(number of employees). Go over this limit, and everyone needs to learn too many frameworks with too little support, examples, tools, and documentation.

Re: Avoid Mini-Frameworks

#85

Post by baobun »

TOGoS wrote: post #71
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…

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

I concede I had a bit of second thoughts after posting the comment you replied to.

After all, hindsight is 20/20 and at the end of the day a major part of our work is making (appropriate) abstractions. Picking good terminology is sometimes hard. I guess to point out that the message shouldn't be read as "all abstractions bad (stop trying)" but to be more conscious about them and to restrain from piling new "magic" on top of a tower of old apocrypha.

Re: Avoid Mini-Frameworks

#87

Post by baobun »

skydhash wrote: post #82
ozim wrote: post #80

Earlier quoted context omitted.

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

This view needs to be balanced. There's a lot of cases where the previous code didn't abstract the domain well, or the domain has changed (mostly at the application level). Fighting the ill-fitted abstraction is a real chore in this case and quickly lead to complex code. I'm all for aggressive refactoring if it leads to something simpler.

It sounds like you are agreeing - that digging into the existing layers can be a good idea that is often neglected or resisted to a fault. That we should treat existing software less like black boxes.

There are caveats here too of course - forking every single thing and excessive NIH syndrome comes with their own costs and risks.

Re: Avoid Mini-Frameworks

#88

Post by rictic »

vbezhenar wrote: post #22
davnicwil wrote: post #7

Earlier quoted context omitted.

these things are hard, maybe impossible to define. For example I mostly agree with your calls/called definition but you also get self-described libraries like React giving you defined structure and hooks that call your code.

React is 100% framework. They even bring their own DSL. It's absurd to call React library. Library is something that can be pulled off project and replaced with something else. There's no non-trivial project where replacing React with anything would be possible. Every React web app is built around React.

Agree, for modern React with hooks. A React component looks like a normal function, only you can't call it. Only React can call it, in order to set up its hooks state.

Re: Avoid Mini-Frameworks

#89

Post by boxed »

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…

Let me introduce you to development on Apple platforms, where "framework" is literally the term for all libraries since the NeXT days.

imo it's better to just figure out the definition in the current context, than try to force your own definition unto others. You can't anyway.

Re: Avoid Mini-Frameworks

#90

Post by boxed »

narvidas wrote: post #6

As a rule of thumb, "magic" is a code smell. Libraries should be preferred over frameworks whenever possible. A toolbelt of small utility-like composables are often easier to maintain and reason about. This results in added explicitness (i.e. less magic, fewer surprises). Personal experience shows that the immediate efficiency gains of a framework often get diminished in the face of all the hacks people introduce lat…

> Libraries should be preferred over frameworks whenever possible

You have to define the terms.

It's not clear how your statement above isn't semantically equivalent to "prefer good over bad" or something otherwise nonsensical.

Post reply on HN