> The alternative of doing things old school with server side templates is ok, but it massively slows down your iteration speed through reliance on tight coupling between backend and frontend.
Huh? Something like Rails lets you iterate on server-side stuff extremely quickly. There is a lot of functionality you can implement that doesn't need JS at all
At this point, I think we'll start to see an electron shell that you can install apps/extensions into. The main thing that will prevent this from gaining traction is ios.
+1 to this. I wanted to build a private blogging app/site with a big focus on speed and performance, it might not be popular anymore but I went with Rails. Server-side rendering lets the browser do what it's good at. The only thing that would make pages load faster would be to stick them behind a CDN (which doesn't play nice with the privacy aspect). If anyone is interested I put up a page talking about the project: https://simpleblogs.org
See but the parent comment is about "web applications" not "web pages". You are describing a web page - there is limited or no interactivity, what is there can be reasonably handled by forms. No one doubts that React isn't the tool for this area
Take a look at the hey email client. It's built by basecamp--the guys who created rails.
As for web app vs web page--it's a very blurry line, and it's rare that I end up building something where the entire site could be considered a web app. Usually only some small pieces of it demand enough interactivity to bother with the complexities of using a UI framework, and for that I wrap a small React or a Svelte app in a div and throw it on a page within the larger site.
And additionally, given that the topic is "building web applications", I can't really understand how you think you can build interactivity without JS. Are you proposing form-based updates or is your understanding of "application" different than GP and mine?
We recently added this "feature" to our react-on-rails codebase, and the only thing I can ask is... why?
Hot reloading on Unreal Engine is a hot mess with all sorts of little caveats to think about. Meanwhile I can hit F5 and as long as my browser is configured right I can guarantee there's no old cruft to deal with. Why in the world would I want to add that kind of uncertainty in my work codebase??
Whenever you’re doing design or interactivity focused tasks, and actually in many cases debugging logic, hot reloading is not only a huge step function improvement, but a categorically different thing.
The analogy I like to make is this: imagine a painter had to wait 3 seconds for every stroke they made to show up. Would they be as good? Would they try out as many variations? Discover new paths they could go because they had the time to “test that weird idea real quick a few times”?
Hot reloading works especially well on React (and not I assume on game engines) because React, with hooks, used algebraic effects, which means all side effects are properly understood by the system and are undoable. So it’s not as hacky at all as you’d imagine.
I never understood the hate for HMR as a concept. Perhaps your implementation wasn’t great, but as a general concept it’s literally a game changer.
The same people who cast shade on it seem to always embrace incremental compilation (like in Rust) for some reason, too.
I guess I can see it in that regard, and knowing the implementation of it is complete and robust helps a lot. And I can see how this is useful for interface design; most of the good IDE gui toolkits of the past preview live as well.
But I also think this lessens the requirement for a solid mind's eye and ability to visualize changes before you make them. Having come from desktop development (with "live" gui development kits like VB) into webdev I guess I got used to code-a-bunch-of-stuff-and-hit-reload pattern.
As long as it doesn't get in my way, I'm cool with it.
The official Rails guides are worth reading and even if you don't want to use Rails are worth checking out as an example if how to do a framework guide well.
As much as your creative sass added to the conversation, I asked a few concrete questions - specifically trying to understand composability, reusability of JS, and what the fellow means by "interactivity" given they claim you can do lots without JS.
They followed it up with a 1-word answer - pretty ridiculous if you ask me - and so I asked an expanding question so I could make my own conclusions of what the other user considers to be acceptable levels of composability and reusability.
While I could undoubtedly find that info myself, I am not the one advocating for Rails here, nor am I the one claiming using Ruby for browser interactivity is a strong idea, so it seems to me like the onus isn't really on me to go search this out
Huh? Something like Rails lets you iterate on server-side stuff extremely quickly. There is a lot of functionality you can implement that doesn't need JS at all