The author is only partway through the learning process. There is a circular progression.
The total newbie just "learns the framework" and is helpless to debug through leaking abstractions. I agree 100% that you don't want to be stuck there.
So eventually she decides to just compose her own architecture. Now she understands all the pieces. But as she matures further as a programmer and architect, she starts to see all the myriad ways that her bespoke architecture is not as good as the more standardized alternatives.
It can't be, because all the people spending their time on bespoke solutions are solving the same problems over and over again separately, whereas the people working on shared solutions keep building off each other. Over the long-run it gives a massive quality advantage to the shared solutions.
Her journey is complete when she circles back around and can pick up somebody else's framework with shared community conventions and still understand all the pieces. She's not intimidated by the prospect of debugging down through layers of abstraction. Because she's good enough to write a framework, she doesn't have to. She can just contribute to one, and benefit from everybody else who's also contributing.
>It can't be, because all the people spending their time on bespoke solutions are solving the same problems over and over again separately, whereas the people working on shared solutions keep building off each other. Over the long-run it gives a massive quality advantage to the shared solutions.
In theory, yes.
In the real world, "the people working on shared solutions" get distracted too easily, follow latest BS fads, change course and rewrite everything for no good reason (too numerous projects to mention). And some of them are just plain mediocre framework designers in an industry that embraces mediocrity a lot more than it should...
What's even worse most frameworks are not that extendable without going out of your way when you need some custom functionality. So as soon as your problem becomes interesting, and you could really use some help from a framework, it's when they tend to break and you have to work around them...
>What's even worse most frameworks are not that extendable without going out of your way when you need some custom functionality. So as soon as your problem becomes interesting, and you could really use some help from a framework, it's when they tend to break and you have to work around them...
Then you discover the framework designers consider your problem too far from their core target use cases and so show no interest in improving that area of the framework. The community question why on earth you were trying to solve that problem in the framework in the first place, and tell you that obviously you should have used a different framework from the start.
Frameworks all target different use cases; often simply the ones the designers happen to have faced over the years. Half the battle in choosing a framework seems to be finding out what those target uses cases actually are - most frameworks seem to think they are good at everything.
God forbid your app evolves and changes such that no framework fully supports all your uses any more...
(That's not to say frameworks are bad, I just think there's a bit too much religious fervour involved when discussing them.)
> Then you discover the framework designers consider your problem too far from their core target use cases and so show no interest in improving that area of the framework. The community question why on earth you were trying to solve that problem in the framework in the first place, and tell you that obviously you should have used a different framework from the start.
Either they're right or they're wrong. If they're wrong, then you have a golden opportunity to start contributing to the framework yourself by writing the extensions, incorporating them into your projects, sending them upstream when they're ready. If they're wrong then you'll be able to work that into your development workflow and you won't lose any speed by packaging up a PR or whatever.
If they're right then this will feel like pulling teeth.
I've seen this a few times with projects I've worked on. I think what it comes down to is this: "despite the trouble I had with feature x, did the framework save me time and effort because 90% of the work (i.e boilerplate) was done for me".
If the answer is no, then using a framework was probably a mistake. However, for 99% of web applications, I don't think the answer to this question is a no.
I started with Rails many years ago, had absolutely no idea what I was doing. Was just googling for gems and snippets from Stack Overflow, if anything ever broke I was done.
A few years later I decided I was going to really dig deep into the meat of it and wrote my own framework in Clojure that we are still using to this day in production. It was incredibly liberating to know every nook and cranny of the framework because I had written it myself. I also figured out why so many decision had been made in other frameworks, it was a phenomenal learning experience.
I eventually realized that our super small team and I simply couldn't sustain keeping this super-custom framework maintained and updated, not with all the other work that needs to be done at the company. We moved most of our work to Haskell's Yesod framework, which has years of community work and incredible craftsmanship behind it. It's now pretty trivial to spin up a new application and have it reuse all of the components written for other apps in the same framework. I don't even bother with docs at this point, it's a lot more effective to stare at the source.
>I eventually realized that our super small team and I simply couldn't sustain keeping this super-custom framework maintained and updated, not with all the other work that needs to be done at the company. We moved most of our work to Haskell's Yesod framework, which has years of community work and incredible craftsmanship behind it.
And then Haskell's Yesod gets abandoned when the core devs move to shinier things and nobody else is bothered, like several Clojure web frameworks that were touted back in the day...
And you realise that maybe updating your own framework when and were you needed it, was not that big of a deal actually....
It's a possibility, which is why you need to evaluate how much the community likes the project, how much they depend on it surviving, how many people would be likely to keep it afloat in case the core devs peace out, how active the core team has been over the long and short terms etc. There's a whole art to picking OSS tooling for your team, none of it is devoid of risk, there's no free lunch.
Obviously, it'd also be totally OK for us to help maintain it with the rest of the people who care, that's a big part of it. Given how much you end up reading the source of frameworks once you really start using them (at least in my ecosystems), you're one step away from starting to change them.
In the case where an open source framework loses its maintainer, in the worst case you are the maintainer. In that case you are no worse off than with your own framework, except that for a number of years the maintenance work was done for you for free.
With one small difference: you'll likely have a much larger attack surface because the third party framework was created to do much more than to just service your applications.
And all that code will need to be maintained now. That can get very costly.
We're not talking about creating the universe from scratch, here. We necessarily build near the top of a pyramid of architectures. In the browser, for example, we build on top of JavaScript and the DOM. In many situations, Unix can be seen as the underlying architecture.
Compared to those underlying architectures, most frameworks are ephemeral and indeed "bespoke." JavaScript, DOM, and Unix are specified in standards and have several implementations. They embody decades of shared solutions and conventions.
"It can't be" is a bold claim. "Massive quality advantage" as well. Which frameworks are you talking about exactly?
I think "circular" sort of gets at the point. A circle keeps going round.
I don't this the author is advocating dropping all frameworks, and certainly not making your own custom framework for every project. The point is more moderate than that: There is just to much reliance on frameworks in general, especially in SPA/front-end development. Frameworks work great until they don't, and then what? Over-reliance on frameworks does create a dependency on the developers, they learn to implement their framework of choice instead of learning good software design. And worse, this can foster the belief that frameworks are a necessity on every project. When all you use is a hammer every problem looks like a nail. Frameworks can be a force-multiplier, but they are also constrictive in a lot of ways. I have run into this first hand, especially with longer-running projects.
I think there's an art and technology to reusable components. This reifies "architecture" into something which can be slowly built up by the community as reusable tools. Lacking this technology one instead must fall to "frameworks" as the unit of shared community development.
This is directly related to one's ability to spin off a library containing a generalizable component of functionality and have it be repeatedly reused. My belief is that this is actually far harder than it ought to be in most languages. Actually, worse than that, most languages and the style of their libraries as supported by the community cause tradeoffs which penalize reusability quite harshly.
* It's difficult to manage documentation of interfaces
* Abstractions leak *heavily* and therefore have
exponentially complex "spooky interaction at a distance"
* Breaking algorithms into chunks must be done at
boundaries defined by efficiencies instead of as
defined by meaning (implementation privileged over spec)
Experienced Haskell users often talk about this story: that Haskell was the first language they ever used which actually felt reusable. This arose from the combination of powerful types, pure code, and laziness. The types provide clear, unbreakable interfaces between libraries. The purity ensures that libraries play together well and can be combined in more ways due to no "spooky interaction at a distance". The laziness ensures that when you cut sequences of computation into pieces you can recompose them later without losing efficiency.
I'm not going to claim that Haskell has figured out modularity, but I do think it's massively better than the status quo here. The upshot is that Cabal Hell is in part caused by the fact that nobody quite knows how to handle such massive modularity in practice.
Where that's relevant, I think, to this post is that without a genuine case for reusable modularity—supported at the language and the community levels—it is much harder to invest your time into reusable things and instead you focus efforts on frameworks. Lacking the technology to have legos we choose between prefab houses.
I think the best way for Javascript, i.e., to move forward away from framework driven development is to double down on the community's investment in purity as neither types nor laziness are ever going to be core to the language. This has already occurred in a small way with things like the virtual dom technique (which can be easily made immutable and updated purely) and the rise of things like Mori and Immutable.js.
As this pattern grows I predict the ability for people to genuinely build applications from well-cut, reusable components will become far more of a reality and the "framework epoch" will slowly close.
It's not intimidation, it's just determining which path you want to take. The people who constructed the ground of the popular frameworks had to start somewhere too.
I don't think the author is intimidated by a framework rather highlighting there is greater opportunity cost associated with learning a framework and having to bend to it's will instead of writing code that does not rely on a monolithic framework.
The author appears to have solid understanding of the principles and it takes deep knowledge and experience to call out bubbles. Successful investors often take similar contrarian views, carefully weighing what is simply exuberance of the herd vs facts.
As you mention, time is required, to fully dig deep into someone's framework. At the end of the day, a framework is like software. you need time to learn it. when you use it in cases where you don't absolutely need it to do a job, you are affected by marketing or herd mentality.
'Everybody uses it so it must be right'. ex) MongoDB.
Everybody suddenly needed NoSQL. you started hearing recruiters ramble on about NoSQL and the urgent need to fill it. Then you start fiddling with it and you end up firing your entire team because they built their church on a questionable sand (MongoDB) and run into all sorts of problems.
I often feel like developers freely toss around frameworks or use new things because they are bored and want to try things differently. Ewww server side render pages are so 2005. I won't touch anything that isn't JS. No, I want this my blog built in Node.js so it can serve millions of yet to come visitors.
Again and again I'm reminded of turf wars where people's job rely on identifying with one set of philosophy even if they are as crazy as writing tests before you code and expect things to not fail.
The total newbie just "learns the framework" and is helpless to debug through leaking abstractions. I agree 100% that you don't want to be stuck there.
So eventually she decides to just compose her own architecture. Now she understands all the pieces. But as she matures further as a programmer and architect, she starts to see all the myriad ways that her bespoke architecture is not as good as the more standardized alternatives.
It can't be, because all the people spending their time on bespoke solutions are solving the same problems over and over again separately, whereas the people working on shared solutions keep building off each other. Over the long-run it gives a massive quality advantage to the shared solutions.
Her journey is complete when she circles back around and can pick up somebody else's framework with shared community conventions and still understand all the pieces. She's not intimidated by the prospect of debugging down through layers of abstraction. Because she's good enough to write a framework, she doesn't have to. She can just contribute to one, and benefit from everybody else who's also contributing.