Rationale

[jhilden]

I just started to write a bit of text explaining the rationale behind this approach:

---

Rails and its server-side rendered response paradigm is still a very good match for many use cases as it avoids a lot of the complexities and performance issues of "modern" API+SPA web app architectures:

• there is a definitive state of the app residing in your sever
• debugging and exception tracking are a lot easier to handle
• you are developing against a single known runtime
• you save a lot of duplicated complexity (network, authentication, data (de-)serialization, state management, routing, ...)
• you can achieve more with less developers

You can find good summary about somes downsides of SPA-architectures here: https://speakerdeck.com/moonglum/adequatejs-wie-viel-javascript-darf-es-denn-sein

On the other side Rails is not the best option for building great frontends:

• no good support for a real "component based design" approach (e.g. with tools like https://storybook.js.org/)
• Rails applications tend to accumulate huge "append only" stylesheets
• many good UI libraries are build in javascript
• Rails views are not very nice to test
• A dedicated UI library like React is a much better choise for this

So our approach tries to marry the advantes of both paradigms into a single solution:

server side rendered responsses + component based React UI

[timomeh]

Some more thoughts:

• it's easier to add non-trivial dynamic interactions to a view since it's already written in javascript
• dynamic interfaces are more predictable with React as declarative library, instead of using imperative methods on DOM nodes

[jhilden]

Cool 👍

What exactly do you mean by "dynamic interfaces"?

[timomeh]

Interactions with things like modals, form-wizards on a single page, animations, expandable menus, etc...

[jhilden]

👍 (I first thought you are talking about programming interfaces)