JavaScript for Line of Business Applications

A real-time framework for single page applications. The idea behind it is to have strong conventions for practices that suit single page apps, including transparent minification and bundling.

It wraps around Express, so route definitions look like a typical Express project, but Apper also has specific places for things like middleware and application settings.

If you’re new to Express then you might like working with the conventions Apper uses, and it will at least push you away from putting everything in a monolithic app.js file.

I think things can be simplified to a single abstraction since the underlying problem to all of this is the same. I present to you CSP and the concept of channels. CSP has been highly influential in Go and recently Clojure embraced it as well with core.async. There's even a C version. It's safe to say that it's becoming quite popular (and validated) and I think we need to try it out in JavaScript. I'm not going to spend time comparing it with every other solution (promises, FRP) because it would take too long and only incite remarks about how I wasn't using it right. I hope my examples do a good enough job convincing you themselves.

A small example exploring how to integrate D3.js data visualizations into a React app.

I think that using React and D3.js together makes sense because they share a common philosophy of "give me a set of data, tell me how it should be rendered, and I'll figure out which parts of the DOM to update for you". Indeed, React has its virtual DOM diffs, and D3.js has its update selections, making both quite efficient in the business of keeping the UI in sync with data changes.

I find that making D3 components play nice inside a React app becomes easier when you follow these simple guidelines: ...

It is pretty awesome at most of the part, so if you need something like Rails for Node.js, Sails is the way to go.

The Sails.JS is an MVC framework, so there are Models, Views and Controllers.

In Sails.JS you can create models, and model represents the data model, so if for each table you would have a model and in case of no-sql databases, each collection is represented by a model. Inside a model you can describe, the attributes present in that model, their datatype and validation rules.

Following the release of Orbit.js, Ember Orbit was announced at the Wicked Good Ember conference. Again, I became excited about using smaller JSON Patch payloads (media type "application/json-patch+json"), see RFC 6902. I started a new branch and decided to support a REST source first; then later tackle a WebSocket source. I am a fan of the JSON API specification which does include patch support. Once I had a JSONAPISource working with Ember Orbit on my branch I updated my SocketSource prototype (class) to follow the JSONAPISource prototype so they could share the same serializer. Also if the client's browser doesn't support a WebSocket or perhaps in the case my socket server gets wacky the application can initialize with the JSONAPISource instead of the SocketSource prototype as the connected source to the application's MemorySource.

Somewhere along the way, I noticed that the community had gone HAM on using Components all the time, in almost every circumstance. To me this seemed crazy! Views have their place, Components have their place. I was curious as to how this shift had come about.

What if we could approach the problem from a different angle? What if we took an existing, non-visual platform that already allows developers to do whatever they want and put a visual layer on top of it? That platform is Node.js and that visual layer is WebKit. Put them together, with Javascript as the underlying engine and WebKit as the visual layer, and you have Node-WebKit!

A suite of examples written for Sails.js, AngularJS, and Twitter Bootstrap.
Contents:

* A REST API test page using Sails' transport agnostic routing (HTTP vs. Socket.io)
* A "Todo List" app demo using Sails' Socket.io messaging and REST Blueprints
* Passport middleware authentication integrated with Sails policies.
* Twitter Bootstrap / Font Awesome custom LESS compiles (Grunt)
* Cache busting JS/CSS for production (Grunt)