When building a modern web app, you have a lot of different options out there. SPA or single page applications have been a recent hot solution. Using modern JS frameworks like React or Vue, coupled with a robust state management framework, you can build some seriously powerful applications. In fact it seems to be the trend nowadays to just instantly reach for these frameworks without asking what the drawbacks are, and there definitely are. I should know, for the last 6 years I've built a financial management and analysis tool for farms that started as a simple Ruby on Rails app and has now morphed into a React + Redux SPA beast. So what have I learned?
SPA is not the answer if you want simple. React and Redux sells you on a vision of having all the data right there in your store, fetch it with a saga, update it here and it is updated over there, etc etc etc. Your entire UI stays in sync with the data you provide it. The issue is that for it to function correctly, specifically SPA apps, you need to put all the data into the store. Which means you can say goodbye to obscure settings pages that used to take you 5 minutes to make with simple Rails views. Now you have to make an API endpoint, add some sagas to fetch that on page load, and build the form in javascript. Depending on the results of submitting that form, you probably will need to reload some data in redux afterwards. It becomes a bit of a nightmare and usually feels like you are hacking something together every time you go to change something.
React Relay is the answer...kind of? I don't run Relay in production but have worked with it at my company and I do think it solves a lot of the issues of duplicating code and keeping data up to date. It just seems to do the exact same thing as what a Rails view would do. All graphQL does is allows the front end to more directly interact with the database and models. I've heard a lot of celebration for it but honestly interacting with the database directly can be done so much easier when serving HTML rather than JSON. So why even use it? Just render HTML directly from the server and use javascript to supplement as it was intended to.
It runs fine on my iPhone! The state of the internet worldwide is pretty lousy compared to what we have here in the US. Most mobile networks and phones simply can't download and run modern SPA apps. Performance is also the problem here. Loading and performing more tasks in Javascript might run smoothly on your state-of-the-art iPhone but will lock up on a cheaper Android phone that most of the world uses. This is something that is often overlooked. Developers quickly jump to importing another module for the small thing they need it to do, and the entire package jumps in size. How do you support additional customers? You can't. You can't increase your server costs to make it load faster on the customer's computer.
Long story short, take a second to think before jumping on the SPA/Javascript everything bandwagon. Most likely you only have one or two pages that really need it. There's no need to bring the extra complexity of an entirely JS frontend to all corners of your app.
SPA is not the answer if you want simple. React and Redux sells you on a vision of having all the data right there in your store, fetch it with a saga, update it here and it is updated over there, etc etc etc. Your entire UI stays in sync with the data you provide it. The issue is that for it to function correctly, specifically SPA apps, you need to put all the data into the store. Which means you can say goodbye to obscure settings pages that used to take you 5 minutes to make with simple Rails views. Now you have to make an API endpoint, add some sagas to fetch that on page load, and build the form in javascript. Depending on the results of submitting that form, you probably will need to reload some data in redux afterwards. It becomes a bit of a nightmare and usually feels like you are hacking something together every time you go to change something.
React Relay is the answer...kind of? I don't run Relay in production but have worked with it at my company and I do think it solves a lot of the issues of duplicating code and keeping data up to date. It just seems to do the exact same thing as what a Rails view would do. All graphQL does is allows the front end to more directly interact with the database and models. I've heard a lot of celebration for it but honestly interacting with the database directly can be done so much easier when serving HTML rather than JSON. So why even use it? Just render HTML directly from the server and use javascript to supplement as it was intended to.
It runs fine on my iPhone! The state of the internet worldwide is pretty lousy compared to what we have here in the US. Most mobile networks and phones simply can't download and run modern SPA apps. Performance is also the problem here. Loading and performing more tasks in Javascript might run smoothly on your state-of-the-art iPhone but will lock up on a cheaper Android phone that most of the world uses. This is something that is often overlooked. Developers quickly jump to importing another module for the small thing they need it to do, and the entire package jumps in size. How do you support additional customers? You can't. You can't increase your server costs to make it load faster on the customer's computer.
Long story short, take a second to think before jumping on the SPA/Javascript everything bandwagon. Most likely you only have one or two pages that really need it. There's no need to bring the extra complexity of an entirely JS frontend to all corners of your app.