Month: October 2014

FlightJS, an event-centric JavaScript library/framework

Are events your favorite part of AngularJS?
Look at FlightJS instead.

Angular’s Event System

At Oasis Digital, we use AngularJS for most of our client-side “SPA” web development. AngularJS is well suited for data and form centric enterprise web applications we most often work on; I’ll write more about why we chose AngularJS another time.

As we teach our Angular Boot Camp class, we spend time on the AngularJS event system. For those who haven’t looked at it, AngularJS’s event system operates at a higher, more abstract level then DOM events – AngularJS events propagate up-and-down AngularJS scopes rather than up-and-down the DOM directly. We typically recommend it only for narrow cases where some bit of information should be transmitted and responded to broadly across the application; it avoids the computational cost of numerous watches.

In both these classes and our development work, we sometimes meet developers who are very excited by the AngularJS event system, and endeavor to create an event-based application with it. We must then unfortunately give the following disappointing advice:

If you are looking to build a mostly event-based system, AngularJS is probably not the right tool for you. There are a lot of merits to events, but the event-centric approach is not the AngularJS way. If you’re going to build primarily with events, you are wasting much of the AngularJS ecosystem, which is primarily about scopes, data binding, directives to enhance HTML with technology and domain specific add-ons, and so on.

DOM Events Find a Home

But that is not to say events are bad. Events are great. Don’t lose hope. There is a home for you: Twitter’s FlightJS.

FlightJS is 100% event centric and DOM-centric; it embraces the browser DOM with minimal abstraction. FlightJS is tiny – according to its website “Flight is only ~5K minified and gzipped. It’s built upon jQuery.” FlightJS fits in well with JavaScript ecosystem; because it adds so many fewer features than one of the big frameworks, there is little to get in your way of using it with any other common tool. Based on a quick look at its mailing list and GitHub repo, is getting a small amount of traction, though perhaps much less so than the big frameworks.

Here at Oasis Digital, we are not switching to FlightJS, and we don’t force an event centric approach on our AngularJS work, in which we aim to stay squarely in the mainstream of AngularJS practice. But if something comes up where events are the right solution, we know where to look, and now you do too.

 

HTML to Hiccup Conversion

Recently I wrote about alternative HTML syntaxes and in-language HTML DSLs like Hiccup. Those posts were about the broad issues. This one is about a boring and practical one.

Hardly any project consists entirely of fresh newly-written HTML. Most projects have snippets of HTML brought in from a (hopefully properly licensed) framework or template. For example, sometimes to start an application page I’ll use some HTML from a Bootstrap example page.

Such examples are written in ordinary HTML, not an alternative syntax or DSL, so I need a way to quickly and mechanically convert HTML to (in this example) Hiccup. A couple of years ago I wondered this, did some research, and put a few answers in the Hiccup repo wiki. It (still unchanged as of this writing) lists these tools capable of converting HTML to Hiccup:

Of those three, I found hiccup-bridge and this workflow quite easy to use:

  1. Add [hiccup-bridge “1.0.0-SNAPSHOT”] to project.clj
  2. Save example HTML snippets or pages in files
  3. lein repl
  4. (require ‘[hiccup-bridge.core :as hicv])
  5. (require ‘clojure.pprint)
  6. (clojure.pprint/pprint (hicv/html->hiccup (slurp “html_source/plain.html”)))
  7. Copy output or portions thereof to source code
  8. Repeat for additional files

Of course this could easily be wrapped in to a one-liner command line operation; but for maximum convenience someone should make an online tool for this conversion, analogous to Html2Jade. Maybe I’ll make such a thing, if no-one else does first.

Separation of Concerns != Separate Languages

A while back I wrote about the merits (and problems) of alternative HTML syntax such as Jade, HAML, etc. Another form of alternative syntax for HTML is an “internal DSL” in a programming language. There are various examples out there, including Domo for JavaScript and Hiccup for Clojure/CLJS.

Screen Shot 2014-10-03 at 10.16.20 PMScreen Shot 2014-10-03 at 10.17.29 PM

Hiccup syntax (which is to say, Clojure syntax) is of particular interest to me. Clojure spans server and web client code very well, and Hiccup data structures can be fed directly to Reagent for a concise and efficient dynamic web application based on React under the hood. Observe this snippet:

(defn lister [items]
  [:ul
   (for [item items]
     ^{:key item} [:li "Item " item])])

…in which ordinary Clojure “for” is used for iteration in a web page. I am experimenting with this tool stack – who knows what might emerge.

Why would anyone want to do this?

The reasons I have heard most often are:

  • Many projects are excessively polyglot without good reason. Even an “all JavaScript” project with a Node server typically has JavaScript, HTML, CSS, perhaps Sass, and various mini-languages (like CSS selectors) embedded inside.
  • Separation of Concerns does not have to mean separation of programming languages; even with separate programming languages, there are countless examples of poor separation of concerns, such as Java logic in a JSP template.
  • Your main programming already has a way to (for example) loop, yet you need a new and different way to loop at each layer.

The main reasons to stick with typical, different languages per layer/concern are more obvious:

  • Developers and non-developers probably already know how to use HTML and CSS; in particular, non-developer designers may have little interest in anything but HTML.
  • There are millions examples online for HTML and CSS.
  • Everyone else uses HTML and CSS as they are, let’s just do the same thing.

So again, why would anyone do this? The answer is as with other choices to use unusual technology – a chance to beat the averages and produce more value per time spent.