View From The Front: JavaScript MVC Frameworks Crash Course

JavaScript MVC Frameworks

The Rise of JavaScript MVC Frameworks

There was a time when front-end web authoring technologies were the “V” of MVC frameworks. As user interaction became more complex, JavaScript MVC frameworks became necessary in order to meet those needs. In this article, you’ll get the gist of what’s popular today, and what’s on the horizon tomorrow.

When to Use A JavaScript MVC Framework

JavaScript MVC frameworks aren’t suitable for every project, but for the right projects, they are clutch. These include single page apps, pages with large datasets being frequently requested and changed, pages with complex user interactions, or likely all of the above. e.g. WordPress and Drupal dashboards.

The Popular MVC Frameworks in Town

There are currently three popular open source JavaScript MVC frameworks:



  • Easy to onboard and take to cruising speed
  • Maintained by Google developers (curiously, no notable Google project to date was written in it)
  • Has the most adoption and buzz among its peers, along with an active Github repo
  • Lots of Silicon Valley startup projects use it, hence more available expertise out in the wild
  • Lots of Angular modules and 3rd-party directives


  • HTML markup-purists object to its unconventional “ng-” directives polluting the markups
  • Too many unresolved pull requests and bugs
  • Core team declared there will be no new features until version 2 and the upgrade path is uncertain (more on this later)
  • Open-ended framework leaves lots of trivial decision-making to developers



  • Considered the “grandfather” of JavaScript MVC frameworks; very stable APIs
  • Extremely flexible, easy to onboard and be productive in
  • Robust documentation and plenty of resources on Google and StackOverflow
  • Small and lightweight in size
  • Suitable for projects of almost any size


  • Development has been stagnated since version 1.1.x; lack of forward momentum inspired projects like Marionette to consolidate and organize common Backbone patterns
  • Its simplistic approach means many technically trivial choices are deferred to developers which could mean more code
  • It’s easy for the codebase to look very different in parts of the same project (even for a small team of three developers) if there’s no established and enforced coding conventions; this leads to unmaintainable projects



  • Maintained by established JavaScript and Rails veterans (this translates to arguably better framework architecture)
  • Runs on “convention over configuration” methodology — “Magic” happens if you follow conventions (e.g. you rarely have to handle ajax anymore); this has added benefits:
    • Internal dev team does not have to reinvent common patterns and conventions, implicitly enforcing code consistency
    • Trivial technical design decisions are handled by the framework (e.g. ajax lifecycle, event (re)binding… etc)
    • On average, you write a lot less code
  • Active community with a busy Github repo
  • Clockwork six-week release cycle
  • Framework rapidly evolves and features are added through a transparent and community-driven process; major API changes go through RFCs for feedback; “The Road to Ember 2.0” RFC is a great example (contrast to Angular); this leads to predictable and less stressful upgrade visibility
  • Active #emberjs and #ember-cli IRC channels (gasp!) for almost real-time support
  • Shipped with a test framework built right in!


  • More painful ramp up than other frameworks (ember-cli, node.js dependency… etc)
  • Emphasis on conventions can turn off some developers
  • Rapid release schedule can take its tolls:
    • Conflicting and outdated documentation
    • Google search and StackOverflow results often contain outdated solutions
    • Time allocated to framework upgrades adds up if you want to keep up (you should); fortunately this is mitigated by well documented release docs
  • Existing in-house JavaScript libraries may need modifications to work with Ember

The Current State of Affairs

Angular announced in its v2 roadmap that there’ll be no upgrade path from existing Angular versions. I can’t imagine large Angular apps being rewritten to compensate for the Angular team’s lack of foresight. The roadmap also deferred all new features to v2, which effectively orphans the current Angular 1.x project.

Backbone has seen slow but steady releases. There’s no sign of the framework going away or seeing major upgrades. I don’t expect this to change soon. But it’s mean, lean, easy and works right now.

Ember has the least adoption of the three. But it garners a disproportionally active community with rapid releases and new features. Unlike Angular, the Ember core team pledged a clear upgrade path to Ember v2, to be released in 2015.

Parting Thoughts

Angular’s core team has painted itself into a tough corner. Until a clear upgrade path is announced, you should steer clear of Angular for projects besides throwaway prototypes. Then there’s Backbone, a safe bet for projects big or small — A gateway MVC framework before diving into other beasts. But be mindful of the freedom it affords. Ember is a tough nut to crack, but once your team gets used to its conventions, the architecture will redeem itself with less code, implicit code style consistency and easier cross-team collaboration.

Before you decide on a framework, visit ToDoMVC and take all the different JavaScript MVC frameworks out for a spin. Decide for yourself what’s best for your projects. With the Javascript community moving to ES6 modules (using compatible transpiling), whatever framework you choose, be sure to put that on your checklist for forward compatibility.

Happy coding!

View From The Front: You should really learn HTML

You Should Learn HTML


Working in the web arena I find myself more often than not with my back against the ropes facing down my own learning curve. I’m constantly getting pummeled by an onslaught of new technology and improved methodologies. At times it feels like I’m striving and struggling just so I can live to fight another day.

The front end of the web experience is where everything comes together…

or falls apart.

Lately I am astonished at how often I meet a web professional who doesn’t know the basics of HTML and CSS. I’m talking about people way more intelligent and talented than I am who can do amazing things in worlds where I only dabble: design, SEO, even advanced software development.

These same people can’t clear a floated div without flipping a table or banging their heads on their desks.

There are also those who are new to the web, who have the privilege of getting started with robust frameworks that function great, right out of the box. Still others prefer to stay out of code completely and leverage GUI editors, which are becoming better able to generate decent looking, usable websites.

I can see why it’s tempting to skip learning to code web pages by hand, but in the ever-changing technical landscape, having a fundamental understanding of HTML, how it’s affected by CSS, and the basic operation of the box model is still a necessary and useful skill.

What is so great about HTML?

With HTML5, semantic data is inherently integrated into your markup. HTML gives your content structure by breaking it up into meaningful sections, adding a hierarchical flow to the content. In an HTML page, your content is structured into sections which make sense for both search engine robots and your end users. Adding CSS to style your markup lets you change the way the content looks. You have the opportunity to give your content even more visual nuance to convey a deeper meaning and create a greater impact. You have the ability to articulate the meaning of your content in a visually rich and organized way.

Is HTML even still relevant?

The web is constantly changing, and the tools we use to create it are constantly improving. And yet, HTML has been around since the beginning. But this doesn’t mean it’s obsolete or irrelevant; rather, it demonstrates HTML’s ability to adapt and move forward in pace with the web.

For some applications it makes sense to bypass HTML almost entirely in favor of a robust language like JavaScript; but if your aim is simply to display content in a web browser, using HTML as your foundation and then enhancing with JavaScript gives you better accessibility.  Mobile apps built with HTML5 and responsive design using CSS media queries is making web content device-agnostic. If you want to target the largest number of web-capable devices and keep with the best practice of progressive enhancement, HTML is still highly relevant.

Aren’t there GUI  web builders that do just fine?

I’m not typically a drag-and-drop kind of girl. I recently built a dummy web page with Wix during half of a lunch break while trying to fight off a nasty flu. I got the job done (that is, I published some content to the web), but there were still limitations which I could have easily overcome if I were simply coding HTML. Instead I had to struggle with, and eventually give up on, the limitations in the GUI – such as the fixed 980 pixel page width.

Other common frustrations that come up when helping non-tech people use GUI web editing tools include: extra line breaks that appear for no reason, images aligning to text in inexplicable ways, and text links that don’t encompass the first or last character in your link phrase despite all your best efforts. Even the best GUI experience leave something to be desired, and the ability to switch to code or text view and see quickly what’s going on can save hours of frustration.

My favorite front-end framework is awesome, why reinvent the wheel?

I’m not advocating that you code every web experience you build from scratch. Even though I enjoy it, I understand that people have other things they’d rather be doing with their time. What I do advocate is to cultivate the ability to code a webpage by hand so that, if there are pieces in your framework that get in your way, you are empowered to not just overwrite, but re-write them. You gain the ability and confidence to identify and remove pieces that you don’t need in order to achieve the best performance, and keep your CSS well organized, lean and easy to revise.

I’m a (Designer/Programmer/SEO/Content Writer). Knowing HTML isn’t my job.

Everyone who works in web can benefit from knowing HTML. The front end of the web experience is where everything comes together, or falls apart. If everyone on the team knows what goes into rendering the project in the browser, then everyone can integrate their specialty more fluidly into the whole. The programmer can understand the semantic markup to wrap around database queries. The designer can anticipate content reflow from the wide monitor to the narrow handheld view. The content writer can direct the nuance in the language by leveraging structural tags. The SEO can polish the well structured page with additional micro- and meta-data. Sure, the front end developer still does the bulk of the HTML coding, along with the PHP and JavaScript and whatever else is needed to tie it all together; but if HTML is a shared context among all the members of the team, the odds of telling a successful story are greatly increased.


HTML is a future-friendly technology because it is a present-friendly technology, highly accessible on all web-ready devices. Writing good HTML has benefits in accessibility, performance, and presentation. Learning it might seem challenging at first, but it doesn’t take long to get up and running. The only tools you really need to get started are a text editor and a web browser. Once you get a firm grasp on the basics it becomes fun and easy to learn more.