Now that we've seen some web frameworks and action, let's discuss how to conduct your evaluation. If you skipped Chapter 2 and creating your scope/strategy document, go ahead and check it out now at http://bit.ly/1g6kDSS, where you can make a copy of the spreadsheet (File > Make a copy). It breaks down the requirements for your projected into three categories: business, technical, and team.
After seeing some frameworks in action and learning more about them, I have a few evaluation points to add under each heading. In the Google spreadsheet, there’s a second tab labeled evaluation that has these criteria added, and some of the more scope-specific (namely team counts) removed. What I’d like you to do is use the columns adjacent to the criteria to make notes about the frameworks you’re evaluating as they relate to those criteria. In the following sections I give some background on what and why some of these other criteria have been added for the evaluation process.
Business Criteria
Licensing
All of the frameworks discussed in the last section are licensed under open source licensing. When you’re evaluating a framework, make sure to note the license because they could be very relevant to your business needs.
For example, some open-source licenses actually specify that all code using that code must then be open sourced. And if you decide to go with a non-open-source framework, your company or group should be prepared to pay the licensees fees (if applicable) over the lifecycle of your application. Licenses are sometimes overlooked in framework evaluation, but it is something that’s better to look out in the front of a project rather than when it’s too late.
Most of the frameworks in the previous section are MIT-licensed, meaning they can be freely used for commercial purposes. If you work for a large corporation, your company may already have a policy about what open source licenses are approved/pre-approved.
Technical
The technical portion of your evaluation has a few extra components than the scope definition. You need to evaluate the framework as a maintainable and iteration-friendly option. Will your code evolve as your application does?
Core
Does the core of the framework have what you need (and things you get, but don’t need, are just junk)? During the framework discussion chapters, we saw two-way data binding and web components as features that could stand out for thing you need/don’t. The core of the framework is ideally just enough of what you need to abstract out things you don’t care to write – the things that aren’t part of that 15% that makes your application special.
Evaluating the core is also where to determine how much “lock-in” you’re willing to take. Angular and Ember commit you fairly strongly to their paradigm, while Backbone and Sammy might require more boilerplate to get started, but could be seen as more flexible. It’s good to remember, however, as Aaron Quint said, “No matter what, at a certain point, you have to write some JavaScript.”
Data
How do you want to abstract your data in your app? You noted the kind of data you plan to work with in the scope document, but now you’ve seen how the various frameworks handle models for data.
Testing
Does the framework come with testing? Is it the kind you want? A new project is a great opportunity to create a culture of testing if you don’t yet have one. Ember and Angular both emphasize testing. Look into encouraging your developers to adopt a TDD or BDD approach to development.
Documentation
How’s the documentation for the framework you’re evaluating (which will help you both on your first and your worst day)? Is it clear and thorough or confusing with large gaps?
Popular JavaScript frameworks have upped their documentation game over time (especially when you compare that to some server-side framework’s documentation). However, you might give more points to Ember for their easy-to-read and accessible documentation over Angular’s sometimes brain-hurt style of documentation.
Extension & Plugins
How extensible is it? Is it painful or enjoyable to plugin and extend (i.e., if you write something yourself, it’s gravy, and on the other hand, chances are, someone’s already written a plugin for your needs). Some frameworks don’t play well with external libraries. A common question is about jQuery, and now all of the major frameworks work with jQuery on the page.
Security and Speed
Does the framework have a record of maintenance/patches? And are those things accessible and simple to implement? Does the framework recognize and cover common vulnerabilities (ex. injection, etc.)?
Most of the major frameworks have you covered well in this respect. Additionally when you’re communicating via a REST-ful API, as common with a client-side application, the security for your database happens on the server.
Team
Project longevity
How long has the framework been around? How long will it be around? This will greatly impact your ability to hire. If it hasn’t been around, then no one’s done it, and a few years down the road, if it’s out of date, no one will want to be doing it.
I believe this factor is the greatest source of anxiety for people choosing a JavaScript framework. It feels like you’re gambling. So I suggest also taking this criterion with a grain of salt. It’s highly unlikely, if not impossible, that your application will exist with the same framework in 10 years, or even 5 years.
This also matters more for opinionated and domain-centric frameworks (ex “I need to hire an Angular developer”). If you go with a less opinionated framework, there’s a good chance someone can come late in the game and get the basic concepts, in contrast to a framework that requires large domain knowledge.
Community
One of the greatest benefits of adopting an open source solution is “googleability” of your software. When I’ve used proprietary libraries, no matter how good the documentation is, this is their weak spot. I have to resign to emailing support when I couldn’t find what I need rather than searching Stack Overflow.
Find out if there are there user groups, conferences, screencasts, etc. for your team to skill up with. Do questions on the mailing list get answered or go into a black hole? Community help is “free” (because you really ought to give back), so don’t underestimate the value it can provide.
Learning Curve
If it takes your people a year to get decently skilled at the chosen base (and no one decent is on your team) that means in a year you’ll have an unhappy, bloated application. Giving your people the time to learn “the right way” is key to success in any new project. This could also meaning pulling in an experienced consultant to mentor your team for the beginning of the project.
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.