Category Archives: JavaScript

Things to think about when building a new web project

I’ve been thinking and talking with people about building webapps. Every project has it’s own set of contexts to consider, and questions to work through. As such each will have things to consider. Here are some questions to work through.

  • Single page vs multi-page
  • JSON HTTP API for data and resources vs generating server side html
  • Big framework vs roll your own
  • Angular/Ember/Knockout
    • testing/learning/state today vs tomorrow
  • javascript module system
    • requirejs/browserify/framework based
  • What server-side frameworks/technologies do you want to use
  • What do you want to learn?
  • CSS Framework for getting started
    • foundation/bootstrap/pure css
  • mobile strategy (responsive design)

For many of the questions and options above, I think that I have strong opinions about the answer (as I’m sure many people do). Thinking through the questions above is an important thing to be doing on any project.

What questions do you think about?

How to use any JavaScript library with RequireJS 2.1

I’ve been using Require JS for a while, having cut my teeth on 0.27.0, and gotten quite familiar with the order plugin that was a part of life when using non require-js libraries.

RequireJS 2.1 provides a different tool for including third party libraries, providing a “shim” object that forms a part of the requirejs config.

With the shim it is easy to add dependencies on non-require js pieces of code. Take a look a the documentation on the shim config( for some details or see some examples below:

Using Twitter Typeahead with Require.js

shim: {
“typeahead”: [“jquery”]

Typeahead depends on jquery being loaded first. Because the API is done via jquery, we don’t need to worry about exporting anything.

Using Twitter Hogan with Require.js
shim: {
“hogan”: {exports: “Hogan”},

hogan doesn’t depend on anything being loaded before it. It exposes itself on the global namespace as Hogan.

Using Twitter Bootstrap with Require.js

shim: {
“bootstrap”: [“jquery”],

Twitter bootstrap depends on jquery being loaded first. Because the API is done via jquery, we don’t need to worry about exporting anything.

URI with Require.js

shim: {
“URI”: [“jquery”],

pushing in a jquery dependency to uri. It has magic in it to detect if amd is being used, and will define itself as an amd module.

SerializeJSON jQuery plugin with Require.js

shim: {
“jquery.serializeJSON”: [“jquery”],

serializeJSON depends on jquery being loaded first. Because the API is done via jquery, we don’t need to worry about exporting anything.

D3 with Require.js

shim: {
“d3″: {exports:”d3”},

D3 doesn’t have any dependencies and exports itself with the d3 global object.

Rickshaw with Require.js

shim: {
“d3″: {exports:”d3”},
“rickshaw”: { exports: “Rickshaw”, deps: [‘d3’]}

rickshaw depends on d3, and exposes itself with the Rickshaw global namespace.

Notes From Yehuda Katz’s visit to Brisbane

Yehuda Katz( had a brief visit to Brisbane Australia, doing a public presentation, and a more private breakfast meeting. In this blog post I’m going over some of the things that struck me as particularly interesting or worth thinking about.

For those of you who don’t know Yehuda, he is an opinionated and very active developer. Yehuda is a member of the JQuery and Ruby on Rails core teams, and he is also one of the founders of Ember.js (a framework for building rich MVC JavaScript applications –

In the public talk Yehuda went through ember.js, talking through what the paradigm of the framework is, and walking through a demo of some of the key features of the framework. It looks like an interesting option for JavaScript applications. It’s on the brink of going 1.0, but already has some high profile applications using the framework. Apart from seeing the interesting elements of ember and how it’s used, it was very interesting to see the way people are using Ember.js with D3:

I’m definitely going to keep my on the framework as it moves forward.

In his spare time Yehuda is working to push the future of the web in ways that help facilitate rich applications. He has got a couple of ways that he is doing this:

  1. he is a member of the W3C TAG
  2. he is working to influence members of the chrome team to build things well.


The Technical Architecture Group works to specify and guide the architecture of the web moving forward. It has the feel of a good internal architecture group in an organisation, filled with smart people trying to make the web better (it’s membership includes Tim Berners-Lee and representatives of the community, large organisations and browser vendors).

Chrome Team

Through some of the work Yehuda has done, he has had opportunity to spend time with some of the people building new versions of Chrome, and helping to guide some of the thinking towards making apis and decisions that work well for web developers.

So I should have convinced you that Yehuda has some stuff worth listening to. Over the period of time he was I had some good opportunities to listen to both his public conversations and hear some of the more informal conversations. Here are some of the things that I found particularly interesting around where he sees the web heading.

Web RTC looks like a cool technology for real time communications ( The support for peer connections looks particularly interesting.

The new world being demonstrated by google polymer ( looks to be very exciting. Definitely well worth a look for web developers who want to get an idea of the way they will be writing applications in the future. Model Driven Views (, and custom elements ( are extremely exciting, and the shadow dom ( looks like a good tool for helping to support and customise the new features brought in. The HTML + CSS workflow currently is the language of the web, with many people speaking it, and with these tools, I think the language is moving in good directions.

The mechanisms for doing asynchronous JavaScript have been moving on from the straight callback approach that has been familiar to people, particularly through the use of node. There has been much discussion around the web around promises and futures, with things heading towards promises. Martin Fowler has an article describing JavaScript promises (, which is where the W3C TAG is currently headed ( I look forward to having this come into play, and having a standard option that doesn’t involve the deep nesting that can come from callback nesting.

It was interesting hearing Yehuda’s perspective on computer science and functional topics like Monads and functional reactive programming. The binding approach used in Ember.js takes inspiration from FRP, and Promises allow a transformation to a monadic approach.

One of the interesting new things coming to javascript in browsers is object.observe, a feature which will make it possible to observe any object for modifications on it or its attributes.

All in all there is a bunch of interesting stuff in the web future. It’s a great time to be doing web development, and I look forward to what the future holds.

Backbone.JS on Rails

A while ago I made a post Two tricks for getting Backbone.js to play well with Ruby on Rails. It was good at the time, but probably not the place you really want to be reading.

For the best information go to quora, and read the answer to the question
How well does backbone.js work with rails? by Jeremy Ashkenas, the creator of Backbone.JS. It’s the best article on the topic, and deserves all the google juice it can get.

In particular the pick function approach mentioned is useful – and would have gone a decent way to preventing the github mass assignment vulnerability.

Inside TinyMCE plugins (and an introduction to plugin dependencies)

I’ve just been spending some time adding dependency resolution to TinyMCE plugins.

The concept is that a plugin can depend on other plugins. As a part of doing this work I’ve had some good opportunity to dive deep into how plugins in TinyMCE work. It’s been a good little trip that I’ll summarise briefly here. I’ll do this by first presenting the lifecycle, then explaining how plugin dependencies will work.

Plugin Loading Lifecycle

The TinyMCE plugin loading lifecycle there are three concepts that are important to understand:

  1. load
  2. add
  3. init


The loading of a plugin will automatically download the javascript code, and run this. This is done by looking for a file, “editor_plugin.js”, in the “plugin short name” folder in the plugins folder. When running in development mode, the file “editor_plugin_src.js” will be used. It is expected that the source code in this js file will use the TinyMCE create function to create a class for the plugin, add the plugin to TinyMCE using PluginManager.add This code should typically try to remain outside of the global namespace, executing within an anonymous function block, as per the code in the example plugin.

Plugins specified in the plugins attribute of the settings object will be loaded if they have not previously been loaded. Historically TinyMCE has also included a – prefix to prevent autoloading of plugins. This is no longer required, as TinyMCE is smart enough to know if a plugin has been loaded, and won’t load it twice. So in effect, there is no reason to include the – prefix (so the only part to remember from this paragraph is that plugins specified in the plugins attribute of the settings object will be loaded if they have not previously been loaded).


A plugin class can be added to TinyMCE using the PluginManager.add function, passing the short name of the plugin and the implementing class for the plugin. The short name should be a unique identifier for the plugin, and the plugin class provides the code that implements the plugin.

Importantly the class can provide an init method which will be called by TinyMCE when it is being initialised. The class should also provide a getInfo method which returns information about the plugin.

There are two ways of performing an add. It can either be done manually before loading TinyMCE, or it could be specified in the editor_plugin.js that gets loaded as a part of the load process above.


The init function of the class for a plugin will be called after TinyMCE has created the plugin, as a part of the editor initialisation process. The plugin will be passed a reference to the editor as a part of the initialisation process.

Plugin Dependencies

Plugin dependencies can/will be specified in an array parameter to the PluginManager.add function call. There are two ways to specify a dependency.

  1. as a string. String dependencies will reference the short name of the dependency. If the dependency has not previously been loaded, TinyMCE will attempt to load the dependency.
  2. as a simple object. The object will have the form:
    prefix: 'url_prefix/',

    These will then be concatenated together to form a url. URLs will be resolved as relative to the TinyMCE installation. In the above object this would generate the url: “url_prefix/name_of_plugin/path_to_file.js”

When specifying a plugin dependency, there is a guarantee that the init method of the dependencies will be called before the init method of the plugin. There is no guarantee of the order in which the plugin “editor_plugin.js” is loaded. This can be seen in the test “plugin_dependency_init_call_order.html” which shows the order in which the init method is called. That the loading of plugins is not specified as a part of the new dependencies work is somewhat intuitive. It is only as a part of the load process that a plugin (and it’s list of dependencies) are made known to TinyMCE, which means that it is not possible to specify dependencies within the plugin before loading the plugin. The init of plugins is only performed after the plugins have all been loaded, making it possible for the dependencies to be init’ed before a plugin is init’ed