What Are the Attributes of a Modern Web App?

Inherent Nature of Vue.js

The Goodness Test

In the world of web technology, the contemporary is temporary. The modern becomes old in a year time. What we find lacking in a modern web application are similar attributes that we find in the modest and old antique furniture or old wine. The older the better. A lack of modesty in a user interface is also an unfortunate part of a modern web application where every web app aims to be overly responsive in nature. Are the preceding attributes truly a set of good gauge to define a good modern web application? Is it consistently good? Does it feel good? Is there evidence from the structure that it is good?

What makes a modern web application good is its ability to solve today’s real-world problems in a manner that is intuitive as possible to its users. On top of intuition, web applications must behave as expected, so actions produce the expected results, and it must perform quickly. In reality, the users of an application determine the Goodness Test, but as developers we want to deliver that in a way that is simple, so the tools that allow us to do this determine the Goodness Test from a developer’s perspective. Bringing in a library such as Vue into the Ruby on Rails world opens up an opportunity to revisit the tools we use for asset management that is how to manage static content such as images, CSS, fonts, and JavaScript.

Tools

Ruby on Rails uses the asset pipeline and sprockets to manage assets; we will discuss this along with Webpack and the integration of Webpack into Ruby on Rails using the Webpacker gem.

Should You Remove Your Old Pipe?

Since Webpacker is created to co-exist with your sprockets asset pipeline. The answer is not yet; there is no need to remove the asset pipeline especially for legacy applications that you want to start integrating Vue into. There may be a point where Ruby on Rails abandons sprockets, so it might be required to migrate assets to Webpacker in future versions. For new applications, we recommend starting with Webpacker for asset management.

Our advice is not to move towards Webpacker for your entire assets immediately, but allow Webpacker to manage the assets of your component while leaving the rest of your assets to assets pipeline. Webpacker is a major shift in how to manage assets, since legacy Rails applications use a lot of gems that assume use of the asset pipeline and sprockets, whereas Webpacker uses yarn where packages are retrieved from npmjs.​org. So it is important to consider the nature of your application and how to proceed with asset management. We’ll discuss how to use Webpacker using tools we have develop to make Vue integration seamless.

Getting Started with Webpacker

Webpacker is a wrapper around webpack and yarn. It makes it easy to use the JavaScript pre-processor and bundler ability of webpack to manage application-like JavaScript in Rails.

It co-exists with the asset pipeline, as the primary purpose for webpack is app-like JavaScript, not images, CSS, or even JavaScript Sprinkles (that all continues to live in app/assets). However, it is possible to use Webpacker for CSS, images, and fonts assets as well, in which case you may not even need the asset pipeline. This is mostly relevant when exclusively using component-based JavaScript frameworks.

Webpacker is essential for the approach we will follow throughout this book. It allows scaffolding of new Vue component and allows embedding of the component onto Rails views. The latest Webpacker ships with webpack 4.x and latest babel. This means we will enjoy free performance upgrade of webpack including the split chunk api and other benefits. You are encouraged to use Webpacker 4 in Ruby on Rails moving forward.

The Yes/No Answering Robot – Version 1

So we’ve created a new Rails app that takes in a simple form that takes a question and randomly returns an answer of Yes or No. The answer is returned without re-rendering the page using the search endpoint with a js format. We add some JavaScript to add some client side validation for ensuring the question contains a question mark and inform the user that the robot is thinking about an answer while the answer is fetched from the backend. Next, we will evaluate this approach.

Evaluating the Rails-Only Approach

The patching of functionality via jQuery works. But can JavaScript be treated as a first-class asset than some working patchwork? As the app becomes bigger, the patchwork may lead to a “JavaScript soup” where JavaScript becomes more like a liability than a liberty of the web view.

Updating virtual DOM is cheaper than DOM. While jQuery is a DOM library, this approach did not leverage on the development of the virtual DOM. There is also a lack of data binding, reactivity, and other things including state management. These issues may become obvious as the answering robot becomes more complex.

Can a Vue-first approach solve some of the problems that Ruby on Rails and jQuery is limited to? Will Vue.js displace jQuery? What are some of the features that a Vue-first approach offer? We will evaluate a Vue-first approach in the next section.

The Yes/No Answering Robot – Version 2

Evaluating the Vue-First Approach

There are both favorable and unfavorable aspects to the Vue-first approach. Let’s consider both the pros and the cons.

This approach will generate a more dynamic answering robot since Vue.js is reactive; the web page does not require a web page refresh.

Moreover, there is an increase in supporting libraries from two ecosystems. This may be a double-edged sword as more tools do not mean getting more work done.

This approach increases the complexity by having to juggle two project structures that are bind by a loosely coupled JSON API. There is also a need to relearn routing in a Vue.js application if you are a Ruby on Rails developer.

All in all, the rabbit hole of diving into Vue.js with a single-page application making Ruby on Rails a backend only solution is too risky.

Is Vue-first with Rails API the best way to build a web application? Could there be an easier way to integrate Vue.js without going to juggling two projects structures for one web application product? Let’s find out in the next section.

The Yes/No Answering Robot – Version 3

If you are not satisfied with either the Vue-first or Rails-only approach, we share the same sentiment.

In this version of the Yes/No answer robot, we will use Rails’ Webpacker to deliver a Vue-first class and Rails-first approach to building a web application. The idea is to follow Ruby on Rails conventions and the traditional MVC pattern (2-1a) and take advantage of Vue for components of the application that requires interactive elements (2-1b).

Vue on Rails project shouldn’t be about conquering every web page with a single-page application. It should start with conquering each component and trying to reuse them on the relevant web page.

Webpacker is an efficient way to divide a web page into important components and let Vue do the heavy lifting for a more complex interface.

Webpacker also provides a clean and clear interface for Vue.js to interact with Ruby on Rails, and it ships with some basic configuration of Vue Webpacker configuration.

Creating Version 3

Evaluating the Vue as a First-Class Citizen of Rails Approach

Like other approaches, this one also has its pros and cons, though as we’ll see it is more favorable overall.

This is a completely different approach where we do not do a surgical procedure on Ruby on Rails or Vue to make them work together. Rather, through Webpacker, we deliver the best of Vue on top of the Ruby on Rails model view-controller architecture. This architecture allows us to follow traditional Rails conventions but allows us to take advantage of the simplicity of Vue and add in components when plain old JavaScript may be too bloated for what you are trying to accomplish.

The caveat is that we assume a small team of 2-4 developers for a small- to medium-sized web application. But this approach may not be desirable for a smaller team or a single programmer where resources are limited.

Reusability: A Powerful Proposition of the Vue Component

Most web pages do not need a complex UI. Not all pages will have a full-fledged calendar or text editor, to begin with. But when you need a complex interface, a component-based architecture will help. A component-based architecture diversifies the Rails views towards modern user interface with the support of Rails API.

Each component packs all the Vue.js goodness into a manageable object. And each component is a Vue instance. It allows reusable code by extending HTML code. Furthermore, Vue component allows you to enjoy access to a Vue’s lifecycle and reactive nature of Vue.js and, above all, have all these in a progressive and reusable manner.

All in all, Vue component offers a systematic way to organize complex user interface into a component object. Programmers can then use this approach to conquer complex page that requires modern UI by dividing them into multiple components and managing them separately without needing to build a single-page application.

Reactivity: Data-Binding and Virtual DOM of Vue

Since each Vue component packs the full features of Vue, it inherits the reactivity system, data binding, and virtual DOM management of Vue.

Reactivity system is one of the reasons why Vue component can turn a boring and static web page into life. It gives the responsiveness and fluidity of a modern web page. Vue brings in some flavor to sections of a Ruby on Rails application that follows conventional routing. It allows us to make an application more interactive and easy to use than your standard resources that you might see from scaffolding a resource in a Rails app.