[yurishimo]

Meh, I think you can get 98% of the way there. Look at the explosion of these "server side SPA" frameworks popping up. Hotwire for Rails, Livewire for Laravel, LiveView for Phoenix, etc etc.

I think Elixir is a super interesting case given how insanely fast it is. If your request to fetch new data and patch the DOM takes 5ms, who cares if it's slower than React? It's plenty fast for a ton of use cases and lowers complexity.

And then, if you do need the super slick interactive element, you bust out React and code up a nice little inline thing that writes it's value to a hidden input field that you can send along with a the submission of a normal form.

Webdev swung heavy to building entirely frontend solutions and I think the past year or so has been the potential beginning of the pendulum swinging back as teams are now feeling the pains of maintaining these huge frontend applications, on top of already needing to maintain the complexity of their backend.

Time will tell!

[thebean11]

> If your request to fetch new data and patch the DOM takes 5ms

Even in the US people are still dealing with pretty bad internet in a lot of places. Even with the best internet, and assuming it takes 0ms to handle the request, 5ms sounds insanely optimistic. I'm in a big city and my ping (to my ISP's datacenters in the same city) is 10-20ms...

[ericb]

So, latency is certainly one locus of optimization.

Another locus of optimization might be development speed and cost. An SPA is really two apps, a front-end, and a back end.

It costs 2x to do an SPA, and all things being equal, features come out 1/2 as fast.

Which wins the app with latency, or the app that gets features twice as fast?

[thebean11]

It doesn't cost 2x. Yes you go from two apps to one, but that one app is more complex than either of the original two.

[ericb]

I agree, it doesn't cost 2x. An SPA probably costs more like 3-4x.

Coordinating two apps is much harder than one app.

A reference for this topic is the Mythical Man Month, which concludes that communication overhead is what is expensive. When you have two apps, the humans, and the software both need to communicate and coordinate.

When there's two apps, you have an OR condition where if either app is broken or in disagreement about the expected API, both are broken. You have two sets of build processes, sets of tests, sets of files to serve, caches to manage, state to manage, versions to manage, and they all need to coordinate.

Instead of one thing to test, with an SPA, there's really 3! The server side app in isolation, the client side app in isolation, and the combination of the two.

[yurishimo]

Sure. I'm being super optimistic there, but it's also worth noting that Phoenix uses a websocket so some of the latency in the handshake is negated for subsequent requests.

Still, 50ms would probably be fast enough for a lot use cases, and if it's not, it's easy to configure debouncing.

[lsalvatore]

There is no "pain" managing large React / Redux applications for experienced frontend software engineers. If you don't want to write JavaScript, you probably shouldn't be building interactive applications for the web.

The Browser manages HTML, CSS and JavaScript and provides Developer Tools to debug and manage these languages. When you build with a javascript framework, you package a user experience that is entirely run by the browser, only to dispatch and save to the server when necessary.

I doubt there is a future for "backend SPA" frameworks- no one will take seriously the idea of, instead of two REST calls to get and put data, every client must connect through a socket to manage user input. Surely that will dramatically increase server bandwidth, and ignite the same type of "bloat" arguments that SPA critics use.

[yurishimo]

> If you don't want to write JavaScript, you probably shouldn't be building interactive applications for the web.

Wow, thanks! I've been writing production apps in Vue and React for large companies for years now, but good to know I can stop. /s

I have nothing against JS; I have problems with complexity on teams of varying skill levels and tenure. If you're a JS shop, it's great. But if you're an agency of Rails developers building CRUD apps for B2B, you shouldn't feel forced to write a bunch of JS just to get some values updating on the frontend in realtime.

[lsalvatore]

You don't need to write a bunch of JS, that's why JavaScript frameworks like React exist to make this easy. JavaScript is the only client-side scripting language on the browser that you can use to manipulate the DOM. If you want to locally CRUD without making a round trip to the server- you have two options- manual DOM manipulation, or use a JavaScript framework. That idea that HTML streaming will replace JS frameworks and REST APIs, and is easier and less problematic than a JS framework, is preposterous to me.

[subsection1h]

Who said that JavaScript frameworks and REST APIs are going to be replaced?

I've noticed that many people who enjoy developing SPAs believe that SPAs are the only way that web apps should be developed, and when anyone suggests otherwise, they get very defensive. Pretty weird.

[ramchip]

> Surely that will dramatically increase server bandwidth

LiveView can actually decrease B/W and load, because the HTML diffs are more efficient than sending JSON, and the statefulness means you don't need to constantly refetch user information from DB/cache, etc. The details depend on your app and how carefully you optimize it, but it's far from being an unconditional "dramatic increase".

> If you don't want to write JavaScript, you probably shouldn't be building interactive applications for the web.

That's gatekeeping and just plain insulting.

[lsalvatore]

JavaScript is the only language browsers will run. It's not gatekeeping to suggest that you have to learn and use JavaScript frameworks if you want to build web applications- it's a fact.

[ramchip]

You can write full-blown SPAs in ClojureScript or Elm, or use the tools we're discussing here like LiveView.

I've had great success with an LV app with minimal JS. The rendering is all server-side in Elixir, plus a few lines of JS hooks for the bits that truly need to happen on the client for a good experience: TZ conversion, countdown timer, table sorting, Chart.js rendering. No framework needed.

The user doesn't notice if a transition takes 100ms because LiveView is fetching an HTML diff from the backend, or 100ms because React is doing an AJAX query to a JSON API, it's the same end result.

[chasd00]

This is the problem

>for experienced frontend software engineers

web development skill varies wildly. Much more so than in any other branch of software development.

btw, "backend SPA"? That web world has officially jumped the shark. "page" has no meaning outside of a web browser. backend single string application makes more sense than backend single page application.

[resignThis2021]

I agree with you.

My only, personal, issue with front-end is typescript - I don't enjoy it for some reason.