![[ERR!]](https://pbs.twimg.com/profile_images/860485252984254466/x_8I4E6d_normal.jpg)
336 Views
Nowadays, in front-end development, we have many frameworks and libraries. Some of them are good, some of them are not. Often we only like a particular concept, module or maybe a certain syntax. The truth is that there is no universal instrument. This article is about the future framework — the framework that does not exist yet. I’ve summarized the pros and cons of some of the available JavaScript frameworks and I dare to dream about the perfect solution.
1 comments
Drew Peterson
11/3/2014 7:08:52 PM
That's sort of the lifelong struggle isn't it? I want to go fast but I want to know/control how it works.
I think the author highlights one of the ways to make control available while keeping things tidy and convenient when discussing constructors. The simple act of giving me an object to mess with before you go do something with it is key. The same kind of thing can be achieved by accepting a configuration function as part of the constructor. It still feels like a nice abstraction, but allows as much or little control as you need.
One thing I'll bring up is that design patterns matter much more than the level of abstraction. A poorly designed framework with one level of abstraction isn't going to be any easier to understand than a well designed system with 10 levels of abstraction. I personally find myself more productive with a little more abstraction, as long as it's well designed. I'm sure most developers here have found themselves writing convenience methods to take care of boilerplate work as they build a system, if not building their own framework on top of something like Backbone, et al.