11 ms·

Do Not Learn Frameworks – Learn the Architecture

187 points by skazka16 12y ago

tracker1 12y ago
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.
solids 12y ago
Totally agree. Frameworks may become obsolete or abandoned by their mantainers, but the key ideas of each one will remain.
fsk 12y ago
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."
- wdewind 12y ago
  Hi. We use Ruby on Rails, we want someone who can code without a framework and could learn whatever we're using quickly.
- morgante 12y ago
  Good companies want you to be able to code well. They don't care if you know the framework or even the language.
  - aikah 12y ago
    > Good companies Good companies want both good coders AND coders with experience in the language or the plateform they use.
  - pacala 12y ago
    Not so good companies have a mess of broken systems. You end up spending more time reverse engineering random bugs in the systems than actually doing any forward progress. Knowing the bugs of a specific framework thus becomes a precious skill.
  - curiously 12y ago
    >They don't care if you know the framework or even the language. 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."
- benihana 12y ago
  I hear what you're saying, but there were several posts and job ads in the who's hiring thread the other day saying "we don't care if you know $technology_in_our_domain, we want quick learners who understand concepts."
  - fsk 12y ago
    I replied to a couple of ads that said that. I didn't get a phone interview.
fsk 12y ago
>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 12y ago
  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?
tux 12y ago
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 12y ago
  What does it exactly mean to learn architecture? And how is it relevant who is on working on backend or web services?
  - tux 12y ago
    Please read the article before you comment.
  - jmatsushita 12y ago
    About learning architecture: https://news.ycombinator.com/item?id=9314911 https://news.ycombinator.com/item?id=9314911
symlinkk 12y ago
Ok, so I want to "learn architecture." How do I do that?
- jmatsushita 12y ago
  Check this: https://news.ycombinator.com/item?id=9314911 https://news.ycombinator.com/item?id=9314911
xtrumanx 12y ago
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 12y ago
  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 12y ago
    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.
    - pags 12y ago
      I'm not sure that time and bodies necessarily produce good abstractions.
    - jdlshore 12y ago
      > 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.
decentrality 12y ago
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_ 12y ago
  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.
- mbrock 12y ago
  jQuery can't stop you from creating and using abstractions.
spectrum1234 12y ago
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 12y ago
  '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.
maxpupmax 12y ago
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 12y ago
  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 12y ago
    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?
    - seanp2k2 12y ago
      E.g. Learn how frameworks are built and what design patterns they implement. http://en.m.wikipedia.org/wiki/Software_design_pattern http://en.m.wikipedia.org/wiki/Software_design_pattern could be a good place to start, if only to get ideas on more things to learn about. You don't have to know a language amazingly well to start picking apart a framework, but it might be helpful to be tenacious enough to go look up and play with the programming concepts they're using which you don't yet understand. 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.
    - 12y ago
jbeja 12y ago
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
felipellrocha 12y ago
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.
mgob 12y ago
Any recommendations for learning web app architectures for an otherwise experienced back-end dev?
- sanmon3186 12y ago
  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
tehchromic 12y ago
Or learn the architecture by learning lots of frameworks
j45 12y ago
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.
asgard1024 12y ago
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 12y ago
  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
  - asgard1024 12y ago
    Thanks, didn't know the book, looks like an interesting read. 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).
  - malisper 12y ago
    > 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.
swalsh 12y ago
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.
- the_cat_kittles 12y ago
  ok, but what specifically made it so much better?
- curiously 12y ago
  6 months planned and you get it done in 2 weeks...something tells me you should not be in project management.
- phatbyte 12y ago
  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.
ef4 12y ago
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.
- akurilin 12y ago
  This is actually 100% my experience, wow. 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.
  - coldtea 12y ago
aikah 12y ago
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 12y ago
  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.
jmatsushita 12y ago
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
phatbyte 12y ago
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.
deleted 12y ago
[deleted]
reddyb 12y ago
"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.
prank7 12y ago
I have been doing web development for last 1 year. Can someone recommend a resource to learn Architecture?
- thruflo 12y ago
  Learning and looking at the internals of frameworks like Rails and Pyramid can be useful. There's a good book http://aosabook.org/en/index.html 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.
- jdlshore 12y ago
  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 12y ago
    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.
thegreatpeter 12y ago
TLDR; You start out as a noobie, you get better and learn from your mistakes.
task_queue 12y ago
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.
shawn-furyan 12y ago
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.]
known 12y ago
Best advice I've seen for a longtime;

187 points by skazka16 12y ago

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.

solids 12y ago

Totally agree. Frameworks may become obsolete or abandoned by their mantainers, but the key ideas of each one will remain.

fsk 12y ago

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

wdewind 12y ago
Hi. We use Ruby on Rails, we want someone who can code without a framework and could learn whatever we're using quickly.
morgante 12y ago
Good companies want you to be able to code well. They don't care if you know the framework or even the language.
- aikah 12y ago
  > Good companies Good companies want both good coders AND coders with experience in the language or the plateform they use.
- pacala 12y ago
  Not so good companies have a mess of broken systems. You end up spending more time reverse engineering random bugs in the systems than actually doing any forward progress. Knowing the bugs of a specific framework thus becomes a precious skill.
- curiously 12y ago
  >They don't care if you know the framework or even the language. 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."
benihana 12y ago
I hear what you're saying, but there were several posts and job ads in the who's hiring thread the other day saying "we don't care if you know $technology_in_our_domain, we want quick learners who understand concepts."
- fsk 12y ago
  I replied to a couple of ads that said that. I didn't get a phone interview.

fsk 12y ago

>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 12y ago
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?

tux 12y ago

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 12y ago
What does it exactly mean to learn architecture? And how is it relevant who is on working on backend or web services?
- tux 12y ago
  Please read the article before you comment.
- jmatsushita 12y ago
  About learning architecture: https://news.ycombinator.com/item?id=9314911 https://news.ycombinator.com/item?id=9314911

symlinkk 12y ago

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

jmatsushita 12y ago
Check this: https://news.ycombinator.com/item?id=9314911 https://news.ycombinator.com/item?id=9314911

xtrumanx 12y ago

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 12y ago
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 12y ago
  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.
  - pags 12y ago
    I'm not sure that time and bodies necessarily produce good abstractions.
  - jdlshore 12y ago
    > 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.

decentrality 12y ago

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_ 12y ago
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.
mbrock 12y ago
jQuery can't stop you from creating and using abstractions.

spectrum1234 12y ago

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 12y ago
'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.

maxpupmax 12y ago

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 12y ago
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 12y ago
  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?
  - seanp2k2 12y ago
    E.g. Learn how frameworks are built and what design patterns they implement. http://en.m.wikipedia.org/wiki/Software_design_pattern http://en.m.wikipedia.org/wiki/Software_design_pattern could be a good place to start, if only to get ideas on more things to learn about. You don't have to know a language amazingly well to start picking apart a framework, but it might be helpful to be tenacious enough to go look up and play with the programming concepts they're using which you don't yet understand. 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.
  - 12y ago

jbeja 12y ago

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

felipellrocha 12y ago

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.

mgob 12y ago

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

sanmon3186 12y ago
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

tehchromic 12y ago

Or learn the architecture by learning lots of frameworks

j45 12y ago

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.

asgard1024 12y ago

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 12y ago
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
- asgard1024 12y ago
  Thanks, didn't know the book, looks like an interesting read. 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).
- malisper 12y ago
  > 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.

swalsh 12y ago

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.

the_cat_kittles 12y ago
ok, but what specifically made it so much better?
curiously 12y ago
6 months planned and you get it done in 2 weeks...something tells me you should not be in project management.
phatbyte 12y ago
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.

ef4 12y ago

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.

akurilin 12y ago
This is actually 100% my experience, wow. 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.
- coldtea 12y ago

aikah 12y ago

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 12y ago
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.

jmatsushita 12y ago

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

phatbyte 12y ago

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.

deleted 12y ago

[deleted]

reddyb 12y ago

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

prank7 12y ago

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

thruflo 12y ago
Learning and looking at the internals of frameworks like Rails and Pyramid can be useful. There's a good book http://aosabook.org/en/index.html 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.
jdlshore 12y ago
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 12y ago
  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.

thegreatpeter 12y ago

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

task_queue 12y ago

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.

shawn-furyan 12y ago

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

known 12y ago

Best advice I've seen for a longtime;