Hacker News Reader

Comment by sc68cal | Hacker News Reader

I was worried that an application I was building in Django, with a frontend built with Bootstrap and some LIGHT jquery was making me look like an old curmudgeon but the part about testability of the frontend really resonated with me. It was MUCH easier to structure everything as pytest unit tests and completely rely on Django for all the business logic rather than trying to put state in the frontend and deal with synchronizing states between FIVE distinct systems (remote devices, the Django application, the database, an event stream, AND the front end).

I recognize that I'm not hip or with it, because I really fell out of front end development at the peak of jQuery where it was mostly about fixing browser incompatibilities, but it's nice to see that maybe it went too far in the other direction and we're overdue for a bit of a swing back towards server side.

View on HN

Just because you have an SPA doesn't mean you need any state in the frontend. Main problem with react devs is just overcomplicating and over-abstracting stuff. The best way to explain it to a backend person is like the same interpersonal problems with overengineered microservices architectures.

redux-query seems a popular library for dealing with API calls in react.

I’ve landed on a project using it.

By default it seems to maintain its own cache in the frontend of all api requests unless you use a non ergonomic feature “useLazy*” where you can give it hint if to use the local cache or not.

It’s completely terrible in a web app! Web is distributed and multi user by default.

End result with the app I’m working on if user a adds an item in one browser session, user b goes to a list view they don’t see the update, they see the redux-query cache.

It’s an over complicated mess for an already solved problem. Have the server send proper cache-control headers and let the browser deal with the caching instead of trying to build fat clients on a web app that should be thin clients.

You are right you don’t need to maintain state on the client but all these fashionable JavaScript frameworks promote doing just that.

redux-query is not popular by any means. [1]

Both react-query (that is tanstack query now) [2] and rtk-query [3] include extensive configurability regarding their caching behaviors. This includes the ability to turn off caching entirely. [4,5]

Your story sounds like a usage error, not a library issue.

[1] https://www.npmjs.com/package/redux-query

[2] https://tanstack.com/query/latest/

[3] https://redux-toolkit.js.org/rtk-query/overview

[4] https://tanstack.com/query/latest/docs/framework/react/guide...

[5] https://redux-toolkit.js.org/rtk-query/usage/cache-behavior

redux-query seems a popular library for dealing with API calls in react.

I’m having a real hard time being polite right now. Do we have an education problem because where is this person getting their information that they think redux-query is popular?

Probably he made a typo and meant react-query.

> redux-query is not popular by any means

Yeah I don't know where the parent comment got this from. Every few weeks I seem to see these low effort posts that basically boil down to "javascript bad", but gets a lot of upvotes. And when you read into it, you see the author often has a poor grasp of js, or its ecosystem, and has set up some unholy abstraction, assuming that's how everyone does it.

Use the right tool for the job lol.

That sounds like an application architecture problem, not problem with react or redux-query.

It is an application problem, agreed.

It’s an application problem caused as a result of choosing the library, a common recommended library, and how the library and its documentation promotes its usage. The tools used were as the tools recommend. Admittedly, joining the project the wrong tools for the job were selected but these are all the react standard supporting libs.

The application should have been architected not to use redux-query, instead use the browser fetchApi and server side cache control headers as we own the entire stack. Today that’s controversial as ”every body uses” and “this is what the docs recommends”

Well, these libraries are doing something inherently complicated on top of just using browser cache headers.

You're only talking about http endpoint caching. These solutions are providing application data caching. These are not mutually exclusive concepts.

The latter offers things like data sharing/normalization across endpoints, data persistence across browser sessions, fine-grained cache invalidation/manipulation, and a lot of things on top of that.

It's a lot harder to manage a cache, and for most apps I never found it worthwhile. But there may be cases where you do want that level of control, like PWAs or an app optimized to never hit the network unnecessarily.

But it's definitely not replaceable with browser http header caching.

Serverside rendering is apparently a new technology now. And this brand new thing called islands which someone reinvented recently.

It's back, but the nice thing is it's 10x more complicated now!

And in slow javashit!

So, an overall win for software developers and cloud providers?

Oh no. So Java JSF was right after all? :-)

No, the only project I've worked on that was a massive failure was built with Java JSF.

Salesforce's visualforce pages are JSF though

Yep, time to dust off PrimeFaces.

>Yep, time to dust off PrimeFaces.

You joke, but PrimeReact and PrimeVue are some of the best libs out there today, due largely to that heritage. Great company.

Sure, it has always been the best JSF framework.

PrimeFaces is very well-maintained and regularly updated.

I'd even go further and say that it's one of the few things that makes working with JSF bearable for me.

I'm still a thousand times more productive with React though, and PrimeReact also helps there.

What are islands? The new servlets?

Smallish parts of JS (React, Vue, ...) sprinkled into your website for interactivity. I use it with AstroJS: https://docs.astro.build/en/concepts/islands/

I straddle the fence here, I think we jump down people's throats a bit too quickly when it comes to putting names on their new library. But I do also wish we'd stop reinventing things and patting ourselves on the back in other cases.

Eg we are definitely working backwards from SPAs now. "JavaScript islands" were how we got to SPA frameworks in the first place.

I don't have all the history and references, but anyone working in web in the late 2000s and 2010s can attest to how progressively adding in javascript on server side rendered HTML was already happening, even componentizing the server side code with CSS and JS packaged up was very common.

"The term “component island” was first coined by Etsy’s frontend architect Katie Sylor-Miller in 2019. This idea was then expanded on and documented in this post by Preact creator Jason Miller on August 11, 2020."

My only gripe, is that this leads the ready on an alternate history of how we got here.

The general idea of an “Islands” architecture is deceptively simple: render HTML pages on the server, and inject placeholders or slots around highly dynamic regions […] that can then be “hydrated” on the client into small self-contained widgets, reusing their server-rendered initial HTML.

cryogenic lab tech: Welcome to the world of tomorrow!

portlets

Portlets! I see I'm not the only member here of this exclusive club.

I started out using React in "islands" almost 10 years ago. The server rendered page would have React components attached to the interactive parts of the page. Fascinating that we're coming full circle to that. Hopefully with better state management and interoperability.

Using a SPA doesn't mean ignoring software engineering principles.

At my work we develop web applications for a mission critical sector (emergency services). We use .net for the backend (we have also used golang in some projects) and Typescript and Angular for the frontend. We follow MVVP patterns, SOLID principles, etc. There are multiple layers, each layer has a well defined single responsibility. Our applications have been quite successful with happy users and great maintainability if I may say so.

There is nothing special about our setup. We could have used Vue.js or react for the frontend. We could have used any platform to build REST endpoints (though personally I like strongly typed languages for implementing business logic and think .net is underrated).

Software engineering might not be as old as say civil engineering, but we've been doing it for decades now and have a rich library of patterns and architecture types to draw from. I've been building software for over 25 years; the technology stack might have changed in that time but the principles are still very much the same or are extensions of the previous ones.

Using a SPA doesn't change the fact that if you want to build good applications, you first have to design them.

Reply on news.ycombinator.com