Hacker News Reader

Comment by reilly3000 | Hacker News Reader

I really have no horse in this race, but I would like to know what the argument FOR React+Redux+GraphQL is for developing apps in 2019.

Is it that we need to offer offline clients to meet user expectations?

Better raw performance on the front end?

Cheaper server costs or easier to deploy serverlessly?

For the progressive enhancement of your resume?

View on HN

Agnostic of stack, SPAs provide a clear separation of concerns. The api layer is responsible for transforming data between the client and controlling access. The client is responsible for presenting the data structures provided by the api to the user, and turning user inputs into data structures that the api can consume.

Don’t forget interactivity and real-time feedback for user actions. SSR simply can’t provide that without lots of javascript thrown inside each template, and we all know what that leads to...

I urge/beg you to check out the Turbolinks 5 + StimulusJS libraries, which are by the same (Rails team) people, which is no coincidence.

https://youtu.be/SWEts0rlezA?t=203

There's a great podcast interview about the what/why of Stimulus: https://changelog.com/podcast/286

Also check out the newly released Phoenix LiveView!

I feel like this line of thinking is very analogous to the whole microservice craze -- you shouldn't need to introduce a network boundary to write well architected software. There's no reason you can't have a clear separation of concerns in a server side rendered application.

What does that actually mean, though?

And "there's no reason you can't, if you wanted" is a far cry from "sure, the work is already done."

For example, something as simple as having a server-side rendered forum built with your favorite back-end language and now you want to build a client for it (web, iOS, Android).

That basically means massive duplication as you create a json interface boundary.

Yeah, you were already passing a { user, topic, posts } object to the template, so you can just serialize it your json api, right? But you can't because when you wrote that code, you knew the data never left the process. You didn't need to scrub the user.password_digest. Adding an api on top of an existing system is a lot of work no matter how much you hand wave about "well architected software."

But forget over the air network boundary. How about just wanting to implement the view layer of your Rails app with Go one day? How exactly would a "well architected" Rails app help you out?

The truth is that one reason that SSRs are simpler is because they are monoliths which spares you from certain classes of concerns. That's the trade-off you have to pay for if you want to cleave the monolith one day.

It sounds like you're assuming the SSR is not well architected and then using that assumption to prove your point. It's pretty easy to have an API layer interal to your application -- have your view templates consume that API. No reason you have to have your view templates across the network, written in another language.

No, what I would say instead is that 90%+ of SSR apps aren't architected like that, so I would accuse you of the same thing: that you're using "well architected" to describe what's actually an exotic configuration that nobody refers to when they talk about SSR, basically creating microservices on localhost that hit your own network stack which is a premature abstraction for most cases that I thought you just got done lambasting in your OP.

Who said anything about microservices on the local network stack? You don't need to do that to separate the layers; just have them be separate logical layers in your application. This is common enough that I almost think we're talking about different things: people have written APIs and SSR apps for much, much longer than SPAs have been around.

This is true for all MVC frameworks as well. You shouldn't need a framework to introduce the boundary between views and models.

I agree 100%... The network boundry is in fact arbitrary. There are all sorts of similar hardware boundries in any computer system which we trust the OS, framework, language, etc to abstract away for us. For example how often do we think about where an Array is stored? It could anywhere from Highspeed cache to swapped out on disk. Likewise the client-server boundry for most of coding should be invisible.

To put it generously, this is theory that rarely makes it to the real world. In reality, all SPAs I've seen had chunks of business logic re-implemented on the client side, and had web services that only made sense within the context of specific user interactions.

Moreover, no one stops you from separating concerns on the server side.

It’s really good at highly dynamic/interactive apps, such as browser versions of asana or slack, or other things where user actions are small but frequent. If you aren’t doing full page reloads and have a lot of changes, it’s much simpler than managing each individual state change in vanilla javascript.

I personally think React’s component model is much nicer than any templating system I’ve used as it supports composition as a first-class feature.

And if done well, yes you get better performance on the frontend. (If done poorly, you don’t.)

> React’s component model is much nicer than any templating system

This is my feeling too. Composition and JSX beat logic in templates.

Though I've seen some pretty hairy React, I still prefer it to badly implemented template files.

Unfortunately, React's been around long enough now that there is legacy code that was NOT done well at all. I unfortunately inherited a project recently that was so convoluted and over-engineered, it took me like 30 minutes just to figure out how to change the logo in the top navbar. I could have done that with a Rails layout or header partial in about 30 seconds!

For my work it's all React + React-Native shared codebase for web and mobile.

I've also heard that graph dbs are better for social data than relational dbs, though I don't know the details. So I guess another use case is you are Facebook.

From my perspective as a developer who's had to use React, it seems more like following trends than solving a real problem.

In my case, I've had to deal with a form-heavy application, where React adds more boilerplate to form handling than just using the DOM.

I've really never bought the performance thing about a javascript-heavy SPA. I'd much rather see progressively-loaded html content than watch a loading indicator. I'd really rather have slightly longer page loads on average than deal with the long wait, and then hurry up and wait of the typical Single-Page App.

For a straightforward well constrained app, the complaint against rails is usually performance. But it breaks down as soon as the well constrained app has to be maintained or grown for any amount of time past typical JS dependency hell.

Rails/ruby perf is getting better with some new work in ruby with JIT and memory. It's got its work cut out to match up with Go, Elixir, or Node, but compared to the rest of the options, it also has a huge head start on some other basic things like community and support.

Mainly that it’s fun, and the client wants it.

I’m not sure if the 20 extra client/server roundtrips increase raw performance though.

Reply on news.ycombinator.com