Frameworks vs libs + from scratch

General Prog (Archived)
,
1

Good read on twitter.

I feel like a lot of popular frameworks could be completely replaced with better 
docs about how to build things with platform features and ala-carte libraries.
how it usually shakes down:
"I want to do X."
"Framework Y does X."
"I must learn framework Y to do X."
but there are few resources available for how to do X outside of Y, even when 
Y is largely superfluous this documentation problem is compounded by how
 popular projects can bring in resources to either pay people to work on docs or
 somebody can otherwise build their career around a big bundle of semi-related
 features called Y the downside of this phenomenon is when you have a problem
 that doesn't quite agree with the assumptions of the core framework, you'll spend 
a huge amount of time fighting against those assumptions. often many times more
 effort than writing something from scratch.
and the discourse around "from scratch" is that it's just about always more wasteful, 
but I haven't found that to be the case. and when you use appropriate decoupled 
libraries (that you can easily throw away or swap out), it's no more wasteful than 
using a big framework.
with the upside that you can incrementally refactor the stack as your assumptions 
change because the components are relatively less coupled. It's a bit of work to set
 things up this way, but it's not a huge amount of effort or anything.
the main hurdle is convincing other people to take this more modular approach,
 which is very hard to do. partly because something with slick marketing and lots 
of usage is considered "safe" even if you know from experience you're going to 
encounter huge maintainence burdens later
plus the paternalism of the framing in technology marketing about "teams" along 
with the desire to hire around commodity skills and not wanting to spend any 
time on training
because this is such a pervasive phenomenon, building things from scratch
 (+ala-carte modules) is a less common skill, which shapes perceptions and 
makes the status quo stick. but I don't think it's an intrinsically more or less 
difficult approach, just different.
5 Likes
2

It’s like that in C++ for sure. The Standard Library can do a rather amazing amount of generic things that most people don’t know about. Like the number of libraries that define something like fold_left or reduce when std::accumulate exists is just weird… o.O

Though admittedly C++ has some very odd naming conventions, like the above accumulate being reduce… But better docs would fix that! ^.^;

Or even the recent networking standard is astoundingly awesome! Or Filesystem!

2 Likes
3

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”
Quote by Edsger Wybe Dijkstra: “Simplicity is a great virtue but it requires ha...”

This makes me think about the last part of this quote I found recently.

4 Likes
4

The quote comes from https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD896.html, you can find lots of good reads in the EWD archive.

3 Likes
5

Maybe the framework in the future should be build to be flexible enough (framework from scratch libs) to change their parts to fit our assumption but it seem hard. I think we should categorize framework first into categories maybe better (one for E-Commercial, one for CMS…); also internal parts should be replaced easily by other libs.

6

The one distinction between a framework and a library, is the direction of control: Your code calls a library, whereas your code is called by a framework. This inherently means that frameworks are a lot more difficult (if at all possible) to combine; they are not proverbial lego blocks.

So, unless there really is no way around having a feature provided in a way that can only really be exposed by using a framework, it makes a lot more sense to use libraries.

7 Likes