Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If not React, then what?

infrequently.org

Post reply on HN
Print view View original

721–730 of 756 posts

Re: If not React, then what?

#721

Post by cheema33 »

cyberax wrote: post #164
goobert wrote: post #149

Earlier quoted context omitted.

React is in use in many heavily used frontends at Amazon, maybe not the retail site But there's no inherent reason React couldn't be used for a page that basically shows pictures of products with a description next to them, the bottlenecks will have nothing to do with the frontend in a well engineered system for that type of site

My constant problem with React-based tools is that they don't support deep links properly. You want to right-click on a product description to open it in a different tab to check later, and you can't. Even freaking Google (who really should know better) suffers from that. Amazon's retail frontend uses plain HTML, so it works fine.

> My constant problem with React-based tools is that they don't support deep links properly.

I worry that most people complaining here about React, including the OP, do not actually understand the very basics of React. Here someone is complaining about how React somehow messes with deep links. Without understanding that React does nothing to links. Nothing.

Re: If not React, then what?

#722

Post by thrw42A8N »

yakshaving_jgt wrote: post #506
switz wrote: post #489

Earlier quoted context omitted.

it's been a term of art for a long time

That's technically true. Indeed, "isomorphism" has been a term of art for about 200 years. More recently though — over the past decade or so — JavaScript enthusiasts have been using this word to describe code sharing, which isn't quite right.

It's been used to describe code that does A on server and B on client side, where A and B are deeply related but definitely not the same. It's not just code sharing, that's just a small part of it.

Re: If not React, then what?

#723

Post by yakshaving_jgt »

thrw42A8N wrote: post #722
yakshaving_jgt wrote: post #506

Earlier quoted context omitted.

That's technically true. Indeed, "isomorphism" has been a term of art for about 200 years. More recently though — over the past decade or so — JavaScript enthusiasts have been using this word to describe code sharing, which isn't quite right.

It's been used to describe code that does A on server and B on client side, where A and B are deeply related but definitely not the same. It's not just code sharing, that's just a small part of it.

My argument is that it's a forced and silly misuse of the word.

I'm struggling to understand also how it came to be [ab]used in this context. To take an old Greek mathematics word and use it to mean something that it doesn't really mean? Why? Isn't that silly? Isn't it pretentious?

Re: If not React, then what?

#724

Post by cbeach »

I've spent years slowly migrating a personal project from PHP to Scala/React, and I'm devastated if React is out-of-date already. The web tech treadmill is relentless!

Seems the author recommended HTMX as an alternative in a couple of scenarios including my own use case (https://caption.me).

I checked out HTMX. The canonical example on the homepage (https://htmx.org/) was a button where a click calls the server and the response contains HTML to replace the outerHTML of the button.

I must be missing something here. Is HTMX really suggesting muddying the back-end code with front end code? So, any changes to front- or back-end would have to be carefully managed to avoid breaking the other side?

Feels like PHP all over again!

Re: If not React, then what?

#725

Post by lmm »

hmeh wrote: post #709
lmm wrote: post #708

Earlier quoted context omitted.

> If, for your application, the difference between a 1-50ms interaction and a 150-400ms interaction matters, then you have reason to for that interaction optimize the performance. If your entire app is like that, then you're probably a particular type of app (superhuman, miro, linear, etc.). > We all like to think that latency matters to our app because we all read that article saying that Xms in latency cost $Y, but…

> I've found that even if the page is, like, tax forms, latency changes the feel of it and affects how the user feels about your site, even if they wouldn't consciously say anything about the speed. I agree with this, but probably wouldn't about specific numbers or use cases. By the way, one of the forms on our app round trips in 75ms when selecting a radio button that controls which set of fields is visible below it…

> It's one part of our app. We wouldn't let that singular use-case dictate our entire stack.

Well sure, but in that case it's no longer "it's solving a problem we don't have". It's solving a problem that may be low on your priority list, that you maybe choose to tolerate, or solve in a more cumbersome way, but it's still an undeniable pain point.

And if you flip the question, I just haven't seen the compelling case for server side rendering. If you have a specific case where something else does something you can't do with React, or does something a lot better than React, then of course do that something else, and if that something else happens to use server-side rendering then maybe it will be a tolerable tradeoff. But I honestly think that if React or similar had come first, we'd never have invented server-side frameworks as we know them (which is not to say that we wouldn't have e.g. a Ruby based convention-over-configuration framework - but I think it would have a state model closer to React's).

> You're making assertions here about it getting more challenging, but I can't tell if that's from personal experience or if it's hypothesis.

It's personal experience, but perhaps outdated, and I never was hugely into Rails specifically. The last time I checked in was several years into wailing and gnashing teeth about people fleeing to React, but only really offering a smattering of ad-hoc fixes to specific pain points. Maybe they've found themselves a good unified state abstraction now, but I think it would be a real struggle especially for a framework that isn't really component-oriented in the way I see it (and indeed prides itself on embracing HTTP and having routes corresponding to pages).

> Yes, HAML is a new language. Our designers can work with it. It's not much more complicated than, say, markdown. Learning new things is what we do, every day. There are certain developers that prefer to hone their skills in the one thing they know how to do. They're the ones that put "React Developer" in their twitter or LinkedIn profile. That's fine. That's a career path. I don't work with those people by choice.

I used to pride myself on knowing dozens of languages, but I've come to see much of that as superficial and pointless. Learning new things that expand the way you think is worthwhile. Learning new tools that you can apply generally is too. Learning yet another slightly different templating syntax or curly brace programming language usually isn't. And some tools have enough depth to them that you can spend years and still learn new, useful things. I don't know that React is one of them - I don't know it as well as I'd like - but these days I generally find it more rewarding to learn a deeper corner of something that I can use a lot, than a new standalone thing that doesn't have any general lessons to impart.

Re: If not React, then what?

#726

Post by _heimdall »

cheema33 wrote: post #712
bryzaguy wrote: post #475

Earlier quoted context omitted.

I worked at New Relic and focused specifically on improving page load performance for one of the products using our RUM data. Even after combining/parallelizing API calls then embedding the data into the page, I found there was still an average 3-6 second average page load cost using React vs an already rendered HTML page which was nearly instant. Not huge but frustrating to discover the constraint when it was my tas…

If your page is taking 3-6 seconds to load, you are either doing something wrong, or not understanding where the problem is and blaming React incorrectly. My React app is statically exported and cached by the browser. There is only a single graphql call that fetches all necessary data. Backend is my only bottleneck. Everything else happens in less than 10ms. And yes it is entirely possible to shoot yourself in the fo…

That depends heavily on the device and network being used for testing. In my experience 3-6 seconds isn't out of the question by any means for a decent sized react SPA loaded on an older device and mobile network.

That isn't necessarily specific to react, any client-side rendered framework will have issues. React tends to be noticeably worse in my comparisons though, and any client rendering is going to be worse than server rendering your HTML.

Re: If not React, then what?

#727

Post by baggy_trough »

flimsypremise wrote: post #657
baggy_trough wrote: post #319

Earlier quoted context omitted.

> Building a web application with a UI in a professional context without a frontend build is borderline malpractice. This is outdated nonsense for most sites.

What does "most sites" even mean? I do this professionally, and I assume that most of the people replying here do as well. The article we're discussing is written by a professional for an audience of professionals. The number of sites I've had to build that were entirely static with no interactivity I can count on one hand.

You don't need a heavy frontend build for interactivity. All you really need nowadays is asset fingerprinting.

Re: If not React, then what?

#728

Post by claytongulick »

deergomoo wrote: post #159
claytongulick wrote: post #151

Earlier quoted context omitted.

What's the beef with clickable divs? Are you referring to just the case where they're misused for top level navigation? Or more generically? It's pretty common to not want the default behavior of an A tag, so instead of the e.preventDefault(); e.stopImmediatePropagation(); dance, a clickable div works great. Non deep-linked sub-nav (tabs, etc...) come to mind. Or maybe I'm hooked into a router and I need to pass some…

* Accessibility tools may not be able to detect that it's an interactive element unless you go out of your way to mark it up as such * It often (always?) breaks middle-clicking/opening in a new tab. In your navigation example is fine, but for example in Jira it's an absolute crapshoot which links will behave properly when middle-clicked * We already have a tag for a clickable element that is not a link:

Good points, but I think you and the others who responded to my question are thinking about "web pages" vs what I generally create, which are responsive mobile PWAs for internal line of business apps.

> Accessibility tools

Not all applications are created for accessibility, it depends on the app and the intended audience. While in a perfect world we'd all be section 508 compliant, cash strapped startups frequently aren't in a position to invest in that for MVP.

> It often ... breaks middle-clicking

Do you use the same standard for a native app that you install from an app store? Almost everything I've written over the past decade or so has been "web tech as a replacement for native" - not a public web site, so the function comparison should be against native apps. I probably should have mentioned that in my original question.

> We already have a tag for a clickable element that is not a link:

Sure, but I don't think it always makes sense semantically or from a code standpoint to use the button tag. For example, maybe I have a tiny little plus symbol for "expand". Like a lot of folks, I generally use some like font icons, or material symbols for stuff like that. Frequently it makes more sense to use a span or div to render the icon, and just handle the click event.

I'm not advocating for the use of divs instead of "a" tags everywhere, I just think there are normal and reasonable situations where it makes sense.

All engineering is a series of compromises and trade-offs. I'm not going to judge a dev that makes an info icon work to slide out a drawer which has a tabbed sub-nav, because they didn't hammer an A tag into something that it wasn't intended for, or because they didn't want to try to make whatever font icon library they're using work with a button tag.

Re: If not React, then what?

#729

Post by plantwallshoe »

Izkata wrote: post #700
plantwallshoe wrote: post #398

Earlier quoted context omitted.

IME there is a general consensus: Routing: react router (not very good imo but widely accepted and good enough) state: No libraries. Just use “useState” and if necessary “useReducer” Builds: vite Then pick a query caching library so you don’t need to treat fetched data like its application state… ReactQuery is widely accepted and very good. Apollo if you’re using graphql

> Routing: react router (not very good imo but widely accepted and good enough) Unnecessarily complicated and confusing, with odd choices in the most recent version (that IIRC are not backwards compatible). I went with wouter after searching around. > state: No libraries. Just use “useState” and if necessary “useReducer” useState is the same thing as the old setState, and useReducer not much different - they're not s…

I don’t see how prop drilling is an anti pattern. Passing data around via props is a feature of the library, it’s totally fine if you need to pass a lot of props.

If you really have too many props or need to widely disperse the same prop you can refactor using higher order components or use a context. A separate state management library isn’t necessary unless you are building something with a ton of complex UI state like a photo editor or a music production workbench.

Re: If not React, then what?

#730

Post by kccqzy »

trog wrote: post #483
kccqzy wrote: post #408

Earlier quoted context omitted.

There's no React-ey style UI. Seriously. It's a UI framework not a collection of prebuilt UI components. You cannot tell if a site is using React or not without opening dev tools.

I might not be able to tell if it's using React specifically, but I can tell it's using a React-like framework trivially because it feels like the entire website is covered in glue

No. You are just dealing with bad code. There are highly performant web apps written in React. It's all about craftsmanship. React gives you many tools to skip unnecessary work and reduce latency, such as shouldComponentUpdate, and assigning keys to elements in a collection. Or architectural decisions like splitting your UI into components correctly. It's up to the individual developers to use them. Bad developers write bad code in any framework.

But one thing I've noticed is that because frontend code runs on users' computers, fewer businesses and engineers have the incentive to really optimize that performance. If one writes bad backend code, it shows up as increased AWS bill; if one writes bad frontend code, well the cost is diffuse and many don't notice it.

Post reply on HN