Hacker News Reader

Comment by lsalvatore | Hacker News Reader

I can't relate to this at all. I've been happily working on SPAs with React and Redux for nearly 6 years.

Hotwire makes no sense: switching to managing client-side state on the server and sending HTML over the wire introduces a ton of problems: you are going to have to write and debug JavaScript eventually. Now your server is running client-side code to update every local browser state? How is that scalable at all?

React has a ton of great libraries for UI that these articles always ignore: Something like react-select to manage a dynamic dropdown- you can't implement that on the server.

You need SPAs for complex dashboards, and React is a great library to store and update local state. I don't understand what the controversy is.

View on HN

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!

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.

I agree with you.

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

> 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.

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.

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.

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.

> 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.

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.

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.

> 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...

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.

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?

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.

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.

I've always thought some of it stems from the nomenclature and the cultures that flow from it. A lot of people (reasonably) don't think the best architecture for their application is a "single page". But many of those same people nonetheless have (often large) portions of their application that benefit from complex client side interactivity. But the whole thing can seem really all or nothing, either you have a "single page application" that does everything client side or you do everything through html from the server. Of course in practice everybody does some hybrid in between these two extremes. But the apparent split creates a cultural battle between the extremes, which is not helpful.

I come from a financial reporting background where pages needed to be dynamic and update through filters / sorting / etc- think Excel or Robinhood- these are applications, not pages. When you are building an application, users don't want to experience a page refresh. You either want a dynamic behavior without page refresh, or not. React Router gives you client-side routing- I don't know why you wouldn't want that even if you were building something like AirBnB where there is mostly static content- to argue against dynamic search and filtering without page refresh seems silly to me.

Yep exactly this. I even just used Coinbase Pro vs. Vanguard in another thread as a concrete example of application vs. website where the Vanguard approach would really suck for an actual trading application.

No need to go full SPA, dynamic dropdown can just be a component(with react-select) in your MPA. You create coupling between your front-end server and the browser but that's not bad at all for many type of webapps.

Reply on news.ycombinator.com