> Who is going to maintain the React app in 3 years?
Uhm, developers? Using projects documentation?
> Who is going to work with the various "repairments" made to get normal browser behavior back into a SPA? History, back button, forward button, bookmarkability, context menu (if modified).
I never had to manually “repair” any of that. Most often you just don't need them. Why would you use a back button in an image editor or an IDE?
> The original developer will have moved on to the next gig.
Developer, singular? Are we taking about small projects here again?
> Are you going to rebuild, or pay even more for the next developer with more experience, to subject themselves to work with this?
In my personal experience, React projects were one of the nicest codebases to work with. I came to projects 2-4 years old, found great documentation, good architectural decisions, and was able to compete a ticket on the first day.
Overall, I think it’s a difference in experience. I build complex web applications. IDEs. User interfaces with complex, customisable data widgets updated in real time. People I talk with about web development are building 3d visualization platforms with C++ compiled to WebAssembly. Games. Image editors.
What your are talking about seem to be simple CRUD apps. I have built those with server-rendered templates, yes (here's a takehome for some company from a couple of years back: https://github.com/golergka/url-shortener).
However, a lot of apps _seem_ to be simple CRUD apps in the beginning, until you anticipate future features and other requirements that will force you to adopt a frontend framework all too late. Do you need a form with search over content from the server? You need a system to query data and cache the results. Update data in real time with websocket connection, while also allowing your user to edit it? You need a system to consolidate state. Save user's data in local storage? Also local state, but also schemas and migrations for when your app updates. Table of 100s of thousands units of data, which user should be able to filter, sort and edit, with updates from the server too? Don't even get me started. There's a lot of other examples I'm too lazy to type. Overall — you either adopt a proper frontend framework or try and implement it in “simple JS” and then spend much more time fighting a lot of subtle bugs that simply would not happen if you used proper abstractions and tools.
You mean the documentation that was never written, because the developer thought: "Ah but this is just the usual usage of the framework I am using. I don't need to write anything about that."
> I never had to manually “repair” any of that. Most often you just don't need them. Why would you use a back button in an image editor or an IDE?
Well, on most SPAs you would need them, because people build SPAs all the time without caring, whether they are actually building an app or are actually building a website. So what you get are things that would be a normal website, but implemented using SPA frameworks and then have broken browser functionality. An IDE or an image editor would probably be OK examples for SPA, but the reality unfortunately is very different.
> What your are talking about seem to be simple CRUD apps. I have built those with server-rendered templates, yes (here's a takehome for some company from a couple of years back: https://github.com/golergka/url-shortener).
Exactly! I am talking about the cases, when people take out the sledgehammer, where a screwdriver would have been appropriate.
Uhm, developers? Using projects documentation?
> Who is going to work with the various "repairments" made to get normal browser behavior back into a SPA? History, back button, forward button, bookmarkability, context menu (if modified).
I never had to manually “repair” any of that. Most often you just don't need them. Why would you use a back button in an image editor or an IDE?
> The original developer will have moved on to the next gig.
Developer, singular? Are we taking about small projects here again?
> Are you going to rebuild, or pay even more for the next developer with more experience, to subject themselves to work with this?
In my personal experience, React projects were one of the nicest codebases to work with. I came to projects 2-4 years old, found great documentation, good architectural decisions, and was able to compete a ticket on the first day.
Overall, I think it’s a difference in experience. I build complex web applications. IDEs. User interfaces with complex, customisable data widgets updated in real time. People I talk with about web development are building 3d visualization platforms with C++ compiled to WebAssembly. Games. Image editors.
What your are talking about seem to be simple CRUD apps. I have built those with server-rendered templates, yes (here's a takehome for some company from a couple of years back: https://github.com/golergka/url-shortener).
However, a lot of apps _seem_ to be simple CRUD apps in the beginning, until you anticipate future features and other requirements that will force you to adopt a frontend framework all too late. Do you need a form with search over content from the server? You need a system to query data and cache the results. Update data in real time with websocket connection, while also allowing your user to edit it? You need a system to consolidate state. Save user's data in local storage? Also local state, but also schemas and migrations for when your app updates. Table of 100s of thousands units of data, which user should be able to filter, sort and edit, with updates from the server too? Don't even get me started. There's a lot of other examples I'm too lazy to type. Overall — you either adopt a proper frontend framework or try and implement it in “simple JS” and then spend much more time fighting a lot of subtle bugs that simply would not happen if you used proper abstractions and tools.