The JavaScript blog.


browser mv* client-side frameworks

The jsblocks Framework

Posted on .

Antonio Stoilkov sent in jsblocks (GitHub: astoilkov/jsblocks, License: MIT, npm: jsblocks), a new client-side framework that claims to have a rendering performance that is faster than React. It's a full-featured framework, and has some unique features. For example, it aims to improve the debugging experience of client-side apps, so rather than getting lost in confusing stack traces and DOM trees, it attempts to display very clear error information.

jsblocks debug examples

jsblocks is made of three main modules: blocks.query, blocks.mvc, and jsvalue. You can use all three libraries, or create builds with the ones you need. Here's what each library does:

  • blocks.query: The core library
  • blocks.mvc: The "Model View Collection" implementation
  • jsvalue: A utility library that works like Underscore or lodash

Models in jsblocks are used to represent values that are rendered in views. For example:

var User = App.Model({  
  init: function () {
  firstName: blocks.observable(),
  lastName: blocks.observable(),
  fullName: blocks.observable(function() {
    return this.firstName() + ' ' + this.lastName();

App.View('Profile', {  
  profile: User({
    firstName: 'John',
    lastName: 'Doe'

Models use observables, so this example should make complete sense to those of you who are experienced with Knockout -- in some ways it reminds me of a blend of ideas from React, Backbone, and Knockout.

Collections are actually built out of observables, but the author suggests that they add an extra architectural layer to your application that can make it clearer. This definitely reminds me of Backbone.

Collections and models can also talk to the server -- both have a sync method:

var Products = App.Collection({  
  options: {
    create: {
      url: 'serviceURL/CreateProduct'

App.View('Products', function () {  
  products: Products(),

  init: function () {
      ProductName: 'Fish'

    // sends AJAX request to the create.url with the new item

Models even support validation, so you can validate user input. Because jsblocks lets you work with data it also has a utility library for iterating and filtering data. This is the jsvalue library I mentioned earlier:

  .range(1, 100)
  .map(function (value) {
    return value * 2;
  .filter(function (value) {
    return value % 2 == 0 && value < 50;

Views support routing, and the routing implementation supports hash URLs and pushState history. Views can also be rendered on the server.

jsblocks has very quickly earned a big following -- it has over 1,500 stars on GitHub. I think the reason for this is it combines almost everything you need for modern web development: data modelling with validation, server sync and filtering, server-side view rendering, client-side view components and data binding, and client-side routing.

If you're a Backbone user and want to try something new then jsblocks may appeal to you. Equally, if you're a React user but struggle with dealing with data then jsblocks might make things easier for you.


libraries modules tabs localStorage client-side

The Local Storage Bridge

Posted on .

Doing something as simple as passing values between iframes and tabs is surprisingly awkward, and you'll end up trying anything to get it to work. Krasimir Tsonev has created a library called lsbridge (GitHub: krasimir/lsbridge, License: MIT, npm: lsbridge), or Local Storage Bridge. It allows you to send messages between tabs using Local Storage as a communication channel.


The API uses the .send and .subscribe methods to pass messages one way. You can also call lsbridge.isLSAvailable to check if the Local Storage API itself is available. Here's an example of the usage:

lsbridge.send('my-namespace', { message: 'Hello world!' });

lsbridge.subscribe('my-namespace', function(data) {  
  console.log(data); // prints: { message: 'Hello world!'}

console.log(lsbridge.isLSAvailable); // prints "true" or "false"  

Internally, lsbridge uses a setTimeout polling loop to set and remove items. The interval is 100 milliseconds, and there's a separate interval for item removal which is set to a second.

This is a pragmatic way to send data between tabs that doesn't require ugly hacks. For more context behind the library, see Krasimir's blog post Using Local Storage as a communication channel.


libraries node modules client-side

Terminal.js: A Terminal Emulator Library

Posted on .


These days the terms VT100 and terminal are synonymous with either text-based interfaces or a shell. But there was a time when terminal referred to "computer terminal" -- a machine that allows you to input commands into a computing system and view the results. This includes CRTs and teletype printers. The VT100 terminal was based on an Intel 8080, and if I remember my computer history correctly represents a transitory stage between the era of remote mainframes and local minicomputer systems.

The thing that's interesting about the VT100 is it implemented some of the ANSI escape code sequences that we still use to annoy people on IRC and make quirky command-line tools. So when you see a terminal emulator set to VT100, it means it supports the features the VT100 had for cursor movement, clearing the display, and so on.

Terminal.js (GitHub: Gottox/terminal.js, License: MIT/X Consortium License, npm: terminal.js) by Enno Boland is a VT100 emulator that works in browsers and Node. Enno has also published node-webterm, which you can use to try out the project in a browser.

The API allows you to create a terminal object, write data to it, and get data back out. This demo uses the colors module:

var colors = require('colors');  
var Terminal = require('terminal.js');  
var terminal = new Terminal({ columns: 20, rows: 2 });

terminal.write('Terminal.js in rainbows'.rainbow);  

Internally, the source is split into handler, input, and output modules. The handlers are basically JSON maps between characters and internal state. For example, handler/esc.js has the escape code handlers for things like moving the cursor down a column (ESC D).

You could use this module to provide a command-line interface to web-based developer tools, or maybe even make your own Chrome OS/iOS-friendly IDE. The node-webterm example demonstrates how to connect the terminal up with WebSockets, so it actually feels pretty low latency. Check out node-webterm/index.html to see how that can be implemented!


libraries client-side starred

Worth Starring: Components

Posted on .

Back in July, TJ Holowaychuk wrote a post entitled Components in which he outlined an approach to JavaScript project distribution. In the post he discusses CSS and the relationship with modernisation, asset bundling and packaging, require fragmentation and package distribution, and the potential move away from libraries like jQuery in the future.

An example of a calendar component.

Almost four months later I found myself wondering what TJ and his collaborators had done since then. I was surprised to find 123 public repositories in the component GitHub account. There are repositories with updates as recent as a day ago.

It's impressive how many of the repositories are truly generic, given the number of them. For example, enumerable helps iterate over sets of objects -- a very focused slice of Underscore's functionality. Other repositories are reminiscent of popular jQuery plugins, and come bundled with cut-down CSS and structural markup, as promised by TJ's post. The menu component is a good example of this.

There's also a search-api repository for the component registry.

TJ attempted to formalise the structure of components in the Component Spec. The specification includes details on a JSON manifest file, project directory structure, and submission to the registry.

It would be entirely possible to use these repositories alongside jQuery-powered client-side apps. Quite a few will work well in Node. I haven't seen many projects using these components yet, but lots of them are worth adding to your GitHub starred repositories.