Time for a change of Vue

“What? UI development? No-sir, you can have it”..

That discussion were common (still going around now), when someone got assigned for UI implementation.

It was a very loooong step to get ready for first pull request (new dev onboard).

A loooong way to start your hands for testing, just after a mere two words update in the code (e.g. changing color in css).

A very tiring sequence of dully works just to put a patch.

Yet, the result was far from satisfying: large code-base, scattered codes, huge amount of foot print in minified client code, and untested functionality (unit testing).

R&D had initiative to put ease developers mind on implementing UI. We tried to find a way for developer to deliver fast product with high quality standard.

Currently, our UI layers are:

As simple as browser request a page to our ui server, the server then render the content: fetches data from our backend systems, passes data into jsp templates provided, combines templates related to the page, then returns the page to user.

A little bit info on the production, we had problem with this architecture as server resources will be demandingly high. Resource requirement goes exponentially over time, in other words, it is not scalable enough. We are using tomcat workers to handle requests, each worker bound to only one request, unable to serve other requests while idling waiting for backend call to respond. In the end, we have to keep adding more and more hardware to satisfy higher concurrent user access (RAM size).

Back to UI developer experience, development problem lies in the speed of newly joining developer to get onboard and how fast we can do the patching.

Using this architecture, developers are forced to download whole server codes, run real tomcat in their workstation/laptop, then deploy the build file (war) and wait till deployment in local server done.. if there was no error ;)

It took 5 minutes at best, and possibly failure after more than 10 minutes (need to retry again) at worst. Doing that 3 times.. boom, half an hour of your life gone.

UI developers should have not care about what backend implementation is, furthermore, they couldn’t be care less about running the java codes and tomcat. When modifying a single file, it would be great if we are not required to redeploy to tomcat server again. But how?

New UI Framework exploration launched

Currently, we are using Angular 1, quite old in JS world standard.. we can say, it started to become obsolete. Many new features for web especially on HTML5 are not present in Angular 1. Maybe we should be moving to Angular 2 (or 4 now?), that’s what we had in mind that time.

You may refer to our UI development history in this page: Evolusi Front End Developer di Blibli.com

Our UI development stacks:

1. Angular 1
2. Grunt
3. JSP
4. JSP tags
5. jQuery
6. Bootstrap
7. Other jQuery plugins, e.g. autocomplete, sliders
8. All running in tomcat server

This stack is good enough for us to deliver production script to the end user, packaged together with tomcat war file, and deployed through automation system to production server.

However, as mentioned above, developing UI in this stack took so much effort. All back to running whole tomcat server and redeployment of all archive just to see a speck of change.

We started exploring alternatives of technologies for these layers:

1. UI framework (rendering)
2. Build framework
3. Development framework
4. Deployment

For UI Framework (or… library turned into framework), we have Angular 1, Angular 2, React, ember, riot.js, vue.js and many others. Our main factors for consideration are rendering speed, slope learning curve and community/doc support.

For build framework, we have few choices, such as Grunt, Gulp and webpack.

Meanwhile, development framework here means how we structure the projects, which boilerplate to choose, hot reload, and many other development related tasks.

Lastly, our new application should be easy for deployment, and should not be worse in terms of performance from the old one.

UI Framework

Long story short.. we chose Vue.js.

Many resources promoting Vue over other frameworks, you can see it here: [1], [2], [3].

It will be a waste of effort to go full defense explaining on why choosing Vue here, you can read up all the reasoning there anyway. However, to get to know with the alternatives frameworks/libraries, we first had internal discussion and split up works to implement a simple slider and input form using various Frameworks. Strong candidates were React, Angular 2 and Vue. Based on our hands-on, we finally chose Vue.

Vue’s speed is fast enough, a lot faster compared to Angular, but still provides sloper learning curve compared to React… some people say, Vue is the marriage between Angular and React.. oh, so sweet isn’t it.

Our preference also from the research team, that coding using templating is better than following React way of creating another layer of language on top of regular HTML code.

Flexibility was found to be important. We don’t want to be bound with certain non-essential complexity, such as the needs of Typescript to write code in Angular 2. It will take another part of our lifetime just to learn a language that will be transformed into vanilla JS, adding unnecessary development overhead.

Here is the performance table comparison among various JS frameworks/libraries: [4].

All green on Vue.. case closed :)

Build Framework

Our UI development build method was using Grunt script. JS and CSS files are grouped into pages name, then those files got bundled into minified js and css files using grunt.

This method encouraged a lot of duplication. Because a script file is created based on functionality related to that page, when another page wants to reuse it, we have to make sure it will not break in all other page using that script. Encapsulation is still hard in this case, because it’s not build based on modular components. Codes are scattered across unknown files because there is no fix standard of where to put which in the framework.

Because of the nature of Angular 1, only God knows what are inside each js files. The files are unnecessarily too long and having various coding standard across the functions. We want to introduce also efficient coding, separating between logic and data fetch layer, for example.

Here, we introduce JS Linting. We are forcing the same code writing standard. It can do syntax checking and variable validations.

Our build tool move to webpack and all it’s plugins: common-chunk, vue-loader, name hash.

Conclusions

Our new UI Stack is more robust and able to be split into vertical teams, delivering content with high speed and short development time.

References

[1] Why we moved from Angular 2 to Vue.js (and why we didn’t choose React), https://medium.com/reverdev/why-we-moved-from-angular-2-to-vue-js-and-why-we-didnt-choose-react-ef807d9f4163, accessed September 2017

[2] Why we chose Vue.js over React, http://pixeljets.com/blog/why-we-chose-vuejs-over-react/, accessed September 2017

[3] Why We Chose Vue.js, https://about.gitlab.com/2016/10/20/why-we-chose-vue/, accessed September 2017

[4] Performance comparison among JS libs and frameworks, http://www.stefankrause.net/js-frameworks-benchmark6/webdriver-ts-results/table.html, accessed September 2017