Overview

What is skit?

Skit is a JavaScript framework for building web pages with this controller lifecycle:

Controller.create({
  preload: function(done) {
    MyAPIClient.getThing(function(thing) {
      this.thing = thing;
      done();
    }, this);
  },
  render: function() {
    return template(this.thing);
  },
  ready: function() {
    events.listen(dom.get('.thing'), 'click', function() {
      this.thing.clicked = true;
      this.rerender();
    }, this);
  }
});

… that execute like this:

Server preload() → render() → Browser ready()

… automatically, without having to configure anything.

What’s skit made of?

  1. A webserver that runs your controllers on the server, then sets them up in the browser with the same-ish state automatically.
  2. A module system for building components that consist of templates, stylesheets and JavaScript together.
  3. A set of lightweight libraries that facilitate issuing HTTP requests, managing cookies, and handling navigation on the server and client side transparently.

What’s it for?

Skit is good for building web apps on existing HTTP-based APIs, like the one you probably already built for your mobile app.

Skit lives in the view layer

Skit is not a full-stack framework, or even a “Node.js framework” in the typical sense — it’s more like a client-side framework that also runs on the server side.

Features

Share client- and server-side code without thinking

  • Write a single JavaScript codebase for your web app. No more client-side app bootstrapping hackery or configuring static asset pipelines.
  • Everything from URL routing to HTTP redirects to “DOMReady” is handled by the same JavaScript controller classes.
  • Skit platform libraries are built to work on the client and server.
  • Build a single HTTP API client for your backend in JavaScript.
  • “Nearly 100%” — if you want, keep cookie/API secrets on the server side only by proxying API requests through skit.

Zero configuration

  • No configuration files.
  • Directory structure dictates URL routes for skit controllers. (!)
  • Automatic resource grouping and minification in production mode.
  • Awesome, unobfuscated development mode for the best development.

The best modules ever

  • Build complete JavaScript/CSS/HTML modules. No need to configure the module loader, just start adding files.
  • Modules are based on a common filename prefix, so you don’t have to add a bunch of boilerplate code to make a new one.
  • Once your modules are defined, they are loaded on the server and client automatically.
  • In production, resources are bundled, versioned and optimized automatically.

SEO the Natural Way™

  • Render content on the server side, then use the same templates to render supplemental content on the client side as users interact with your app.
  • Quit returning empty responses with a loading spinner. Seriously, cut that out.
  • Robots should like you for you, don’t you think?

How it works

Skit initially renders a controller in the server, then reinstantiates the controller in the client.

Skit request lifecycle

The skit lifecycle starts on the server side, where the server loads the current page’s controller module and renders a response. Then, in the browser, the controller module is reconstructed and the execution continues.

Server side

  1. Skit parses the URL structure to find the current skit controller
  2. Skit instantiates your controller module

  3. Your controller: Example.js

    1. preload() — Loads data from the backend API
    2. load() — Sets up state after data is loaded
    3. render() — Generate <title> text and <body> HTML for the resulting page
  4. Skit stores the state loaded in preload
  5. Skit outputs the HTML rendered during render
  6. Skit outputs a bunch of extra JavaScript to take over in the client

↓ HTTP transport ↓

Client side

  1. Skit reloads the same server-side modules in the client
  2. Skit restores the state loaded in preload, serialized as JSON

  3. Your controller: Example.js

    1. load() — Sets up state after data is loaded (now in the client)
    2. ready() — Sets up client-side event handlers for clicks, scrolling, etc.
    3. … whatever else your client does in the browser.

Default configuration

  1. Templates are rendered with Handlebars. There exists a facility to roll your own and use your own template compiler here, but this is not documented yet.
  2. CSS is just plain CSS. CSS files defined in modules are always included when the module is required.
  3. JavaScript is plain JavaScript. There is support for inserting your own compiler step here (eg. CoffeeScript), but it is not documented yet.

Try it

Install skit and run an example project to get a feel for it:

 $ npm install skit
 $ ./node_modules/.bin/skit skeleton skit-example
 $ ./node_modules/.bin/skit run skit-example --debug

Also check out Getting Started for a more comprehensive walkthrough.

See skit in action

Visit https://launchkit.io/ and log in to see skit in action. Inspect the source returned from the server to find bits of skit magic.

FAQ

  • You seriously made another module loader?

    Yeah. There are several reasons why:

    1. To create a new-feeling environment that is clearly not node, because you’re writing code that runs in node and IE9 and Chrome etc. It shouldn’t feel like any old node.js module.
    2. In order to automatically include stylesheets and template partials used by other templates.
    3. To add a notion of internal-module-only includes. Internal includes, usually partials and secondary stylesheets and sometimes internal classes, can’t be loaded by other modules.

  • Can I use this with <my favorite framework>?

    Maybe! It won’t help too much if your existing client-side framework of choice depends on DOM manipulation for rendering, however.

    I have successfully integrated React (and automagic .jsx compilation) in this example project; I’m no React expert, but it seems pretty cool.

  • Did you know “skit” means “shit” in Swedish?!

    Now I do! Tusen tack! Var är toaletten?