Skip to content

Instantly share code, notes, and snippets.

@robwormald
Last active August 29, 2015 14:01
Show Gist options
  • Save robwormald/6da0d837232600145b18 to your computer and use it in GitHub Desktop.
Save robwormald/6da0d837232600145b18 to your computer and use it in GitHub Desktop.
Brain dumping my ideal JS framework.

#Next-gen Javascript Applications...

Preamble

I've been developing "full-stack" Javascript applications for a while now, primarily using AngularJS in the browser, coupled with Ionic Framework for mobile apps, powered by SailsJS running on Node.js. I'm a huge fan of Javascript - I've always found it "gets out of my way" more than any other language, allowing me to get ideas out of my head with a minimum of friction. Unchecked though, JS applications can become unwieldy because of that same flexibility.

I think the reason both Sails and Angular work so well for me is that they provide the right kind of structure - just enough reinforcement to keep me inline and structured, without forcing arbitrary rules on stuff.

The Angular team recently released their design documents for the 2.0 version. Any release is many months away, but as it's being designed in a very modular fashion, a number of the pieces are already available. I've been playing around with them for the past couple of weeks along with ES6 in general. There's some awesome stuff coming in both Angular 2.0 and ES6, but unfortunately now I find it very frustrating to go back to the "old" way of writing Javascript. I realize the hilarity of calling ES5 "old" when ES6 is not even a finalized standard, but I believe there's a lot to be said for being aware of what's coming over the horizon.

What follows is basically a brain-dump of how I see JS applications going forward.

I'm doing this more to get it out of my head than anything else, but any input is welcomed.

Standard disclaimer : I have no idea what I'm doing and thus any the opinions / proclamations / misconceptions below are untested, possibly dangerous, strictly my opinion and not those of anyone else. YMMV. YOLO. etc.

Modules of Today

relevant xkcd

CommonJS - what node.js uses.

A typical CommonJS module written for node.js looks like:

//myModule.js

//import a dependency
var someThing = require('someThing');

//export module 
module.exports = {
  someFunction : 
    //do some stuff
  
  someValue: 'foobar'
};

and is then used like:

var myModule = require('myModule');

myModule.someFunction();
AMD - Asynchronous Module Definition

A typical AMD named module looks like this

//Calling define with module ID, dependency array, and factory function
define('myModule', ['dep1', 'dep2'], function (dep1, dep2) {

    //Define the module value by returning a value.
    return function () {};
});
Global modules etc

There's a variety of different ways outside of CJS/AMD, but in the browser they tend to look something like:

(function(myModule) {
 
    function privateAdder(n1, n2) {
        return n1 + n2;
    }
 
    myModule.add = function(n1, n2) {
        return privateAdder(n1);
    };
 
})(window.myModule = window.myModule || {});
Angular 1.2

Angular modules generally look something like this.

app.js

//create an angular module, and import the someModule dependency
var app = angular.module('demoApp',['someModule']);

//each module's config block runs once, before the module's .run() block runs.
//inject the dependency *providers* into the config block to configure dependencies before they are instantiated.
app.config(['someDependencyProvider',function(someDependencyProvider){
  //configure stuff in here
  someDependencyProvider.someSetting = true;
  someDependencyProvider.addThing({ thing : 'foobar'})
}]);

//each module's run block will run once, after the .config block.
app.run(['someDependency',function(someDependency){
  //start something
  someDependency.startSomething();
}]);

//create a controller and use DI to inject the dependencies
app.controller('MyViewController',['$scope','someDependency', function($scope, someDependency){
  //now we can do stuff with $scope and someDependency
  
  //get some stuff
  someDependency.getSomeStuff().then(function(stuff){
    //then add stuff to scope.
    $scope.stuff = stuff;
  })
}])

None of this stuff is easily interoperable.

ES6 modules

Note: the information in here is likely to change. Futurespeak.

There's two big things in ES6 regarding modules. The first is that there is a standard. Or at least there will be one. April 27 ES6 Specification is the latest es6 draft.

Read this first : A Brief ES6 Modules Overview

thing.js

//export a class
export class Thing{
  
  constructor(name){
    this.thingName = name;
  }
  
  sayHello(){
    console.log("hello world from " + this.thingName);
  }
}

//export a named function
export function doStuff(){
//do something
}

main.js

//import the named class, optionally renaming the imports
import {Thing, doStuff as fooStuff } from  './thing';

var newThing = new Thing();

newThing.sayHello();

fooStuff();
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment