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