11–20 of 86 posts
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.
Does anyone have specific recommendations on how to pursue what the author suggests?
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…
Your own patterns and practices are developed to apply directly to what you're building.
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.
It's a delicate trade-off.
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."
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.
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…
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.
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…
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.