UI Technology Choices

Angular

• Most popular frontend framework

• Backed by Google
• Web component (directive) idea interesting for creating reusable components and mixing behavior into tags
• Comes with building blocks for structuring application and code (suggested file system layout, controllers / services / directives)
• Large scale framework is appropriate for large scale application

Compared to Backbone

For a large scale app such as ultra, wanted something which would impose more structure on the code. Backbone is fairly low level, and we wanted something at a little higher level of abstraction to reduce boilerplate and simplify common tasks.

Compared to Ember

Ember was a reasonable choice as well. Angular was favored due to being the most popular UI framework, which would help us hire people who are already familiar with it. In recent time, Ember has released some impressive performance enhancements that might have given it enough of an edge over angular to be considered more deeply (but too late now).

Cons

• Easy to create performance issues not present in other frameworks (dirty watching, inefficient DOM access, etc.)
• Recently, Google released they are focusing efforts on Angular 2, which may be difficult to migrate to
• Introduces its own module system which is not useful if using something like AMD or typescript modules
• Can take a while to learn, especially all the details around directives

Typescript

• This one was a pretty easy choice for an application of ultra's scale.
• Ability to refactor code
• Catch some defects at compile time instead of run time
• Higher chance of catching conflicts during integration of multiple code lines
• Allow us to use some ES6 features today (classes, arrow syntax)
• Generated code is "very close" to plain javascript. Helps w/ debugging and reduces lock-in (if we decide we don't want to use it later).
• Recently, has seen increasing adoption and support from Google (used in angular 2.0)

Compared to coffeescript

Coffeescript is mainly just syntactic sugar, and doesn't provide typing. As javascript itself improves (ES6, ES7, etc.), coffeescript will not be as useful, and it may even run into trouble for diverging from the new JS standards. On the other hand, typescript has committed to following the javascript standards track such that it is always just augmenting javascript.

Compared to Dart / Haxe / ClosureScript / Scala.js / etc.

Some of these may have been reasonable, but still waiting to see if any go mainstream. The major danger with them is if the abstraction is too far from javascript itself, the generated code may be difficult to follow or bloated. Given the improvements underway to javascript, betting on it via TypeScript looked like the safer bet.

Cons

• Introduces non-trivial build time
• Introduces a layer between "the code we write" and "the code we debug"

SASS

• Benefits over plain CSS are pretty well understood
• Ability to specify variables, mixins, functions, etc.
• Writing styles in "nested" form is much cleaner and helps prevent "style leaks"

Compared to LESS

SASS and LESS are pretty similar, but SASS is slightly more powerful (or at least it used to be).

Cons

• Compiler is in ruby and is slow (we use a C based open source one via node.js/grunt). LESS's compiler is written in node.js and is reasonably fast.
• Similar stuff as typescript around introducing a build and some indirection between what runs in the browser.

Foundation

• Base style scaffolding
• Widgets
• Modern, forward looking

Compared to bootstrap

Used to only support LESS (supports SASS now). Major advantage of foundation over bootstrap was built in support for rem's.

Cons

• Javascript widgets are difficult to use, not very feature rich, and some don't have built in localization (yet)

Restmod

• Create domain entities to encapsulate model logic and data (vs. "wild west" API access)
• Bind against shared models in the UI instead of one-off containers
• Highly extensible and configurable

Cons

• A little unnatural to mock test data (we could create our own tools to improve this)
• Can be challenging to model some aspects of the Learn API
• Building up "object chains" can be a little verbose (CourseModel.$new(id).gradebook.columns.$new(columnId).grades.$fetch())

Grunt

• Has become the industry standard build tool
• Very large ecosystem of modules (via npm)
• Node.js is very portable, lightweight and easy to setup and run

Compared to gulp

For every open source project using gulp, there's more than 100 using grunt. Grunt has a large ecosystem. Gulp's main selling point is that it is faster and that modules are more "general" (can be used outside of gulp), but in practice grunt is fast enough and gulp modules require thinking in streams instead of files which is a little more difficult. At the time, gulp had some issues around composing tasks.

Cons

• Can do a lot of things, but can't cook me lunch and dinner

Node.js

• Very portable, lightweight and easy to setup and run
• Easy for non-highly-technical people to use
• Required to use grunt
• Module ecosystem (express, nedb, etc.) is a great fit for writing the mock API quickly
• In production, just serves the index.html (rest of assets is served by CDN), which it can handle easily

Cons

• It's not java