JavaScript for Line of Business Applications

Nightwatch is a recently released acceptance framework based on Node.js that uses Selenium WebDriver API to automate web applications testing. The tool promises a simple syntax which enables the writing of end-to-end tests using JavaScript and CSS selector that runs against a Selenium server.

But when we do it purely in the browser, we have to make quite a few concessions: search engines have a hard time indexing that content, for example. It also takes longer for users to see the rendered content (not in every case, but in many, many cases.) Also if you're using a lot of plugins for your favorite library, or a heavyweight MVC framework, sometimes it can slow down interactivity.

I've thought for a long time (and blogged about it previously) that the ideal solution would fully render the markup on the server, deliver it to the client so that it can be shown to the user instantly. Then it would asynchronously load some Javascript that would attach to the rendered markup, and invisibly promote the page into a full app that can render its own markup. This code would also have to be fast enough to meet or exceed the performance of other modern solutions, or it won't be worth it.

What I've discovered is that enough of the pieces have come together, that this futuristic-sounding web environment is actually surprisingly easy to do now with React.js. React isn't a full-fledged framework, it's a library, so you'll have to build your own foundation and write some glue code. I've been rewriting an existing website in React (usually a terrible idea, we'll see about this time), and now that the code is settling down a little bit, I'd like to share how it works. This post will just be an overview, but up next I'll share some of my glue code and lessons learned etc.

a dynamic form library for Facebook React, providing abstractions for building dynamic forms and controlled grids. Widgets provided by Telerik's KendoUI.

Traditional javascript widget libraries (JQueryUI, KendoUI, Sencha) tend to model each wdiget as a standalone MVC entity. For example, a ComboBox widget has code for managing the state of the combobox, for updating the DOM when the state changes, and for logic like querying for the list of options and for applying filters. The React philosophy is that this approach results in poor separation of concerns and makes large codebases difficult to reason about.

In React, widgets are pure (in the functional programming sense). All state is stored in a central javascript controller layer (not in the DOM). Views are pure and are seperated from models (unlike MVVM which couples model and view). This means, for example, that the invalid-ness or disabled-ness is not decided by logic the widget itself; rather, logic outside the widget determines the widget state and then the "dumb widget" will render to match this state. This means complex validation rules and other business logic can be handled in a central location, decoupled from the widgets.

Knockout MVVM + offline persistence with Amplify. Automatically bind the model to offline storage. This script leverages both systems.

After an extensive Google search I found a script that leverages both systems to store a single observable. The interesting thing is that it uses Knockout’s subscribe method to subscribe to changes. This means all changes are ‘automatically’ stored away. I’ve decided to extend Knockout’s ko variable...

Here are the main things we will be doing in this tutorial.

* Create a controller that will automatically pull from repo and restart server.
* Get sails to run in production mode and deploy using forever.
* Auto update code on git push using git hooks on BitBucket (probably very similar for github)

JavaScript routers provide developers with a method for tracking user state and loading required resources, as needed, without requiring a URL change or page reload. 

A quick Google search for “JavaScript router” will present you with a number of useful libraries (e.g. Sammy, Crossroads, etc…). However, my personal experience with such libraries has left me wanting more structural guidance when developing large, complex single-page applications with dozens (or hundreds) of routes. To fill that niche, I have released EdisonJS.

Most JavaScript routing libraries provide little to no guidance in terms of how one might best go about organizing complex single-page applications with many routes. EdisonJS seeks to simplify the organizational structure of complex single-page applications by encouraging developers to organize their applications as a series of parent (“section”) child (“route”) relationships. The result is a simple, clean, and powerful organizational structure.

EmberJS has a lot of features for helping you build a clean JavaScript interface. One of my favorites is the computed property; Ember can watch a property or set of properties and when any of those change, it recalculates a value that is currently displayed on a screen...

In my last project I needed to cacluate the sum of a few properties in an array. What I need is something that works like Ember.computed.alias('name') but allows me to transform the object instead of just aliasing a property...

This allows me to easily define a 'sum' for a property without a lot of duplication. 

React is, according to their own definition, “A Javascript library for building user interfaces.” When I first read about react, it immediately struck me as a very good solution for a front end javascript framework. After making a couple small projects using react, I can conclude that it is a pretty great framework after all. In this post, I’ll outline how to hit the ground running as quickly as possible with react.

React uses a specialized version of javascript called jsx. The basic idea is to provide some intuitive syntactic sugar to represent react’s internal version of the DOM which is used by react components — the building blocks of a react-based application.

Knockout JS does an excellent job in binding the interface with a View Model. Sometimes we’ll need to do some data manipulation before it can be shown to the users. How would we go about?

A few options come to mind...

jide.js is a new toolkit for creating modern web applications. It consists of a collection of useful controls and all the tools you need to create your own, application specific, components. jide.js fully embraces AMD (require.js) to allow you to pick only those parts of it that you truly need. Starting with version 1.0.0-beta3, you’ll also be able to use it with Browserify.

At its core, jide.js is built around observable values, event emitters, and data binding. It utilizes the features of modern browsers (IE9+) to create a solid cross platform experience and to leverage the features of the current JavaScript language instead of clinging to the past.

This article only serves as a brief introduction to jide.js. There are lots of other controls built into jide.js that help you create your application, and the presented style is only one way. If you prefer not to use templates at all, that’s fine too. You can, for example, use operations such as filter, map and sortto create live updating variants of your original data.

To learn more about jide.js, please visit the project website where you can find lots of examples, demos, and guides. You are also directed to the project’s GitHub repository.

When I read Atomic Product Development a few weeks ago, it was a lightbulb moment for me. It managed to finally put words (and code!) to the handful of loose ideas that had been rattling around my head for the better part of a year. I've started contributing to the project, and you'll undoubtedly hear more about it from me in the future, but I thought it might be helpful to first show a basic application of the concepts to AngularJS.
The atomify projects (specifically atomify-js and atomify-css) were not created with frameworks like AngularJS in mind. If you take a look at the atomify-example, you can see it's more like Backbone or vanilla JS, but the principles and underlying tools are universally appealing.

Therefore, the challenge I've spent the last couple of weeks solving is how to utilize that foundation in the context of AngularJS. As it turns out, it's actually pretty simple.

I had always been repeating what I’d heard about screen readers: they can’t work with JavaScript. Turns out that’s not exactly true. The video is the best way to show you...

* VoiceOver, Ember.js, and WAI-ARIA

Protractor is an end to end test framework for AngularJS applications built on top of WebDriverJS. Protractor runs tests against your application running in a real browser, interacting with it as a user would.

Protractor can be run as a standalone binary, or included into your tests as a library. Use Protractor as a libraryif you would like to manage WebDriver and your test setup yourself.