This chapter explains some frequently used tools in Rails frontend.
Webpack and the Asset Pipeline are explained in the previous chapter. Please note that although I have tried to refrain from expressing my personal likes/dislikes, there may still be a little bit of it.
jQuery
Some people who can use jQuery may feel that "jQuery is enough". In some cases, this is true.
If all engineers can use jQuery, then there is no problem, but recently, there are fewer advantages to learning jQuery due to the browser improvements. It may not be desirable to have new team members learn jQuery if they don't know it. It's better to spend time on learning other things such as plain Javascript, Vue.js, React, Typescript than jQuery (though of course it's better to be able to use jQuery than not).
Also, it may not be appropriate to compare jQuery with frameworks (Vue.js/React) because jQuery is exactly a Javascript library. The advantages of jQuery are that code can be written in small code and there are many plugins for jQuery and a lot of information. In other words, there may be cases where both Vue.js and jQuery are used simultaneously.
Vanilla JS (Plain Javascript)
Vanilla JS is plain Javascript without using any plugins.
If "jQuery is enough", then "Vanilla JS is enough", also right? It's true for both in some cases. To sum up, Vanilla JS is enough for systems that do not require continuous maintenance by some maintainers ,or systems that do not have rich UIs and do not require much Javascript. However, even with Vanilla JS or jQuery, the following problems described in the previous chapter remain.
(In the system that includes large Javascripts, ) the code becomes complicated and difficult to maintain for other members. And also, (even if it can be written cleanly to some extent) the implementation method will vary depending on the members.
After all, if a system needs a lot of Javascript, it is better to use a frontend framework to solve this problem. Of course, in this case it is necessary to consider whether there are enough members and skills. In reality, however, it is often adopted because it is somehow popular or looks good, without much thought.
CoffeeScript
CoffeeScript is an easier way to write Javascript, and is often used with the Asset Pipeline and jQuery.
I personally liked it for its ease of writing, but it may not be enough to adopt (or even begin to learn) in the current Rails frontend situation. That doesn't mean you must not use it absolutely.
TypeScript
In short, it can be thought of as a "type definable js" that increases maintainability at the expense of learning and implementation costs. It can also be used in conjunction with a frontend framework.
If you don't need it now, don't rush to learn it. But given the current Rails frontend situation, I would recommend it over CoffeeScript. Since it has been around used for a reasonably long time, frontend engineers should at least learn enough to be able to talk about its advantages and disadvantages.
Bootstrap
Since it has been dependent on jQuery for a long time, it got caught up in the de-jQuery trend and became de-Bootstrap, but actually it may not be such a bad choice since bootstrap5 no longer depends on jQuery.
In particular, if it can be used well in admin systems where there are no front engineers, or in systems that do not require a lot of rich UI, the time spent on the frontend can be minimized.
Appearance design
Some people may think that Bootstrap design looks uncool or outdated, but it can be improved with a little customization, so if they can only implement an uncool design, it is a matter of usage. In addition, it can be used icons such as FontAwesome to be a better design.
Examples of features that can be easily implemented in Bootstrap
- Modal, Alert, and Toast
- Tabbed layouts
- Folding
- Responsive support
- Sorting and Reordering
CSS Framework (Bluma etc.)
Framework may sound like a big library, but it may be thought of as a tool that defines common CSS patterns in advance.
By using one of them, it provides some guidelines for CSS and reduces unnecessary definitions, thus keeping maintainability a bit higher. Also, once you get used to it, you can easily make your site responsive.
I mention Bluma because I have used it, but there are many competitors if you look for them.
Ajax Libraries
- XMLHttpRequest (Vanilla JS)
- Fetch API (Vanilla JS)
- jQuery (Library)
- Axios (Library)
- Superagent (Library)
- rails-ujs (Default installed in Rails)
These are some of the Ajax library options.
Although I have the impression that Axios is major and quite easy to use, if you don't want to rely on libraries, it would be good to be able to use the Fetch API in the long run. Other tools should only to be used when there is a reason to use them.
rails-ujs
rails-ujs is an Ajax library that has been included by default since Rails 5.1 and has no dependency on jQuery. Before that, it was jquery-ujs and had a dependency on jQuery.
If you can use Ajax with remote: true on Rails View, and if you understand it properly, it's definitely useful. But considering the current Rails frontend situation, I'm not sure if it should be used or not, and some projects don't use it.
Sass
It is a CSS extension that makes it easier to use, and I think its most useful feature is nesting.
There are many projects that use it, so even server-side engineers should have a rough idea of what it is.
npm
Manages frontend tools, equivalent to Bundler in Rails.
Even if you don't use Webpack(er), it can be used it to manipulate Javascript files such as combine, compress, obfuscate, and lint.
Yarn
The role is the same as npm, and since it is installed via npm, both are often installed in the development environment.
Here is some information about the advantages over npm.
- Build speed
- Version integrity
- Security
- (+ Unique features)
However, npm has been improved recently, and there seems to be no difference between the two.
I don't know the details of the differences between yarn and npm, and there may be few people who can speak well about the advantages and disadvantages in the latest versions. It might be interesting to hear if there is someone on your team who knows more about this.
SPA
SPA (Single Page Application) is a way of building a web application that provides seamless screen transitions.
It can be easily understood by looking at sites such as Twitter and Gmail, which update the rendering of only a part of the screen when a link or button is clicked. Since SPAing the entire a website can be very costly, I recommend SPAing only the main screens for which you want to improve the UI/UX as needed.
BFF
BFF (Backends For Frontends) is a frontend only system that does not update the DB in the server.
For example, if the backend will run in Rails API mode, a frontend system is needed, but BFF means the system that is responsible for the screen display that have the responsibility of Javascript. DB accesses are done by calling the backend server's API from the frontend Javascript using Ajax.
The following options seem to be used for building BFF systems.
- For front-side engineers to build is Node.js.
- For server-side engineers to build is Rails.
Rails as BFF
There is a way to use ActiveResource instead of ActiveRecord.
I have developed a system using ActiveResource and have the impression that it is simple and readable. The advantages and disadvantages are considered to be as follows.
Advantages
- Less code, simpler and easier to develop, because one service has fewer functions.
- Conflicts between the backend and frontend are less likely to occur, and it is easier to determine the cause of the problem when they do occur.
- Suitable when backend and frontend engineers have separated their responsibilities.
- Rails engineers can be in charge of building the BFF system, and frontend engineers can focus on js/css.
Disadvantages
- The difficulty of environment building is not low.
- Building backend as API mode.
- Building Rails system as BFF.
- Less information about it compared to monolithic.
- If using ActiveResource, it is not updated very often and there is a little uncertainty about the future.
SSR
SSR (Server Side Rendering) is considered when there are problems with rendering speed or SEO etc. when rendering screens using Javascript.
SSR often refers to Nuxt.js or Node.js, but Rails View is also SSR.
Nuxt.js
A Framework of Vue.js.
Some people may think of it as a tool for SSR, but it is often used to make Vue.js easier to use even without SSR.
Isn't Vue.js also a Framework?
Vue.js is a Framework of Javascript and Nuxt.js is a Framework of Vue.js.
It seems that Nuxt.js is used because Vue.js alone can be written too freely and libraries can be used easily.
Next.js
A Framework of React, like a React version of Nuxt.js.
I have not used it much yet, but it seems to be somewhat major and reputable, and it seems worth learning.
Should I study Vue.js or React (Nuxt.js or Next.js)?
I don't know the definitive answer, but Vue.js seems to be relatively major in Japan at now. If you learn one of them, using the others will not be hard. It would not be a problem to use the one you feel easier to use first.
They have the common ideas of Virtual DOM, State Management, Component Management (Import), Router, TypeScript, etc.
Testing Javascript
There are several tools available for testing js, but Jest seems to be the most major one these days.
I'm not as familiar with Jest as I am with RSpec, so I can't explain it in detail, but at least to me it's more difficult than rspec. In particular, there will often be a need to write tests that match the granularity of the components or mock the API interactions.
Also, the test environment should be built that is as fast as possible, since you will be running it many times during development.
Is jest only necessary for Webpacker?
If the assumption is "use Webpacker for many js, and use Asset Pipeline for few js", then it is enough to cover js in system spec for Asset Pipeline. Of course, even in this case, you can make tests if you want.
Code Checking for Javascript
ESLint is a static code checker for Javascript, like a js version of Rubocop. There are some competitors such as JSHint and JSLint, but ESLint seems to be the most major one now.
It is almost required if the frontend framework is used, and even if it is not, it is recommended to use it as well.
Component-oriented
This is a concept to maintain high maintainability by dividing HTML, managing them as parts, and using them in combination. This is mainly used when using a frontend framework.
If an entire page is managed in a single file, the code becomes too large and difficult to manage, so by dividing the code into parts, reusability and readability can be improved.
Atomic Design
This is a bit of an aside, but Atomic Design is a relatively major component-oriented management method. It has directories such as Atoms, Molecules, Organisms, Templates, and Pages, and the former are smaller than the latter.
The directories are often customized for each project, so there is no need to know them exactly, but it is good for frontend engineers to have at least a rough idea of what they look like.