More frameworks
You’ve checked out the three major players in contemporary JavaScript frameworks. Now I’ll share information about some of the other popular frameworks including KnockoutJS, Polymer, React, and SammyJS. KnockoutJS was among the major players in the last couple years, so you'll notice that has a similar MV* pattern as the previously mentioned frameworks. Polymer, React, and Sammy have different goals, and as such could serve a different purpose in your application stack.
Knockout JS
Background
Basic Facts
Released: 2010
Stars on GitHub: 4.7k+
Dependencies: None
License: MIT License
Knockout is based on the MVVM (model-view-viewmodel) pattern, leveraging observers to keep your UI in sync with your data. Knockout has been popular in Microsoft circles, and until fairly recently (when Ember edged it out) was one of the three most popular JavaScript frameworks.
Knockout has a great tutorial and a great set of features that put it in league with the other top JavaScript frameworks – two-way data-binding, templating, and dependency tracking. It’s 46kb minified and supports older browsers, down to IE6, whereas Angular is dropping support for IE8 in 2014.
When you write Knockout, you’ll write declarative ui-bindings to communicate back with your view model. Here’s a short example, also on JSFiddle:
<input data-bind="value:myValue" />
<script>
function AppViewModel() {
this.myValue = "A value!";
}
ko.applyBindings(new AppViewModel());
</script>
PolymerJS
Background
Basic Facts
Released: 2009 (1.0 in 2013)
Stars on GitHub: 20k+
Dependencies: None, loads its own smaller jQuery library
License: MIT License
Polymer is a framework still in pre-alpha mode as of this writing, but it's already generated a lot of buzz, with well over 3k stars on GitHub. Polymer is based around web components, and it’s actually a set of polyfills, UI components/elements, and of course, a web framework to tie it all together. It’s constantly evolving, and no longer bills itself as much as a framework.
The concept of a web component is actually very similar to Angular directives, if you recall our unicorn example from earlier. Rather than binding particular behaviors to various IDs or selectors in a standard additional document, you write your own components with their own associated behaviors. Polymer's goal is to leverage the (as yet incompletely implemented) web components and other APIs and become a fully-fledged framework leveraging those capabilities.
Until when components are fully supported across the various browser vendors, Polymer requires polyfills in order to be implemented, with the idea that the polyfills will be removed once the web components capabilities available.
Polymer architecture diagram: http://www.polymer-project.org/images/architecture-diagram.svg
Caption: Polymer’s architecture diagram
If in some object-oriented languages, "everything is an object," in Polymer, everything is an element. In Polymer, you can use an element to define an AJAX call, for example.
In the world of JavaScript frameworks, Polymer is definitely a cool new kid on the block. Is definitely intriguing, in particular because it's actually leveraging technologies that theoretically will be implemented natively in the not so far (theoretical) future. Polymer has some elements that you can use already, such as the accordion element. Check out their demo and source, and the elements reference.
When checking out Polymer, it’s also worth your time to explore X-Tag and Brick, the competing libraries from Mozilla (just in case you worried this book included too many Google technologies!). X-Tag is more lightweight than Polymer, and luckily, Polymer and X-Tag have been in touch with each other and X-Tag now works off of the same polyfills used by the Polymer project, leaving a few out (such as Shadow DOM). Brick is Mozilla’s bundle of elements leveraging X-Tag, much like Polymer’s elements.
React
Background
Basic Facts
Released: 2013
Stars on GitHub: 4.7k
Dependencies: JSX is optional, but highly recommended
License: Apache License
Facebook announced their React library to a less than enthusiastic audience at JSConf US in 2013. Since then, however, the library has garnered more of a following. In particular, developers are interested in its use of a “virtual DOM” to improve performance, or using the library to do server-side rendering to solve the SEO problems many single page applications have.
React is meant to focus solely on the V in MVC, to allow you to create reusable interactive components. You’ll leverage JSX (although it’s not required) to transform XML in JavaScript. While it sounds awful, it makes some sense since you’re visualizing the DOM.
A simple Hello World in React:
<div id="hello"></div>
<script type="text/jsx">
React.renderComponent(
<h1>Hello World</h1>,
document.getElementById('hello')
);
</script>
SammyJS
Background
Basic Facts
Released: 2010
Stars on GitHub: 2.4k
Dependencies: jQuery
License: MIT License
SammyJS is a very small framework, designed to serve one major purpose: routing. You can call it a library, but many JavaScript applications developer like writing much of their own JavaScript scaffolding (rather than committing to another framework style), and sometimes all you want is routing. Knockout developers often use Sammy to fill that role in their application.
Sammy also integrates well with other libraries, being fairly unobtrusive. It extends jQuery to allow you to easily add routing and templating to a project; if that’s all you want, Sammy has you covered. Sammy was inspired by another minimalist framework, Sinatra, so it attempts to limit its own reach and focus on doing a few things very well.
Let's see an example of Sammy action:
// Yes, that’s jQuery
$.Sammy({
// simple syntax
this.use(/*a plugin*/);
});
I had the opportunity to interview Aaron Quint about his work on the Sammy framework, to hear from a contributor why he got started in what’s become a wide landscape. A few interesting points from our conversation:
On why he got started:
Aaron got started on the framework in 2008/2009, releasing it in 2010. He was inspired by the Sinatra Ruby microframework, and learned a lot from conversations with the author, Blake Mizerany. At the time, “No one was really talking about large JavaScript applications” – probably a good indicator why when we look at the frameworks in this book, at lot of them started development around the same time.
The nature of the field was that everyone was rolling their own system – structure was an exception to the rule: “I was guilty of having an application.js, or worse, a functions.js … The idea of having a framework or something simple to wrap your mind around having pages, and having actions, was kind of foreign [back then].”
On maintaining a library:
Largely, people are afraid of “abandonware”: “You see it a lot in node modules,” Aaron says. Often, it’s where a maintainer disappears, and then there’s a “new” gem/module/library filling the void (not the case with Sammy, however, Aaron’s sticking around). When I asked Aaron about continuing development on Sammy, he said, “I always wanted to keep it really, really simple. If I was to do anything, it’d be to rip things out … and make it smaller.” Sammy has a fairly active mailing list for a smaller framework, and the library still works, because it’s not a huge library.
Aaron feels that some of the larger frameworks release new builds without an especially good reason (no bug fixes, just new stuff). It brings back the point of making sure you aren’t expecting magic out of your framework: “Personally, I like JavaScript … at the end of the day, if you’re going to write JavaScript, maybe you should write some”
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.