Daily Javascript

Feature.js (GitHub: viljamis/feature.js, License: MIT)

Feature.js is a very fast, simple and lightweight browser feature detection library. I received this from a ex-colleage of mine and I was amazed I did not stumble upon this before, since it has more than 1200 stars on Github. There are several features you can test with this library, here is a list of them:

• AddEventListener
• Async attribute
• Canvas
• ClassList API
• CORS API
• Context Menu
• CSS 3D transform
• CSS transform
• CSS transition
• Defer attribute
• DeviceOrientation
• DeviceMotion
• Geolocation
• History API
• Input Placeholder
• LocalStorage
• MatchMedia
• Picture element
• QuerySelectorAll
• REM Units
• Service Worker
• Sizes attribute
• Srcset attribute
• SVG
• Touch
• Viewport Units
• WebGL

Since the tests it uses are pretty straight forward I will not go into this al to much. The most used test is done by simply checking if the requested feature is within the object in needs to be in.

You use it with simple if statements like so:

if (feature.webGL) {
    console.log('WebGL supported');
} else {
    console.log('WebGL not supported');
}

If you want to see it in action head over to the project page where the developer has implemented a nice demo.

Catbee (GitHub: markuplab/catbee, License: MIT, npm: little-loader)

Catbee is Catberry little brother. Unlike Catberry, Catbee use “Single State Tree” conception. All state mutations run in signals, and powered by the AppState module.

All data focused in Baobab tree, instead of distributed flux stores. The tree contains the full application state, and it has 2 interfaces: modify API also known as “Signals”, and read API also known as “Watchers”.

Signal is the only way to modify state tree. It looks like middleware, but it is way more flexible and adopted for sync/async operations. If you want to learn more about signals, checkout this and this. The developers recommend running signal on each user action, when you need change application state, and also signal automatically run on every url change.

Signals use composition conception, and contains an array of independent functions. It’s very simple way to maintain big codebase. Here is an example of a Signal:

let signal = [
  setLoading, // Sync function
  [ // Here we run parallel functions
    getUser, { // Async function with 2 outputs success and error
      success: [setUser], // Run if we call output.success in getUser
      error: [setUserError] // Run if we call output.error in getUser
    },
    getNews, { // It's function will run parallel with getUser, like Promise.all
      loaded: [setNews],
      error: [setNewsError]
    }
  ],
  unsetLoading
];

Components can access data by watchers. There are two main reasons you should use watchers. You’ll need data context for template rendering, and you’ll also need state update events to rerender your component. You do not need bind watchers manually, it’s inside of Catbee.

// Here we use simple Baobab.watch API
module.exports = {
  news: ['news', 'data'],
  isVisible: ['news', 'UIState', 'isVisible']
};

// You can also use Baobab.watch dynamicly
module.exports = function (attributes) {
  // Here attributes is <cat-component id="unique" cat-id="1" watcher= "dynamic"></cat-component>
  var id = attributes['cat-id'];

  return {
    title: ['news', 'data', { id: id }, 'title']
  };
}

I really like this library because of my associations with Baobab. My first encounter with it was via the post “Plant a Baobab tree in your flux application” which was written by Christian Alfoni. It lead me to think differently about flux and redux, I recommend you read it.

Don’t forget to challenge yourself this week. I prepared another weekly challenge which is: “Implement the Mandelbrot set using Javascript”.

Little Loader (GitHub: walmartlabs/little-loader, License: MIT, npm: little-loader)

Little Loader is a lightweight JavaScript loader which is advertised as “The Only Correct Script Loader Ever Made”. It was developed by Formidable for a project they did for Mallmart.

The need for this library grew from the lack of browser support for the which the team needed. To give an example look at the overview made by the team.

I’m already using it in one of my projects because after watching the introduction video I was convinced this is the best library for dynamically loading remote JavaScript files.

So how do we work with it? First of all make use it is installed by running:

npm i little-loader -S

Now we can require it within our app like so:

const load = require("little-loader");

load("http://example.com/foo.js", function (err) {
  // .. This is where you continue with your app.
});

That’s all actually. There are multiple ways to include Little Loader. You can get it from a CDN, from npm and it is compatible with AMD loaders such as RequireJS.

When including Little Loader via a normal script tag, it will attach it self to the window Object and can be accessed via window._lload like so:

<script>
  window._lload("http://example.com/foo.js", function (err) {
    // .. Your code....
  });
</script>

It’s Friday again, which means no new library today, but to make up for it I think I chose a really nice challenge. The Mandelbrot set. Some of you guys are probably familiar with it already from school or as a performance test.

I came across this problem just recently when I was looking at the bigfloat library. The developer included it as a performance demo and it got my interest because of “The Computer Language Benchmarks Game”. Where it is listed as one of the benchmarks challenges.

For details on the challenge go to the challenge page.

The results will be up next Friday so make sure you have submitted your implementation before then.

NuclearJS (GitHub: optimizely/nuclear-js, License: MIT, npm: nuclear-js)

NuclearJS is a reactive flux implementation build with ImmutableJS data structures. It has been developed by Optimizely, which is a company that provides A/B testing suite and more as a service.

NuclearJS was designed first for large scale production apps. For a much more lightweight Flux implementation that shares many of the same ideas and design principles, as check out Microcosm.

As we have seen many Flux implementations already we have grown skeptical about new implementations. So that bears the question: “How NuclearJS differs from other Flux implementations?”.

Well all app state is in a singular immutable map. In development you can see your entire application state at every point in time thanks to awesome debugging tools built into NuclearJS.

State is not spread out through stores, instead stores are a declarative way of describing some top-level domain of your app state. For each key in the app state map a store declares the initial state of that key and how that piece of the app state reacts over time to actions dispatched on the flux system.

Stores are not reference-able nor have any getX methods on them. Instead NuclearJS uses a functional lens concept called getters. In fact, the use of getters obviates the need for any store to know about another store, eliminating the confusing store.waitsFor method found in other flux implementations.

NuclearJS is insanely efficient - change detection granularity is infinitesimal, you can even observe computed state where several pieces of the state map are combined together and run through a transform function. NuclearJS is smart enough to know when the value of any computed changes and only call its observer if and only if its value changed in a way that is orders of magnitude more efficient than traditional dirty checking. It does this by leveraging ImmutableJS data structure and using a state1 !== state2 reference comparison which runs in constant time.

Automatic data observation / rendering – automatic re-rendering is built in for React in the form of a very lightweight mixin. It is also easily possible to build the same functionality for any UI framework such as VueJS, AngularJS and even Backbone.

NuclearJS is not a side-project, it’s used as the default Flux implementation that powers all of Optimizely. It is well tested and will continue to be maintained for the foreseeable future. Our current codebase has over dozens of stores, actions and getters, we even share our prescribed method of large scale code organization and testing strategies.

For examples I would refer you to project homepage because there you can find better explaintions than I can give it in my daily posts.