Over the past two weeks, I’ve been slowly winding down LayerVault and traveling. During my downtime, I’ve been catching up on the latest and greatest in the web application world. (Trying to build a product at VC-funded speeds over the last 4 years, I never really had the time to poke my head up.) Given this unusual amount of free time, I can actually play around with each of these new whiz-bangs.

Here are some of the technologies that have me excited in the first part of 2015.

(A little bit of background for context: I’m primarily interested in web technologies and application stacks. I’ve worked almost exclusively in Ruby and JavaScript for the last 10 years. I no longer ascribe to monolithic development that Rails provides, although I still prefer Rails-built API servers. Were I starting a project today, I would use Rails for the API layer, and Ember for the front-end.)

Rust and Go

While not true competitors, I will lump them together here.

Both languages are meant to be system-level languages that should be considered instead of C/C++ on projects. They both boast great memory safety, easy concurrency, performance, and are reaching a serious maturity. Both languages make it easy to target several different architectures and bundle things up into nice binaries. This makes deployment of applications much easier: just ship a single file, instead of orchestrating hundreds or thousands of them.

In a very peculiar way, both of these languages are squirming their way into the ears and minds of web application developers.

I’ve greatly enjoyed using Go to build a few CLI tools. It makes sense that Go was the language of choice for the CLI-driven git-lfs extension. Go feels more restrictive than Rust, but I appreciate its opinionated stance.

Unfortunately, I think the master-only approach to libraries will continue to make things tougher and tougher for Go as a language. Godep, the language’s leading dependency-management too, feels too separated from the core language. Godep’s discoverability is also an issue: I did not learn about Godep until I was a few projects deep.

I’m a little less-familiar with Rust, but it feels like it could have wider pickup than Go. Rust, although still at 1.0-beta at the time of this writing, could pick up where Go falters. It’s first-class Cargo tooling feels quite a bit like Bundler or ember-cli. (That’s no accident, they have all been contibuted to or built by Yehuda Katz.)

What Rust has in tooling, it lacks a bit in expressiveness when compared directly with Go. Nonetheless, Rust feels like it will birth projects with longer shelf-lives and more complicated architectures than Go.

Over time, I expect to see many developers from interpreted languages (Ruby, Python, JavaScript) kick the tires on Go and Rust. Go will be preferred for simple services and command-line tools, whereas Rust will be used to build out entire application layers.

For learning Go, check out a Go by Example and then try to build a simple CLI tool pretty quickly to codify your knowledge.

To get hyped about Rust, I recommend listening to the latest Changelog episode that covers the state of the language. The best resource I’ve found for learning the language is Rust by Example.

I find both of these languages interesting, because a great web framework in either of these languages could make them better choices than Rails for building web applications that serve APIs. As of this writing, the tooling, testing and dependency management of a typical Rails project still more than makes up for its comparatively worse performance.

JSON API

One of the more annoying parts about maintaining a web application is dealing with the constant inconsequential decisions needing to be made around the structure of the API. If not thought through carefully, you will end up building an API with inconsistent semantics. An API with inconsistent semantics is frustrating to develop clients for, because it makes keeping any client code DRY nearly impossible. It is death by 1,000 corner cases.

For this reason, JSON API is particularly remarkable. It aims to be your “anti-bikeshedding weapon.” It takes very opinionated approaches on how to structure resource-based APIs on the web. Which verbs do what? How do I represent relationships? How do I update resources? JSON API gives the answer to all of these questions and more.

What’s even more exciting is how this opens up some very simple server and client development. In a modern Rails app, making your app speak JSON API is as simple as dropping in the JSONAPI::Resources gem. I could hardly believe how much work this saves. The same is true for clients.

JSON API is currently 1.0-rc3, though. Things have changed quite a bit in the last year since I started using JSON API in my projects. It has mostly stabilized at this point, and then team is promising full backward-compatibility from 1.0 onward.

Once this hits 1.0, I would recommend adopting it for any resource-based web APIs your team builds going forward. It pays dividends nicely.

ES6, ES7, and beyond

ES6/ES2015 has been in the works for quite some time, and native support is just now landing in modern browsers. (Most client-side frameworks have been using transpilers to give developers all ES6 features earlier.) The new hotnesses are nice, but I’m mostly excited for two features in particular: classes and modules.

While these are nice things to have in general, I hope that this will have a ripple effect on the quality of JavaScript applications. The multitude of different module-loading schemes (RequireJS, AMD, jQuery Plugins) without a single standard is a microcosm of the JavaScript ecosystem: it’s an absolute mess. Code reuse is more difficult than it needs to be, and you find multiple libraries all doing the same thing. JavaScript gets the award for Most Difficult to Successfully Install a Dependency.

My hope is that with ES6 modules and classes, JavaScript starts getting more opinionated and uniform about how its projects are structured. By choosing and sticking with a standard, hopefully the JavaScript community can move on to making more important decisions.

Glimmer

Glimmer is a new rendering engine that should be landing in Ember 1.13. Ember has been my client-side framework of choice for almost a year at this point. I think some of the productivity gains are monumental. The tooling afforded by ember-cli is second-to-none in the client-side world.

The biggest gripe with Ember has been performance. It can be slow as molasses, especially when dealing with lists-of-lists. This was made extremely clear at the React Conf 2015. Ember’s performance today cannot hold a candle to AngularJS or React in the given example application. Rather than starting a religious war over the matter, the Ember team has put on their big boy pants and tackled the problem head-on.

This, I feel, will be a very big deal for Ember. It will be the last cornerstone for having the best client-side framework: Ember has strong idioms that ensure organization on large projects, it has powerful tooling through ember-cli, the team is committed to a Stability Without Stagnation approach, and now with Glimmer it will be finally as performant as other popular client-side frameworks. Ember already does a very good job of getting out of the way and letting the developer focus on application-specific decisions to be made.

You can track it’s progress at isemberfastyet.com.

Stability without Stagnation

All of the web application technologies that I am keeping a close eye on either explicitly or implicitly adopt the policy of Stability without Stagnation. It’s an evolution of Joel Spolsky’s Big Rewrite idea, a.k.a the thing that you should never do. Stability without Stagnation in the OSS context favors slow, regular forward steps over big changes.

This results in software that isn’t the first-mover on new paradigms or ideas, but more likely the last-mover. Because the entire community is brought along with each release, Ember could be at the leading-edge of being the last-mover on client-side frameworks. The Ember community is small, but united.

Customer-facing projects can benefit from this ideology as well, as I touched on in the blog post The Launch is Dead.

More and more, I feel great software is built by measured increments and not big brushstrokes. Companies and projects that set a processes that adhere to Stability without Stagnation will set themselves up for long-term success. More and more projects are coming around to this idea, and I feel it gives 2015 plenty of momentum to be a great year for software.

—

What are you most excited about? Let me know on Twitter.