by skazka16 on 4/3/15, 1:59 AM with 82 comments
by ef4 on 4/3/15, 6:36 AM
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.
by xtrumanx on 4/3/15, 3:49 AM
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.
by shawn-furyan on 4/3/15, 3:13 PM
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.]
by fsk on 4/3/15, 3:17 AM
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.
by maxpupmax on 4/3/15, 4:17 AM
Does anyone have specific recommendations on how to pursue what the author suggests?
by jmatsushita on 4/3/15, 8:29 AM
"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."
by prank7 on 4/3/15, 12:31 PM
by felipellrocha on 4/3/15, 5:00 AM
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.
by aikah on 4/3/15, 7:53 AM
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.
by fsk on 4/3/15, 3:14 AM
by tracker1 on 4/3/15, 3:09 AM
by swalsh on 4/3/15, 6:29 AM
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.
by asgard1024 on 4/3/15, 6:27 AM
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.
by mgob on 4/3/15, 5:14 AM
by phatbyte on 4/3/15, 9:34 AM
by j45 on 4/3/15, 5:53 AM
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.
by tehchromic on 4/3/15, 5:37 AM
by spectrum1234 on 4/3/15, 4:08 AM
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.
by decentrality on 4/3/15, 3:49 AM
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.
by tux on 4/3/15, 3:23 AM
by reddyb on 4/3/15, 11:38 AM
I couldn't agree more with that.
by task_queue on 4/3/15, 2:29 PM
Something about not using javascript heavy frameworks for a site that displays articles.
by thegreatpeter on 4/3/15, 1:40 PM
by symlinkk on 4/3/15, 7:21 AM
by known on 4/3/15, 5:31 PM
by jbeja on 4/3/15, 4:36 AM