
Do Not Learn Frameworks – Learn the Architecture - skazka16
http://kukuruku.co/hub/programming/do-not-learn-frameworks-learn-the-architecture
======
ef4
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.

~~~
coldtea
> _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...

~~~
jkire
_> 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.)

~~~
vinceguidry
> 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.

------
xtrumanx
Let's say I'm building a web app and develop my own patterns and practices.
Obviously it'll be a bad idea to have everyone working on my project create
their own patterns and will make sense to mandate everyone follow one set of
patterns so we don't have to keep context-switching whenever we're working on
a different part of the app.

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.

~~~
pags
The difference is that the framework is built to be an open source framework -
it has general abstractions.

Your own patterns and practices are developed to apply directly to what you're
building.

~~~
acjohnson55
But a good framework has well chosen abstractions that took many person-hours
to settle upon, a community of engineers working to perfect it, and probably
uncountable hours of production battle-testedness.

~~~
jdlshore
> has well chosen abstractions

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.

~~~
acjohnson55
Not all frameworks. Good frameworks. The best incorporate the lessons learned
from working with previous frameworks.

------
shawn-furyan
The biggest counterpoint that I can think of to actually putting your own
framework into production, especially if it's a one man/woman show, is
security. A large open source framework will have implemented and fixed a ton
of security blunders which you will not have. It doesn't really matter how
encyclopedic your knowledge of software architectural patterns is, even though
design is important for system security, there is a large component that is
case-by-case attack mitigation. Your almost always going to be better off with
a security conscious framework than with an ad-hoc framework.

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.]

------
fsk
>Do I use frameworks? Only when it's not required to maintain a product in
future.

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.

~~~
a_c_s
I've been there a couple of times, dealing with abused frameworks can be
rather painful!

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?

------
maxpupmax
So this is neat and all, and I'm all about learning more about whatever... but
what does it mean to learn the architecture? It's not stated in the article
where this is useful to me personally (in terms of experience), and I assume
for others like myself. What does it mean to write something in javascript
with "module libraries" only? That doesn't mean anything to me.

Does anyone have specific recommendations on how to pursue what the author
suggests?

~~~
Scarbutt
Javascript does not have built-in support for modules, so he is using a
library to have module support.

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.

~~~
saiprashanth93
This is still a little vague. What does it exactly mean to learn
architecture?? Should I be reading the source of the framework and understand
how all the design patterns fit in?? How well should one know the language to
read the source of the framework?

~~~
Digit-Al
Free online book discussing design patterns using Javascript:
[http://addyosmani.com/resources/essentialjsdesignpatterns/bo...](http://addyosmani.com/resources/essentialjsdesignpatterns/book/)

------
jmatsushita
A lot of folks here ask how to learn architecture. I really love this intro
statement from "The Architecture of Open Source Applications"[1] and higly
recommend reading the book!

"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."

[1] [http://aosabook.org/en/index.html](http://aosabook.org/en/index.html)

------
prank7
I have been doing web development for last 1 year. Can someone recommend a
resource to learn Architecture?

~~~
jdlshore
Martin Fowler's _Patterns of Enterprise Application Architecture_ is
excellent.

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.

~~~
gedrap
Yes, your point of making it unnecessary is really important. When you see
patterns, etc. for the first time, it gets very tempting to over engineer
stuff.

------
felipellrocha
I generally agreed with the article. I think people concentrate too much on
learning the specifics of frameworks, and forget about the underlying ideas
behind the frameworks itself.

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.

------
aikah
This is a false dichotomy but I'm not surprised, especially in the js world.
JavaScript is so little opinionated that developers refuse to read each others
code, because it's usually not written in the way they think js should be
written. And soon it will be worse with classes,proxies and all the python
like "ninja" features of ES6.

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.

~~~
z3t4
One of the great things about JS is that you can (unless minified) look at the
source code. That's how I have learned JS and are still learning! Most times
when looking at other peoples code you learn how not to code though ... But
once in a while you find a gem and a light bulb lights up in your head.

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.

------
fsk
The problem is that job ads always say "We want experience in X, Y, Z." They
never say "We want someone who can code without a framework, and could learn
whatever we're using quickly."

~~~
morgante
Good companies want you to be able to code well. They don't care if you know
the framework or even the language.

~~~
aikah
> Good companies

Good companies want both good coders AND coders with experience in the
language or the plateform they use.

------
tracker1
One thing that I think is especially true with this mindset, is that being
able to pull in just about any utility via npm has really changed the
landscape for JS development.

------
swalsh
I'm going to admit, I didn't finish the article. So, I apologize if my point
is useless. I've done plenty of web development before Angular/backbone etc.
The productivity that I've experienced after becoming proficient in these
frameworks more then makes up for any debugging issues. My other experience is
that though sometimes it may take a tediously long time to figure something
out, once you get it working... it just works.

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.

~~~
phatbyte
I think you missed the point of the article, you should've read it all. The
author doesn't say JS frameworks aren't productive. He said that developers
should also learn software architecture. It's a good advice imo.

------
asgard1024
I think patterns are stupid idea. You bother learning a way of doing things
(the _pattern_ ), and you bother all you colleagues learning that way of doing
things. OK, cool, that sounds good.

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.

~~~
mbrock
Richard P. Gabriel critiqued this notion of "patterns should be abstracted and
instantiated" in his 1996 book _Patterns of Software_ [1].

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](https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf)

~~~
malisper
> Richard P. Gabriel critiqued this notion of "patterns should be abstracted
> and instantiated"

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

Gabriel then goes on to argue that the advantages of the first one (that it is
more efficient and more compact) go away once faster computers and good
editors are thrown into the mix. I completely disagree with this. Just try to
figure out what test is being used in the second example. The first example
clearly says:

    
    
      :test #'baz
    

That tells me that the test is baz. In the second example, there is no such
indication. You have to actually parse the entire piece code to figure out
where the test is. This makes a huge difference not only in reading code, but
also in debugging code. There are many more things that could go wrong in the
second piece of code than in the first. If there was a bug in both examples,
it would be much easier to find it in the first example since there is so much
less of it. This is just like Hoare's saying, "There are two ways to write
code: write code so simple there are obviously no bugs in it, or write code so
complex that there are no obvious bugs in it". In the first example there are
obviously no bugs since the code is so simple. In the second, it is much
harder to tell since there are so many more things going on than in the first.

~~~
mbrock
I wouldn't claim conclusively that the second version is better, but I see
Gabriel's point. Yes, the first version is elegant, and it is easier to spot
the predicate—but I also can't tell you exactly how the predicate is used,
because I don't know the definition of MISMATCH.

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.

------
mgob
Any recommendations for learning web app architectures for an otherwise
experienced back-end dev?

~~~
sanmon3186
I am in the same boat as you. Though web development is not my primary job,
this is how I learn it in my spare time. Would love to hear from others.

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

------
phatbyte
I agree with the author. As a self-taught developer I have fallen into the
"learn frameworks" trap in the past, but once I started to really study
computer science, SOLID practices, patterns and so on...oh boy what a eye
opener.

------
j45
One of the best lessons I've learnt from mentors is that meaningful
architecture that is even a little clever will most often make more of an
impact on a project than any particular framework or language, because many
are reasonably capable.

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.

------
tehchromic
Or learn the architecture by learning lots of frameworks

------
spectrum1234
Typical frameworks will soon enough become less popular as "modular"
frameworks are beginning to surface. See Aurelia or Este.js or even web
components.

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.

~~~
crdoconnor
'Modular' frameworks often commit the error of giving too much freedom to
developers to use their own patterns, which end up being incompatible when
they are combined together.

It's a delicate trade-off.

------
decentrality
Wondering where jQuery fits in the author's mind right about now.

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.

~~~
_ZeD_
Sincerely, the difference between jQuery and angular.js, imho, are obvious.

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.

------
tux
Good article, I agree with learning architecture first. No one should start
learning by using framework first. But don't forget about "loosely coupled"
frameworks like PhalconPHP. It allows you to code your own without using pre-
built one.

~~~
aryamaan
What does it exactly mean to learn architecture?

And how is it relevant who is on working on backend or web services?

~~~
jmatsushita
About learning architecture:
[https://news.ycombinator.com/item?id=9314911](https://news.ycombinator.com/item?id=9314911)

------
reddyb
"They are the guys who have been in the industry for 10 years, just like me,
but they studied specific solutions rather than principles."

I couldn't agree more with that.

------
task_queue
This blog slows to a crawl on a 4 core phone with 3 GB of RAM.

Something about not using javascript heavy frameworks for a site that displays
articles.

------
thegreatpeter
TLDR; You start out as a noobie, you get better and learn from your mistakes.

------
symlinkk
Ok, so I want to "learn architecture." How do I do that?

~~~
jmatsushita
Check this:
[https://news.ycombinator.com/item?id=9314911](https://news.ycombinator.com/item?id=9314911)

------
known
Best advice I've seen for a longtime;

------
jbeja
I agree with and I want to add that using this approach is more effective is
you are using statically types language, which can set upon more rules and
constraints to the architecture vision; design patterns and frameworks can
only get you so far

