JavaScript MVC frameworks

8:27 PM Xun 2 Comments

MVC has been having a great run for a while (a long while). It was introduced in the computer's stone age (the 70s, the first micro processor, the floppies, main frames), morphed into a well-accepted architectural theory in the bronze age (the 80s, IBM, computers for personal use became possible). Then computers and the internet and mobile devices became our overlords, exploding in power and complexity. To rein in the complexity and keep us from being entangled in the web of our own weaving, MVC becomes the default and de facto application architecture.

We all know now the three legs of the MVC stool:
Models - Data, business rules, logic, etc.
Views - Presentation layer, be it a chart, a table, an image gallery. The front end of things
Controllers - The link between model and view, the commander-in-chief that takes signals and issues command.
 


On the server side, we have a set of big players and well established design patterns and architectures. Ruby is the trail blazer that first goes MVC in full throttle. ASP .net MVC soon followed suit, moved over from the web form development model where UI is tightly coupled with the code-behind logic. ASP .net MVC provides powerful view engine, various routing techniques, and flexible controllers that accept and return data in the formats requested.

On the client/JavaScript side, the playground is always more diverse therefore more interesting and more confusing.

JavaScript MVC frameworks

Briefly searching the web on JavaScript MVC frameworks, you get a dozen and still counting. According to infoQ's research, the following are the top MVC frameworks:

Backbone.js: Provides models with key-value binding and custom events, collections, and connects it all to your existing API over a RESTful JSON interface.
AngularJS: A toolset based on extending the HTML vocabulary for your application.
Ember.js: Provides template written in the Handlebars templating language, views, controllers, models and a router.
Knockout: Aims to simplify JavaScript UIs by applying the Model-View-View Model (MVVM) pattern.
Agility.js: Aims to let developers write maintainable and reusable browser code without the verbose or infrastructural overhead found in other MVC libraries.
CanJS: Focuses on striking a balance between size, ease of use, safety, speed and flexibility.
Spine: A lightweight framework that strives to have the most friendly documentation for any JavaScript framework available.
Maria: Based on the original MVC flavor as it was used in Smalltalk - aka "the Gang of Four MVC".
ExtJS: Amongst other things offers plugin-free charting, and modern UI widgets.
Sammy.js: A small JavaScript framework developed to provide a basic structure for developing JavaScript applications.
Stapes.js: A tiny framework that aims to be easy to fit in an existing codebase, and because of its size it's suitable for mobile development.
Epitome: Epitome is a MVC* (MVP) framework for MooTools. soma.js: Tries help developers to write loosely-coupled applications to increase scalability and maintainability.
PlastronJS: MVC framework for Closure Library and Closure Compiler. rAppid.js: Lets you encapsulate complexity into components which can be easy used like HTML elements in your application.
Serenade.js: Tries to follow the ideas of classical MVC than competing frameworks.
Kendo UI: Combines jQuery-based widgets, an MVVM framework, themes, templates, and more.


Why so many frameworks? Why JavaScript MVC? What is MVC in JavaScript? Which one or ones to choose?

Well, if you were me, you probably would try to dismiss all those frameworks as noise. You may just want to bury you head in the sand, keep piling another jQuery plugin or another Ext js feature. But before long, the chorus of MVC became deafening, and you found your project on the JavaScript gradually spiraled out of control, and it becomes more and more difficult to track what triggers from what controls have changed the state of your data. The JavaScript become yet again become a multi-million lines of mess.

So think again about a JavaScript MVC framework.

Flavors of JavaScript MVC

MVC on the JavaScript side is a little different from the server side MVC you know, or the ASP .net MVC i know. In fact, MVCs are a little different from the JavaScript frameworks within. First and foremost, the frameworks try to clearly separate data and presentation, views and models.

Models: data that flows underneath your site. More precisely, data models that represents the structure/schema of your data. Data relationship, constraints can be defined and verified. Think of a user data model, it will have typical elements like age, gender, name, etc.

Views: layout, templates and interface. The side that your users can see and manipulate. They are your models marked up as photo galleries, task list, a table of data, etc.

Different frameworks have different takes when it comes to controllers. For some, the line between controllers and views are blurred, or views simply initiate the actions that theoretically would have belong to controllers. For example, backbone.js. Others do make controllers an command center that launches an application, initializes data models, monitors data changes and calls for appropriate actions. For example, Ext Js, Ember js.

There are also other flavors of JavaScript MVC. The most notably, the MVVM (Model-View-View Model) implemented by Knockout.js. Knockout.js has your typical views and models, however the controller part is termed as View Models, which bind DOM elements with data models and automatically refresh UI when data changes.

It is hard to get to know therefore evaluate each of the frameworks which all carry with them oh-so-good halos and incredibly cool demos and live websites, so we have to heavily rely on word of mouth that is circling on the internet. Some articles provide just that, for example:

Essential JavaScript: the top five MVC frameworks
Journey Through The JavaScript MVC Jungle

Backbone.js
Of the JavaScript frameworks, Backbone.js sits on top of the list and it has an impressive list of heavy-weight players, such as USA Today, LinkedIn mobile. Backbone.js has a collection of methods that manipulate data models, get/set, construct, make a collection, push/pop, extend. The whole backbone.js is revolving around data models and data handling logic.


var user = Backbone.Model.extend({
    name: 'Annoymous',
    age: 18,
    initialize: function() { ... },

    email: function() { ... }
});

Knockout.js
Knockout.js is particular hit with ASP .net MVC, I do not know why. And the heart of Knockout.js is view-model.

The following (from Creating a Dynamic UI with Knockout.js)populates a products array from data requested from a web API.
function ProductsViewModel() {
    var self = this;
    self.products = ko.observableArray();

    // New code
    var baseUri = '@ViewBag.ApiUrl';
    $.getJSON(baseUri, self.products);
}

Ext Js
Dealing mostly with Ext Js in my professional life, I have to give Ext Js MVC a mention. Ext Js 4 makes data packages center of its library, it also has an extensive set of data model mechanisms to define, validate, populate and manipulate data. As typical of Ext Js, it goes on the verbose mode. An Ext Js MVC application would have the following file structure:

 
 Ext Js Controller establishes awareness of its view through the init method:
Ext.define('AM.controller.Users', {
    extend: 'Ext.app.Controller',
 
    init: function() {
        this.control({
            'viewport > panel': {
                render: this.onPanelRendered
            }
        });
    },
 
    onPanelRendered: function() {
        console.log('The panel was rendered');
    }
});
And an Ext Js View use an Ext Js component for display.
Ext.define('AM.view.user.List' ,{
    extend: 'Ext.grid.Panel',
    alias : 'widget.userlist',
 
    title : 'All Users',
 
    initComponent: function() {
        this.store = {
            fields: ['name', 'email'],
            data  : [
                {name: 'Ed',    email: 'ed@sencha.com'},
                {name: 'Tommy', email: 'tommy@sencha.com'}
            ]
        };
 
        this.columns = [
            {header: 'Name',  dataIndex: 'name',  flex: 1},
            {header: 'Email', dataIndex: 'email', flex: 1}
        ];
 
        this.callParent(arguments);
    }
});
So which JavaScript MVC framework would you choose?

References: 

The MVC Application Architecture
Essential JavaScript: the top five MVC frameworks
Journey Through The JavaScript MVC Jungle
Backbone.js
Knockout.js

2 comments:

Ext Js Buffered Store getGroups Error

3:09 PM Xun 0 Comments

Ext Js has many features that rock. One of them is buffered grid. So unlikely traditional grid where pagination is done through navigating with a set of controls. Ext buffered grid panel allows you to scroll through the grid infinitely, the same way you would scroll up and down with a long web page. Behind scene, this is made possible by a buffered data store that fetches extra pages of data and cache them in page cache. A buffered store is configured as:
 buffered= true

However with this powerful feature comes with unanticipated bugs (oh, boy, do not we developers live with bugs.)

 The bug today I found is that buffered grid does not go well with grouping and column reordering. So using the sample infinite-grid provided by Sencha, I made a minor modification to have the grid group by author, and I get the following grid:

 

All is well, until I started to drag and drop to reorder the columns. Oops, after one successful drag-n-drop, the grid frozen.

After a little debugging, I found that the columnMove event triggered a refresh grid call, which in turn triggered a getGroups call, which in turn triggered an unhandled undefined error. StackTrace and error screenshot as the following:



So after some noodling around, I made the following changes and made the grid happy again.
 Ext.define('Ext.csx.data.BufferedJsonStore', {
    extend: 'Ext.data.Store',
   
    getGroups: function (requestGroupString) {
        if (!this.data.items) {
            return [];
        }
        this.callParent(arguments);
    }
});

Complete code available at: https://github.com/xunxdd/extjs.git

0 comments:

The Microsoft Universe

6:36 PM Xun 1 Comments

In his latest post Why Ruby? in Coding Horror, Jeff AtWood announced that he no longer lives in the Microsoft universe, as proof, his presented his new project Discourse that is entirely without a trace of .NET.

Left the oppressive shackles of my Microsoft masters behind. Free at last, free at least, thank God almighty I'm free at last! Jeff Atwood echoed the sentiment he expressed sometime ago.

For a guy who resides at the top of developer echelon, who created StackOverFlow (that had saved the developer mass, me included, countless hours), who authors the most respected and wildly-read blog Coding Horror, he deserves a universe entirely of his own, his choosing.

Sadly or gladly for us .NET developers, we still inhabits in this Microsoft Universe, from a long long time ago when IE6 was the king of browsers, and will still in the foreseeable future when all the cool kids will only role their eyes at the mention of anything Microsoft.

Yes, we are hopelessly brain-washed by Microsoft, its PCs, its office suites, its browsers, and most of all, its technologies.


Does anyone still remember Visual Basic for windows forms, or VBA, a flavor of Visual Basic, or VBScript the scripting language that were pretty widely used in ASP pages? Or ASP (short for Active Server pages), the once dominant server side language for generating web pages dynamically?

Then of course, suddenly it was nothing but .NET this and .NET that. The name at first sounded as bizarre as before iPad was unveiled, and caught fire in the tech world as fast as that iPad was embraced by the general public. And of course, all of us Microsoft devotees are transformed into visual studio users (despite or because of the hefty price tag).

I still remember the frenzy .net 1.0 caused and the cold sweat I had when I struggled to learn asp .net 1.0. As with typical Microsoft marketing (or marketing in general), the .net framework is filled with emerald gold with once impenetrable acronyms (CLR - common language runtime, CTS - Common Type System, BCL - Base Class Library), and is everything you need for complete success. Quoting from .NET official site:

the .NET Framework provides a comprehensive and consistent programming model for building applications that have visually stunning user experiences and seamless and secure communication.


Microsoft released .NET 1.0 and visual .net in 2002, and to this day, .NET framework and visual studio has gone through 7 major releases.

(From .NET Framework wikipedia)


Overview of .NET Framework release history
GenerationRelease dateNotesDevelopment toolDistributed with
1.02002-02original versionVisual Studio .NETN/A
1.12003-04first updateVisual Studio .NET 2003Windows Server 2003
2.02005-11rewrite of frameworkVisual Studio 2005Windows Server 2003 R2
3.02006-11WCF,WPF,WFExpression BlendWindows Vista, Windows Server 2008
3.52007-11LINQVisual Studio 2008Windows 7, Windows Server 2008 R2
4.02010-04parallel extensionsVisual Studio 2010N/A
4.52012-08asynchronous programming modelVisual Studio 2012Windows 8, Windows Server 2012


The 2002 ASP .NET web form release was a major shift from previous scripting languages, and it caused huge confusion among hapless little developers like me who tried plugged in code into the life cycle of an aspx page at the right moment. PreInit, init, preload, load, prerender, render ... I sincerely believed then I was too brain damaged to get it.

Now with the decline (possibly quick collapse) of PC era and all cool things about mobile, shall I say, .NET is desperately trying to catch up and accommodate?

One telling example is that the latest release of .NET 4 has not only the major .net languages C# .NET, VB.NET, F#.NET, it also includes a Dynamic Language Runtime (DLR) to allow languages like IronRuby and IronPython to run on top of .NET framework. This kind of adaptation can be seen elsewhere, visual studio has long included jQuery support, and it recently also started support GIT.

Wow.

With the push of MVC since .net 3.5, Microsoft is now open about the sin of the original .net web form. It was cumbersome, it violated the fundamental development principal of separating presentation and data and a loosely coupled system.

Ouch!

Only if I knew or had a choice then.

Too late!

1 comments:

Ext Js (vs. JQuery)

6:57 PM Xun 0 Comments

For the past two and half years, I have been using Ext Js incessantly; Before that, I never even heard of that. Like everyone (who has done anything with JavaScript), I was captured head to toe by jQuery. Of course I watched that little kid John Resig, with his chubby face, side-swept overly long hair, lectured us on his JQuery in Google Tech Talk, feeling pang of shock and awe.

That was when I was the de-facto one and only web developer in the company, answering Yes to every humble request my non-programming co-workers asked for. They always asked: can we add a slider to the page? Yes. Can we break the auto-generated PDF exactly into 3 pages? Yes!

Then I moved on and to a tech company, where IT professionals is nothing but the norm,  and where jQuery is nothing more than some hodge-podge with a small core of code for DOM traversal and manipulation and event handling.

Oops.

My journey with Ext Js began, and my relationship with jQuery ended abruptly.

Fast forward to Now.

Now I am using Ext Js 4 (after using Ext Js 3), the newest and boldest library upgrade. It is really more a rewrite than upgrade, because it introduces a new class system, a new data package, a new charting and graphing package ... the list can simply go on and on.

Technology is a curious thing. How fast we move on, upgrade and update our knowledge, how fast we "delete" memories of old technology. Now that I am using Ext Js 4, I had to think hard to remember what Ext Js 3 was like. As for jQuery, I feel that the only thing that has firmly being implanted in my brain is that $ sign.

Still, still! jQuery is as booming as Ext Js is regarded divine in my professional circle. How do they compare if we have to compare?


The most obvious difference is that jQuery uses GPL and MIT license, meaning you can use the library for free without much worries; On the other hand, Ext Js is developed by Sencha and is commercially licensed and it is not cheap.

jQuery, at its core (which is small and condense) is a library for DOM manipulation, outside of that, jQuery has a vast repertoire of plug-ins, all free yet with varying qualities; Ext Js provides a comprehensive framework that includes a rigorous class system, a set of utilities that deals with string, date, array etc.,., a complete set of UI controls, most impressive of them being Grid. With Ext JS 4, it also provides dynamic loading and MVC architecture.

jQuery is small; Sencha is heavy-set.

Ext Js has comprehensive, detailed documentation and maintained for every version; with jQuery we cannot say that. Yet, jQuery, because of its vast user base and community support, you would normally turn up with a lot of references across the web; in comparison, for Ext Js questions, your best hope is your more experienced colleagues;

Ext Js, for its rigorous class system and enormous size, entails a very steep learning curve; jQuery, for all of its user-friendliness, simplicity and light-weightedness, is much easier to learn.

Both unit testing has become a norm in web development, both Ext Js and jQuery have excellent unit testing support. The default choice for Ext Js is Jasmine, and qUnit for jQuery.

Both jQuery and Ext Js have been keen on providing mobile development platform and have been successful in doing so, with Ext Js/ Sencha, there is sencha touch; for jQuery there is jQuery mobile.

Both jQuery and Ext Js have been going strong, I would say, most people lean toward jQuery.

So it still remains to see who will have the last laugh if there is indeed some competition.

References: jQuery Ext Js

0 comments:

The peanut M&M that is progressive enhancement

11:53 AM Xun 1 Comments

The past year (2012), I have been living under a rock. I did not know that the concept of Progressive Enhancement has taken the web design world by storm (it was listed as #1 in Top Web Design Trends for 2012 by .net magazine).

This is because I still work, develop for a world of pre-iPhone, pre-Android mobile devices, where graceful degradation still holds the norm. That is, JavaScript reins. We generally only concern ourselves with working with the latest browsers (we do not worry about browsers on mobile devices).

That made me a hermit, a frog dwelling in a well who can only see the one square of sky that is directly above him.

Mobile devices (phones, tablets, in ever changing sizes and resolutions) now rule. Mobile apps in native code rule. This puts even HTML 5 (the new crown jewel of web development) on the defensive. Remember the tremor you had when Mark Zuckerburg said one of biggest strategic error made by Facebook was focusing on the development of HTML5 Web applications instead of native apps for devices? That is about as much a blow to Flash as when Steve Jobs declared that Flash is dead.

To which, the web folks rally around a new web design strategy: Progressive Enhancement.

Though progressive enhancement is not exactly new, and it has come to focus in 2003, after the presentation "Inclusive Web Design for the Future", and after which the term Progressive Enhancement came into life.

What is progressive enhancement? What is graceful degradation? What is the big deal?

Well, they may or may not look that much different, depending how you look at it.

Graceful degradation means we assume the more advanced systems and browsers, take for granted that the target frameworks are equipped with all necessary technologies, then design and implement applications accordingly.

Progressive enhancement goes the other way. It starts with core functionality and content that must deliver to all browsers and frameworks, then automatically detects the more advanced features in its hosting environment and make available those more advanced functionality.

Progressive enhancement is like provide a free version to all users, then gradually argument some cool features depending on how much you pay; while graceful degradation only provides the most advanced version, and to the less fortunate, it says: good luck! Upgrade your system!

Only now the less unfortunate web browsers in a large part are those in mobiles. Only no one can ignore mobiles!

Graceful degradation would have worked perfectly if the myriad of iPhones and androids have not invaded and hijacked the course of web development.

That is Only if ...

The article "Understanding Progressive Enhancement" has very intuitive analogy of progressive enhancement. Borrow/steal here (including image and explanation).

So your web is like a peanut M&M.

Start with your content peanut, marked up in rich, semantic (X)HTML. Coat that content with a layer of rich, creamy CSS. Finally, add JavaScript as the hard candy shell to make a wonderfully tasty treat (and keep it from melting in your hands). 

Content/The peanut

Start with the core, the peanut. Make it available to every level of users. Because some users/devices detest or cannot afford any unnecessary trappings. For example, mobile devices. Search engine spiders.

Styles/The chocolate coating.

Progressively, responsively apply style for folks who like and can tolerate embellishment / beautification of the application. For example, folks who are paranoid about JavaScript.

JavaScript/THE hard candy shell

Lastly, put in the JavaScript that made interaction and all the fancies possible. ...

Hopefully I will have a little more time to explore progressive enhancement later.

References:
http://dev.opera.com/articles/view/graceful-degradation-progressive-enhancement/
http://www.alistapart.com/articles/understandingprogressiveenhancement/

1 comments: