That naivety led to A Shift in Attitudes the following year. While my go-to stack was starting to shape up, the industry was still going through a major upheaval and I was still too new to recognize that there was no settling down.

Even today, I think we’re still in that state, with major new frameworks, libraries and tools showing up weekly. So this shift recognizes that I have a new current stack: which is just the set of tools I’m currently using while I hide from JFF.

I wasn’t going to post anything else on Medium and instead, start posting any new articles on dev.to, since Medium has become so commercial with disabling the ability to read some articles completely, unless you’ve paid a membership fee. But I can’t let my most recent posts refer people to tools and frameworks I no longer use.

Of course, different projects may call for different tools, but most of my projects both at work and at home have similar needs and complexities, and as a result, I have been able to stick with a few core choices. I’ll list those below.

I’m going to break this into application (client) and back-end (server) stacks.

Current 2020 Tools: Application

I had written about moving to Vue.js in 2017, and the reasons why there, and it has been solid for me every since. There were a couple of things from React I would have liked to have, but overall Vue was still my preferred web app framework anyway. Furthermore, all of those have been added in the imminent release of Vue 3. Vue is fast and easy to get going with, but has some finesse depth that I’m still learning in year 4.

For components and styling, if you’re using Vue, nothing really competes with Vuetify. Incredibly deep, flexible and powerful, it makes my applications really look great. And a creator who cares a lot less about the money than about providing useful tools (so please sponsor him and do what you can to help, I’m sponsoring the project both on GitHub as well as on OpenCollective, as well as having purchased one of their themes). I’ve also contributed to the project with some code work. If you use something for a key part of your work, for free, please do what you can to give back. It may not be much in these times, but with enough of us doing it …

I’ve needed to produce desktop applications for Windows and Linux (occasionally Mac OS X), so Electron is my go-to tool there. It is really quite powerful and once you figure out your project (build process), it just works and provides installers as well. It may be as easy as “yarn add electron-builder -D”, but that reminds me to give a special shout-out to electron-builder too.

I’m generally using font-awesome icons for all projects. While many developers use the free version, I’ve paid for a license for the Pro version, partly for the extra icons, partly to support them, but as of this year, mostly for the wonderful Subsetter tool that allows you to graphically choose only the set of icons you want for your project, save those choices as a reloadable yaml file, and export the set for use in your app.

Other than JavaScript itself and core tools like Node, the only component from my 2016 MECH stack post that has survived is Apache Cordova. It, and it’s twin sibling, Adobe PhoneGap, remain a dominant force in JavaScript-based multi-platform mobile development. There are some other notables such as Ionic and Quasar, but Cordova remains at the top of my list. For now!

There are plenty of other web application development tools and frameworks but you’ve already read plenty about these: Webpack, VisualStudio Code, yarn, etc. I use these as well, but it’s time to cover the server-side stack.

Current 2020 Tools: Server

I try not to mix-n-match languages, unless there’s no appropriate alternative or some other compelling reason. I do like Go and Rust, but with the simplicity and availability of Node-based JavaScript server code, I have the luxury of focusing on a single language for both sides. I addition to the small syntactic differences, there is also the practical side of occasionally being able to share code or stack tools.

Express.js is a reasonable and solid choice here, but I prefer the lighter and faster Fastify.io for the back-end. Most of my back-end servers do not have high scalability needs, but I want them to be low-latency snappy regardless. Fastify is a simple, easy and rich framework for providing a collection of endpoint routes, such as in a server providing a REST API.

Almost all of my back-end servers are a combination of REST API and a WebSocket connection providing push notifications. The API is quite simple, and there’s no polling, just a possible new async REST request when a particular category or item of data changes. This has worked amazingly well in practice in production use, and allows the server to free resources when the user closes a browser tab or an Electron app.

For data storage, I do really like FaunaDB for scalable, highly-performant document storage, and the free tier is incredibly generous for almost any project. However, their lack of support for storing larger binary files (e.g. user-supplied images or other blob assets), a possible future cost hanging over my head, and the overwhelming desire to simplify away from a separate database server (this one remote) has led me to a much simpler solution for most of my projects, with no translation and relay of requests to a separate data server, not even a local database:

I have come up with a scheme for some of my latest server back-end that uses Node’s native async file I/O to provide data on request with a simplified schema where there are only server-side concepts of users, projects and assets (which can be binary/blob). All of these can be accessed with as single disk op, without any indices or overhead other than the actual folder paths and files. The server will be as fast as Fastify can process a route, the server can verify the Authorization: header, and a single Node fs read can fetch it. I call my new generic API server “SOSSBox” (Simple Online Storage Server) and I’m clearly going to have to post a separate article on this server/data storage in the future and document how to make a reusable and configurable standalone server for general storage use, for others to use.

So I don’t even use Mongo or SQL or Fauna or any other database at the server end currently. That might have to change in the future, but my needs are quite simple at this time.

As I try settle down on JavaScript web app tools, libraries, frameworks and template engines, one thing I’m learning is that the frameworks that shield you from the complexities of knowing a lot about the functionality they provide often don’t really shield you from having to learn those things anyway. Yes, they do, when you’re looking at a simpler example app, or taking a course on a subject, but when you go to code up something of your own that is more meaningful, that uses a library or bit of middleware (for example, Passport.js), it isn’t really going to shield you from learning a lot about that third-party code. You still need to understand Passport.js, or promises (or async/await), or sessions, or local storage, or Redis or Mongo or socket.io or EJS or Vue or Ember or Handlebars or whatever… The brutal truth is that JavaScript web developers need to know many of these in depth, and have a general understanding of the rest, as well as many, many other frameworks, middleware, and libraries. And I haven’t even really even included the actual toolchains in that.

Now what I think these “easy” and opinionated tools and frameworks actually do very well is provide good recommendations for what to use, from the people who have already been down this path. They, and their users, have often developed an ecosystem that is part of the framework, or built around the framework, that represents all the things you’re likely to need, and the most popular add-ons. There is strength in numbers here, so you can be pretty safe choosing to learn about these.

For example — and this is just an example, I adore the feathers team, and feathers-authentication — but in trying to add feathers-authentication to my REST API server the first time, I had to dig into Passport and other technical details, because the documentation does not attempt to go very far beyond its own scope, which is a nice, unifying convenience/independence layer, around the underlying authentication mechanisms, appropriate for that framework. In other words, it documents that ecosystem element, often very well, but not necessarily the underlying dependent libraries.

Maybe I’ve outgrown the opinionated frameworks now and just want to know what their opinions are, rather than actually use the framework and learn another wrapper around those suggested dependencies. Or maybe it’s that since I don’t know these dependencies as well as I should, I can’t appreciate the packaged ecosystems as well as a more informed web developer might. (I’ve got almost 35 years under my belt as a full-time professional developer, much of it developing Internet server software, but in that big picture of decades of development I am still relatively new to JavaScript-based web development.)

The Changing Landscape — Async/Await

I’ve been starting a lot of smaller new projects, and at each new starting point, I tend to first take a good look around and try to determine what has changed in just a few months here or there. In the world of JavaScript web development, I have never encountered such a fast-changing wealth of options.

This time around however, I feel it’s finally time to update to Node.js 7 and start using async/await to make my code much more linear, readable and maintainable. This async/await functionality is coming to the ES7 version of JavaScript, is already in the Edge browser, and has been a feature of Node.js since version 7.6.0 (and the current version at the time of this writing is 7.10.0).

Promises are so 2016, amiright? Hmm. (For more, see this article.)

I recently answered a question on reddit that was in theory about Koa.js, but I think in reality it was more about comparing some ES7 async/await code with what would be needed without it (i.e. with promises). I highlighted the linear, non-nested, callback/then-free readable nature of the async/await version:

Try coding this example with promises:

var result1 = await func1();
var result2 = await func2(result1);

it’s about as simple as you can get. Now add a parallel processing of several async requests:

const items = await fetchItems();
for (let item of items) {
const result = await processItem(item);
console.log(result);
}

Again, it’s linear code. No callback hell. Easy to see the logic here, and much, much shorter code. For error handling, you wrap it in a try/catch and that’s it, you can deploy this readable, maintainable code.

In this case, they allow a nice async-friendly, non-blocking Node.js application to efficiently schedule potentially lengthy processes, and in the second part of that, schedule them to run in parallel. In very easy-to-understand and maintain (i.e. and thus more likely to be bug-free) code.

And best of all, there are no calls to promise-related functions, the concept isn’t really even visible (even if that’s how await is implemented).

But it goes well beyond that, because there may be more than just potentially slow (and known) processing to perform. There’s nesting, and recursion, and who knows what else, much of which would be a real mess to implement with promises. I think what really grabbed my attention was the small bit of code on the Koa.js home page in the “Cascading” section that accomplished so much in so little:

const Koa = require('koa');
const app = new Koa();

// x-response-time

app.use(async function (ctx, next) {      // 0
  const start = new Date();               // 1
  await next();
  const ms = new Date() - start;          // 5
  ctx.set('X-Response-Time', `${ms}ms`);
});

// logger

app.use(async function (ctx, next) {     // 0
  const start = new Date();              // 2
  await next();
  const ms = new Date() - start;         // 4
  console.log(`${ctx.method} ${ctx.url} - ${ms}`);
});

// response

app.use(ctx => {                         // 0
  ctx.body = 'Hello World';              // 3
});

app.listen(3000);                        // 0

In this case, the code marked (0) runs linearly on startup, then on a web request, the first provided async function grabs a timestamp (1) and waits for the second function, which grabs its own timestamp (2), then waits for the third one, which is the actual handler that returns ‘Hello World’ as the web page body (3). Then it returns to continue the second function where it left off (4), which logs the request… then returns to the first function which adds the elapsed time for all of that to the X-Response-Time: header (5).

It’s a linear series of functions, each with their own linear code, that run in a predictable, deterministic manner, calling (via await) nested functions of which the caller isn’t even aware. Whoa. In a different perspective, this is the simplest implementation of coroutines that I have seen.

Future-Ready Code

Much of this is achievable in ES6 code with generator functions and the yield keyword, but I don’t really like the generator syntax (the use of ‘*’ as something other than an operator) and I see it mostly as a stop-gap placeholder syntax for JavaScript until async/await completely finishes the approval process and is an official part of JavaScript in ES7.

So instead, at least for Node.js projects, I’m going to use async/await as much as possible, and avoid promises and generators. I’m just going to skip that stage and my code will work in Node 7 and be using the most modern and future-ready features right from the start.

Keep The Whole Toolbox Handy

Two of my new projects start with providing a REST API only. And yes, I’ve decided to use Koa.js for those, because it’s lean, unopinionated, modern, from the Express.js team, just newer. It’s what they would have designed if they were starting again and didn’t have backwards-compatibility with existing apps to worry about. I already have my own opinions now. Yes, I’m going to use Passport.js for authentication, mostly because I want both local auth, OAUTH1 for Twitter authentication, and OAUTH2 for just about everything else. It’s a lean, mean API-only, so I it seems pretty much ideal for Koa.js. I still love Feathers.js, but here’s the thing:

I think I’m finally starting to really understand that you shouldn’t go into any given project with any preconceived notions of what frameworks, libraries and tools you will be using. Wait until you get there, check out what else is now available, maybe code up a quick test or proof of concept, see that your work flow is something you can feel comfortable with personally, and that you can easily debug the code, etc.

There will be some times when you will need to work mostly on one end (back-end or front-end), sometimes it’s both. Sometimes webpack or a full-featured framework is going to be overkill; sometimes it may be critical. Sometimes the most important thing will be performance; other times it will be reliability or maintainability by others. And there will be times when there is an existing body of code that will make the trade-offs lean in a completely different direction than would otherwise be the case for a completely new project.

I’ve spent quite a long time trying to pick favorite frameworks and tools. I love Feathers.js and Vue.js but it’s not a commitment. In my latest project, I will be using Koa.js for the back end, because I think it is simple code and I want to keep the implementation simple and minimal, and because I love the async/await features available now. (These aren’t well documented yet in the ecosystem around it, so in the future I may need to blog this project as an example reference for others.)

And I’ll be using Ember.js (or perhaps Glimmer.js directly) for the front-end, even though I love Vue.js. I’m doing the back-end API first so in the spirit of my comments above, I haven’t completely decided on the front-end and won’t until I have a chance to review things again when the time comes.

On The “Best” Frameworks

I think what I’ve learned from this process to find and decide on my favorites is that there are actually a lot of very good frameworks and tools out there. Any one of them is probably a reasonable choice. We don’t need framework battles and disputes; there is no “best” framework any more than there is a best operating system. The best depends on the circumstances, and the many trade-offs involved, which are likely to be specific to the situation. There’s no reason to limit ourselves when starting a new project (unless that is one of the constraints of the organization doing the development work, and in that case it is a business decision, not a technical one).

That said, we all have our favorites and preferences and likes and dislikes. I’m going to try to stick with JavaScript as much as possible as my primary language. I don’t like the Angular syntax much, and (at least for now) I really don’t like mixing HTML with JavaScript as is common with JSX and React projects. I’m a lot happier with EJS however, and I prefer either Handlebars templates or EJS. I prefer to see interface code broken into reusable components, and I prefer Vue.js for that reason, as well as Ember.js and Glimmer.js. I think most back-ends would do nicely with either Koa.js (modern, lean and independent), or Feathers.js (on Express.js) for something rich and full-featured (full-stack). And I’m likely to keep choosing from those as I go forward with projects.

But I think it’s important to take a good look around at the changing landscape at the start of each project. Don’t be too tied to a given favorite. Remain flexible, as each project may have it’s own choices for most appropriate.

Update: Years later now, I’ve posted a 2020 update on my preferred stacks for both back-end and web application development: here.

Previously I wrote about how I had settled down with Ember.js and Hapi.js in my battle with JavaScript Framework Fatigue. (Or so I thought I had.) I also spent quite a bit of time developing a prototype of an application with those frameworks, in order to take a more in-depth look.

But somewhere along the way I became a bit frustrated. Perhaps quite a bit. Neither Hapi.js nor Ember.js really seemed to be the highly-opinionated (i.e. carefully-guided) ecosystems that I thought they were, and I realized eventually that I was spending more time struggling than coding. There were also some worry signs, one of which was that Eran Hammer had already left Wal-Mart Labs, and moved on to new projects. Both Hapi.js and Ember.js are still really great in many ways, and incremental improvements over others that came before, but … if starting from scratch in 2017, neither was really just solving what I wanted them to solve, and providing what I needed. I wasn’t sure exactly what that was… until I found Feathers.js and Vue.js.

Feathers.js

While skimming through my Twitter feed one day, yet another reference to Feathers.js came up, and I remembered that I had taken a mental note in the past to investigate that further. When I started reading about Feathers, I found that the website provided great documentation on it, both on the web or downloadable in PDF, HTML, ePub and .Mobi formats!

Note: The “Auk” version is the newer/current development version, and provides significant new improvements in the areas of authentication, making Feathers isomorphic, smaller, more modular, full support for ES6 promises, etc.

Feathers provides all the functional areas you need to provide a great back-end of web or mobile app. It all seemed so much simpler and logical, especially once you got past a couple of key concepts which weren’t difficult. For example, that everything is a “service”. Data storage is also a service, with data storage providers implementing the single common service interface. And Feathers is Express-based, compatible with the many Express middleware add-ons.

I took a closer look and found that, when used at both ends, it provides simpler methods for a front-end to communicate with a back-end, methods which transparently supported communications via REST APIs or Socket.io, or other transports. It is extensible, swappable, optional support for major pieces, but provides direct implementations for several good choices for major components. The instant REST APIs (that also implement the common service interface), easy built-in real-time communications via simple support for socket.io or Primus. The simplest implementations I’ve seen for routed web apps that used React, Angular, Vue, etc, with examples and documentation for how those fit together. It was much much simpler and consistent, and the lack of opinion on everything else you used with it meant that I’d be able to use Ember if I wanted, but maybe I should look at the path they had already taken.

Feathers is well-focused and intent on solving only the problems of providing the server implementation, and optional client-side support for real-time communication with that server, but provides all or at least most of the pieces you will need to do that.

There also wasn’t really an opinion on which client framework to use… in fact many of the developers used React for the front-end while others used Vue.js or Angular.js. They had good support for many frameworks, including examples for how to use them with Feathers.

And there was Vue.js popping up again. It was time to check that out too.

Vue.js

Ember.js hadn’t resolved my JavaScript Framework Fatigue after all. The deeper I went, the more it seemed there was so much to learn. Probably because it wasn’t just a client component rendering framework like Vue, but was attempting to be a highly-opinionated ecosystem. It was a lot simpler and more powerful than most, and a clear improvement over some earlier frameworks, but there were still some things I didn’t like about it, personally. And they were starting to add up.

There were many technical issues as I tried to actually build a deployable app. That is not unexpected, but the trouble I was having was that it was very difficult to figure out what went wrong when something did. It’s okay to be an opinionated framework, but the whole point of that is to help the developer avoid having to make a lot of decisions and learn a lot of indirectly-related services in depth. But Ember wasn’t doing that for me. I was having problems and needing to learn in depth about all the components in the ecosystem anyway. This started to get to the point where I was unable to continue making progress, and I took a bit of a break from it to just read more, about alternatives, which is when I found Feathers above, and then Vue.

This is picky, but I think one of the things I didn’t like was also very subjective. At times, it was a bit like learning the syntax of a new language:

  {{#each model as |scientist|}}
    <li>{{scientist}}</li>
  {{/each}}

While I do like this much better than earlier approaches to providing complex templates, compare it to Vue.js:

<li v-for="item in items">
  {{ item.message }}
</li>

This is at least a little ugly in terms of requiring a v-for, but that compares to Ember requiring a {{#each}} and {{/each}} which doesn’t seem any more intuitive. The Vue alternative also retains the HTML tag at the level it would be, <li> in this case, as well simpler and easier to read “item in items” syntax for the actual list iterator. I’m also partial to the handlebars-style syntax so the for loop body works for me. It just feels less technical to me to say v-for=”item in items” rather than {{#each model as |scientist|}}. And it doesn’t require anything special at the end of the loop, just close the </li> as you would expect. I know this is very subjective, and this wasn’t a roadblock, but the Vue alternatives work better for me, and I suspect it would work better for many other web developers too.

Plus Vue has almost all of the benefits of other choices (like React) without the negative. There’s a better, much faster, and even faster virtual DOM. (Vue is much faster than either React or Ember, and even outperforms Ember by a fair margin after the latest Glimmer engine update in Ember 2.x.)

There are also fabulous options for making components. The components implementation is the best I’ve seen; Vue components are the easiest to provide and use; simple syntax like:

<div id="example">

<my-component></my-component>

</div>

and:

// register
Vue.component('my-component', {
  template: '<div>A custom component!</div>'
})

So your whole page can actually read like it makes sense (imagine that!):

<div id="app">
  <chat-app v-if="user.authenticated">
    <user-list></user-list>
    <message-list>
      <compose-message></compose-message>
    </message-list>
  </chat-app>
</div>

And as if that wasn’t enough, then you discover Vue’s (optional, of course) single-file components, with their clear and readable syntax, in .vue files, with easy import syntax, and with <template> <script> and <style> sections:

Note also the “scoped” keyword in the <style> section, preventing those styles from being applied globally. They can be scoped to this component, with a single additional keyword!

There are also custom directives and hooks, Flux-like state management, conditional rendering, and just about anything else you’ve come to expect from the best.

Summary

If you haven’t checked out either Vue.js or Feathers.js, do yourself a favor and please do so. I haven’t been this excited and optimistic about development in quite some time.

It’s not just me saying this. In the Best of JavaScript http://bestof.js.org Rising Stars 2016 comparison (which uses actual GitHub stars to measure), Vue.js won first place in the most popular front-end framework category here, as well as most popular project overall, here. Feathers.js (a further refinement of Express.js) came third for most popular node.js framework here, behind Express itself, and Koa.

This article introduces the results of my year-long quest for the ideal server/client JavaScript stack. I’ve spent months exploring available options, finding some products, libraries and services that I really like, almost reaching the conclusion that each was the best choice for my projects, only to find a fairly big “gotcha” each time.

Edit/Update: It seems that some folks are reading more into this article than I intended. The key words above are “the best choice for my projects”. That said, the purpose of my writing this is to share that experience with web developers in case others find it useful or at least slightly informative. I’m not “proposing” anything. I’m not “introducing” anything. I’m documenting where my journey led, after I had already eliminated Angular, React, and some of the other popular web platforms and libraries. I have nothing against them; I will probably eventually use them all, but not for my projects in the near-future. Settling on a small number of core platforms and libraries has eased my JavaScript Framework Fatigue. It may add to yours, if you have not yet heard much about Hapi.js or Ember.js.

I’ve been experiencing JavaScript Framework Fatigue on an almost daily basis, and told myself repeatedly “just pick something”, only to see something the next day that might be revealing how tragic my earlier choice would have been. It’s a never-ending process, that fortunately, for me, seems to finally be settling down. A couple of key JavaScript technologies have been holding as the best choice, for some time now. Actually it’s been a few months and my mind (and my book budget) are finally getting a well-deserved break from new things.

Beyond being written in JavaScript, my requirements were fairly easy, mostly just that if it was a full-stack end-to-end implementation (like Meteor or Sails.js), that it be a rich environment that just worked with direct support or add-ons for a variety of services such as back-end storage and authentication that I’d eventually need. If it included its own view support, it would need to be easy-to-read and maintainable. Ideally it would be capable of providing individual independent components, and if it did not satisfy my end-to-end needs, it needed to be the opposite: solving a specific portion of those needs while not imposing use of certain other frameworks and libraries (or at least not too many). A JavaScript library with narrower focus would need to solve a specific responsibility well, without ruling out the use of different libraries or tools for other tasks for other pieces of the equation. And there needed to be a solution for all of this that enabled mobile development as well as website app.

What did I look at? Well I started with MEAN… Node.js to enable a server-side solution written in JavaScript; and of course learned Angular, Express, Sane, Koa, Meteor, Sail.js, services like Firebase, Parse, Syncano, Appgyver, Appery, Monaca, Serverless and others, Apache Cordova, Ionic, Vue.js and numerous other frameworks.

In this article, I’m not going to get into the “Bootstrap vs Material Design vs. others” discussion, other than to say that I find Google’s Material Design elements to be far less intuitive than alternatives: mostly attractive graphic design, but at the expense of intuitive functionality. I won’t be using it.

But let’s cut to my conclusions here:

MECH = MongoDB + Ember.js + Cordova + Hapi.js

Obviously any server-side JavaScript solution is probably also based on Node.js. The core frameworks I’ve decided on are are: Hapi.js on Node.js plus storage (currently Mongo because of wide support, easy of deployment and reasonable storage and pricing).

Then on the client side, Ember.js provides a full-featured app experience with the rapid and flexible user interfaces that I expect, with the addition of Cordova or Electron depending on the non-browser target platform. The Cordova part solves the cross-platform mobile app portion, and similarly I could add Electron for turning it into a desktop app.

So to me, the JavaScript technologies that really shine here are:

Node.js + Hapi.js + Ember.js

Unfortunately that doesn’t make for a very useful acronym.

Hapi.js + Ember.js = a lean, mean app machine

Let’s look at these more closely.

Hapi.js

Among the many server-side and full-stack frameworks, Hapi.js stood out. First, it was small and fast, but more than that, it is really really easy and intuitive to use. It feels like a smaller project even though it is a very rich and fairly complete server-side framework. But it has been a critical part of the deployment to many of the world’s largest sites, including its primary developer, Walmart Labs, and many others. It’s extremely simple to use, and just handles many of the mundane things that computers should handle, such as setting the MIME type on HTTP requests according to the type of data returned in the reply. It’s capable of handling all of Walmart’s mobile app requests on Black Friday; so I’m reasonably confident it won’t be the weak link in my app.

And it’s easy to use. The following JavaScript code is the full source for a Node.js REST application which listens on a GET handler for a ‘/’ route and echos the HTTP headers supplied on the call back to the caller as a JSON response. (Yeah, it’s almost entirely automatic.) Does coding up a whole server get any easier than this?

Ember.js

As someone who has been a professional software developer since January 1984, I clearly remember the initial excitement I had the first time I started understanding what I was reading about Angular.js. Oh how far the world of JavaScript development had come in such a few short years. One of my colleagues was also very keen on React.js, so I also needed to investigate the state of things there. What I found in both cases were fine projects, yet there were a few things that nagged me about Angular, and I wondered if it couldn’t just be done better. And a few things about React that really made me feel like it might be a step backwards.

One of the biggest lessons of my three decades as a professional software developer was the importance of maintainability, and readability. The code needed to be very readable, and easy and most importantly obvious. Put bluntly, obvious code has very little chance of being buggy. But if there is a problem, it’s typically a lot simpler to identify and fix.

An Angular project was simply not as readable and maintainable as Ember code. And React went well beyond that and failed my “obvious test” in significant ways. Ember “just works”.

Ember.js gives me a very readable user interface (view), detached from the data being represented (model), and the core logic that determines how that data will be used (controller). While Ember is famous for its extremely easy-to-use two-way binding, recent versions of Ember also provide the reactive programming model of one-way binding pushing down and events and actions bubbling back up. In fact, Ember components (rather than controllers) are now the recommended approach. It is a complete client package with a CLI with built-in generators for views, routes, components, etc.

I think the thing I like most about Ember is that it makes it easy to look at both logic code and presentation templates and understand almost immediately exactly what is going on, and what the structure of the app would look like when rendered.

Here’s an example from the Ember home page, which does something fairly complex. This code below displays the three most recent pull requests from the Ember.js project on GitHub. The controller in this case is automatic (implied), so all that is needed is first the model, then the actual HTMLBars template for the view:

That’s not a lot of code for an application that displays the most recent three pull requests from a live GitHub project. Here is the output at the time of this article:

I think that’s pretty impressive for such a small amount of code. Yes there’s some CSS too (not included). See the Ember.js site for this and other examples.

I’m not going to make this article longer by writing too much about MongoDB or Apache Cordova. There are far too many articles and books that are much more appropriate out there, and the topics have been covered extensively. What I will say however is that Mongo’s use is so wide that it is a de facto storage mechanism now and the default in many cases, and it makes for an obvious choice if sticking with the majority appeals.

I’m a bit concerned by the reports a couple of years ago regarding its ability to fetch stale data on reads; some movement on that but it does not yet look resolved. However, that seems to only be an issue in cases in a fairly complex case where there is a cluster of Mongo servers and a master fails, in a particular combination of events, something we’ll all say “It will never affect my use case” and then be proven wrong when the application is a big hit and scaling up into the world of high-availability. For most of us, we’ll never get there and if we do, we can afford to assign someone to that problem then.

Honorable Mentions

Honorable mention to gun.js for data storage. I really like the design and approach but it just seemed too new and evolving to be used for a serious production project (yet). It’s incomplete in terms of background replication, but the design looks good and I think it’s a matter of time before it starts making serious waves. It’s something I’m going to be keeping a close eye on though. I think that’s a project that some corporate interests should come along and fund as full-time work with a full-time QA/doc/support team. Perhaps someone like Joyent, Mozilla or the Apache Software Foundation.

Although almost the complete opposite, I also really like the Firebase product. But have serious concerns about them following the Parse path with a mega-corporation buying them (in this case Google rather than Facebook) and then having other corporate needs that force changes. This has already been realized in the example of Firebase doing away with Firebase accounts, instead forcing login via Google accounts. (Not for the actually end-users of Firebase, just for the developers with accounts on Firebase. Er, not on Firebase. Anymore.)

Hapi.js + Ember.js = a lean, mean app machine

I have taken a couple of online courses in the past, and found them mostly horrible or bland and did not really learn from them, until one day I tried CodeSchool and the “Shaping Up With Angular” course, which I found educational and informative. Then I tried the “Warming Up With Ember” course, which was a bit dated, but unquestionably the best learning experience I’ve ever had online. (That course has since been replaced with a newer updated course.) In both cases, either of these courses was well worth the $29 I paid for a monthly subscription.

I’m actually signed up with five online course providers, but since I don’t really have anything (as positive or negative) to say about some of the other online services I’ve used, I won’t name those here. That’s not the point of this article; this is not a review of this service or other online course providers, or a comparison article. It’s my recognition that the monthly subscription model that most of them use may be causing them to lose income from customers that actually love their service.

It’s a Matter of Time

I canceled my monthly subscription today, both because I’m too busy (this month at least), and because the cost is high enough that if I’m not actively using it, it’s time to suspend those monthly fees.

I’m doing too much to pay $29 US (which is more like $40 Canadian) for learning that I can’t take advantage of this month (and perhaps next).

That made me consider what problem was causing me to cancel a service that I really liked and would strongly recommend…

Time for Another Option (Literally)

While the free courses and flat-rate monthly subscription is a good model for new signups, as subscribers complete courses of interest, and those remaining courses become of less interest, I think ex-subscribers might appreciate some kind of per-course fee option, or at least on-demand fee, once they are familiar with the quality and service and courses. I suspect the flat rate is more appealing to new signups, and to the course providers, but it is difficult to justify the ongoing expense if it goes unused or little-used for many of the months. Of course, you don’t want to confuse customers with too many choices either, but offering free, per-use pay, and all-inclusive monthly rates isn’t overwhelming either.

So, for example, I’d love to see an option to pay for a specific course with no end date, or perhaps an option to pay for actual online course usage, such as $5–10/hour, or even better: some amount per-day (which is considerably lower than the per-month rate). I think for a service that costs $29 per month for an unlimited number of courses and usage, something like $10 per day might be good (and is something to encourage users to move beyond free that could also lead to an upgrade to monthly).

In my case, now that I know how good this particular course provider is, I would certainly pay $10 on the day that I find I have some time to continue my courses. Or $10–20 for a specific course with no end date. Or to draw in more people, $10 to start a course and another $10 when I start the second half of the course.

These kinds of options allow the user to take the course of interest while not being pressured into completing it that month, or paying per month just to have the opportunity *perhaps* continue it next chance they get some time.

This Sucks

You see… I have a problem. I like this service and yet I felt I needed to cancel. That bugs me. And it was certainly not due to dissatisfaction of any kind; the courses have been wonderful; perhaps the best learning experience I’ve ever had. Keep up the good work folks, but give me an option to give you more money!