Ability to focus on the backend
- The Ruby language + code design
- Our web framework + the HTTP protocol
- Databases and ORMs (PostgreSQL, Elasticsearch, Redis)
- Background jobs
These are all huge fields, and very delicate. I really want to be good in all these fields, and research and experiment which are the best tools for each field (for example, I recently found out that Sequel is a lot better than ActiveRecord). So, how in the earth will I find time for frontend as well? Can’t someone else do frontend instead of me, let’s say a frontend person?
If you’re a full-stack developer, you think that you can handle both very well, but in most cases that’s just not true, because there are too many things to know in the backend world alone.
Ability to hire actual frontend developers
Ok, fair, buy why not still keep the frontend in Rails? Frontend developers generally aren’t familiar with Ruby and its ecosystem (why would they be, that knowledge is useless to them once they switch to a project with a PHP backend), so they will naturally avoid Rails jobs. That’s really unfortunate, I don’t want just a frontend that “works”, I want it to be awesome and well designed. Frontend developers shouldn’t have to care in which language/framework the backend is written in.
Frontend developers don’t use regular ruby Sass anymore, because it compiles too slowly for them as the project grows. Did you know that Libsass is an awesome C/C++ implementation of Sass, which compiles 10x faster than ruby Sass? Did you know that even Libsass isn’t the best way to write CSS? PostCSS lets you write regular CSS, and what it does is just corrects your CSS during compilation to be cross-browser. Now, wait for it… PostCSS is 3x faster than Libsass. So, PostCSS is both the best way to write CSS and the fastest option.
Does Sprockets have support for Libsass or PostCSS? Of course not, we like our ruby Sass, even though frontend developers aren’t using it anymore. I hope you have worked in a codebase with a bit more frontend code to know how compilation time can grow fast, and how keeping it fast is essential for productivity (analogous to how speed of our tests is essential to our productivity).
sprockets-* extensions for every new thing, it’s much better to just use
the awesome Node.js tools directly.
Most Rails developers use Turbolinks to make their websites snappy, and Turbolinks 3 will allow us to achieve an even better performance and UX. It can now keep certain parts of the webpage still, and refresh the rest. However, Turbolinks of course still renders the whole webpage in the background, and only then replaces the parts that are needed. That means that you don’t get any performance benefit, because the backend still has to do the same amount of work.
An alternative is to just use AJAX directly, with or without UJS. However, that obviously doesn’t scale, that’s the whole reason why JS frameworks were invented in the first place, to tame spaghetti AJAX calls into something structured. So, for any non-trivial projects the only right choice is to use something like React.js.
Sure, on server side you should still do HTTP caching of your JSON resources,
but that’s now much simpler and more maintainable, because you can now cache
one type of resource in only one place. Your frontend may want to request
list of posts in different contexts, but if it always requests
only need to cache that action.
When our backend only provides JSON API, we are agnostic to the type of client that is consuming it. Of course, we could expose a JSON API alongside the regular HTML API, but that almost always introduces duplications, and it’s harder to manage.
JSON APIs provide extreme flexibility, because the company can now decide that they want to have an iOS app alongside the web frontend, and they can just use the same JSON API. Of course, building a flexible JSON APIs isn’t an easy task but the JSON-API specification aims to bring conventions which makes this much easier, and it has almost reached version 1.0 and it’s already very usable with a great library ecosystem.
When you have a flexible JSON API, you don’t need to care who consumes it; it can be a web frontend, iOS/Android app, or a washing machine. Those clients all need to speak only one common language: HTTP & JSON.
Easy to make frontend-only prototypes
With frontend-backend separation it’s easy to develop independently. Frontend developers don’t need to wait for the backend to implement the endpoint, they can just write their part and use fixtures (all JS frameworks make this very transparent to use), and then they can just swap from fixtures to a real endpoint once it’s done.
You can imagine that this makes prototyping very easy to do. Prototypes are crucial for rapid web development, because they enable very fast iteration.
I’ve worked a lot on full-stack Rails applications. And it just doesn’t work properly in the long run, because frontend is always done by Ruby developers, and then code design and UI are suffering due to lack of knowledge. GitHub is managing this very well, but you can’t always count on exceptional developers.
Let’s keep backend and frontend separate, because they really are two separate fields. Let’s optimize for quality and developer happiness.