When I joined Optoro, a technology company that helps retailers manage their returns, five years ago, the world of front-end development was in a completely different place. Grunt was the go-to tool, and Gulp was becoming popular. "Bundling" was just concatenating all the JS into a single
script.js. AngularJS was the hottest front-end framework, and CoffeeScript was a socially acceptable language to use.
If you were to time travel from four or five years ago to today, there would be so many new concepts to learn. Changes to ECMAScript alone are huge since five years ago. These things make transitioning from a Gulp + AngularJS to a more modern setup more tricky. On top of that, every developer has their own opinions based on what they've used. Convincing a group of people that X library is better than what they are using takes a lot of effort. Because changing a library/framework isn't as simple as changing your
package.json and a few lines of code. These libraries/frameworks are investments. There is always a cost to adopting a new technology. So balancing costs and benefits of a certain technology is tricky when introducing a technology stack.
But, as you can see from the title of this blog post, we eventually ended up picking Vue over all the other awesome frameworks/libraries out there. Before going into why we picked Vue, I wanted to talk about our steps leading into committing to Vue and adding support for it in our build system. Changing the build system would be required for anything that we would have picked since everything has moved towards modules, bundling and code splitting. We can't get away with the string concatenation of the scripts anymore.
Another convention of the newer frameworks/libraries is using component-based architectures. All of the user interface is built using components. These components are expressed like HTML elements and can be easily reused. Components authors can set specific APIs for their components and allow for more predictable user interfaces. Since we already had a number of applications written in AngularJS, we decided to start by adopting a component-based architecture inside of our current systems. This made developers start planning and architecting their user interfaces with components instead of giant monolithic controllers. As we switched to Vue/React/Angular, we can use that same concept. AngularJS added support for components in version 1.5. This was exciting and refreshing. It really made AngularJS more enjoyable and maintainable. I updated our docs and added support for AngularJS components during our Hack days so our developers can start building components.
While making progress on componentizing our apps, newer frameworks and libraries were becoming more and more popular. Every other day there would be blog posts about React, Vue, or Angular. Internally in our tech department, discussions on what we should use next started coming up. Teams were starting to plan new projects. People felt that it would be a good opportunity to look into alternatives to AngularJS.
As our tech department grew, the difficulty of maintaining our front-end application also grew. With global concatenated scripts, it was becoming really difficult to keep track of things. Since AngularJS automatically injects services into a controller with Dependency Injection, it was often harder to track these services across different modules---the assumption developers made with concatenated scripts was that the injected service was somewhere in the
script.js. It also made it more difficult to debug. Our bundles were pretty big. We were shipping a lot of unused code. It was pretty easy to make AngularJS perform poorly. We eventually added ESLint and John Papa's Angular style guide to improve our code, but that was limited to the JS code. It didn't check the templates, and it was hard to enforce it on existing code bases. The linter eventually was pretty noisy and fixes would take additional time. Overall, we were ready to try something else.
For the successor for AngularJS in our stack, our goal was to pick something developers could adopt quickly and wouldn’t have to go through a huge mental shift. Something familiar would definitely win the hearts of more developers. React was ruled out due to JSX and a complete different way of doing things compared to AngularJS. Angular (2+) was opposed due to being completely different than AngularJS and TypeScript. In the end, Vue seemed like a good alternative to AngularJS. It has similar template syntax and a lot of shared concepts (Directives, Filters, and Components). It’s also easier to learn than React or Angular (2+) coming from AngularJS.
The learning curve wasn't the only part of Vue that attracted us. A lot of our developers found the documentation to be extremely helpful. Everything is organized nicely and the code examples are easy to understand. After reading through the docs extensively, picking up and building something with Vue is relatively easy. Different code samples and examples really cover a lot of ground. I personally benefited a lot from the documentation.
People joke around and say, "There is a new JS framework every five minutes." It's a bit exaggerated and partly correct. If you are not actively following JS Twitter, the rapid pace of development of new tools and technologies can be overwhelming. It's hard to tell if a new library will stick. So far the sticking factor has been the community behind a framework. AngularJS and Ember had set a good example.
Fortunately with Vue we didn't have to worry about that part. The vibrant community around Vue gave us a ton of confidence. It's not Yet Another Framework™. It's being used by a lot of people and it is growing pretty fast. As of December 31st, 2018, Vue has been downloaded 23 million times on npm, vs 1.7 million in 2017, Vue Devtools had about 700k users, vs 84k in 2017, and the Vue Github repository has 130k stars, vs 37k in 2017. Evan You, creator of Vue, mentions a lot of these stats during his State of Vue talks.
By this point we realized that Vue was the perfect candidate for us. After winning the hearts of the people in our Tech Department with Vue, there was still a lot of work before we could deploy Vue code to production.
Months after polishing and fixing bugs in the integration with Vue, we shipped our first Vue app to production on March 2018. Right after that, other teams started building their new apps with Vue and the feedback has been awesome. With the help of Vue's documentation, our developers were able to pick up Vue in a pretty short amount of time. Some of our developers took online courses and some just learned it on the fly. Thanks to code splitting from webpack, our bundles are much smaller and we are lazy loading all of our non-critical code. These performance improvements are going to make the user experience of our applications better by loading faster.
So that's it, right? Have we fixed all of our front end problems by adding Vue and webpack? Of course not. Once we have more teams on Vue, I next want to focus on transitioning the initial webpack setup from Vue CLI v2 to Vue CLI v3. This will allow us to drop all the repetitive webpack configs and have simpler apps.
There is always something to improve and upgrade. This is our first blog post, and we have a lot of awesome posts coming up. I hope you follow us to keep up with what we’re up to! Thank you for reading!