Three technologies to look out for in 2017

I love technology. I’m relentlessly optimistic that software can always be crafted better, and bring more joy. I think this can be achieved through better approaches, better tools, and through better attitudes.

While I don’t quite have a crystal ball, I’ve sat down with the rest of the Red Badger team, here’s a summary of our top three picks for better technology in 2017.

Elm: Better Frontends

Elm is an absolutely fantastic, functional, statically typed programming language that seeks to become the mainstream approach to creating your frontend web applications. It promises freedom from costly runtime-exceptions, blazingly fast performance, and an absolutely joyful developer experience.

JavaScript has seen absolutely staggering growth over the last decade and the web has become filled with incredibly rich experiences. However, the size and complexity of modern frontend web applications often showcase JavaScript’s weaknesses from its origin as only a small "glue" language for Netscape Navigator.

Elm is specifically designed to let you confidently build robust, modern web applications, which you can then compile to JavaScript, letting it run in your browsers as normal. This is not dissimilar to what like what Babel or Coffeescript propose, but Elm turns it up to eleven.

Run-time exceptions are a thing of the past with Elm, as its strong type checking catches possible exceptions at compile time. These kind of exceptions are often costly, hard to debug, and difficult to prevent. In addition, the compiler offers contextual and fantastically helpful hints, having been designed as an assistant, rather than an adversary. No more hunting for a frustratingly vague, "undefined is not a function".

Types also allow Elm to make optimizations that popular JavaScript frameworks would struggle to achieve. Current builds of Elm 0.17 easily beat both React and Angular2 in performance.

Elm’s creator, Evan Czaplicki, has fostered a remarkable, vibrant community around the language that’s only been gathering steam. Documentation is generally thorough and well written, forums helpful and external tooling, like package managers, safe and well designed.

So, what can’t it do? Elm is still young, and there are yet to be examples of extremely large or long-lived Elm projects, meaning there are unexplored issues in managing an Elm projects at scale. It also currently still generates quite sizable javascript bundles -- so if it’s important that your application use as little network and footprint as possible, it may not be for you.

If you want to get started, no need to be worried about re-writing your entire application, you can begin by just using Elm in a small portion of your codebase and see if it makes your team, and your users happy.

I’m extremely enthusiastic about Elm and hope to explore it further in 2017.

Serverless: Better Infrastructure

Serverless lets you forget about deployment, and focus on crafting applications. There is an inevitable point in all web-based development where you have to think about how you plan to move software from an engineer’s laptop, to a server. Not just once, but hopefully often, reliably, and without concern that a sudden spike in traffic will overload your infrastructure.

For small organisations, the responsibility for this often falls on the same engineers writing the application code, often referred to as DevOps, taking up their valuable time. In larger organisations, these could be entirely different departments, requiring large amounts of planning, communication, and potential bureaucracy.

Serverless leverages AWS’ Lambda and other services to provide infinitely scalable, immediately provisionable environments that are so simple you can get one running in less than a minute.

A simple setup for an API may involve something like a Node.js server, an AWS API Gateway instance to route requests to it an S3 bucket for storage, and an entry point for your Node application. These are declaratively defined in simple YAML file, you slap serverless deploy into your terminal and you are good to go! Your application is live on the internet.

Made some application updates? Run serverless update and your changes are deployed.

The ease of deployment lets you focus on creating small, well-crafted applications across large teams as you don’t have the fear of complex deployment solutions. Even better, Serverless is infinitely scalable; AWS will simply provide more resources as the requirements increase, and you’ll only pay for exactly what you use. No more idle servers.

If you need functionality that Serverless doesn’t currently support, there’s a simple plugin system which you can use create whatever your needs may be. Serverless isn’t perfect for everything -- long running tasks can cost you a pretty penny, and specialist libraries, like a mathematical fortran package, can be hard to integrate for now. It also binds you into AWS as a cloud service provider, and if you’d prefer to have freedom from that, other options may be more suited. Red Badger recently launched a number of projects using Serverless, and are extremely happy with the results.

Elixir: Better Backends

Elixir is a functional backend language based on Erlang, running on the legendary BEAM VM.

For a number of years, our good friend Node.js has been Red Badger’s go-to choice in tackling many backend needs. Node is an amazing piece of technology, with its non-blocking IO innards handling some tasks amazingly -- but it’s not perfect for everything. Long, blocking tasks quickly gum its innards, and certain problems, like mathematical challenges, are difficult to implement on a JavaScript runtime.

Often it can be tempting to go back to old flames, like Django and Ruby on Rails -- but as experience tells us, these can quickly lead to large monoliths that require constant maintenance, careful effort to extend, and rewrites to be performant at larger scales.

Elixir provides a functional concurrent, fault tolerant approach to backend applications. It has a process system that uses threading on your behalf exceptionally well making scaling a doddle.

For an engineer already familiar with Ruby on Rails, the Phoenix framework offers a familiar experience, letting you step foot into the Elixir world while still having a similar arrangement of logic to work with.

However, unlike Rails, once your application reaches a certain age and complexity, the traditional difficulty of refactoring and extending your application is mitigated through Elixir and Phoenix’s strong focus on explicit state and functional approach. Even better, as it is incredibly performant, you can defer infrastructure enhancements like Redis or external message queues to far further into the future.

Like Elm, it also tries its best to help. For example, you can write code snippets demonstrating what a function should be doing in its comments, and Elixir will check these at compile time to ensure they’re still honest!

If you’re interested in Elixir, the documentation and tutorials are welcoming and if you’re curious about Phoenix, there is a fantastic book all about it.

Elixir will continue to grow, as it allows small sets of developers to confidently implement complex backends that shovel out value. Look for it shining like a star in 2017!

Marcel Cutts, software engineer, Red Badger.

Published under license from ITProPortal.com, a Future plc Publication. All rights reserved.

Photo Credit: alphaspirit/Shutterstock