JavaScript for Line of Business Applications

There are a lot of TODO tutorials out in the wild, and I'm certainly not going to write up another one. What we're going to build today is something altogether more exciting, something never before seen in the world of introductory tutorials. Wait for it... today we are going to build a DICE ROLLER.

Hopefully our Dice Roller is going to show a couple of the interesting Ember features in an application which does not require a server backend.

The first thing that needs to be done is to build an HTML file to serve the application. For starters, this is just a matter of building a basic HTML document with the jQuery, Emberand handlebars scripts included. Handlebars is a templating language which lets you write out data bound templates that are rendered into the browser.

Ember uses a lot of convention over configuration. This basically means that when it goes to a URL, it expects a number of objects to exist with very specific names. If it doesn't find these objects, it can often create default ones.

In this case when we load our application, Ember looks for a handlebars template calledapplication. This template is loaded for every url or request and wraps up and displays the entire application. For now, this template can be quite simple, but when you build a more complex application it can include things like menus, headers and footers.

This article presents a custom control that allows to easily create a data-bound an HTML Table to a remote, server-side ObservableCollection:

* An ObservableCollection is used on the server in order to notify remote clients of updates.
* It uses knockout.js library for client-side databinding.
* It uses websockets internally, but abstracted by Spike-Engine, will fallback to flash sockets for older browsers.
* It is cross-platform and with a minimized packet payload and message compression.
* The application server is a self-hosted executable and the client is just a plain HTML file.

Few weeks before writing this article I had an interesting idea, I wanted to abstract client-server networking and create a nice API that would maintain an HTML Table automatically populated by being data-bound remotely on an ObservableCollection. Essentially, allowing data-bound views be updated in real-time whenever a change occurs and a new item is added or removed from the collection. This would allow people to build seamlessly and easily very dynamic and great looking websites, providing users with a great user experience.

You’ve heard of nCrunch, right?  It’s a continuous integration plugin for Visual Studio that tracks changes to your code and then automatically builds and runs your unit tests in the background whilst you type.  Once the results are back it decorates every line of code with a red or green light to indicate whether the tests are passing or failing.

Where are you going with this?
Good question. nCrunch is fantastic…for .NET development. I do a fair bit of work in .NET but more and more I find myself working in JavaScript and desperately missing the constant feedback.

So how can we get something similar for our JavaScript tests? By using grunt of course!

GruntJS (which I’ve been playing around with recently) can be setup to run QUnit tests using the headless PhantomJS browser and to feedback the results.  In fact, this is all nicely packaged up in the grunt-contrib-qunit package for you, so it’s pretty simple to set up.

This time we’re going to take that shiny new MEAN Stack and put it to good use by building a very simple to-do list. We’ll also set up a basic automated testing suite. This process will take 12 steps and you can follow along here. I will link to the diff on github for each step below as well. The mean-stack-todo repo started off as a direct duplicate of the mean-stack-skeleton repo from last week.

Over the course of this tutorial, you’ll see some of the key features and concepts that make the MEAN stack such a powerful development tool. Here are a few highlights to keep in mind:

* The MEAN stack comes with a very powerful suite of testing tools. Javascript’s flexibility makes writing tests extremely easy, Jasmine syntax makes your tests into aset of stories that help lower the barrier to understanding your code base, and tools like Karma and Nodeunit enable you to have unit test coverage of your entire stack. Even if you decide to not write unit tests for your application, AngularJS’s end-to-end test runner enables you to fully automate your integration testing.

* You can include dynamic Javascript directly into your templates. The first rule of writing AngularJS code is that your Javascript should never reference the DOM. In the AngularJS world, $(‘input#inputName’).val(‘vkarpov’) is (almost) always the wrong thing to do. Your Jade templates should be the definitive guide to all of your app’s UI/UX decisions, while your client Javascript should simply maintain the state of your data.

* You use the same language all the way through. MongoDB stores your objects in a format that is very similar to JSON and the database shell uses Javascript-like syntax. NodeJS queries MongoDB using JSON queries, then passes the resulting objects to AngularJS as JSON objects. What does all this mean? All Javascript, all day. This streamlines the code itself and makes coordinating development across your team way easier.

Tom Dale's answer: As one of the authors of Ember.js, I frequently get asked: "Should I use Angular or Ember?"
I think the answer to that question has a lot more to do with what kind of application are you building?

While there are a few superficial similarities—they both use bindings and are more helpful for writing web applications than, for example, Backbone.js—they quickly depart from one another in how they expect you to approach building apps.

We want developers to be able to build ambitious web apps that are competitive with those native apps. To do that, they need both sophisticated tools and the right vocabulary of concepts to help them communicate and collaborate.

With Ember.js, we've spent a lot of time borrowing liberally from concepts introduced by native application frameworks like Cocoa. When we felt those concepts were more hindrance than help—or didn't fit within the unique constraints of the web—we turned to other popular open source projects like Ruby on Rails and Backbone.js for inspiration.

Ember.js, therefore, is a synthesis of the powerful tools of our native forebears with the lightweight sensibilities of the modern web. 

You can use “meteor deploy myapp.meteor.com” in your project root directory to spin up your app in a development environment that’s maintained by the awesome folks at Meteor. It’s a simple process. The problem is that it is explicitly stated that this is not for Production apps and you don’t get multiple hosts. So pretty quickly, you’ll need to find a new solution once you go live.

Note: Meteor’s hosting platform Galaxy is coming to beta in the coming months. It’ll likely stay in beta for a while with a disclaimer that it’s not for Production apps. When it’s ready, it’s going to be glorious, but until then, you’ll have to find an alternative solution.

Use “demeteorizer” to bundle up your application as a standalone node app and deploy it to one of the several Node hosting platforms like Heroku, Nodejitsu, or Modulus. This will certainly work if you only need one server (dyno, servo, or whatever each person calls it). But once you need to scale beyond that, you’ll bump up against the fact that none of them offer sticky sessions in a way that your Meteor app needs.

Don’t let their marketing fool you. Some claim to offer sticky sessions. They are lying and when you run into problems and in the face of proof (an ip log showing the same visitor hitting multiple servers), they’ll shrug their shoulders and say, “we don’t know Meteor”.

If none of this sounds attractive to you, then you do have another option. It’s the place we ended up at: we just rolled our own stack. And it was easier than you might think.

It is no surprise that streaming technologies such as meteor have taken the spotlight over the last year. They present a compelling real-time way of keeping the client in sync with the server. One interesting result of thinking in real-time is that things like conflicts become top of mind: what is supposed to happen when two separate users modify the same data at the same time?

When dealing with traditional websites and basic REST API's, however, less thought is given to these concurrency scenarios. Real-time aside, in an age where client-heavy applications are becoming commonplace, this behavior can be problematic. In this post, I explore this inadequacy and also explore a possible solution.

The last mile of development for the My Dashboard feature was to spice things up a bit and make it look better. We hired a design company to come up a new look and feel and they went to work. Within a week, we had a meeting with them and they presented a few different options. We picked the one we liked the best and went to work. Below are screenshots that I used to implement the new design.

The last feature I had to implement was the "Show More" bar that appears when widgets are hidden. This was the most difficult thing to implement and I tried many different things before arriving at a solution that works. First of all, the widgets bars that can be expanded are put into their original (collapsed) state using max-heightand overflow: hidden. From there, I look at the list inside the bar and compare the height's of the two elements. If the list is taller than the bar, the Show More bar is added.

One of the more interesting developments in web standards lately is the Indexed Database (IndexedDB for short) specification. For a fun time you can read the spec yourself. In this tutorial I’ll be explaining this feature and hopefully giving you some inspiration to use this powerful feature yourself.

In a nutshell, IndexedDB provides a way for you to store large amounts of data on your user’s browser. Any application that needs to send a lot of data over the wire could greatly benefit from being able to store that data on the client instead. Of course storage is only part of the equation. IndexedDB also provides a powerful indexed based searching API to retrieve the data you need.

We’ve covered the specification and support, now let’s look at using the feature. The very first thing we should do is check for IndexedDB support. While there are tools out there that provide generic ways to check for browser features, we can make this much simpler since we’re just checking for one particular thing.

In my experience, the "next level" tutorials out there seem about 30 levels further along. We go from "Hello, World!" to building out an entire blogging system with comments. Which is also great, but a lot of times those tutorials assume the reader has done a whole bunch of intermediate fiddling, and they often drop a bunch of big functions on you all at once. I tend to learn best by making lots of smaller, intermediate steps, and I don't think I'm the only one.

Well, good news, everyone! I've done the fiddling and read a bunch of tutorials and shouted at my command prompt until things finally worked. I have a web project up and running which uses Node.JS, the Express framework, the Jade HTML pre-processor, and MongoDB for data. I can read to and write from the DB. From there, the sky's the limit.

Here's the deal: I'm going to show you how to get all of this stuff set up. I'll be assuming that you're a front-end developer who knows HTML5/CSS3/JavaScript well enough that I don't have to explain those. If that's you, then this should be a solid primer.

Web components is an emerging group of specifications under the banner of the W3 that provide developers with a serious, browser-integrated mechanism for creating reusable components for the web platform. X-Tag is focused on making a foundational piece of the Web Component spec, Custom Elements, available to all recent browsers.

X-Tag was developed at Mozilla by Daniel Buchner and Arron Schaar, working directly to help shape and advance the W3 specs in partnership with various key individuals at Google (most notibly, Dimitri Glazkov and Alex Komoroske).