2015 Fluent Conference Recap

---

A talk I gave April 30th, 2015 to the Santa Barbara JavaScript Meetup, based on my experience at Fluent and the sessions I attended. There were so many more that I couldn't attend.

Santa Barbara JavaScript Meetup

I gave a well-received talk on Yeoman to the Santa Barbara JavaScript Meetup crowd on Wednesday night, hosted by Agilysys. Based on the positive feedback, we'll definitely host more.

Ember 1.0

Earlier this year I was evaluating Ember.js along with several other frameworks/libraries for some projects at work. At the time, pre-1.0, I found Ember promising but frustrating due to its steep learning curve, frequent breaking changes and documentation that was inadequate and out-of-sync with the codebase. Still, I found much to admire in Ember's approach, as I noted in a previous post.

One thing that struck me almost immediately was a strong push back from the Ember principals against AMD. The most prominent example was Tom Dale's blog post 'AMD is Not the Answer', which drew some impassioned responses including this one and this one from RequireJS creator James Burke. Having incorporated AMD into my toolbox early on, I find the necessary boilerplate a very reasonable tradeoff in return for concise modules with explicitly stated dependencies, available in the browser.

You can imagine my surprise confusion amusement then, when I read the Ember 1.0 announcement the other day and found this gem:

Today, tools like require.js and module systems like AMD, Node, and ES6 Modules continue to gain traction. Increasingly, people are using named modules and module loaders rather than storing their code in globals.

To prepare for this future, all of the code lookup and naming conventions in Ember.js now go through a single Resolver. The default Resolver still looks for code under global namespaces, but Ember App Kit already provides an alternative resolver that looks for code in AMD modules.

This quote from the Ember official blog is actually a little misleading. A closer look at the Ember App Kit reveals that it supports ES6 module syntax, which is then "transpiled" to AMD syntax via the ES6 module transpiler. Still, this is a far cry from Tom's blog post and likely reflects the widespread adoption of AMD in the developer community around Ember.

With Ember reaching 1.0 status as of August 31, I'm taking another look to see if the stability, module support, and documentation have improved. I'll build out a demo app with the same Youtube emulator domain as other recent demos for side-by-side comparison of a fairly simple but non-trivial example application across frameworks/libraries. I'll post the source on github and link here when it's done.

Aura.Backbone.YouTube

Continuing with my theme of demo projects built on a common problem domain - a bare-bones YouTube emulator - I decided to dive into Aura.js http://aurajs.com. Aura is a "clean and scalable architecture for complex JavaScript applications" that evolved from ideas put forth by Googler Addy Osmani and former Yahoo Nicholas Zakas . It provides a high-level component-based abstraction with focus on sandboxing and inter-component communication via publish/subscribe. Aura is framework-agnostic, so you can plug in popular tools like Backbone, Angular, Ember, etc. For the demo I plugged in the ever popular Backbone library.

View the demo here http://tdoherty.github.io/aura.backbone.youtube/

View the source on github:

aura.backbone.youtube

https://github.com/tdoherty/aura.backbone.youtube

aura.backbone.youtube - An Aura.js demo using Backbone.js and YouTube APIs

Backbone Boilerplate

I wrote a rough demo with Tim Branyen’s Backbone Boilerplate using YouTube data feeds. It’s a work in progress as I’m learning Backbone Boilerplate and its bundled LayoutManager.

Check out the demo here

Backbone-Boilerplate.YouTube
github.com
A Backbone Boilerplate demo using YouTube feed data. Contribute to Backbone-Boilerplate.YouTube development by creating an account on GitHub.

AngularJS

I wrote a rough demo with Google’s AngularJS using YouTube data feeds. It’s a work in progress as I’m learning Angular.

Check out the demo here

Angular.YouTube
github.com
An AngularJS demo using YouTube feed data. Contribute to
Angular.YouTube development by creating an account on GitHub.

jQuery.SpinJS

I created a jQuery plugin wrapping Felix Gnass’ excellent spin.js. The plugin adds a background div with configurable color and transparency, and supports AMD. Check it out and let me know what you think.

jQuery.SpinJS
github.com
jquery plugin for spin.js. Contribute to
jQuery.SpinJS development by creating an account on GitHub.

Client Side JavaScript MV* With Ember.js

My team at work is evaluating the suitability of several tools for client-side application development. We’re looking at building out some non-trivial applications on the client and wanted to make the best collective, educated decision on the best tool(s) for the job.

The tools we’ve been looking at include:

• Backbone


• Knockout


• Angular


• Ember

Backbone

I’ve already grown pretty familiar with Backbone, having spearheaded its adoption into our tools set a year or so ago. We’ve built out a few non-trivial applications with Backbone and admire it’s simplicity and elegance. Backbone is lean and non-prescriptive, it’s a minimalistic library that gives you the most basic structure and tools for event-based model management.

Twirl Your Mustache

Reuse Templates On The Client And Server With CouchDB, CouchApp, and Mustache

In my last post I talked about my introduction to building applications with Apache CouchDB and CouchApp. I’ve been refactoring the app to use Backbone.js and RequireJS on the client, and to take advantage of templating to make presentation logic more DRY. This post shows how to reuse Mustache templates on the client and server using CouchDB and CouchApp. I’ve left out the Backbone/RequireJS code for simplicity, and illustrate the client code using jQuery’s shorthand ‘$.get’ AJAX method.

Mustache is a logic-less templating language available for a variety of languages. It ships with CouchApp, and Backbone is agnostic, so it seemed a no-brainer. Mustache supports partial templates, for portions of a page’s markup, and I’ll show how to reuse a partial template to do a partial page refresh on the client.

Say we have the following extremely simplistic template:

/templates/page.html:

Partial templates are indicated with the greater than (‘>’) symbol, so here we’re indicating that a partial template named ‘content’ should be rendered in the <div id=”content”> element. Now let’s say we have the following partial template:

/templates/partials/content.html:

For the server side, we can render HTML pages via CouchDB ‘shows’ and use Mustache in the show code, i.e.:

/_shows/page.js:

Here, this.templates refers to the current design document’s ‘templates’ property, and this.templates.partials to its ‘templates.partials’ property. These correspond to your CouchApp’s directory structure prior to push.

We can then hit the page at: /dbname/_design/docname/_show/page, and use a combination of rewrites.json and a proxy or virtual host to pretty up the URL.

For our purposes, we’re considering reusing a template from the ‘partials’ directory for a client-side partial page refresh. We can serve the template markup from a show also, passing the template name in the URL, i.e., /dbname/_design/docname/_show/templates/page.html:

/_shows/templates.js:

Here, we first look for the template name in the design doc’s templates, then in templates.partials.

On the client, we’ll use the jQuery plugin for mustache, which ships with CouchApp:

<script src=”vendor/couchapp/jquery.mustache.js”></script>

First we’ll make a GET request for the template:


Then for a partial refresh, we’ll GET our updated data and apply the same partial template on the client:


This is an extremely simplistic example, the point being to illustrate the considerable DRY we can achieve through template reuse. Write the template once, and use it on both the client and server.

Nice!

Freddy vs. JSON

RequireJS 1.0 Released

Link: RequireJS 1.0 Released

RequireJS Presentation

Link: RequireJS Presentation

RequireJS - Adventures with an asynchronous script loader

A presentation I created for the dev team at work, published with the blessings of our director of development…

Developing and building RequireJS apps with a central code repository

Most of the projects I develop at work are enterprise Microsoft apps, using Visual Studio and Team Foundation Server. Reusing JavaScript in VS projects typically involves either copying the code (violating the DRY principle) or creating pre-build events to copy the code at build time (a little better, but far from ideal)

I’ve been doing a lot of JavaScript application development lately, and really loving James Burkes RequireJS module loader. For a recent project I ended up copying a non-trivial amount of common utilities code, and decided it was time to figure out a better method to centralize common JavaScript code without requiring a script server and related overhead (HTTP requests) and maintenance.

After some experimentation, and discussion with RequireJS author James Burke, I figured out how to develop and build RequireJS apps using a central repository for common JavaScript code. The basic gist is that you specify a HTTP path to the repository code modules during development, (a localhost website) from which the files are dynamically loaded, and a filesystem path (to the source of the localhost website) in the build configuration file. The RequireJS optimizer consolidates the common modules via the filesystem path, along with the local modules, into a single file for deployment.

This allows me to maintain and version control common JavaScript code in a single project, and use that code in separate projects, much the way I do with dll/project references in compiled languages like C#.

main.js with HTTP path(s):
require(
        {
            paths: {
                //various application path aliases
                “core”: “//localhost/ipayment.core.javascript/scripts/core”
            }
        },
        [
            //direct dependencies
        ],
        function (<dependency>) {
            <dependency>.<method>();
        }
);


app.build.js with filesystem path(s):
({
    appDir: “../”,
    baseUrl: “Scripts”,
    dir: “../../Build”,
    paths: {
        //various application path aliases
        “core”: “../../../iPayment.Core/iPayment.Core.Javascript/Scripts/Core”
    },
    optimize: “none”, //”uglify”, “closure” (Java Only), “closure.keepLines” (Java Only), “none”
    modules: [
        {
            name: “main”
        }
    ]
})

Cool!
Tim

Using jQuery deferreds is a little like courting a woman: you have to be careful not to make promises you can’t keep.

Me

Using QUnit with RequireJS

I have really been enjoying James Burke’s RequireJS library: http://blog.dohertycomputing.com/post/3466960658/requirejs and have recently applied it to a project at my day job. When it came to testing the application, I decided on QUnit for unit testing, and started poking into using it with RequireJS. 

I was able to successfully run tests using the RequireJS approach, i.e., define a test module, with the code to be tested as explicit dependencies, and waiting to start the tests until the module and all its dependencies are loaded. Async behavior is handled via QUnit.stop()/start() as described in the QUnit API: http://docs.jquery.com/QUnit

define(
        [
            “my/moduletotest1”,
            “my/moduletotest2”,
            “my/moduletotest3”,
        ],
        function (moduletotest1, moduletotest2, moduletotest3) {
            return {
                RunTests: function () {
                    test(“mod1test”, function () {
                        QUnit.stop();
                        moduletotest1.ajaxyMethod(arg, function(result) {
                              deepEqual(result, matchExpression);
                              QUnit.start();
                        });
                    });

                    test(“mod2test”, function () {
                        QUnit.stop();
                        moduletotest2.ajaxyMethod(arg, function(result) {
                              equal(result, matchExpression);
                              QUnit.start();
                        });
                    });
                    …
                }
            };
});

Then in the QUnit page script:

QUnit.config.autostart = false;
require(
          [
            “UnitTests/TestModule”,
          ],
          function (testModule) {
            QUnit.start();
            testModule.RunTests();
          }
);

Works like a charm!

On inventing JS module formats and script loaders

Link: On inventing JS module formats and script loaders

Nice post by James Burke, author of RequireJS, (which I have fully embraced in my latest production app) on why the Asynchronous Module Definition (AMD) appears to be winning the JavaScript module wars. It’s a clear, concise, and cogent argument.