Predictions 2016

The era of Java EE developers writing untested spaghetti code with jQuery is to an end and while the transition will be chaotic, motivated individuals will be able to shape the new era, not only with new concepts in development but also business culture as a whole. Never has frontend development been more demanding. Even traditional workplaces must acknowledge the cataclysmic change that clear-cut layers and roles are to be blown apart. The borders between enterprise and non-enterprise frontend development choices became a thin layer to be perforated.

It’s time to evaluate this years frontend decisions which are based on an interconnected idea of modern development that will fit like bricks. Last year we’ve seen many new trends emerging that finally stabilized in 2015. Many frameworks mentioned last year fell out of favor and can’t be recommended for green field projects anymore.

As always, for projects of smaller scale you can and should get much more experimental for a reflux into mainstream.

Backend Language

The self-imposed restriction to one language for everything became unjustifiable. There is no jack-of-all-trades language anymore, individuals and companies shouldn’t be biased and be prepared to continuously learn new tools required for the optimal solution. Small, self-contained and interoperable services allow for a multiplicity of possibilities. Why should it hurt to write a repository search engine for your project in Python if it solves the issues faster and better?

The means justify the ends should be your only constant. Sometimes this means using Go if you need a language with strong concurrency or node if isomorphism gives you advantages.

Spring Boot has clearly won in this regard. It provides a full-fledged, yet elegant JVM-powered backend solution which integrates very well with other tools. The Java monolith was broken down and so a number of languages, e.g. Groovy or Scala have to be leveraged for tools like Gradle or Akka.

Frontend Language

On the client there is no reason not to use ECMAScript 2015 with the excellent transpiler Babel handling the brunt of work. Non-isomorphic environments with multi-functional teams benefit greatly when switching between tasks by removing the typical JavaScript gotchas. Maintainability will overall benefit from the new syntactic changes.

Long-term projects with a large codebase and possibly changing developers will find a veritable alternative in TypeScript which catches many issues during development. Especially for those who work on Angular 1, it is time to consider a migration in order to be future-proof since Angular 2 will be idiomatically written in TypeScript.


It has become clear that Grunt isn’t going to cut it anymore when it comes to a reasonable build tooling since it is too slow and too tedious to maintain and adapt the configuration for all but the most trivial projects. Gulp is the clear winner and primary solution for traditional buildcycle tasks.

However the issue of the initial pain to set up the code persists and therefore webpack has become the go-to tool for managing a large part of a modern standard build, especially with the rise of transpilation and libraries like React which recommend it. Sometimes the entire buildcycle can be replaced by the module loader, sometimes it needs to be augmented with a simplified Gulp. The complexity is reduced by abstraction and therefore you can start developing without extensive setup time. Also you will see the immense benefit of having a loader with extensibility for your development and delivery process in general.


LESS was basically given a death sentence by Bootstrap moving to Sass. Last year’s article strongly tied the future of the precompiler to Bootstrap and therefore It will probably fade to irrelevancy. The learning curve for migration is not steep and hence there will be no pain.

However the traditional way to write CSS is on the retreat with the rise of modularization and libraries like React. Extensible base-frameworks like PostCSS which allow importing and writing of styles as code will become the new CSS if you use said tools.

BEM continues it’s triumph as naming scheme for styles in large-scale projects while not going overboard on the abstraction and complexity like other methodologies. However it hasn’t become mainstream yet and depends on the commitment of single developers.

Material Design saw its 1.0 release and is now ready to go for early adopters while promising not to vanish soon. It will bridge the gap between mobile and desktop applications when it comes to user interface components.

Dependency Management

Bower will probably be dead within the next year and that’s a good thing considering its ill design. The argument that bower is the only option for flat client dependencies doesn’t work anymore with a module loader like webpack or the more experimental jspm in combination with a new and improved npm which will flatten dependencies as much as possible. Leave the sinking ship as soon as possible.


Large frameworks like AngularJS which require many months to get accustomed to are rather frowned upon. Don’t take this as a general recommendation to stop using AngularJS for new projects. Under the premise that you use TypeScript in order to be ready for Angular 2 you will be fine.

However, in most cases libraries that do one thing well are the way to go. Virtual DOM libraries like React or Mithril had rightfully an immense impact. React provides a shared rendering technique for partial server-side rendering which is especially powerful in isomorphic environments and a way to write native mobile code. However it is best understood as concepts rather than a library and abstract concepts like efficient DOM diffing or web components are here to stay irregardless of their implementation.

lodash is the established utility library for JavaScript and finally beat Underscore to a pulp. There is no way to escape it and only to embrace its power.

Immutability paired with a functional approach bears so strong benefits for a language like JavaScript that the idea should be essential to every large-scale web application. Just like TypeScript: the larger your application, the greater the benefit. Immutable is an excellent library for immutable data types and as such minimizes DOM manipulations. Bonus points if you combine it with a uni-directional dataflow architecture like Flux.

What’s left

Last year we talked about editors, linting and testing separately but the minor changes don’t justify an individual section. Atom has become more popular with simple tasks while Sublime Text 3 continues to sit on the throne gained by its performance. IntelliJ IDEA is still a viable option if you also work on languages that requires a good debugger or refactoring but for most task it is too slow.

ESLint has become the standard for linting, especially with the excellent support for ECMAScript 2015 and its modular plugin system.

The differences between Mocha/Chai/Sinon and Jasmine comes down to the preference whether you like the idea of a plugin system which allows you to choose an assertion framework (Mocha) or you want an opinionated all-inclusive testing framework (Jasmine).

Other concepts like test-driven development or improving the communication between groups will continue to keep us busy to integrate in our workaday life.


No comments yet.