seanmonstar

Jan 24 2012

A new direction for web applications →

As I said last night, I don’t see how nodejs is the solution, by itself, for a web application that talks to many services. I’d still say that MVC is the best solution we have seen so far. Python has great support for long-running async tasks, talking to various databases, and the like.

That said, I love my JavaScript. Here’s where I see nodejs being a win: writing JavaScript on both sides of the stack feels great, and it gains small amounts of CPU time by making file I/O asynchronous. For other long-lasting tasks, such as resizing an image, you still need to set up a task in a queue for other CPUs to crunch.


Dec 5 2011

Widgets the Right Way →

A lot of sites are using widgets more, be it for ads, or these terrible social buttons that have emerged. Besides not wanting to spend time downloading the social buttons that I won’t use, what I hate the most is that they all have this in common: If they lag, they stall the rest of the page.

That’s because they document.write their contents into the page, which prevents all further rendering until they’ve loaded. Don’t do that. Read this from Rich Thornett about how to make your widgets suck less.


Nov 30 2011

Asynchronous UIs →

A great post by Alex McCaw, creator of the Spine MVC JavaScript1 framework, about how front-end developers do Ajax interactions wrong. Users shouldn’t be stopped because we’re waiting on the server to respond. The interface should respond immediately, and a background sync action should be kicked off.

I’ve been thinking about this for the past year, and wanted to reflect these ideas in Shipyard, and make them come alive in the Add-on Builder, myself.

  1. I refuse to use CoffeeScript, so it’s off limits to me. ↩


Nov 21 2011

Past Month of Shipyard

Last month I got to start working on Shipyard almost full-time, as I need it to make Add-on Builder work by the end of the quarter. I’m not ready to call Shipyard 1.0 until I’m confident with the API for Models, Controllers, and Views. Models are largely done, Views need some work, and Controllers need a start. Besides that, though, what has happened to Shipyard in the past month?

Here follows a changelog-ish list.

  • Animations
    • A merge between MooTools’ Fx.Tween and Fx.Morph classes
  • Events
    • addListener returns a Listener object with attach and detach methods.
    • support for once
    • legacy API
      • official API for EventEmitters is addListener, removeListener, and emit
      • previous methods will soon log a DeprecationWarning, before being removed by 1.0
  • New utils
    • Logger
      • Makes the console more familiar for Python users
      • Doesn’t error if there is no console available
    • Cookie
      • Thanks to MooTools
    • Color
      • Thanks to MooTools
  • DOMEvent
    • Thanks to MooTools
  • Env
    • provides browser and platform
  • A briefer test runner
    • Only prints dots for successes, F for failures, and prints errors at the end

If commit lists are more your thing, you can look to GitHub. The next month should see event delegation, and more work on the View/template system.


Nov 8 2011

var that = this

I used to think say you should use that in the question “What variable should I name this for closures?” This was because self is already a variable that points to window. However, I’ve since revised my opinion on what is a good variable name in this case.

I now find that and self to be too vague.

Instead, I think the variable should be named after the Class that you are currently coding in. As always, it’s easier to explain with code:

var PackageController = new Class({

    doSomething: function() {
        var controller = this;

        someEl.addEvent('click', function(e) {
            controller.react();
        });
    }

});

The reason is because once you start delving a couple nested functions deep1, I find myself sometimes wondering if I bound that to the value I wanted. This way leaves little to wonder about. And since you read code far more than you write it, best to write the most readable code you can.

  1. I know, some of that can be solved by moving the functions to named methods on other objects, but you’d be lying if you said you never happened to have a function for a .forEach loop, and then another inside for an .addEvent, or something similar. ↩


Oct 19 2011

JavaScript Module Syntaxes →

Excellent analysis of current module patterns by fellow MooTooler Sebastian Markbåge.

His conclusions match mine, and I used them in Shipyard profusely.

  1. In a production environment, you will always want to minify and concatenate your scripts. Since there is always a “build” step, all syntaxes are equal in production.

  2. In development, what matters most is a syntax that gets out of the way of programming, and more importantly, testing your code. That means that AMD is out. CommonJS modules have less boilerplate, and work immediately in other environments, like nodejs. This means you can very easily drop into a terminal, run nodejs, and import your module without a hitch.


Sep 19 2011

What is Shipyard? →

This week, at our Mozilla All Hands, I shared some slides about Shipyard, a JavaScript MVC framework that is making it’s way into Add-on Builder. It’s not finished, but since I shared it there, it felt appropriate to share what there currently is here.

Summary

An application framework that covers all the common things any JavaScript application would need to deal with: interacting with a server, storing data, rendering said data in the browser, and responding to user actions. An application built on Shipyard should only have to write the parts to pull all those things together.

If you’re application is going to have 1000 lines of JavaScript, would you rather write all those yourself, or have 900 of them be in a framework that is tested and used by others?

When starting a web application, you would reach for Django, or CakePHP, or Rails; never would you decide to use just the language itself. Why shouldn’t you do the same when the target language is JavaScript?

Framework-wide Goals

  1. Be able to declare dependencies inside the code, and not be bothered with managing them during development or deployment.
  2. Be easily testable, using a node test runner.
  3. Not reliant on any other language. Build scripts will use JavaScript. The End.

More

It’s heavily influenced by MooTools, since they have an excellent modular design, but turned into modules while Moo 2.0 figures itself out. There’s slides, and the repository, again.


Jun 29 2011

Why I pick Python over JavaScript →

I love JavaScript. It’s awesome. But this is an excellent view at why I still think Python has a place on the server. Some of the points I share pain with:

  • Very small standard library
  • Only a single number type (which is limited)
  • No built in module system

Page 1 of 8