←back to thread

262 points gherkinnn | 1 comments | | HN request time: 0.209s | source
Show context
pier25 ◴[] No.42164501[source]
> I like to argue that some of the most productive days of the web were the PHP and JQuery spaghetti days

I've wondered if going back to that paradigm would be more productive or not than using React et al.

Plenty of big sites like Amazon or Steam still are made this way. Not exactly PHP + jQuery but rendering HTML on the server and sprinkling some JS on top of it.

Has anyone gone back to working like that?

replies(13): >>42164565 #>>42164636 #>>42164646 #>>42164666 #>>42164714 #>>42164722 #>>42164754 #>>42164840 #>>42164957 #>>42165180 #>>42166069 #>>42169495 #>>42169508 #
scrollaway ◴[] No.42164840[source]
It’s really not more productive.

Working with react has a higher barrier of entry (something which is becoming less true over time given that many templates etc exist for it), but if you want to be producing pages and functionality, a good react dev will run leagues around even an a exceptionally good jquery dev.

I’m solid at both and we are talking a dev cycle that is magnitudes faster once you are set up reasonably well. There’s a reason it’s popular. Typescript makes a lot of testing unnecessary and gives many guarantees on robustness. React makes it a breeze to create complex state full components. Nextjs makes it super easy to deploy all this to a web app and quickly create new pages.

replies(2): >>42164893 #>>42164963 #
pier25 ◴[] No.42164893[source]
> a good react dev will run leagues around even an a exceptionally good jquery dev

It probably depends on the use case, no?

If you only need links, forms, and data tables what advantage does React have over SSR + jQuery?

replies(2): >>42164987 #>>42166351 #
klysm ◴[] No.42166351[source]
Composabilty and abstraction. I can bang out a react form in our app in minutes just by defining the shape of the fields. All the loading states are handled automatically. Mutations and refreshing data works out of the box. Navigating between pages is instant. Data is cached even when navigating between pages. Some pages that require many user inputs utilize optimistic updates to afford very low latency feedback.

React makes all of that easy to compose. I tell it how to render my state, and I write code that updates state.

replies(2): >>42168427 #>>42170630 #
thunky ◴[] No.42168427[source]
> Composabilty and abstraction

Also possible without react with far less complexity.

replies(2): >>42168835 #>>42169115 #
lmm ◴[] No.42168835[source]
It really isn't, unless you go full server-side session (with something like Wicket), and the latency of that is usually unacceptable these days.
replies(1): >>42172139 #
thunky ◴[] No.42172139[source]
I think you and the sibling may have missed the requirements up thread:

If you only need links, forms, and data tables

replies(1): >>42178685 #
lmm ◴[] No.42178685[source]
In my experience even something you thought was a basic form will usually have some kind of UI state (e.g. one input that then enables/disables another input).
replies(1): >>42179626 #
thunky ◴[] No.42179626[source]
Can't that be done in one or two lines of jQuery?
replies(1): >>42179903 #
lmm ◴[] No.42179903[source]
Yes, of course. And then you add one or two more lines of jQuery. And then another few lines to deal with the client-side and server-side state getting out of sync. And then...

Is putting in a couple of lines of JS that has no knowledge of the backend-managed good enough for small one-off pages? Maybe. But it's definitely not composable and abstractable, which was the original claim.

replies(1): >>42183510 #
thunky ◴[] No.42183510[source]
I assume we're still talking about links, forms, and data tables. If the forms are so complex that we need React to manage them then it may be worth trying to simplify them a bit first.

Or if the forms have to sync with the backend then there are other React-less options, for example:

https://htmx.org/examples/value-select/

replies(1): >>42189602 #
lmm ◴[] No.42189602[source]
> If the forms are so complex that we need React to manage them then it may be worth trying to simplify them a bit first.

Some forms are simple enough that you don't need composition and abstraction, yes, no-one's denying that.

> Or if the forms have to sync with the backend then there are other React-less options, for example:

> https://htmx.org/examples/value-select/

Ok, now try composing that. What happens when you want to nest one of those inside another (i.e. have 3 levels of selection)?

replies(1): >>42193954 #
thunky ◴[] No.42193954[source]
The forms/inputs are composable on the backend where the state is managed and the html is produced.

Here's the most dynamic form I can think of: https://www.globalgolf.com/golf-clubs/1064148-titleist-tsr2-...

Any input change triggers any/all other inputs to change.

Looks like they send the entire page each action, no React, yet the user experience is much better than the typical competitor site where they've overengineered the whole front end.

Their faceted search is nice too: https://www.globalgolf.com/golf-clubs/used/titleist/fairway-...

Notice how when you add a filter it updates the URL. Breath of fresh air.

And this is way beyond what I had in mind when I read links, forms, and data tables.

replies(1): >>42199963 #
lmm ◴[] No.42199963[source]
I clicked a couple of inputs and it's now stuck on a loading animation of a glass getting filled with golf balls (been running for about two minutes now). So you've pretty much proven my point.
replies(1): >>42200535 #
thunky ◴[] No.42200535[source]
Oh no...

Welp guess I'll have to take my business elsewhere. Thanks for the heads up.

Now I'm off to find a golf site that uses React for guaranteed perfection.

replies(1): >>42209437 #
scrollaway ◴[] No.42209437[source]
As a third party to this conversation, I think it's completely hilarious that you try really hard to make a point that ends up proven wrong, and your answer, rather than actual introspection about your beliefs, is sarcasm and an overall rude response.

This stubbornly stupid mindset is why we have wars.

Edit: I checked the site myself and was able to reproduce the issue mentioned in GP. This is a terrible website.

replies(1): >>42236526 #
1. thunky ◴[] No.42236526[source]
> you try really hard to make a point that ends up proven wrong

I really don't think the argument for or against React has been settled.

GP focused their mic drop on my example rather than the larger conversation, which missed the point. You're doing the same thing now.

Feel free to add something to the conversation.