Nobody actually makes single page apps in a single page anymore, do they? Some are saying they should really be called native web apps, which sounds fine to me. Anyway, coincidentally two readers sent me their own single page app libraries. They both build applications from separate files, but work in quite different ways.
Griffin.yo (jgauffin/griffin.yo, License: Apache 2.0) by Jonas Gauffin is a framework written in TypeScript that supports templates, view models, routing, and caching of server-side data.
Once views and models have been loaded they are cached in the browser (the cache is emptied if the browser is reloaded). Thus as long as the user continues to use the site as a SPA application everything is only loaded once from the server.
There's a blog post about Griffin.yo that introduces the main ideas, and the examples are written with TypeScript. It uses a project structure that is similar to many other web frameworks. I don't think there's a project generator, so follow the quick start guide if you want to try it out.
The other SPA project I was sent recently is Igaro App (GitHub: igaro/app, License: GPL). The author, Andrew Charnley, claims it's faster than AngularJS, and the current version is 1.0.0.
The thing that makes Igaro different is it's HTML-free. It avoids using DOM query selector methods to try to improve performance, and therefore has no template engine. Instead it uses routes to build pages, and standard CSS for styling and layout.
There's a DOM element creation API, so you can make elements in a way that reminds me of React:
Objects created by Igaro are decorated with features for two-way parent-child event management, and dependency tracking. You can do this to arbitrary objects by using the bless method. Bless could be used to make widgets that work with Igaro apps.
In terms of ES6 support, Igaro makes heavy use of promises, which makes sense. Given the use of string fragments over templates, I expected to see ES6 template strings. I couldn't find any examples of template strings in Igaro, but given that it has a Grunt-based build system I don't think it would be too hard to add Babel to an Igaro project.
I think the paradigm shift to "native web apps" is the right way forward for single page web apps. Rather than the community settling into Angular or React it seems like we're making more libraries – and more creative libraries – than ever!
The API is based around events. Here's a quick example:
Naturally it promotes Code School (owned by Pluralsight), but it's nice to see something useful and well designed there. It used to have a very dated internet.com page, so Code School's page is a step up.
Are you a fan of Node's crypto API? Like the other core modules, it tries to strike a balance between providing the bare minimum and just enough abstraction. You shouldn't need to be a cryptography expert to use it, but at the same time it doesn't want to be too limiting. However, whenever I need to quickly md5 or sha1 something, it feels like too much work. I also find it a little difficult to explain to beginners.
Sindre Sorhus has written a module called hasha (GitHub: sindresorhus/hasha, License: MIT, npm: hasha). It provides a more friendly wrapper around crypto that uses sensible defaults. To get a hex encoding of a string, you can just use hasha(new Buffer('unicorn')). If you want to hash a file, then use hasha.fromFile with a callback. You can supply the desired hashing algorithm as well:
The ability to render any React component over a map means you make dynamic map features that feel very fast -- Ivan's library calculates the co-ordinates independently of Google Maps, so you can treat your React code separately instead of worrying too much about how it relates to Google Maps.
Now every object on the map can be hovered (however, you can still use css hover selectors if you want). If you try zooming out here example, you will still be able to hover on almost every map marker.
This algorithm allows you to tweak hover probability of map objects, for example making some objects "more hoverable". distance_hover example with different hover probabilities
The main example shows a map combined with fast infinite scrolling, SVG icons, and balloons made with React.
MyScript is a service for handwriting and handwritten shape recognition. Gregory Pakosz sent in some Polymer MyScript components for interacting with the service. The components are built with MyScriptJS, and they cover things like mathematical expression and text recognition.
The demos on the MyScript Web Components homepage are interactive, so if you select the <myscript-math> example and press play you should be able to draw some equations and see the results.
Rozu (GitHub: avoidwork/rozu, License: BSD-3-Clause, npm: rozu) by Jason Mulligan is a webhook API server that uses io.js or Node, MongoDB, and Redis. MongoDB is used for persistence, and the Redis pub/sub API is used for inbound events.
It's built with tenso for the REST API, and keigai for data storage with MongoDB. It can both send and receive webhook events. To send events, you make a POST to /send with a logged in user, and to make it receive a JSON payload you use /receive. Receiving events uses a token, so it's pretty easy to use it with sites like GitHub.
Once you've installed it you can create an account by making a GET request to /register. If you visit / (whether signed in or not) you'll get a list of API methods.
The problem is that we use several different packages to build our application, taking full advantage of the awesome NPM private modules that were recently released. The problem was that it has become increasingly hard to keep track of what environmental variables were required to make the project function, or were just generally available, because they were all being accessed at different levels of the applications dependency tree.
With environmentalist, you define a JSON file that specifies each environmental variable:
"description": "Used to compute the password hash of users",
Because you can include a description it's already useful because in my experience most people export (or heroku config:set) and forget about it later. I also like the fact you can set a default value and the required state. The name is the only required field, so if the values are obvious and self-documenting then you can keep things simple.
When you run environmentalist in the command-line, you'll see a table that shows all of the environmental variables in the current package and its dependencies, which means you can construct projects from submodules with environmentalist JSON files and it'll dig them all out.
If you've created a Node application but you want to support plugins, what to do you? package.js (GitHub: s-a/package.js, License: MIT and GPL, npm: package.js) by Stephan Ahlf is designed to allow you to open up your project to plugin developers through npm or other package managers.
It allows you to load modules from a set of paths, and then ensure each module has a property (expectedPackageIdentifier) in its package.json. It's a small module with unit tests and an example in the readme.