ActiveViam

Nordic Capital, a leading sector-specialist private equity investor, has made a majority investment in ActiveViam | READ MORE

Our journey from GWT to React – Part 1/3: An Outdated Technology Stack

Anastasia Polyakova |
June 29, 2016

GWT to ReactSeven years ago, Quartet FS made a decision to build a front-end for ActivePivot, its in-memory analytical platform. Prior to this, it was only possible to connect to, and interact with, ActivePivot using Excel and employing the MDX query language. We needed a lightweight client, a user interface with which we could connect to ActivePivot from any workstation without prior installation.

This requirement led to the creation of ActiveUI, developed in GWT (Google Web Toolkit).

Screenshot of ActiveUI version 3

Screenshot of ActiveUI version 3

Originally backed by Google, the GWT framework allows code to be written in Java and compiled into an optimized cross-browser compatible JavaScript. GWT was a great and relevant choice at the time, because it provided many advantages, such as compatibility with older versions of Internet Explorer, the facility to develop in a statically typed object-oriented language like Java and the possibility to debug your web application directly in your IDE (Integrated Development Environment).

After all, ActivePivot is developed in Java, therefore developers and consultants could easily develop for both the front end and the server application. Also, some of our clients, especially those in the banking sector, were still using old versions of Internet Explorer such as IE6, IE7, or IE8, because of internal policy constraints.

Moving away from GWT

Although an ideal choice initially, GWT became less appropriate as time went by. In 2012, Google announced that GWT would be transformed from a Google project into a fully open-source project. As the release pace decreased and release dates kept being postponed, the technology became less up-to-date with its environment.

JavaScript gains momentum

By contrast, JavaScript, together with its ecosystem, has gained momentum in many areas. First, HTML5 and CSS3 have brought a lot of new features to the browser. Secondly, JavaScript has evolved from a browser scripting language into a richer language, boosted by a technical committee that is willing to release a new version of the JavaScript language specification (EcmaScript) every year following an iterative online and transparent process (cf. TC39 process).

Outstanding native features were introduced to JavaScript, such as multithreading with Web Workers, binary data handling with Typed Arrays or ES6 object-oriented classes. Many language extensions and supersets were popularized like Facebook Flow or Microsoft TypeScript which provide static typing. And promising EcmaScript proposals such as the C#-like async/await feature or the SIMD API will soon become a standard. Hence, JavaScript is evolving quickly into a language that provides a ‘best-of’ set of existing language features. And thanks to transpilers such as Babel, there is no need to wait for browser support since its application can be written using a modern syntax and converted into cross browser JavaScript.

The rise of Node.js

In parallel, a new JavaScript runtime environment called Node.js became more and more popular which has made it possible to run JavaScript on the server side. The adoption by the industry was fast. Microsoft, Netflix, Paypal or Linkedin for example already use Node.js and JavaScript to run some of their server side application in production.

Now used also to build well-known desktop applications, JavaScript continues to grow and even starts to overshadow well established languages like Java or C. Electron for instance, a cross-platform desktop application framework, is used to build the popular messaging application Slack, the code editors Atom by GitHub or Visual Studio Code by Microsoft, offering an easy way for developers to build JavaScript extensions for those applications.

Node.js is also widely used to build and maintain JavaScript projects and a strong set of tools has emerged which for instance can be used to:

  1. Manage project dependencies with tools like npm
  2. Configure projects’ workflows with builders such as Gulp
  3. Package the final application with bundlers like webpack

The Node.js ecosystem keeps increasing and a plethora of exciting and innovative frameworks has been introduced in pure JavaScript, including libraries offering polyfills that can emulate missing native browser functionality. As of April 2016, npm recorded more than 1 billion weekly downloads through its registry.

NPM packages

Rolling weekly downloads of npm packages – Credit: http://blog.npmjs.org/post/143451680695/how-many-npm-users-are-there

At the beginning of June 2016, the number of packages stored in the npm registry reached approximatively 288.000 packages with about 330 new packages added daily. In comparison, the 11-year old and popular Maven Central repository for Java has around 146.000 packages with an average of 80 new packages added daily. Since 2014, npm has become the largest repository across all languages and it is increasing its dominance at an astonishing pace.

Module counts

Module counts Repository comparison – Credit: http://www.modulecounts.com/

On GitHub, the world largest source code host with 15 million users and 38 million repositories as of June 2016, JavaScript is also breaking many records with the highest number of active repositories since 2014 and the highest number of repositories across all languages at the end of 2015.

Google Chrome’s dominance

Node.js also fueled a fierce competition between Google V8, Mozilla SpiderMonkey and Microsoft Chakra to build the fastest JavaScript execution engine and thus improve browser performance.

Providing incremental updates and a major release every 6 weeks, Chrome has rejuvenated the browser scene and became widely adopted. Backed by the Google V8 engine, it surpassed Internet Explorer’s share during 2012.

W3C

W3C browser monthly usage share – Credit: https://www.w3counter.com/trends

Internet Explorer has become much less popular and by the end of 2015 the older versions of Internet Explorer (such as 6, 7 and 8) had become almost completely obsolete.

Usage share

Internet Explorer and Microsoft Edge Usage share – Credit: https://www.w3counter.com/trends

The limits of GWT

Considering all the trends described above, using GWT has become progressively less attractive and sensible. Mid-2016 Java 8 is still not supported in a stable release of GWT. Does it really matter though? After all, some of the latest features provided by the JavaScript specification cannot be written in Java anyway. Support for the old Internet Explorer has fallen drastically and most of the features described previously are not available out of the box through GWT. Even though it is possible to re-implement or integrate them in your project, it is defeating the purpose of using a cross-browser Java framework: Hard to catch up with such a fast-paced environment!

The technology itself, in the context of our project, has some drawbacks. With more than 170.000 lines of Java code (excluding blanks and comments), it takes the application about 15 minutes to fully run the necessary tests and compile all the browser permutations with 16GB of RAM and 4 hyperthreaded cores (Intel i7). Debugging in Dev Mode is slow, supported only by old browsers and it quickly triggers ‘out-of-memory’ errors. The newly introduced “super dev mode” has a lot of incompatibilities and bugs when used with Internet Explorer or Firefox. This was making it harder to “sell” the technology to developers.

Non-optimal Architecture

Finally, the architecture that was selected to build ActiveUI was not optimal. It required to have a server that ran specifically for the application. Any call would transit through this server. This meant that a request from the browser to ActivePivot or its response had to be serialized, sent through the network and deserialized twice, creating unnecessary overhead and latency and increasing the probability of a memory issue or network problem.

activeui gwt

A Complete Rewrite

For all the above reasons, we decided to completely rewrite the ActiveUI application, changing not only the architecture of our product but also the technology stack.

Look out for the next article in this series, where I will share the challenges involved in choosing a new framework when so many options are available and explain how we ended up choosing the right one!

Like this post? Please share it on your socials

About the author

Schedule a demo

ERROR!

Sorry! We were unable to process your
request. Please try again!

success!

Your request is submitted successfully!
We will keep you up-to-date.