Choosing a JavaScript Framework

shutterstock_112692424

In software development, choosing the right technology for the right job is (arguably) the most important decision a developer can make. But it’s also something easier said than done: For example, you can use many different general-purpose programming languages for the same job, and it’s not clear which one is the most suitable. At other times, a project has particular needs that only a handful of technologies or platforms can provide.

With all that in mind, let’s talk about the differences between some JavaScript frameworks, focusing in particular on how to choose the right one for the right project.

As JavaScript has grown, people have created different libraries to expand its utility in Web development. Some of those libraries, such as AngularJS and Ember, are incredibly popular. Unless you’ve actually built a few applications with each one, it’s hard to get a feel for their respective strengths and weaknesses. (I’ve met a lot of Web developers who picked what they thought was the best one, used it for a year, and then, while deep into their project with no turning back, decided they had made a mistake.)

Know What the Features Mean

Before you can really understand what the frameworks offer, you need to understand what the different features even mean. MVC? MVVC? One-way or two-way binding? And so on. We’ll get into those briefly, but before that, let’s consider a most important point:

Focus on the Final Product

When choosing a framework, focus on what you’re trying to accomplish. How sophisticated is your Web application’s front end? Will you be doing a lot of JavaScript number-crunching, and thus need easy access to the data? Or will you be creating a beautiful front end that is user-oriented but doesn’t have a lot of data manipulation?

The strength of your coding skills is still another factor in framework selection. Different frameworks allow you more leeway and freedom—but with that freedom comes the need to do more actual coding.

Some frameworks are considerably larger than others, and lock you into specific architectures. AngularJS is a good example; it’s difficult to stray outside of the suggested architecture, but the architecture comes with a long list of features that automatically take care of problems for you, which means less coding.

Compare that to a framework such as Knockout, which gives you much more flexibility, but you also have to do a lot of rolling your own to figure out what works best for you. (Ember falls in the middle, although some people might disagree.)

Models, Views, and Controllers

Most of the frameworks take different approaches regarding models, views, and controllers. The model is your data. The view is what your users see on the screen; treat it as a representation of your data. The controller is the code that manages the data.

Frameworks differ in how the models, views, and controllers are architected. A lot of developers have found a need to separate the model into two different types of data: one is the actual data stored in the database, and the other is the temporary data that assists in what the user sees on the screen. The “real” data exists in one format, but to be presented on screen, it needs to be in a slightly different “shape” in order to be manipulated by the user interface.

This need has resulted in an addition to the Model-View-Controller (MVC) architecture, with a fourth component, the Viewmodel. I found some great explanations of the difference between MVC and Model View ViewModel (MVVM) on Stack Overflow and one blog. (I will usually put additional data inside the viewmodel that isn’t part of the main data, such as a list of countries needed to populate a dropdown list.)

Data Binding

Next comes data binding. Before these frameworks existed, you had to put your controls in your HTML, and then use jQuery to read the data out. If you wanted to gather up data to be sent to a server through AJAX, you had to gather the values from your different controls; or if you were reading data from the server, you had to go through the data and populate your controls. This was a headache.

Data binding refers to copying the data values between your model and your controls on the screen. Thus, if your model has a user object containing a first name and last name, the framework will put the first name and last name on the screen automatically for you. With two-way binding, as the user modifies the first name and last name inside a control, your data automatically updates.

People have differing opinions about whether two-way binding is a good thing or not, and whether a library should allow it. Regardless of those opinions, different libraries do allow it; and if you need it, you obviously want a library that supports it.

Here’s a great video and slideshow that explains how our three libraries, Ember, knockout, and AngularJS compare on two-way binding. (Despite that support, developers have still found themselves in messy situations, particularly with AngularJS and Ember; consider carefully the implications of one- or two-way binding before going down either road.)

Examples

In all of these frameworks, you’re going to be writing code. (If you’re not comfortable writing JavaScript code, now is the time to start learning it.)

With the below example, I’m focusing on Knockout because that’s the one I’ve been using lately (which is not to say it’s always the best one for the job). Suppose you have a model that includes first name, last name, and home country, like so:

[js]

var model = {

firstName: ‘George’,

lastName: ‘Washington’,

country: ‘USA’

}

[/js]

In order to use two-way binding, you have to wrap functions around each item, using what are called observables:

[js]

var modelObs = {

firstName: ko.observable(‘George’),

lastName: ko.observable(‘Washington’),

country: ko.observable(‘USA’)

}

[/js]

You can learn the details on how this works on the Knockout website. For now, I want to point out that if you bind each member to an input box on a page, the value will immediately change in your model in response to the user’s input. If the user types “Thomas” in the first name field, you’ll get a different value when you check the firstName function:

[js]

console.log(modelObs.firstName());

[/js]

will show ‘Thomas’.

Or, if you change model, like so:

[js]

modelObs.firstName(‘Ben’);

[/js]

then the input box on the screen will immediately change. That’s what two-way binding is all about. (As an exercise, think about why you need a function to set the value, rather than a simple assignment, as least with old versions of JavaScript.)

Conclusion

There are many more frameworks out there that you’ll want to explore. If you’re looking for work as a Web developer and trying to decide which framework to learn, you should look at the requirements of the jobs that interest you. If you’ve been focusing on Ember but seeing only AngularJS in job postings of note, then perhaps it’s a good idea to explore AngularJS. That’s what will ultimately help you decide which frameworks to learn.

Image Credit: PureSolution/Shutterstock.com

Post a Comment

Your email address will not be published.