Write Libraries, Not Frameworks

https://www.brandons.me/blog/libraries-not-frameworks

by brundolf • 6 years ago

1044 327 6 years ago

brandons.me

duxup3• 6 years ago

Well that just makes me want to know what his week was like / brought him to that point.

Not that I can't imagine, I just want to hear about the train wreck.

brundolf11• 6 years ago

Wrestling with an overly-magical and under-supported framework. I won't name names because I don't wish to drag anyone through the mud.

duxup3• 6 years ago

Totally understandable.

You hit another good word there, magic. Frameworks IMO get to be magical or at least extra magical ... but with that extra magic comes responsibility (documentation, support, etc).

gitgud2• 6 years ago

"I won't name names because I don't wish to drag anyone through the mud."

If it's a large framework like Angular they can take it...

JMTQp8lwXL3• 6 years ago

Do you introduce a domain-specific language? You're now responsible for part of the build chain, and for editor integration.
Now, if there's a major organization backing the framework, maybe the calculus works out. Google can back Angular...

In my experience, even large orgs don't necessarily have the capacity for building out full-featured editor integration and build tools. Google has a great team managing Angular and it still has no tool for performing codeshifts. The editor integration to date still leaves much to be desired.

With the number of years and man-hours dedicated to this point, I'd imagine these thing would've happened by now, or they may not happen at all. Lately, Angular's push has to been to 'make it faster', which helps with developer productivity, but not much movement on the developer experience (better editor integration) part.

Agree with the thesis, but it's still understated how expensive creating your own DSL is.

brundolf11• 6 years ago

Yeah, the outcomes vary for sure. For a counter-example you can look to JSX which has excellent support in most major editors, but it's definitely the exception to the norm.

JMTQp8lwXL3• 6 years ago

Agreed, the size and scope of the DSL will impact the amount of man-hours necessary for developer experience related work. Resourcing that effort is a separate concern, but one that should be considered for the DSL's viability.

JSX, being a sugared syntax for the React.createElement API, likely doesn't need a team of 20 for editor integration, whereas Angular templating language has more to it: pipes, directives (shorthand and non-shorthand syntax), property bindings, expressions, etc -- and templates need to be evaluated in context of their corresponding TypeScript Component.

vbezhenar3• 6 years ago

React is an immensely popular library. You can't really expect that some random DSL would receive similar amount of attention.

vbezhenar3• 6 years ago

One option is using XML with complicated enough XML Schema. Good editors like Intellij Idea support editing such an XML and provide good autocompletion, on-the-fly validation. XML libraries would parse that XML into tree and validate it against schema without any additional effort.

While XML certainly deserves some blame, the amount of tooling around it is unmatched.

megameter• 6 years ago

XML's main limitation derives from its base primitives: Strings and hierarchies of ordered strings labelled with strings. Starting from that premise adds a great degree of schematic overhead to convey semantics, which tends to overflow into syntactical boilerplate.

Traditional parsers start from one string and evaluate that a character at a time. JSON starts from a few JavaScript primitives. SQL has primitives that vary with the engine you're using. These are other points on the spectrum that are appealing in the details - a plaintext string is accessible to all text editors and simple string processing tools. JSON covers a selection of common data primitives. And SQL has a grip on automatic constraint enforcement, which helps in defining user types with high data integrity.

If I had to pick one that's really going underused, SQL would be it. A string source file could be dissected into a number of tables and edited like any other CRUD system, then re-serialized as a string. That we don't do it this way is more an accident of our current beliefs about which means of implementation are appropriate for various tasks - queries on relational data are "slow" compared to bodging buffers and recursing through DAGs. But if we want nice developer tools we should probably start acting like data integrity is more important. Slopping dependencies around the file system and relying on a separate bespoken tool chain to reconstruct their relationships as part of a built artifact is a thing we ought to outgrow at some point, but it's also so intrinsically accepted that the paradigm is hard to escape.

userbinator2• 6 years ago

While XML certainly deserves some blame, the amount of tooling around it is unmatched

That tooling was created as a result of XML being difficult to use otherwise, not the other way around; in much the same way that some languages like Java seem to depend on an IDE to be even usable, far more than others.

rhengles3• 6 years ago

I think all the major frontend frameworks are overly complex beasts, they're too big and can't be used as libraries - for example, you can't replace some functionality out of the box without making a fork. I also didn't find any other reactive frontend framework that could fill this requirement, so I decided to write my own. [0]

It is the simplest thing I could conceive (to build, not to use - I plan to provide more convenience, but the selling point is the ability to customize everything.) It's template based and without a virtual dom - during render, each variable used will be listened and when it changes, the element that uses it is updated directly, without recomparing the whole tree. It's still in progress.

[0] https://github.com/arijs/ari

brundolf11• 6 years ago

You can use React like a library. You can even go without JSX, though nobody really does. React is also kind of odd because it includes a bunch of other stuff like hooks, even though most people bring their own state management to it. But it's definitely the least-framework-y of all the major frameworks.

JMTQp8lwXL3• 6 years ago

Have you tried React? It feels fairly library-esque to me. You can be useful in as little as two lines of code:

const elem = React.createElement('div', null, 'Hello World');

ReactDOM.render(elem, document.querySelector('body'));

It's 35.9kB gzipped, although "too big" is subjective. I may be unimaginative, but over my last 5 years or so with it, there isn't much I've wanted to change. As a library consumer, I don't personally mind if a VDOM is used or not, so long as performance is good enough not to ship a noticeably lagging UI to my users. Having experienced both React and Angular --one uses VDOM, the other not-- I haven't found this implementation detail to meaningfully impact performance, but I spent my time building straightforward CRUD apps.

I would consider sharing an example to Ari of something that's hard to do in React/Vue/Angular, and how it's made simple with AriJS. That might help elucidate where it shines, and the key problem being solved.

ninjis• 6 years ago

Off the cuff, that sounds a lot like Knockout.

https://knockoutjs.com/

dwheeler• 6 years ago

I was expecting a one-sided rant. Instead, I got a reasoned distinction between two different approaches, the trade-offs of each, and a discussion about the cases where one approach (frameworks) can be beneficial but also identifying the added risks of going that route. I agree with the conclusion, and why.

I wish even more people were willing to write down a discussion of alternatives and their trade-offs. Instead of "Google does it this way, so it's obviously the way everyone should do it"... a reasoned discussion of the pros and cons. Good to see.

aledalgrande• 6 years ago

I like to use this approach with all team decisions. It is how you get real buy in from people, because after seeing pros and cons, they chose A instead of B.

kevsim4• 6 years ago

Agreed. In one team I managed, we artificially created "red teams" to take opposing view points if we were getting into traps with too much group think. Leaves the teams with confidence in their choices and real buy in, as you said.

travisjungroth• 6 years ago

Yeah, I was expecting something a lot less nuanced after that warning at the beginning. I both love using full-featured frameworks (I reach for Django over Flask) and totally agree with the article.

This was the blog equivalent of someone sincerely saying “Pardon my language, but gosh darn it that man is a jerk!”

leetrout2• 6 years ago

Flask always looks better at the start but Django always gets me further, faster, safer (protecting me of my mistakes).

I’ve spent the past 4 months learning rails and it makes me realize how much I didn’t appreciate about Django and its magic compared to rails magic.

userbinator2• 6 years ago

A framework, usually, must predict ahead of time every kind of thing a user of it might need to do within its walls.

The one thing not mentioned in the article is that the above line of thinking is almost guaranteed to lead to an insane level of abstraction, which was parodied in this classic article from nearly 15 years ago:

http://web.archive.org/web/20141018110445/http://discuss.joe...

(Sadly, that site is gone, but the memories live on...)

Addendum: to see this in practice, one needs to look no farther than Spring, the famous Java framework:

https://docs.spring.io/spring-framework/docs/current/javadoc...

wetmore• 6 years ago

The repeated joke about killing your ex-girlfriend did not age well.

oh_sigh• 6 years ago

I doubt it landed well in the early 2000s either

gherig4• 6 years ago

What's wrong with it?

ianmcgowan• 6 years ago

I think the same thing every time reading this otherwise-excellent post. I don't think we should attempt to erase history, but it is super jarring, at least for me. Was it ever actually funny?

ngngngng2• 6 years ago

I hope, one day, that we look back on the "woke" over-analysis of the last few years and say "That didn't age well."

setzer22• 6 years ago

I don't think that's ever been funny. What's that, standup comedy for psychos?

It's that kind of joke that at best will make you look like a moron and ruin the mood... It's especially sad since the post is otherwise interesting.

overgard2• 6 years ago

Pretty sure murder was taboo back then also. The only difference is people are much more eager to virtue signal these days by finding offence wherever they can..

Edit: to explain my position a bit, what I observe with people that are easily offended is that they can't seem to separate what the character is saying from what the overall piece is saying.

Just for example, think of The Office. Michael Scott says a lot of horribly sexist and homophobic stuff right? And we as the audience frequently laugh at it. But I don't think anyone in their right mind would say that The Office is sexist or that the audience that watches it is. Because we understand that the humor is that Michael Scott is saying something really inappropriate but he's also clueless and naive.

In this piece, the salesman character makes a dark joke. That is part of the character of the salesman, along with other aspects that are revealed. If you personally don't find it funny -- maybe you just don't like dark humor -- hey, I won't tell you you're wrong, humor is always subjective, but I don't see anything offensive about this. It's not advocating for violence it's simply adding a weird dark personality quirk to an already very weird character.

What I find with the easily offended crowd is all they look for is "bad thing involving a protected group in here? OFFENSIVE!" and completely ignore the actual context of everything else. It'd be like if you took a "that's what she said!" joke from The Office and completely ignored the context of Michael Scott's character.

avl999• 6 years ago

The interesting thing is that Joel is actually gay so he probably specifically went out of his way to not offend the sensibilities of his readers and the culture at large at that time by using "girlfried" as opposed to "partner".

Moreover dark humor has its place. Indeed 2 of the biggest comedies of the last 20 years used exactly this kind of humor (Seinfeld and The Office). Even to this day some of the most acclaimed comedies have humor in this vein (Veep and Curb Your Enthusiasm for eg).

phkahler• 6 years ago

That was good. I still use the Joel Test to evaluate companies.

thomk2• 6 years ago

Did you ever see his YouTube channel? It has exactly one video and it is awesome: https://www.youtube.com/channel/UC65NUFfqjWn3y02kYYl9nSQ

leeoniya• 6 years ago

https://projects.haykranen.nl/java/

Koshkin• 6 years ago

  getInstrumentableClassLoader()

    Return a ClassLoader that supports instrumentation
    through AspectJ-style load-time weaving based on 
    user-defined ClassFileTransformers.

Oh man... I admire the people who have invented this. But at the same time I feel sorry for those who have to use this in order to earn their living.

thomk2• 6 years ago

Stuff like that always makes me feel like someone has turned off their logical reasoning and they are just basically creating code that fills in some personal mental gap that somehow 'completes the set' of the things they are working on at the moment.

zerkten• 6 years ago

The people that use Spring love it, well, at least they did when I was last working with them. They also loved talking about patterns, often didn't have enough traffic to stress the systems built on these relatively heavy object hierarchies, and were relatively comfortable (the only competition was the other half of the company using .NET.)

chii2• 6 years ago

It does have it's place. Aspect oriented programming will allow you to write, for example, logging code that are very configurable. It allows you to remove the concern of logging from your classes completely.

In fact, any cross-cutting concerns - like transactions, can be done this way. So you can write code that don't care about transactions, but behind the scenes, it is all within a single transaction, and transaction errors are handled centrally.

It adds runtime costs of course. And the more you add this way, the more complicated it becomes. And certainly can be abused.

watwut• 6 years ago

Spring is not hard to use. It is popular because it is comfortable.

einpoklum2• 6 years ago

Am I a weird person if that one doesn't seem very egregious to me?

The class loader is an important entity for a Java app. And you can have more than one (although this is advanced voodoo already). So, an instrumented class loader.

blackrock• 6 years ago

This reads like a circular definition.

zests• 6 years ago

Most of those crazy looking Spring classes aren't used by users and are just used internally by the framework developers. Of all the complaints people have about Spring, I've never heard "these classes are too abstract" or "these names are too obtuse."

There was maybe one instance where I had to deal with obtuseness like that. Definitely not the norm.

inopinatus2• 6 years ago

After X11 and Spring, the Maximum Abstraction Task Force shifted to focus on infrastructure, which is why your Java Virtual Machine processes are now running as a uniquely allocated user ID in a container scheduled by a control plane on a pool of OS instances separated by the hypervisor service of a dynamically sized cloud placement group.

tasogare2• 6 years ago

It still shows up in 2000 lines of stack traces when an exception occurs. For comparison a similar stack traces in Asp.net Core is 20 lines...

monadic2• 6 years ago

You might as well say “i don’t believe sledgehammers make good hammers”.

sidpatil• 6 years ago

"If you wish to make an apple pie from scratch, you must first invent the universe." —Carl Sagan

stiray• 6 years ago

... but at the end you get perfect apple pie that is exactly tailored to the ecosystem, doesnt suffer from overdesign, bloat, is baked to perfection and its taste is from heaven.

The only question is if you can afford hiring a few gods for the task or you are rather satisfied with whatever falls off a truck and in reality is completely uncapable of inveting universe (or even capable of baking).

At the end the customers digestive problems are those that do matter. And you can get sued for food poisoning.

I personally love apple pies and am just not satisfied with plastic taste of supermarket frozen, microwave oven heated "products".

“When you want to hurry something, that means you no longer care about it and want to get on to other things.”

― Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance

niftich2• 6 years ago

Spring class names are the stuff of legend, but most of those classes you wouldn't deliberately use in your application. They're there so Spring can layer up its own functionality feature by feature. The only problematic part about this is when these class names leak into error messages, and the level of indirection becomes difficult to follow.

The way you use the core inversion-of-control framework people often just call "Spring" is you take your homegrown, doesn't-depend-on-Spring business logic, you make a config file, and if you're not executing it a servlet container, you make one entry-point class to start it all up [1].

There other projects under the Spring umbrella, and some of them are meant to be called from your code. Like Spring JDBC for database access, whose framework-like nature is apparent, yet in terms of its usage pattern, it resembles a library [2].

[1] https://docs.spring.io/spring/docs/current/spring-framework-... [2] https://docs.spring.io/spring/docs/current/spring-framework-...

pscanf2• 6 years ago

I agree in theory, but in practice I've found it very hard to keep Spring (Boot) out of my code.

Part of the blame I think falls on Spring's DI container, which is "too good". It makes it easy to pull in any bean, even the wrong one, which means developers have to be disciplined managing how beans depend on each other, and you end up with controllers returning entities. Of course, any codebase turns into a mess if you're not disciplined, but my impression is that developers tend to be less careful when working within the confines of a framework like Spring because it gives them the false sense that they can do no wrong.

Recently I started a side project with Spring Boot (after all I like the framework), trying to organise it following Uncle Bob's Clean Architecture approach, which aims to isolate the core business logic of an app from its implementation details like database code and external interfaces. The core turned out pretty well isolated, but the rest is all Spring. Database access? Spring Data. External interface? Spring MVC. Communication with external services? Spring RestTemplate. I'm not saying it's bad, it's actually awfully convenient, but it's not so easy to swap out - say - Spring MVC for http4k, so you end up with Spring being everywhere. Which again, not a bad thing, just something to consider.

nickbauman• 6 years ago

DI/IoC is just another way of expressing global variables. The global variables exist because of the constraint of class-orientation getting in the way, among other things. Spring exists because of the relative weakness of the Java language. You won't see this kind of technology emerging in more powerful languages.

diehunde• 6 years ago

I prefer to read articles like the one you linked. They feel honest. If you don't like something you don't have to say "but yeah for this specific case it's fine, or if google is behind then it's alright..." just to be more correct and avoid comments from haters. I don't mind if you are a junior dev or Joel Spolsky. You should always write with confidence, especially when it's an article about an opinion.

juped2• 6 years ago

I kinda want to make a Spring class name generator now.

Qerub• 6 years ago

Somebody already did that for us others to enjoy: https://github.com/achin/boss-work-manager-configuration, running at http://java.metagno.me/

edem2• 6 years ago

Spring is not a good example. If you're a seasoned Java developer you look at an `AbstractDestinationResolvingMessageTemplate` and you just know what it does. I'm not kidding.

Spring used to be a bad example yes, but not anymore. They really put the thought and work into fixing its design. Right now I can write an app __completely__ independent of Spring. In fact that's what I'm usually doing. You can do Clean Architecture with Spring now. Please keep your facts straight.

oreally3• 6 years ago

If you're a seasoned Java developer you look at an `AbstractDestinationResolvingMessageTemplate` and you just know what it does. I'm not kidding.

This claim is so bad.

You could look at the name AbstractDestinationResolvingMessageTemplate and the useful information they would be gaining is that it's a message template. They would still not know how to use it; they'd still have to do an additional step like checking the documentation on its usage etc. The amount of useful information to text is small and it doesnt help.

mping4• 6 years ago

I remember the Rails people making fun of the Spring stacktraces vs the Rails one (being much shorter). Guess what, a couple of years later Rails has the same layers of abstraction

finnthehuman2• 6 years ago

It was always an argument about fashion. It just wasn't in fashion to admit that out loud at the time.

The conclusion was "the rails-not-java club is best" and then everyone worked backwards to find believable reasons why. At the impromptu pitch meetings "minimalism vs. complexity" took off.

Now that the rails club is out of fashion and the k8 club is in. Well, we'll invent reasons that over-engineering is better than deployment automation that "just" sticks a .jar in a .deb and apt-get upgrades a handful of non-virtualized servers colocated at a local datacenter.

sixhobbits• 6 years ago

I have a vague memory of a similar parody article which I've never been able to find again. IIRC it was in Ruby and he imported all libraries into a "god" object that could do absolutely anything.

Anyone know what I mean?

arethuza• 6 years ago

My comment in that discussion from ~15 years ago was based on experiences with a project that I "inherited" - 30,000 Java classes and interfaces, 20+ layers of abstraction, team of 30+ people working for a long time. And most importantly, it didn't actually work!

I actually "finished" it to the point of a working system for the customer with real customers in about 5 weeks by ignoring most of what they had done - required a handful of classes and JSPs. Probably distinctly under-architected but it worked and was built on for a number of years after.

gombosg• 6 years ago

The problem with over-engineered projects... our team inherited a project that was designed by some architects in an ivory tower and implemented by some other engineers.

It was quite complex (message queues, multi-threading, async etc.) so that it would be 'scalable' yet crushed under the slightest load, customers were experiencing delays during peak hours.

We removed about a quarter of the code (some intermittent queues & components), nothing changed in terms of functionality. Now we're removing more code and switching over to less complex data structures to fix the delays.

Maybe a complete rewrite would have been better after all, who knows.

I'm not a very experienced developer. I like to ship stuff and get projects done in reasonable time and a "YAGNI" attitude. Let's just rewrite stuff and introduce more abstractions when it actually hurts and a refactor is in scope.

On the other hand, I see a tendency that if you give projects (it could be a greenfield project or some maintenance) to a team of, say, 6 developers, then they will just 'create work' for themselves, filling up the todo list with items which may lead to an over-engineered project that could have been easily be done by 3 people within the same timeframe.

If you have some good reads/stories on this topic, patterns to watch for, I'd appreciate if you shared them.

bane2• 6 years ago

Similar experience here. About 6 months ago I inherited a team of 30 that had spent 4 years building some monstrous microservice "thing" that didn't work and never seemed to build reliably and barely worked even if it could be deployed. Lots and lots of late nights trying to "deploy to testing" and wasted weekends restarting things.

I stopped the work, broke the team up (and let a few of them go), re-assigned the goals of the project to 3 people who, working half-time, from scratch, and in Python, rebuilt the entire thing in 3 months, delivered it and it worked (and continues to work). "Builds" are now an scp to a VM, and a restart of a flask application.

My wife recalls a similar experience where a complex application she worked on (and ran reliably on very little infrastructure and with an entire team of 4), and serviced thousands of simultaneous users, was replaced (when a new CTO came in) by a giant, consultant driven Java project that required approximately 6x the infrastructure, 3x the staff to keep it going, and at launch could only serve 9 to 12 users at once. It was a debacle. But sunk cost fallacy forced her company to throw millions of dollars of consultants at it until it achieved some minimal level of barely available service. She and her boss left around that time.

She heard that a couple years later the CTO was let go, the consultants fired and it was all replaced by a team of 5 rewriting it all again from scratch (in Java) but like you also without all the architecture barf dropped in from orbit, and immediately went back to servicing the thousands of users again.

I'm convinced that this is the fault of some kind of consultant industry that seems to infest enterprise software circles that is really only good at inventing ways of designing systems that require more of their services, but never seem to actually deliver working systems.

jonathanstrange• 6 years ago

I wouldn't mind frameworks if they actually had what they claim to offer. Nowadays so many frameworks don't even deliver, they have those nicely looking webpages and come with advertisement after advertisement of their features (even if they aren't sold!), and then when you look closely at the source code or API docs, half of those features are vaporware.

This is more than infuriating, it can actually cost you a lot of time if you're not careful about evaluating the framework.

commandlinefan2• 6 years ago

I can’t even figure out what Spring is claiming to offer. The only benefit of Spring is that you can move what ought to be compile-time exceptions into the runtime.

a13692099932• 6 years ago

http://web.archive.org/web/20141018110445/http://discuss.joe...

"Right. Fuck you. Fuck your lack of hammers. Fuck your factory factory factories. And fuck your store. If you decide to pull your head out of your ass, I'll be over here, duct-taping a rock to a stick so I can actually hammer a actual nail into a actual piece of wood."

I'm reminded of the HGttG scene regarding the display department.

a13692099932• 6 years ago

duct-taping a rock to a stick so I can actually hammer a actual nail into a actual piece of wood.

Note to anyone actually trying this: if you have a drill, drilling a hole in a piece of wood and sticking the stick (preferably dowel) through works better; if you need more weight, attach the rock to one side of the head, and a coin or other patch of metal to the other.

Also (if you have the space for it): adopt a lathe/smelter/set of chemical-refining glassware/etc today!

d0m• 6 years ago

IMHO, the framework vs library debate is similar to the inheritance vs composition.

Inheritance: You must predict how people will use your class. Make a mistake and they're screwed and need to resort to all kinds of hack. (Like frameworks)

Composition: People will use your class if it fits their needs. They can easily wrap the code, tweak or simply discard it. (Like libraries)

tynpeddler• 6 years ago

This was eerie to read. I've made some of the exact same points, word for word to others. It would be fascinating to do a survey/quiz for developers to see who's tempted to write tiny custom frameworks, and who knows better. This rant would also make a good first day read in an enterprise software engineering class.

Thinking over my career, I've seen a lot of libraries and tools out there that are really trying to be tiny frameworks. One example is [ngOptions](https://docs.angularjs.org/api/ng/directive/ngOptions) from angular 1. As a web developer, you're already using javascript, html and css at the very minimum. Yet ngOptions went ahead and created a new configuration language just for rendering a drop down. It was ok for simple stuff, but it rarely felt right for more complex widgets.

I think java bean mappers kind of fall into this trap as well. On the surface, bean mappers look like libraries. But once you start customizing the mappings, you see that each library has created a complex configuration language. The problem is that configuring custom mappings takes about the same amount of space as creating a tiny method to manage a specific field mapping. The difference is that I have to read a bunch of documentation to understand the bean mapper, but I already know how to write java.

At the end of the day, library vs framework boils down to imperative vs declarative. Libraries and imperative languages are composable and relatively easy to understand but can sometimes require a lot of work to accomplish difficult tasks. Frameworks and declarative languages require a lot of work to get right and are really only appropriate for problems that are well understood or formally described. They take on a tremendous amount of responsibility, but when done well they are incredibly valuable. There's a reason the world runs on SQL.

brundolf11• 6 years ago

The difference is that I have to read a bunch of documentation to understand the bean mapper, but I already know how to write java.

I think this is spot-on, and sums up one of my points in a way that's a bit closer to the heart of the issue. However:

At the end of the day, library vs framework boils down to imperative vs declarative.

I don't think this is true at all. There's a correlation, maybe. Particularly in languages like Java that don't have great support for declarative stuff themselves, frameworks like Spring have served as a kind of workaround for that shortcoming. But if anything I would say pure functions lend themselves even more to library-thinking than imperative code does.

ravenstine• 6 years ago

Just write whatever you want. I cite the following rule:

Given enough time, the best code will inevitably be perceived as crap. – Ravenstine's Law

OrgNet• 6 years ago

All code has bugs. - me (and everyone else)

ChrisMarshallNY3• 6 years ago

I agree.

However, I program for Apple devices, so my libraries are called "Frameworks."

I'd say that we should call them "Modules," instead. That probably covers all the bases.

fphilipe• 6 years ago

so my libraries are called "Frameworks."

Not if you make them static libraries.

ChrisMarshallNY3• 6 years ago

Tru, dat, but static libraries are so “five minutes ago.”

daxfohl• 6 years ago

Same thing from years ago: http://tomasp.net/blog/2015/library-frameworks/

syspec• 6 years ago

The best distinction I've read is:

When something is a library, your code calls functions on it.

When something is a framework, it calls functions on your code

brundolf11• 6 years ago

I think that can be more precisely defined as Inversion of Control: https://en.m.wikipedia.org/wiki/Inversion_of_control

which has a strong association with "framework" thinking, but I think it's still useful to treat them as distinct concepts

galaxyLogic• 6 years ago

That seems like the only precise definition I've seen for what is a framework.

From this perspective it would be interesting to see some rationale for why libraries not frameworks.

I would say that libraries are not the opposite of frameworks at all. You can have a library which contains a set of framework-classes.

uryga• 6 years ago

it's a rough rule of thumb at best though – higher-order-functions or other things that take a callback blur the line a lot (IoC, what a sibling comment said). or say a library has an event-loop, or maybe does networking and you only provide some handlers – would that make it a framework?

i guess it's about frameworks being "the main thing happening". i.e. a framework controls the whole program's execution, occasionally yielding control to your code. which is a bit wordier to be sure :)

snorremd• 6 years ago

I agree. Otherwise every library for languages with first class functions and callbacks would be frameworks.

goto11• 6 years ago

The article also makes a good point that there is no hard line between library and framework, it is spectrum.

grecy• 6 years ago

I'd add to that and say

When something is a framework, it calls functions on your code AND it does a lot of the heavy lifting for you.

I studied Frameworks in my Software Engineering degree, but really had no appreciation for them until developing large software in WebObjects.

Until you've extensively used a well-written Framework, libraries seem great. After, you realize a library just helps you here and there, but a Framework is so much more.

gitgud2• 6 years ago

Frameworks compose libraries for you, this is not always a good thing...

revskill• 6 years ago

Framework often kill themselves because when there's new innovation or paradigm, it's hard to change. (Angular 1 is example).

So there'll be a rewrite or a complete new framework born. But a library will live forever whatever technology changed or not.

But framework is useful to integrate or test out many libraries into one to build something fast. Think it's like a boilerplate to reuse.

TLDR: Library is the primitive to build upon. Framework is just one use of libraries.

hyperpape3• 6 years ago

I’m pretty sympathetic to this, as my experience with Spring has been “it’s convenient when it works, but awful to deal with when it’s not working”.

However, I think to push this line of thought, it would help if we had examples of how to build significant applications without a framework. Ideally someone could provide a walkthrough of an app like that. Unfortunately I can’t volunteer myself: the last time I built without a framework, it was a mess.

jvanderbot• 6 years ago

If you're trying to build an entire app, you are not building a library. An app uses libraries and frameworks to stitch them together. A library brings functions, and a framework brings connectivity and logical flows. An app without a framework is an app with a hidden framework. An app without libraries is an app with a hidden framework and monolithic, catch-all, single-purpose library.

hyperpape3• 6 years ago

So then turn the question on its head. What are the examples of frameworks that should have been libraries?

It’s not that I disagree with you, necessarily. I’m just trying to extract a more specific claim from this post.

brundolf11• 6 years ago

I think you're right that people - even (especially?) those who use frameworks - should know how the sausage gets made. Though it's hard for me to address your specific wish since the answer varies widely depending on what kind of "app" we're talking about

hyperpape3• 6 years ago

Any kind of app where you might reach for a framework. The point is to have a reasonable contrast between "here's how you do it with a framework, here's how you do it without one". I think size is important, as I can imagine that the benefits of a framework might show when there's more to do.

Personally I'd think of a web app, since this is one place the discussion comes up a lot, but I don't know that's a requirement (I also think the idea that you can build command line tools out of a handful of libraries with no framework is pretty widely accepted).

jmchuster4• 6 years ago

I think Dropwizard is a great alternative to Spring. If you want to draw a spectrum between framework and "curated libraries + best practices", it's much closer to the latter. But then I guess that also depends on how much you consider the libraries it uses like guice and jndi to be "mini-frameworks". Ultimately, all that matters is how easy it makes your job, in both the best case and worst case scenarios, so I'll leave that to your own judgement as an engineer.

garethjrowlands• 6 years ago

Dropwizard was amazing when it came out and is still much better than deploying to Tomcat, say. But it's showing its age and I'd consider it too frameworky these days. My current currently preference is http4k, which is more library and less framework. Admittedly, that's Kotlin and thus not a fair comparison, but then, newer things can take advantage of other newer things.

Ididntdothis• 6 years ago

Good article. A while ago I worked a little with Angular and I thought to myself that probably 80% of it could easily be in a reusable library instead of tying it to the framework.

That way you could write a lightweight framework with a powerful library under it.

tanilama4• 6 years ago

I think the key difference is that frameworks usually hijack your control flow, while library are not.

But is framework necessarily bad or inferior to library? I would like to present React as an example. React heavily regulates the control flow for its developer, leaving several specific hooks to allow you control the timing when your code would trigger.

But React is an excellent piece of software. And assuming in a perfect world, if everything we interact are more or less functional or self-containing, then timing doesn't really matter, and uncertainty is thus controlled.

In the end, the lesson here seems to me is, making good frameworks are much harder than making good libraries. For libraries, you need to make sure the building blocks are solid, but for frameworks you are defining a whole world for people to visit.

khant2021• 6 years ago

You are absolutely right sir 100% every one of starts doing like this he will be more successful

lhorie3• 6 years ago

I would argue React is actually a great example why the article title is on point.

Idiomatic React has completely changed several times over the course of a few years. This shows that it did not anticipate people's needs well enough. And React is in the fairly enviable position of receiving corporate backing in the tune of a million dollars per year.

Now consider tools like Redis or Postgresql. You can interface with them from just about any language and you can go years without your usage of them ever becoming unidiomatic.

tanilama4• 6 years ago

DBs, IMO, are neither library or frameworks. They have their own DSL after all, which is close to programming languages.

Programming languages are hard to categorize as either library or framework. They are libraries with full set of control flow primitives or framework that doesn't assume a particular flow at all.

hesarenu• 6 years ago

Could you point out which reactjs code has completely changed? I believe reactjs has remained the same, there are deprecations, hooks etc but basic premise is same.

strogonoff2• 6 years ago

This thread is peculiar.

Framework <-> library is a spectrum, of course, but as an obvious indicator of React’s location on that spectrum—you can feasibly use it inside, say, an Angular app to render a particular third-party widget. At its core, React is a super-efficient unopinionated render() and tools for constructing its input. On its landing page it establishes right away (IMO, correctly) that it’s a library.

The reverse, bringing a single Angular component into an otherwise React-based webapp, is basically an oxymoron. Angular will generate e2e test scaffolding for your entire project, prescribe where to query data, expect you to follow a particular file layout in your codebase, and pull in enough machinery to rule out any auxiliary uses.

tchaffee2• 6 years ago

With Postgres that's because SQL has been a standard for decades now. And with idiomatic React the changes were largely not because of what you claim: not anticipating needs well enough. The changes in what is idiomatic were largely around discovering better ways of doing things, along with JavaScript itself changing. You can still write a React component using idioms from five years ago and it's still easy to read the code. React is very focused, and very simple. The main motivation for moving to the newer idioms is that you can make the code even shorter and more readable. It seems to me that they anticipated the need to keep up with the JavaScript language evolving quite well.

Frost1x• 6 years ago

I think the key difference is that frameworks usually hijack your control flow, while library are not.

Which is what should be expected.

The point of a framework is to not only provide higher level abstractions to rapidly put together a certain type of application but to also provide a certain approach or set of approaches (a "framework") to follow as a guide during the process.

This means some generalization should exist but if a framework is too abstract its really no longer a framework... it's a library.

A library is supposed to simply provide useful utilities/lego blocks to assemble however you want and not necessarily give specific guidance or patterns.

Certain common patterns of usage may arrive as a sort of emergent property based on fundamental library choices/structure but it's overall pretty flexible.

einpoklum2• 6 years ago

But is framework necessarily bad or inferior to library?

The point is that more people, projects and even frameworks can use the library you write. If you write a framework, people have to drop whatever it is they're using and go with your framework. That's bad, unless your framework is the one to trump them all, which it probably isn't.

skohan2• 6 years ago

I think React is somewhat of a special case, because a lot of what makes React good is that it mitigates a lot of the issues which make web painful to deal with: "the browser" is this highly inconsistent target, and Javascript doesn't have built-in facilities for modularizing code, and React gives you a sensible way to get consisten behavior and implement reusable components in this type of environment.

Another way to put it is that for web you're already pretty heavily invested in the "framework" of HTML/CSS/JS wheather you like it or not. React is essentially just choosing another baseline framework to replace it, not adding a framework where none exists.

bch• 6 years ago

I don’t recall from where I heard it, but I’ve heard libraries described as proper tools where you get to take their facilities and (to an extent) use them as you wish, versus frameworks which are an old text adventure game; you have to work within the constraints (and hopefully the frame work is both sane and well documented, otherwise “You are standing in an open field west of a white house, with a boarded front door.”)

thom6• 6 years ago

This has generally been the approach in the Clojure community. Of course, lacking standard frameworks, every library gets abandoned every few years so you have to learn a new even cleverer one. And wherever you might benefit from a group of very cohesive abstractions (e.g. in data science) you’re instead left with a bunch of random incompatible things (that again, will be abandoned in due course).

simongray5• 6 years ago

What are you talking about? Every Clojure library does not get abandoned. It's just a process of survival of the fittest, like with any language. The popular libraries in Clojure are (mostly) actively maintained like with any other language.

thom6• 6 years ago

It's great that this has been your experience, but I'm on my fourth SQL library at this point. I've been through several HTML rendering libraries, same with authentication, same with config management. The zipper and component libraries I used are abandoned. The data science story is sad compared to the R or Python ecosystems: Incanter dying, clj-ml unmaintained, Fastmath is good for some random stuff but not comprehensive, tech.ml on the rise but still not standard to the point anything actually integrates with it, multiple competing viz libraries, some of which require a browser. Even core stuff like spec hasn't stabilised yet.

I have used Clojure full time for 11 years and it's nonsense to pretend that the ecosystem doesn't have problems that most Ruby, R, Python or .NET developers don't have at all or as often, by virtue of them having strong frontrunning frameworks. I'm not saying they're necessarily more happy or productive than Clojurists, but there is constant churn everywhere in the Clojure ecosystem, and it increases the cognitive load on every project I have ever done in the language.

debaserab22• 6 years ago

This feels like an apples vs oranges comparison. Libraries tend to be more focused and single purpose (e.g., provide an interface for technology X).

When you begin composing libraries together to do a multitude of things you tend to end up with a defacto framework whether you call it that or not.

Frankly, I'd rather use a framework that has been battle tasted and hardened through open source and is well documented instead of one that is incomplete and lacks conventions built in-house.

quickthrower2• 6 years ago

React is a great example of a library that provides enough structure that you typically don’t need a framework. I don’t think you always need a framework for this reason. And it’s definitely battle tested as are all the extras like router etc.

debaserab22• 6 years ago

Aside from the fact that create-react-app itself is pretty much a framework, even if you don't use that and roll it all yourself you end up with a codebase that has many of the same hallmarks of a framework such as directory conventions, common class patterns, a bootstrapping mechanism, etc. There's plenty of messy React codebases out there that screw this up.

macphone• 6 years ago

One more of those Libraries, not frameworks

https://atultechspace.wordpress.com/2019/02/19/libraries-vs-...

justanotherc• 6 years ago

A framework, usually, must predict ahead of time every kind of thing a user of it might need to do within its walls.

Well, when I'm building something opinionated like something resembling a framework, I usually aim for something that handles 80% of the use-cases, and then make sure that you can go around the framework for the other 20%.

Your "thing" should always have a way to get out of the way and fall back to the un-abstracted way of doing things. Then you don't have to predict the future.

pierremenard• 6 years ago

This article looking at frameworks as introducing cyclic dependencies of interpretation is illuminating: https://parametri.city/blog/2018-12-23-language-oriented-sof...

The trouble with frameworks is that to use it, you have to match your application to the language of the API. If you’re not careful, you end up coupling your system to the framework. This means that you create a cycle between yourself and the framework by architecting your component as an interpreter from F_o to F_i.

You can avoid this cyclic dependency by marginalizing the framework at the edges of your application, as suggested in the post, but that strikes me as much easier to do with libraries.

huntedsnark• 6 years ago

I liked this piece, but came out of it more on the side of frameworks, oddly, than libraries. I went into it with a bias ostensibly shared by the author based on the title but here we are. Probably different priorities or values in terms of what constitutes 'shipping' I would guess based on our respective backgrounds.

gorgoiler• 6 years ago

This is good advice and of course, because of the nature of computer science and software engineering, it WLOGs its way to many other topics.

For example: I’ve always enjoyed the tools that come as a pile of small Unix utilities, rather as one single application (GUI or not, but usually GUI.)

BitTornado in the early 2000s. Git of course, where you build your own workflows that work for you using the different command line tools (fetch and rebase, pull and merge, cherry-pick if you want to.)

Much of the Debian helper script suite is designed to be reusable in small components in a makefile, rather than enforcing you do it all their way in one big invocation. And of course the current systemd vs bash-plus-lsb-shell-functions comparison.

I found I couldn’t use ZFS without systemd recently, on an Ubuntu install. ZFS shipped with init scripts that only worked with systemd, but systemd meant my console booted blank. I decided to fix the former rather than the latter and it was pretty easy to write my own ZFS init scripts using the LSB init shell functions — a library, not a framework.

Animats• 6 years ago

Yeah, but nobody gets to have their own conference for a library. Frameworks are a product. Frameworks have cults. Libraries are parts. There's no money in parts.

pjmlp• 6 years ago

I rather have the comfort of frameworks, and the occasional edge case than dealing with creating the world from scratch.

This is what gives "hunt for libraries" mentality of Khronos versus the comfort of using MetalKit or DirectXTK.

Happily using frameworks since Turbo Vision.

rishiraj8824• 6 years ago

I totally get what would have gone in to come up with this. Often frameworks are released and their versions are bumped up with major changes without thinking about the struggles/emotions developers might face. Speaking from experience, just recently I had to sit together fixing and upgrading my codebase to the latest version of a framework that I was using. More than the development process itself these take more time and the developer frustrates himself going over StackOverflow and reading through comments on GitHub issues to figure the point he is missing out on.

More importantly, I think that framework writers need to think of their developers as their users and make sure everyone is notified about the updates happening and are on the same level. I know it is a lot to ask for given that these projects are open source but a huge gap in the way we leverage open-source products for its use.

sigil• 6 years ago

You use libraries. Frameworks use you.

jokoon• 6 years ago

That's why you can use several libraries at once, but you can only use one framework at a time.

That's also why I refrain myself to use things like unity, unreal engine, godot, etc.

Once you wrote something, a framework prevents you from using another framework, or the cost of porting is way too high. Libraries are more easily interchangeable.

Ayesh• 6 years ago

You can do so to some extent in PHP. I'll wait for the PHP has rep to slow down....

In PHP, there is Framework Interior Group that created a few standards to which many frameworks implement their components. The interfaces are designed by FIG, and frameworks implement them (or rather, use libraries that implement them).

Containers, HTTP message objects, request handlers, middleware, caches, they all can be interchanged if they implement these interfaces.

Frameworks can now give the choice to the user to pick their own preferred libraries.

There is Laravel, which is on the far end of opinionated frameworks, but Symfony andnSlim for example provided a lot of flexibility.

waitingforset• 6 years ago

This is my core experience with Tensorflow vs Torch for deep learning -- Tensorflow keeps trying to predict how users will want to structure their research code, while Torch just sticks to making really nice building blocks.

technicolorwhat• 6 years ago

As I see it. A good framework is an extraction of common used patterns and a set of libraries. Sometimes people make the mistake of not dogfooding their frameworks or turning that process around, starting with a framework hoping that it will make life easier. Someone from their ivory tower saying, this his how it should academically work. Like the early .net enterprise block framework or asp.net. The frameworks that are painful to use are usually extracted to soon or not accommodate the 80% for that specific use case

EDIT: Words

arendtio• 6 years ago

Most of the time you need one framework (to give a best practice structure to your project) and many additional libraries to add functionality. So it should be obvious that the number of frameworks this world needs is quite a bit lower than the number of libraries.

In addition, you are always free to go with your own implementation and that is true for the structure dictating frameworks as well as for the libraries.

skohan2• 6 years ago

The more I program, the more I am convinced that owning flow of control is one of my primary jobs as a programmer.

If I surrender this to a framework, there are a lot of decisions I can't make with regard to performance, and I have a lot less certainty about when and in what order exactly things are executed.

There are of course some exceptions, but in general I want libraries to provide me simple, synchronous functions, and it's my job to figure out how to spread them out over the hardware.

toshk• 6 years ago

On the level of practical risk: on the security level libraries are much more risky imo. A good framework for most project i've seen will lead to a more structured and secure codebase. Probably precisely because there is less room for creativity.

For instance Laravel is very structured: orm, auth routes, controllers system etc., where express.js let's you do whatever.

And almost all Expressjs or other Nodejs projects i've joined were a mess and had security issues, something as simple as CSRF tokens, or not allowing redirects to external domains, are often forgotten or not fully implemented.

Doesn't mean I don't sometimes prefer a library approach, but the developer(s) need to be a lot more qualitative.

indeyets• 6 years ago

oh, Laravel is actually an excellent example. It has a lot of hidden "magic" knowledge inside and it takes many months to get a good understanding of how it works. Until then it is trivial to make bad decisions based on this wrong knowledge. Lack of proper IDE support (because of laravel's dynamic nature) doesn't help. And yes, I know about laravel-ide-helper. It has it's issues too

kevsim4• 6 years ago

This hits home for me right now. I'm currently battling some performance problems related to a lot of "magic" that happens when using the Apollo GraphQL framework and am strongly considering ripping it apart and taking back control of what happens and when.

nift• 6 years ago

Would be super awesome if you could share what you find! Having the same issues here - and I have a real time accepting that stuff becomes slow when you wanna return over 1k records. Sometimes way less for advanced things. Read: nested objects. But that slow? Come on.

I also use nestjs and there it seems updates to how to resolve a field has made it tons faster l, purely looking at the trace.

And I know that it won't be as fast as regular old json due to the checking but that slow? Must be something someone can do :)

jordiburgos• 6 years ago

Is Apollo GraphQL helping you more than REST + queries?

cageface• 6 years ago

I’ve been working in some largish Rails codebases lately and this is exactly the problem I have. When I’m looking at a screenful of code I have no idea who is calling what, what’s in scope and from where, and what the shape of any of my data is.

In my opinion the productivity benefits of these kinds of frameworks evaporate and go negative pretty quickly once you move very far beyond what they provide out of the box.

choward• 6 years ago

I think a lot of that has to do with Ruby not having real modules and everything being global.

masswerk• 6 years ago

You could make a point that programming is managing flow control.

dTal• 6 years ago

Good luck using any sort of GUI toolkit then. Virtually every single one requires you to sacrifice the very top level of your program to some sort of "MainLoop()" function.

(I agree with your main point, and the above fact causes a quasi-allergic reaction in me which causes me to avoid GUI programming - despite graphics being one of my favorite topics.)

OJFord• 6 years ago

Instead of using something you're quasi-allergic to, you could work on one you're not?

traverseda• 6 years ago

Try the "imgui" library?

hinkley• 6 years ago

In a similar vein: boilerplate code is fine in the main control flow. It’s okay if it takes twenty lines of code to set up your library, as long as it’s not the same 20 lines for everybody in production.

Frameworks tend to avoid any boilerplate in the imperative core but then multiply I throughout the rest of the project. Possibly due to chronology.

kovac• 6 years ago

How can a library providing only sync functions a good thing? Lots of IO is inherently async and it makes little sense for a library developer to go out of his way to make it synchronous only for the callers to make things asynchronous again. If something is async, it's async. You deal with that.

Also, I don't see why one would even consider using a framework if squeezing out every bit of performance from your hardware is that important. I can't imagine writing a Web app without some framework in the interest of time it takes to develop. Then writing a hundred of the same stuff again? You just have to ensure you don't use a bloated framework which is akin to not choosing a bloated library. Unless you are working on a device layer, it's not our job to spread things over the hardware. Unless you have direct access to memory, you can't do this anyway with most of the languages designed to develop apps. I think the primary goal of an app developer is to implement the business logic correctly and securely in a reasonable time. I agree with the OP that libraries should be preferred but I don't see a problem especially with performance in the domains frameworks are used.

DmitryOlshansky3• 6 years ago

Writing libraries is a never ending grind of:

1. trying hard to do one thing and do it well (and failing usually), but ...

2. there are many dependencies that you should allow your user to pass explicitly ...

3. and that’s the problem - you have 0% control on how the library is integrated but receive full responsibility for how well does it work. Even libc could be very different and will not behave the way you’d expect it to.

The big problem of making everything a small well thought-out library is large integration surface + having to be flexible and accommodate for all potential cases of integration.

That’s why we mostly have hundreds of overlapping “fat” libraries - too much trouble and too much integration complexity to split them up.

atoav• 6 years ago

This is why I love writing libraries in Rust: the language provides so many ways of protecting users of your library to shoot themselves into the foot.

Combine this with the built in and easy to use testing and I find myself often to break out core functionality of my applications into libraries just because it is a sane way to keep things decoupled.

This is far harder in languages without a strict type system: you can do everything right and your users still abuse it.

DmitryOlshansky3• 6 years ago

Well I’m long time D language user and we had unit-tests built-in from 2005+ (if not earlier - I started in 2010).

It all helps but never eliminates the problem completely.

DmitryOlshansky3• 6 years ago

Also to destroy your point on Rust making it safe for your end users.

Library that doesn’t have stable C API is next to useless outside of its original language/community/etc. and I have been bitten by this a few times already myself (my great libraries in D’s std cannot be easily exported outside of D).

Do not repeat my mistakes - provide stable C API (and ABI by extension) as soon as you can. You cannot make it safe though it’s simply not accounted for in the land of linker “technology”.

strictfp• 6 years ago

One other huge downside of frameworks is that they don't (easily) compose with other frameworks and libraries.

namelosw• 6 years ago

Framework and libraries are both useful. Besides those, languages are also useful.

The problem is there are too many frameworks instead of libraries. People are writing frameworks by default, and frameworks make strong assumptions, making things not flexible, thus frequently burn people.

When tackling a new domain, it's better to write libraries first. Then write frameworks if it can indeed improve things. On top of that, when framework works, there's a chance a language may work better.

In brief, frameworks are overused, while libraries and languages are overlooked.

inglor• 6 years ago

However if yo write a framework write a framework.

Don't cripple the community by doing the IoC part and the framework calls you but create a fragmented ecosystem of a million ways to do state, routing and so on.

Looking at you React. Doing Vue was so much easier when I had a Vue project because there were a lot fewer choices.

openfuture• 6 years ago

The frameworks that people really like are things like emacs and xmonad. That is to say, the framework is opinionated enough that you are writing configuration not applications but also flexible enough that your configuration can be completely arbitrary.

Many frameworks are too close to being libraries while still being frameworks, so you lose your control for a dubious return (you don't start with working software and tweak it, rather you have to build from scratch inside of someones else's paradigm).

auggierose• 6 years ago

Frameworks' key trait is that they impose limitations on the programmer

You could say that a type system also imposes limitations on the programmer. Is a type system a framework? Would you rather use a library than a type system?

I think the point is rather that making a framework is much much harder than making a library. So it makes sense to first create a library to solve a problem if that is feasible. Once you are reasonably comfortable with your choices during creating your library, you might think about turning your solution into a framework. You should do that only if there is an actual benefit in doing so.

I think frameworks live on a higher abstraction level than libraries. If you need that higher level, libraries are a poor fit. If you don't need it, why make your life harder in going there?

winter_blue• 6 years ago

The general principal the author is talking about — ie not being overly opinionated— and asking yourself “Could I use this in combination with something else like it?” — could be applied to even something like a programming language.

For example, Elm 0.19+ would be the counter-example in this case. It makes it very hard t/ almost impossible to interact with JS code. A more flexible web front-end wouldn’t force such a strong opinion upon its users. It would let the users decide, and leave flexibility / room in various aspects of the language.

foobar_• 6 years ago

On another note here a a few claims framework authors make which are usually short sighted

1. Frameworks promote code reuse

Frameworks however don't promote reuse within different versions of the same framework, which makes the code reuse claim hypocritical at best.

Where is the code reuse between Angular 1 and Angular 2 ?

Libraries also promote code reuse by the use of shared object files (C) or modules (Python, Node.js ...) and it is usually more long lasting.

2. Frameworks are easier for beginners to use

Frameworks get difficult quickly once the initial use case is run out. Frameworks appear deceptively simple because they hide complex code under the rug, but anytime you need to do functionality similar but different to that initial complex code, you will have a problem.

With a library, you can inspect the code ... copy it and edit it to do what you want, it is not as simple with frameworks especially when you have to deal with 100 levels of inheritance.

In a way frameworks encourage code illiteracy.

3. Frameworks are not composable

Using two or more frameworks is next to impossible because of all the assumptions frameworks make. Frameworks are totalitarian in this regard.

4. Object Relational mismatch is real

By forcing the object model on everything, it makes understanding non OO models for data, which is most data ... very difficult.

Relational model is more generic as it supports references and is obviously more efficient.

amelius• 6 years ago

Frameworks can't be composed. This property is a huge red flag.

amarflybot• 6 years ago

What about the compatibilty issue for Libraries.. Do you think if dependent libraries are not compatible it will create issues? Like back in 1998, half of the developers time went in figuring what version of hibernate works with what version of Spring mvc.

Later on, BOM came into existence.

Then everything was packaged in extendible autoConfiguration and Boot came along.

1337shadow• 6 years ago

It's primarly a matter of taste, but I suppose that if you use only libraries instead of a framework: you will end up copy/pasting the same boilerplate to tie each library from one another over every project.

You could make a library that standardizes a library format and take care of that boilerplate, then you can focus on what makes your project different, but that's not very different from a framework is it ?

mtzet• 6 years ago

I find that this type of duplication is incidental: I happen to need to do the same thing, but if one project has special requirements the other projects don’t need to change. Hence the boilerplate is fine and doesn’t need to be dragged into a library.

ChrisMarshallNY3• 6 years ago

I guess I should weigh in with my experience in this area, as author of both libraries and frameworks, in a lot of different domains, over a number of years.

I feel that it depends on what needs to be done.

For the most part, I prefer writing fairly atomic libraries. I like to use a “LEGO Block” approach, and [relatively] small, focused, modules are ideal for this.

I like each module to have an independent project identity and lifecycle. Makes for much higher quality and usefulness.

Sometimes, though, I need a really fundamental infrastructure. In that scenario, a framework is the best approach. In a lot of cases, we may have considerable control over the implementation of the framework, so that resolves a number of the downsides (like prediction of how it will be employed).

I’ve written a number of frameworks. It’s a huge PItA, and I avoid it, if at all possible. It is my experience that the biggest pain point is quality. I find that proper testing of a large infrastructure is damn near impossible.

If anyone has ever looked at my library (and framework) projects, they will see that my testing code (often harness, as opposed to unit - https://medium.com/chrismarshallny/testing-harness-vs-unit-4...) tends to dwarf the actual CoT.

I consider writing a framework to be the “nuclear option,” to be only employed when nothing else will do. Even then, my frameworks tend to be layered affairs, with coupling between layers as loose as possible.

Writing any reusable software module is like having a child. I can’t just walk away from it when I get bored.

A framework is a huge responsibility. Once it is written and out there, I need to take care of it, in all its contexts, and for all its life. It is a lot easier to deprecate a small module, than a large infrastructure.

The same goes for libraries, but the scope of a library is a great deal more manageable and flexible than a framework. I find flexibility to be a crucial aspect of long-term software (I have written software that has lasted decades).

When I design software, I am constantly looking to the future. It’s become force of habit, and, as Niels Bohr once said: ”Prediction is very difficult, especially about the future.” The less control I exert on the future, the better.

If I can accomplish the same job as a framework with a set of independent modules, even if it is more work to do the modules, that’s what I do. A framework is a big, fat atomic blob that tends to age badly (in my experience).

However, I am obsessed with quality; which is not always an acceptable posture in today’s fast-paced, competitive workplace.

Engineering, at its most fundamental level, is always about finding the most practical approach.

http://www.solipsys.co.uk/new/TheParableOfTheToaster.html

usrusr• 6 years ago

I think the article leaves a bit of a blind spot where the dreaded "in-house framework" lives. Those are always the worst of frameworks when evaluated like you would evaluate a "proper" framework, but they can make up a lot by being used exclusively by their original authors or at least under their personal supervision (then it all depends on people skills). The biggest drawback is that they can cut you off from a lot of upstream innovation, so maybe don't go that way in client side front-end dev... (but sometimes even that can be good, a properly fossilized pure servlet source tree can be nicer to work with than one that has gone through every hype since struts2)

trboyden• 6 years ago

I found the blog post to be just another take on the micro-services vs monolithic application debate. Where micro-services = library and monolithic = framework. As a full-time coder I take a different approach - documentation is everything.

I could care less if a piece of code is a library, a framework, is made up of micro-services, or is monolithic. It all means diddly-squat if the documentation sucks and you can't figure out how to use the damn thing. It really doesn't matter if a big company sponsors the code either, because they usually have the worse documentation. Take the Mongoose Application Framework by Infor (https://mongoose.infor.com) which is supposed to be designed to help developers quickly build applications. The API has virtually no documentation. It has tons of libraries but you don't know what they do or what they are capable of unless you dig into the code to see what it does. They re-implement tons of standard .NET API with their own twist on it.

That experience changes the way I develop for fun. I have taken to do a lot my free-time coding with Python because the documentation, for the most part, is very well done. Most of the Python developers seem to take a documentation-first approach to their code which makes it easy to take on new concepts and branch out into different areas such as IoT or AI.

leetrout2• 6 years ago

Django’s docs are world class. It’s by far the example I always reach for when talking to people about how I think “great” docs should be written and served.

BiteCode_dev• 6 years ago

Write free code, extract libraries, then organize some into frameworks.

We don't need to exclude any of those practice. In fact, focusing on only one of those is what leads to the most problems in my experience.

Tade0• 6 years ago

When a programmer thinks to herself

I see the author is in the "they is not a singular pronoun" camp, which means we cannot be friends.

Anyway I don't know how it is in other parts of the stack, but based on my experiences on the front-end, to build a large-scale project you're going to need a:

- Router

- Way to manage forms & validation

- Way to communicate with the backend

- Set of tools for testing

- Set of commonly used components - that includes layout

- 118n support

- Convention where to put certain files and how to name them

- Store

So it would make sense to have all this in one coherent framework. That being said not all projects are large-scale projects. Normally you'll only need a subset of the mentioned.

Bottom line is it's a question of scale.

alecco• 6 years ago

It's the most honourable way, but kiss goodbye to recognition and money. Somebody will slap a UI/app on top of it and get all the credit and get paid for it. It's one of the paradoxes of free software/open source.

AGPL fixes this somewhat but it just makes it practically not profitable for everybody involved.

ivanhoe• 6 years ago

First you write libs, then you get tired of always doing the same scaffolding work, so you build the boilerplates to cover the most common flows - and before you realized you end up with a framework... the resistance is futile

andybak• 6 years ago

The one thing I do value from frameworks - especially in an unfamiliar domain - is that they teach me how to structure things.

I can usually patch functionality together from various sources but understanding how to break a process down if you haven't done it before is often very challenging.

For example - Django taught me how to structure server-side code that needed to handle input from both a database and a browser and potentially an API in a way that keeps things nicely layered.

I'd done all this before with PHP but my architecture was a dogs dinner. I could structure my own code nicely now - but only because of the experience I gained from using an opinionated framework.

willio58• 6 years ago

Recently I’ve discovered the world of Django (late to the party I know). It’s so nice to work with a well-developed web framework for once.

jmull• 6 years ago

The corollary to this is:

    *Use* libraries, not frameworks

Similar to the case of writing, this isn't absolute. But when you decide to use a framework in your project, you are accepting a set of limitations and should do it with your eyes open.

Unfortunately, framework authors make this difficult. It's understandable but frameworks spend a lot of effort promoting their "pros" to developers and none on clarifying their "cons" (well, typically).

When you adopt a third-party framework for a project, you want to do an analysis of the longer-term implications of the limitations the framework. Sometimes that analysis is easy. E.g., if I am making an "event" app -- like an app for "XYZ's 2021 Comedy Tour" -- there isn't a long term (though there, it makes sense to take it further and see if there's an even more restrictive "template" app that will still nicely meet requirements).

But if you are hoping to extend and build-out your app/project/solution over time, especially if you don't know details of how, up-front, it's tough to accept the limitations of a framework.

eternalban• 6 years ago

There is also Write Libraries, not language features.

The progression language -> library -> framework maps to semantics -> a vocabulary of expression -> ideology.

I think the OP has made an error in considering a framework as a sort of 'maximalist' construct that must cater to any and all possiblities.

Let's consider a (known) rigirously and formally specified 'framework' approach and see if it needs to "predict ... every kind of thing ... [possible to accomplish] within its [constraints]":

https://www.oracle.com/technetwork/java/javase/documentation...

A framework design team is tasked with facilitating a technical goal:

RoR: "MVC for the world!".

Java Beans: "Tool makers of the world, unite!"

J2EE: "Look ma, my IT commodity programmer can do distributed component oriented programming and not even know it!".

At its most abstract consideration, RoR is an idoelogical take on writing MVC. "This is how you do it". Beans nails down an approach for wirable components that can be supported at both design and runtime with tooling and automation. JEE says lays down 4 canonical and formally boxed contexts of reference (naming), transaction, persistence, life-cycle.

None of the above had to predict ahead of time "everything". Frameworks are almost always really about top-down considerations.

[p.s. follows]:

Keep in mind that we're always building on top of the 2 fundamental layers of langauge semantics and libraries. The proverbial "standard library" is the reminder. So that just leaves the final layer, and the critical consideration of "more libraries" or "manifesto on how to use libraries".

The actual core issue is composition limitations. It is far easier to compose libraries (vocab-a + vocab-b + ..) than it is to compose framework (which may not even be possible).

A framework is a 'final consideration' of the best approach for a (set of) niche technical concern(s).

m12k• 6 years ago

One way to improve both frameworks and libraries (but is especially needed with frameworks) is if they create 'safety valves' - places where it's possible for the programmer to just break free of what the framework/library is doing and do their own thing. With this approach, and sufficiently modular architecture, you get ease of use at the highest level, but can drop down to as a low a level as needed to work around limitations (a common example is ORMs just letting you write raw SQL when you want to, but most of the time you can get the benefit of their abstractions).

HarHarVeryFunny• 6 years ago

This discussion reminds me of one of my favorite quotes: "form is liberating". I always associated this with the sculptor Henry Moore, but the beauty of the idea is that it can be applied to all sorts of domains, whence it's also associated with Brook's Mythical Man Month about software development.

The association here is that frameworks are "form". One might intuitively think that form/frameworks is/are constraining rather than liberating, but per the sculptural analogy the roughed-out shape provided by the framework liberates you to concentrate on the details rather than suffer from analysis-paralysis when there is too much freedom of approach (just a large block of marble from which you might sculpt literally anything).

But it depends on the scope and nature of what you are trying to do ...

If your problem fits withing the scope/form of the framework, and your value-add is in the details, then using a framework, all else considered, make sense.

Alternatively, when you are trying to do something outside of the norms of gentrified frameworks, then the flexibility of libraries (or ultimately a blank sheet of paper) is what is called for.

Of course, the devil is in the details... a poorly designed framework may be TOO constraining and not provide enough flexibility to be widely applicable, while poorly designed libraries may be overly restrictive due to poorly designed APIs that don't place nice with other libraries or the data structures you'd like to use.

chrisan• 6 years ago

1 more plus for the form of frameworks. People on your team must be on the same page and work within that form. If everyone is left to their own devices you will get a lot of friction when going into parts of the code you did not create yourself.

I like to think of frameworks like a kitchen. The chef sets the menu and everyone works to produce how the chef thought it should be.

Sure sometimes you will run into things that you fight the framework, but a good framework normally allows a "raw" way of doing it "by hand" instead of the sugary framework way that "just works (most of the time)". But most of the time it does work out fine and you can hop between other's proejcts/parts of the code and have instant familiarity and intent

dkarl2• 6 years ago

The devil is sometimes in the large as well. Form changes — code that used to run while generating a web page now runs in a REST service. Code that used to run in a REST service now runs as a FAAS. Code that used to run in a FAAS now runs in a stream processor.

Your framework could tie you to a specific form, forcing you to implement your FAAS by posting each request to a REST service, or forcing you to implement your stream processor by posting each event to a FAAS. Or you can liberate your code from form by making sure that nothing important about it depends on a form-specific framework.

Townley• 6 years ago

True, but all code ages out, and I wouldn’t expect the average LAMP stack site to have adjusted to the REST-powered react world any better than a rails app would. When use cases change, huge parts of a code base should be rewritten (otherwise it was duplicated work to begin with)

That said: good, modular, well-developed frameworks evolve alongside their use cases. Django with DjangoRestFramework is an excellent choice for many API use cases, and the migration path is about as painless a major architectural overhaul can be.

spaceribs• 6 years ago

I don't see Chefs complaining about the difference between getting better kitchen utensils versus working in a more functional kitchen. They go hand in hand.

andrewmatte• 6 years ago

I like microframeworks because they do one thing well and they don't in the way - like a library. When I use batteries-included frameworks, I end up not using a lot of what they offer.

bullen• 6 years ago

This makes no sense, both have their place and limits are good! Ossification has a purpose!

I often use the metaphor of a tree:

  leaf = library
  stem = framework
  root = platform

Write platforms so you can hot-deploy everything including the database and change the turnaround of the iteration to as close to zero as you can!

In my MMO engine client I have a couple of hundred of milliseconds turnaround from saved source to running in the engine (platform + framework + library) without any reloading of assets.

Same thing on the Server.

Only use OS + language (C+ (only string/stream and classes for structure only) for client and JavaSE for server) and build everything else yourself except if there are libraries built by one person (personally I use JSON and DNS4J for Java and GLEW + SoftAL for C, all of those are at the edges!). Everything else is a recipe for long-term disaster!

activatedgeek• 6 years ago

This discussion is reminiscent of “composition” vs “inheritance” programming patterns.

You can “compose” libraries or “inherit” frameworks to execute the job.

clamstew• 6 years ago

Could this also be stated that a DSL or code that seeks to abstract away most code in the real language is more overhead to maintain, grow, and build on top of than building stuff mostly on top of real language?

In which case, are we merely saying adding code abstraction layers are at the extremes - where you need to add a lot of custom code - more overhead than working on top of the bare language.

grumple• 6 years ago

This is a really bad take imo.

Frameworks exist to prevent you from having to do work that has already been done, to a much greater extent than libraries. Those interfaces between libraries are the part that waste the most time for little reward. For web development in particular, reinventing the wheel will waste a huge amount of time. Looking at them as limiting rather than accelerating is an idealist dev's mistake that ignores the realities of business.

While you're busy gluing those components together, your competitors who used a framework already made it to market. While you're reinventing authentication, they've got their first customers. After launch, while you're figuring out new ways to add features that come with the framework, they are able to focus on scaling and growing their customer base.

Sure, this works out differently if you're one of the big tech companies, with tons of bodies to throw at any problem. But if you're on a small to medium sized team, use a framework. There's a reason so many successful startups and mid-sized teams (and large teams) start and grow with Rails or Django compared to non-framework paradigms - and it's not that there are more people doing it. Node-based non-framework app attempts seem to be far more popular and far less successful on average.

danfromsales• 6 years ago

Very well-written. Sounds like a discussion, not just a rant.

js4ever• 6 years ago

I have noticed 2 kinds of developers: Vanilla vs Frameworks

the later seems a lot more demanded by the market, but the formers are usually producing better/unique applications, and with much better perf compared to a framework based app

2 weeks ago a customer asked me to optimize a slow Angular SPA frontend for a simple CRUD app. It was taking 30 seconds to load nearly 15MB of js for the login screen!

I have simply trashed everything, 250MB of code and dependencies, ALL replaced by 15KB of Vanilla HTML/CSS/JS. The customer just could not believe how fast and efficient the new frontend was! His first question was which magical framework I used ...

afterwalk• 6 years ago

Did you tell him about the new framework called http://vanilla-js.com/? : )

sidlls• 6 years ago

A common objection to this is the proposition that eventually engineering will produce a framework, even if it's not intentional, so why not just choose an existing one and adapt/patch as necessary?

I tend to agree that good engineering teams will produce a useful framework, eventually--but this framework will be very specific to the domain of the problem it solves. It will be extensible and flexible to add new features to. It won't be something that can be generalized well to other problems, though.

sorokod• 6 years ago

In a fundamental way, any programming language is a framework with many of the attached strings mentioned in the article.

rurp• 6 years ago

One nice benefit of framework restrictions is standardization. For example a Django developer can jump into a lot of Django projects and instantly know a lot about them. Things like the builtin admin are often very similar between projects. This can ease onboarding a great deal, to everyone's benefit.

thayne• 6 years ago

I think the best way to make a framework is as a collection of libraries that are designed to work well together, but can also be used independently. Then users can pick and choose which parts they need.

tobyhinloopen2• 6 years ago

This is why I like bootstrap. I usually pick the sass version, remove all includes, and only include what I use.

I like frameworks that allow this. Most don’t, even if they claim they do.

mstijak• 6 years ago

I would like to share my view as of an author of a JS UI framework. It largely depends on the project, but sometimes it can be very difficult to integrate many libraries to play nicely together. To build an admin web application with some data entry, a developer would need a set of standard widgets like inputs and menus, a nice data table implementation, form validation engine, a router and a state management library. For more serious applications charts may also be needed, multi-lingual support and some advanced widgets like maps, html editor, calendar, or diagrams. If each of those is a separate library with separate rules for styling, state management, selection, number and date formatting, context menus, tooltips, the project quickly becomes very very complex. If all things are integrated into a framework you get a sane development experience. There are always some sacrifices and some features may be missing, but frameworks usually cover 80-90% of all requirements. The problem is that requirements change and frameworks usually have hard time to catch up and preserve backward compatibility.

gabordemooij• 6 years ago

I have to admit that I never use frameworks, only libraries. I feel everytime I use a framework there is some kind of mismatch between what the author of the framework had in mind and the problem at hand.

tobyhinloopen2• 6 years ago

Strapi. I just want the CMS/admin panel. I don’t want the... well everything else

commandlinefan2• 6 years ago

Google can back Angular, Pivotal can back Spring

Funny, when you talk about frameworks that create more problems than they solve, these two are the first two that pop into my head. In fact, I’ve been trying for years to find any problems that either of these two actually do solve.

crimsonalucard• 6 years ago

Libraries aren't everything, but they should be preferred.

The story is much much more complicated than this. Every single one of you is using a framework everyday, that is unless you program in assembly language.

All Programming languages are highly opinionated frameworks on top of assembly languages.

When you know this, then you know that you can't just say something simplistic like libraries are "preferred."

If all programming languages are frameworks on top of assembly language then frameworks are not only preferred they are Required for humans to make sense of complexity.

When you write a framework like django within the framework of python you are putting a framework within a framework. It's similar to writing a compiler that compiles some PL into python. You are building layers and layers of interfaces between your logic.

For every extra layer you add, two things, in general, happen:

     1. Complexity decreases
     2. Restriction increases

So when someone writes an article like this, what they are actually saying is this:

    "The complexity and restriction balance in the current framework/programming language 
     strikes the right balance so in my opinion (keyword)
     writing another framework on top of the current framework will
     increase the restriction to the point where the trade off is not worth it."

When writing a library as opposed to a framework, what people are essentially doing is augmenting the capabilities of the current framework without creating an extra layer of abstraction. Another good way to think about it is that frameworks are equivalent to extra layers of abstraction and therefore the benefits and downsides of adding more layers of abstraction are equivalent to adding more frameworks. So it's really not as simple to say that "Libraries are preferred."

The story actually gets even more complicated then this. I spoke previously as if there is a trade off between Complexity and Restriction. While a decrease in complexity is always good, an increase in restriction is not always bad.

Take for example ELM. ELM is a language (or framework) that compiles to javascript and HTML. It is more restrictive then javascript due to type checking. Yes type checking is a framework that decreases freedom and increases restriction. But people think type checking is a good thing. Why? Well, the ELM type checker/framework is so powerful that it restricts you from ever writing a run time error. You absolutely do not have the freedom to write code that has certain bugs in ELM while in javascript you absolutely have the freedom to pollute your code with thousands of obscure bugs.

Restriction can be good, really good. In fact restriction outside of testing is our greatest tool and weapon for combating the problem of bugs occurring as a result of too much complexity.

In short, I don't like this article because it doesn't illustrate the full story. It kind of biases against frameworks. The author did not think deeply enough, he thinks of frameworks in terms of things like rails or django, but he does not think of what a framework is from a more general perspective.

Keep in mind, react or how react is used is basically a framework as well. Nobody uses it as a library, they prefer the component abstraction to take over the entire notion of the DOM.

mengopie2• 6 years ago

Do we need frameworks? If you think a framework is a layer of abstraction, then an OS is a framework, a browser is a framework. You dont need angular to write web app but you need browser and OS. So someone needs to write frameworks.

mengopie2• 6 years ago

Do we need frameworks? If you think framework is a layer of abstraction, then an OS is a framework, a browser is a framework. You don't need angular to write a web app, but you'll need OS and browser. So someone needs to write frameworks.

6gvONxR4sf7o• 6 years ago

Whenever I've had tools a platform/infra team provides that feels like I'm working with my hands tied, maybe it makes things withing some predicted boundaries and everything else hard, this seems to be the culprit. I never realized it until I had a teammate redesign an infra tool from a framework into a library, explicitly pointing out this distinction. Now I explicitly think about it as a fuzzy spectrum when I'm writing what's kinda analogous to higher order code, or really anything that feels like "investment" code I want to leverage to help myself down the line. Being aware of the spectrum has let me be intentional about my choices in a way that may be the biggest improvement in my programming since I learned about unit tests.

Recently, pytorch-lightning has been interesting to me because it seems to be relatively close to the boundary between these two ideas.

juped2• 6 years ago

Phoenix is the only web framework I like, because I can understand and control its control flow in a way that I can't with, say, Rails. Plus running on BEAM is great - the whole Erlang ecosystem has always felt like what OOP hype-men promised us in the 90s and 00s, but in reality.

Write Libraries, Not Frameworks

Related Stories