If “hello world” is the whole requirement behind an app, and you won't develop it further, you don't heed to use react. In fact, here's your whole app: “hello, world!”. Copy it, save it in .txt file, serve in static anywhere you want.
I wish more people would actually follow this advice. When they don't need anything "reactive" they would not use React. When they don't actually need an SPA, they would not use React. When they don't actually need dynamic behavior on a website, they would not use React or JS.
But unfortunately people use what they don't need all the time, rather following hype than reason.
Or, may be, they use the tool they're familiar with, because what they need is to be productive immediately instead of wasting their time to learn different tooling. Even if this different tooling is simpler that what your already know.
Right but the earlier you catch your mistake the more time you'll save in total.
Generally people use 10x on cost at every subsequent step. Andy Grove famously talked about how this made the FDIV pentium bug cost Intel untold millions instead of pennies.
He said when the mistakes and decisions seemed free early on, that's actually when they were the most expensive.
As more commitments were made towards the design, it became costlier to back out. Then they discovered it after production and shipping, and by then it became so costly and famous people still remember it 30 years later.
To be more direct, if someone doesn't know how to do it right they Shouldn't Be Doing It. If someone can't fly a plane, they shouldn't be flying planes. If someone can't operate a construction crane, they shouldn't be operating one.
Same thing here. If they're doing it wrong because that's all they know, they are unqualified. They should not be given the responsibilities.
So that method of doing what you're familiar with is the cost of incompetency. Planes and cars crash under incompetent hands and software doesn't fare much better.
I'm a little bit confused. At first, we were talking about people using React for Hello World or similarly small and simple project, but here you're talking about making architecture decisions for huge projects?...
In context of a simple project: yes, React is not the best tool for the job if you look at project requirements. But also consider the fact that the bundle size and optimization might not be that important from business perspective, and project scope is very limited from time perspective. That's why using React might be the best choice: you're optimising for developer productivity on the short run.
However, the situation you are describing now is different. Not only project's business priorities are different, but also the scope is much larger. Which means that spending time on choosing tools and learning a new tool would tale a much smaller % of project's timeline, and thus it makes sense to spend a lot of time on that to potentially save a lot of time and improve other characteristics later on.
In other words, you don't do pre-production on hello world, but you do on something huge.
Who is going to maintain the React app in 3 years? 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). The original developer will have moved on to the next gig. Are you going to rebuild, or pay even more for the next developer with more experience, to subject themselves to work with this?
This is the hidden cost associated with such decisions. If you decide to make it an SPA, you are automatically opting in for paying wages of frontend devs for the next years and not only that, you are probably opting in for them to need longer time to get browser staples back working. Things like a navigation, that could be a rather simple <ul><li> construct, maybe 1 or 2 days of work for rendering simple HTML templates on the server, with some nice CSS styling, can suddenly take weeks to implement and adjust. Can the most likely little need for SPA justify this extra cost?
Usually you are also not only having one frontend developer, but multiple ones to pay, since you don't want all the knowledge in one hand only.
Take a good developer salary and this can easily get into the millions over the years.
> 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.
