home

Reactive Programming in JavaScript (funjs London, April 2014)

I gave a presentation on Reactive Programming in JavaScript at FunctionalJS London on 28th April 2014.

To describe reactive programming, I like to think of the key concepts of functional programming (using values and functional composition to solve problems in a declarative style) applied to real-world constraints such as async, mutable state and UIs.

The main idea behind reactive programming is that of “data types that represent values over time”. Because they are values (rather than side-effecting callbacks, for instance), they can be passed around and composed like any value, abstracting away the execution flow into declarative expressions.

For UIs, data-bindings provide a declarative mean to bind values (either plain values or reactive “observables”) to the view.

Continue reading →

The Symbiotic Web (Frontend London, Nov 2013)

Somewhat on the late, here is the presentation on The Symbiotic Web I gave at Frontend London last November.

Have you ever wondered: is the Web a platform for Information or for Applications? Is one the “correct Web” and the other a perversion of its true purpose?

Answering this question takes us back to the roots of the Web, namely the two key concepts of URIs and links. They are what truly make the power of the Web, alongside the descriptive HTML format, for both humans and machines that use it. For humans, we tend to add visual ornaments through the presentation layer (CSS), whereas we feed machines extra information through the semantic layer (e.g. Schema.org, micro-formats, etc).

At the same time, it’s no denying the growing role of the Web as a platform to distribute and run applications. However, the danger is that we compromise the mission of the Web to distribute information in a standard readable format, by hiding it behind the execution of JavaScript and proprietary APIs.

Maybe the true power of the Web is found at the intersection.

Continue reading →

We need to talk about source maps

As the Web platform matures, the code that powers our websites is built using increasingly complex processes.

A wide palette of languages is now at our disposal, with varied degrees of expressiveness, though under the hood they all end up transpiled to the same holy trinity of HTML/CSS/JavaScript: Sass, LESS et al to CSS; CoffeeScript, ClojureScript, Scala or C/C++ (via Emscripten) to JavaScript. We even compile yet unborn versions of JavaScript (ES6) to today’s JavaScript using traceur or es6-module-transpiler.

In parallel, we have learned to optimise the assets we distribute for performance: we minimise them to reduce payloads, concatenate them and inline dependencies to save on HTTP requests, add hashes to their filenames to cache-bust URLs.

However, the more transformations between the source we write and the code that gets served to ours users, the harder it is to inspect, reason about and debug.
Continue reading →

Abstracting away the grunt work with Plumber

When Grunt first came around, it was an undeniable breath of fresh air: finally, a build tool with a common “task” interface for the variety of front-end jobs we’d been piecing together with a mishmash of ad-hoc shell scripts and slow Rhino-based solutions (remember the Dojo build system?). Better even, it was written in JavaScript using NodeJS, in the native language of the Web, so that Web people could easily understand and extend it.

Grunt made our lives easier and everyone was happy. The new freedom was exhilarating. Front-end devs highfived each other in the corridors.

But as time went on, we kept using it for more and more complex projects and Gruntfiles seemed to grow out of control, even though a lot of the tasks that were actually performed remained pretty much the same (transpile languages, minimise, etc). Setting up even a simple project today involves a fair amount of boilerplate code.

To ease the barrier to entry, scaffolding tools like Yeoman were introduced to abstract this process into a single command. The result, though, is simply that the boilerplate code has been generated for you (yo webapp generates a Gruntfile over 400 lines long). It doesn’t make the boilerplate code any more maintainable or readable.
Continue reading →

Don’t write your examples in CoffeeScript

Recently, I stumbled upon a growing number of articles about frontend coding that used CoffeeScript in their examples. In particular, articles about Backbone.js.

While I’m not a fan of CoffeeScript, for various reasons, and wouldn’t tend to use it myself, I completely respect your right to disagree and don’t mind at all if you use it for your projects.

What I do mind, though, is the use of CoffeeScript to reason and present information about JavaScript and JavaScript libraries.

The reason should be self-evident from the previous sentence. If not, bear with me.

The best analogy I can think of for the transpiled relationship between JavaScript/CoffeeScript is HTML/Haml.

Take the following example:

%blockquote.film{:cite => "http://www.imdb.com/title/tt0062622/quotes"}
    %p= Just what do you think you're doing, Dave?
    %footer
        = — HAL in 2001: A Space Odyssey

Which translates to:

<blockquote class="film"
            cite="http://www.imdb.com/title/tt0062622/quotes">
    <p>Just what do you think you're doing, Dave?</p>
    <footer>— HAL in 2001: A Space Odyssey</footer>
</blockquote>

Even though there is a somewhat guessable syntactic mapping between the two, would you use such a Haml snippet to illustrate the use of <blockquote> and <footer>? Hopefully not.

No matter how much you enjoy the power of an alternative syntax, using it for anything else than demonstrating that syntax distracts the attention from what you’re actually writing about.

Just because you know how to map CoffeeScript to JavaScript (and really, you should know) doesn’t mean everybody does, or cares to.