Saturday, May 11, 2013

JavaScript MVC frameworks

Posted by Xun at 8:27 PM 0 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

Monday, May 6, 2013

Ext Js Buffered Store getGroups Error

Posted by Xun at 3:09 PM 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

Saturday, April 27, 2013

CSS Rules for better web performance

Posted by Xun at 6:36 AM 0 comments
In the book High Performance Web Sites, Steve Souders laid out 14 rules for better web performance. 

The rules are: 

1. Make fewer HTTP requests
2. Use a content delivery network
3. Add an Expires Header
4. Gzip components
5. Put stylesheets at the top
6. Put scripts at the bottom
7. Avoid CSS expressions (an IE-only evil)
8. Make JavaScript and CSS external
9. Reduce DNS lookups
10. Minify JavaScript
11. Avoid redirects
12. Remove duplicate scripts
13. Configure ETags
14. Make Ajax Cachable

That was 2007. 

Today, most of you probably would react to the rules with: So? I already know that. And most websites have adopted most of the rules. An iron proof how succinctly and effectively the rules are stipulated. 

On the heel of the success of High Perfomance Websites, in 2008 Steve Souders teamed up with other JavaScript/Front-end web development stars and published another book: Even Faster Web Site.

Only today I happened upon the book and hastily read it over. It has many gems here and there. Doug Crawford written about Axes of Errors and the AJAX landscape; Nicolas Zakas dives in various JavaScript performance tips. And many more.

There is one bit I am very interested in: the key of writing efficient CSS selectors, because normally to me, CSS is the most lightly treated element in a big application, it is mostly perfunctorily written and I hardly ever given it any thought on its performance implications.

First of all, a little open secret.
Browsers match CSS selectors from right to left.




Take for example: p a.active

So instead of shooting for your target from left to right, that is, finding all p then all anchor elements inside p, it sets out finding a.active first, then continue to their parents.

Why it goes about this way? StackOverflow has a very detailed explanation.

With this insight, some rules can be laid out for writing efficient CSS selectors. And yes, indeed, the rules have long been laid out by a guy named David Hyatt in a article Writing Efficient CSS for use in Mozilla UI.

The rules are:

1. Avoid universal rules 
 * -- wild card selectors are dangerous

2. Don't qualify ID selectors
   DIV #unique  is meaningless

3. Don't qualify class selectors
   Try change selectors such as LI .chapter to .listChapter

4. Makes rules as specific as possible
    Try not write selectors with 18 nested levels.

5. Avoid descendant selectors
   Descendant selectors are expensive.

6. Avoid tag-child selectors
Think twice before you use. Better just drop it.

7. Rely on inheritance.

Friday, April 19, 2013

My first taste of GIT

Posted by Xun at 7:41 PM 0 comments
GIT is a wonderful thing, but my first taste of GIT, more specifically, my process of migrating from SVN to GIT is wrought with failures and cryptic error messages. And I suspect I was not alone. For up to this point, there are 26,229 questions tagged with GIT. Considering what a young thing GIT is, this speaks for both of its popularity and "hardness".




To migrate my project from SVN to GIT, other than the instructions given by my colleagues, I also consulted the following links and chewed on the many help tips turned up from Google (honestly most of them are left undigested).

Converting a Subversion repository to Git
GIT ---everything-is-local
Converting from Subversion to Git

So all of the wonderful links have listed the steps and commands. I just want to retell my trials and errors. Actually just errors.

First Trial: Migrating the whole SVN (history, branches and tags) to GIT. Failed Completely!

Error 1
Found possible branch point
Solution: .Go to git/config file and delete all the branches and tags entries under the svn-remote section

Error 2:
RA layer request failed
By StackOverFlow, this is because some revision get messed up, so need to go to the next GOOD revision and continue from there.

However since this happens at an ever more frequent rate, it killed my effort of migrating whole history to GIT.

Second Trial: Migrating without the history. Successful!

Third Trial: Converting SVN externals to GIT sub-modules. Successful eventually!

Add old externals as sub modules were relatively easy. However, when I tried to remove them I had a hard time. Of course, stackoverflow came to rescue, as the solution found at here.


  1. Delete the relevant section from the .gitmodules file.
  2. Delete the relevant section from .git/config.
  3. Run git rm --cached path_to_submodule (no trailing slash).
  4. Commit
  5. Delete the now untracked submodule files
  6. rm -rf path_to_submodule



However, even after I followed the steps, I still received the following errors as the following:

A git directory for xxx is found locally with remote(s):<br/><br/>

So later I found that I also need to delete the relevant folders in .git\modules.

...

But after the migration, my experience with GIT has been relatively smooth.

So far. So good.


Saturday, April 6, 2013

The Microsoft Universe

Posted by Xun at 6:36 PM 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!

Saturday, March 30, 2013

Ext Js (vs. JQuery)

Posted by Xun at 6:57 PM 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

Sunday, January 13, 2013

Remembering Arron Swartz

Posted by Xun at 6:27 PM 0 comments
I think the first time the name Arron Swartz ever came into my consciousness was about 10 years ago, so long ago it was like ancient. Not sure what or why, I just stumbled into the little blog Raw Thought. I was immediately taken. What incredibly cool and intelligent writing, I remember myself thinking. I love the title Raw Thought, too. Cool guys  always come up with cool names.

But as all internet things go, that was that. I quickly jumped on to other It things.

The second time, Aron Swartz was in the news, that he was charged with some felony for illegally downloading millions of articles from JSTOR. From the news, I had a thin grasp how incredible Arron Swartz is. As a teenager, he helped shape R.S.S., the protocol that sends the content of Web sites out as feeds; he is the co-founder of Reddit, the very popular website. I was filled with envy. I remember seeing his picture, and thinking: what a cool and good-looking guy.

The third time, the name Arron Schwartz was splashed across all major news. And the words: suicide, hang himself, depression. Along the words: RSS, Reddit, SOPA,feds, MIT, JSTOR.

And suddenly there is no escape of Arron Schwartz. I read the moving tribute RIP, Aarono Swartz by Cory Doctorow
, the very first one; then later read the statement by his family and friends. I read Postscript: Aaron Swartz (1986-2013) on the New Yorker. 

So much glory, so much grief, so young ...

I am still a nobody, a anonymous who toils (though how much I love that) in the internet machinery. All the things said, twittered, posted somewhere from some guys above somewhere will soon be lost in the next second I traverse through link by link, still even as I do that, I was filled with awe and wonder: why did he take his own life? How could he have achieved so much in such a incredibly short life? 

I still do not know Arron Schwartz, but I know the tech world has lost a very cool, talented soul.

Therefore, for this moment, I remember him!