官术网_书友最值得收藏!

Frameworks versus libraries

Why use a mash-up of smaller libraries when there's a monolithic framework out there with everything that we need? Libraries are our tools, and if they fulfill a need in our architecture, by all means use them. Some developers shy away from low-level tools because of the dependency-chaos that ensues. In practice, this happens anyway, even if we're leveraging an all-encompassing framework.

At the end of the day, the distinction between frameworks and libraries doesn't really matter to us. Creating a third-party dependency nightmare doesn't scale well. Neither does sticking with one tool exclusively and maintaining a lot of code ourselves. It's about finding the right fit between depending heavily on other projects and reinventing the wheel ourselves.

Implementing patterns consistently

The tools we use to help implement our architecture do so by exposing patterns common throughout JavaScript applications. And they do so consistently. As our application scales in size due to a growing featureset, we can apply the same framework components over and over. Frameworks also promote consistency in the patterns we implement ourselves. If we look at the internals of any framework, we will see that it has its own generic components; these are extended to provide us with usable components.

Performance is built in

Open source frameworks have the most developers looking at the code, and the most projects using the framework in production. They get lots of feedback from the community of users, and these include performance enhancements. Third-party tools are the right place to focus on performance, because they're likely the most utilized code in a given application. Leaving all performance outcomes up to browser vendors and JavaScript libraries isn't smart. Leveraging the performance behind components we use all the time is smart.

Leverage community wisdom

Successful JavaScript frameworks have strong communities surrounding them. This is more powerful than having robust documentation because we can ask questions as they arise. Odds are, someone else is trying to do something similar in their project, using the same framework as us. Open source projects are like a knowledge engine; even if the exact answer we need isn't out there, we can often find enough through the wisdom of the community to figure it out ourselves.

Frameworks don't scale out-of-the-box

Saying one framework scales better than another isn't justified. Writing a TODO application as a benchmark for how well the framework scales is hardly useful. We write TODO applications to get a feel for the framework, and how it compares to others. If we're unsure about which framework fits our style, a TODO application is a good start.

Our goal is to implement something that scales well in response to influencers. These are unique and unknown upfront. The best we can do is make predictions about what scaling influencers we'll likely be hit with in the future. Based on these likely influencers, and the nature of the application we're building, some frameworks are better candidates than others. Frameworks help us scale, but they don't scale for us.

主站蜘蛛池模板: 林州市| 华池县| 大姚县| 嘉义县| 岑溪市| 鄯善县| 南充市| 白沙| 阳谷县| 武山县| 沂源县| 夏河县| 株洲市| 周宁县| 永宁县| 丰县| 尚义县| 沈阳市| 盖州市| 翼城县| 嘉峪关市| 陆川县| 偏关县| 昌都县| 平罗县| 卫辉市| 长岛县| 巴塘县| 南乐县| 农安县| 轮台县| 霍州市| 壤塘县| 缙云县| 麻江县| 烟台市| 长岛县| 韶山市| 郁南县| 晋城| 大渡口区|