Do Not Learn Frameworks – Learn the Architecture
kukuruku.co
kukuruku.co
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.
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...
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.)
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.
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.
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....
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.
And all that code will need to be maintained now. That can get very costly.
That's a non-trivial refactor right there.
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.
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)
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.
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.
To an outsider who needs to now contribute code to my web app, what's the difference between following my patterns and following a framework's patterns if a framework was used instead?
What's good about most frameworks is the fact they come with documentation, tutorials, tests and all that good stuff so someone new to the framework can quickly get up to speed. The author even admits to having people have problems understanding his architecture.
My advice to the author is don't worry, people will eventually get better. JavaScript seemed inaccessible to a lot of people (including myself) until jQuery came along. The more jQuery code I wrote and gained more experience in JavaScript, the more I learned how little I needed to use jQuery to accomplish a ton of stuff. Backbone, Angular and other frameworks will probably have the same effect on people some day.
You're right, nobody wants that. What I have found to be the best way to avoid this is to actively talk to each other and together choose the simplest solutions that fit the case. Mixing and matching different patterns is good if they fit neatly. This results into less boilerplate and/or messy spaghetti code, as the abstractions fit the problem domain perfectly.
So essentially, talk to each other and work together as a team. Don't just hack on things randomly.
Your own patterns and practices are developed to apply directly to what you're building.
That's a rather large leap of faith.
It's more likely that it has a bunch of abstractions that were chosen early in the project when the maintainers were young, dumb, and eager; that have since shown their age and have been worked around repeatedly; but can't be removed due to being core to the framework and having a large body of applications depending on them.
Another way to look at it is that every production framework needs a subset of its development team that is really knowledgeable and paranoid about security, proactively watches for new attacks, and which can very quickly roll out effective mitigations. If you don't have at least one person on your team that will handle this role, then you're better off using a security conscious framework, and if you only have one, then they'd better be very good.
Otherwise, sure, make your own framework to learn architectural principals, to improve your ability to digest the architecture of production frameworks, and to improve your ability to extend the framework into areas that are unique to your use case. Just keep it out of production.
[disclaimer to avoid discussion forks: for this comment, I'm assuming that the framework is being used for non-trivial systems, if what you're doing is trivial, then you may not need a framework at all, bespoke or otherwise. I'm not particularly interested in the question of what constitutes a non-trivial system. Set the bar wherever it makes sense to you to consider significant code reuse imperative.]
I've been on the flip side of this too many times. Some outsourcing company developed a product using a framework (usually on a fixed-price bid), which enabled them to ship something that sort of mostly worked so they could get paid. Then, I'm stuck supporting and maintaining it, and it takes 3x-5x longer than it should because of the poor framework choice and poor usage of that framework.
However, I think the big problem is dealing with code that an outsourcing company "sort of mostly worked so they could get paid". The incentives are just not there for a quality product: framework or not, they are going to produce a slapdash hodgepodge of code.
If they didn't have a framework, is there a reason I'm not seeing to think that the resulting mess of code would be any easier to support?
Does anyone have specific recommendations on how to pursue what the author suggests?
An anti-architecture (in the article's sense I think) might be people who just know jquery but do not know javascript or how the DOM, the browser api, etc.. works, some just use jquery for something that can be done with 10-15 lines of JS, but they don't know better, they lack the principles/architecture knowledge to do so.
The "architecture of open source applications" books are a good read to get an idea of how bigger pieces of software work, but none of it is JS IIRC.
"Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well—usually programs they wrote themselves—and never study the great programs of history. As a result, they repeat one another's mistakes rather than building on one another's successes."
There's a good book http://aosabook.org/en/index.html called the Architecture of Open Source Applications.
More generally, you might find it useful to read Christopher Alexander's Timeless Way of Building.
Remember, the best architecture is minimal architecture, because architecture is the fundamental, hard-to-change patterns in your code. So learn architecture, but also learn how and when to make it unnecessary.
I do think, though, that he wrongly blames frameworks for the bad code people usually write. It doesn't matter if you're writing homegrown code, you still have to write a framework of some sort around it in order to get any work done. I think that the front end frameworks currently available out there all are really bad solutions for what they purport to solve.
It's like you're promised a cutter that cuts cubes, when you need your cube to fit a hole in a shape of a circle. Even after you're done using the cutter, you still need to cut around the edges to make it fit, and in doing so, you probably could've just skipped the first step in the first place.
Instead of blaming the tool, the blame should be placed in the abstraction. To keep with the analogy, if I had been handed a circle cutter, I could probably fit my shape in the hole with no problem. Better yet, if I was able to choose between a square or a circle cutter before I start a job, that'd be perfect.
As it currently stands, Backbone did a great job at separating the concerns of a web app, but its rendering methods resort to too much thrashing of the dom. Angular attempted to solve the thrashing, but, along its way, it ended up lowering the divide between logic and presentation via its assortment of ng attributes. I haven't tried yet, but I have high hopes for React and its solutions.
The hallmark of a great framework is one which clearly defines what its one task will be and executes it beautifully, and simply. Allowing newcomers to start from the top, and work their way to the bottom without much effort. Since none of the javascript frameworks out there are of high quality at this point, most of the code written in those frameworks will just not be very good, and it's ok for right now. That's the learning process that the industry goes through every time a new technology is introduced, and I have high hopes that sometime in the next couple of years a framework will come out that will set the tone for the years going forward.
It's not about "not using framework",it's about reading the source of anything you're going to use and vet it. Obviously that's the last thing js developers like to do.
That's why I like Go by the way.The language is so limited anybody with a minimal understanding of Go can read it. No fancy stuff,just ifs,functions and for loops.
Angular is what, 10000 of codes with the comment striped at most. Well you'll learn a lot of "architecture" just by scaning it.
Don't listen people telling you not to use frameworks,where do you think their skills come from,how do you think they earn money,by spending time building their own undocumented ,sub tested ,full of cross site scripting exploits, frameworks again and again? bullshit.
But use libs and frameworks you're ready to spend time debugging. Thus something with a source code YOU can understand.
I agree however, that angularjs "check what error codes means online" instead of explaining them in the console is terrible.
I say it again, want to be a great dev? read source code.You'll learn much more about programming because the practice is right here in the source, than with crappy article like the OP.
Personally I've never felt the need to use a framework, but I can see how it can be useful, like if your team has little experience. Then a well documented road map might be useful. But not so fun if you decide to go by foot.
Good companies want both good coders AND coders with experience in the language or the plateform they use.
Good luck telling that to a recruiter.
"Oh looks like you don't have 5 years of experience on a super esoteric framework released last year. Great we'll talk soon."
Seriously, using knockout js recently. I completed a project, and all its mile stones in 2 weeks. We had 6 months planned. I completed the whole project in 2 weeks. When I was done, there were NO bugs under priority 4. In the 7 years of development before that, I have never experienced such a pleasant development cycle. I'd kill someone if they ever took this new tool away from me.
But you never bother to teach it the computer! The computer should understand the pattern as well, in form of some abstraction. Because now you force yourself and others to recognize pattern every time you need to use it (either read or write it in the code). That's ridiculous.
In some languages, patterns are commonly expressed via macros. Instead of learning patterns, you learn set of macros. That way, even computer understands those patterns and it is clearly obvious from the code what pattern was used, you don't have to translate code back to patterns. But the macros are not the only way to do it.
To summarize as briefly as possible: abstraction has costs, too. Sometimes it's better to spell out the pattern.
As you probably know, the idea of patterns came from architecture, where "reusable abstraction" translates to "modular house" – which is not obviously better.
[1]: https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf
I think patterns should always be "abstracted and instantiated". I always found his example of actual code in support of his argument a bit weird. From the book:
Does the following code fragment:
(mismatch sequence list :from-end t
:start1 20 :start2 40
:end1 120 :end2 140 :test #’baz)
seem easier to understand than this pattern of use:
(let ((subseq1 (reverse (subseq sequence 20 120)))
(subseq2 (reverse (subseq list 40 140))))
(flet ((the-same (x y) (baz x y)))
(loop for index upfrom 0
as item1 in subseq1
as item2 in subseq2
finally (return t) do
(unless (the-same item1 item2)
(return index)))))
:test #'baz
For example, should a positive result from BAZ mean that the items are the same? There's no way to tell. You could argue that this is because of poor keyword argument naming, but that's part of the point: in the second version, there's no need for such considerations, because the use is explicit.
(Consider yourself lucky that the function uses keyword arguments to begin with!)
Nor do I agree that the first example is obviously bug-free. How would I know? The definition of the actual logic is in some other file. Yes, that's true for the library functions used in the second example, but those are standardized.
Other examples of ambiguities: Are START1 etc counted from the end of the list or from the beginning? What happens if there are several mismatches? What's the time complexity? Etc. Of course these would be part of the documentation, in an ideal world.
I should point out that Gabriel isn't arguing that patterns should not be abstracted (or "compressed"), only that there are tradeoffs.
However, I think when you program the pattern you have already instantiated it, anyway. At least when you used it several times throughout your program. In those cases I think it's then better to explicitly abstract it away (i.e. tell the computer you are using the pattern).
a) Learn fundamentals and working of JS (right from event loop), How modern browsers works as full blown runtime, single page applications, Functional programming paradigm etc.
b) Be able to categorize and put opensource I come across frequently, into problem buckets they solve. Started with libraries, frameworks and tools and am going one level down now
c) How massive development is now possible on browser side with kind of tooling available
d) Picked up Angular and Node for "Hello World" and some small apps for learning
e) I follow related subreddits like- r/Javascript, r/AngularJS, r/webdevelopment etc and of course lurk on HN
Architecture, and the approach to, and through it, is one of the most valuable (and transferable) skills as we spend our lives guaranteed to use new tools that somehow need to do the same things, more efficiently.
Looking at any problem and synthesizing it down to it's architecture before frameworks and language is a fun and useful exercise.
Frameworks are only helpful when modules can't easily interpret data from IO all the way to metal. The said above modular frameworks can do this and will begin to change the SPA game completely. Exciting times ahead.
It's a delicate trade-off.
Yes, it's a "library" but come on, all the framework versus principles narrative applies with that too.
Directly interacting with the DOM without abstraction seems way too risky, in exchange for some bloat.
And the principal one, moving jQuery to the "library" side and angular on the framework one, regards not the "size" (in kb) of the sources, but the usage.
jQuery is a library because it up to the developer to use it. You can see it just like a light wrapper around the browsers (incompatible) DOM manipulating API.
angular is a framework because it's not you that use it, it's you that plug it in your application and that "owns" the logic. You need to adapt your application logic to fit in the framework API.
And how is it relevant who is on working on backend or web services?
I couldn't agree more with that.
Something about not using javascript heavy frameworks for a site that displays articles.