Live data from Hacker News

If not React, then what?

infrequently.org

351–360 of 756 posts

Re: If not React, then what?

#351
post #283

Earlier quoted context omitted.

I'm familiar with React. And no, links in React often don't work without extra attention. It's way too easy to put some state information into the context and then have your pages depend on it. For example, you have a page with a filter that is implemented via a simple state, and then a list of widgets that pass the filter. The widgets have a click handler that opens the widget details. Now you right click on it. If…

> I'm familiar with React. And no, links in React often don't work without extra attention. ^ These two statements are at odds with each other. React will return a pure browser link that behaves exactly as a browser link: function Comp() { return text ; } > The widgets have a click handler that opens the widget details. > > Now you right click on it. If you're lucky, it opens the widget details in a separate tab. How…

> React will return a pure browser link that behaves exactly as a browser link

No it doesn't (in practice). React is typically used with something like React Router that takes over the whole sub-tree of paths. So links are handled by the single-page app itself, and this can lead to the state leaking through.

Yes, you don't _have_ to do it this way.

Re: If not React, then what?

#352

The fundamental magic of react is that it lets you write code that renders O(n) UI states in a functional manner (i.e. by returning the HTML you want) rather than O(n^2) UI state transitions in a mutable manner (by mutating the page via nested callbacks), and somehow makes it kind of fast-ish People love complaining about React, but I don't know if they remember the pre-React world where you had to write the code to…

How are you getting to O(n)? Is that in terms of the logic you need to read and keep in your mind? Or is it the actual computational complexity?

Am curious on the O(n) calculation as well haha — I get what OP is saying, but would love to know if there's some deeper technical details here.

Re: If not React, then what?

#353

Earlier quoted context omitted.

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve pa…

These disagreements almost always boil down to one side saying "some people use React to build content-oriented websites" and the other side saying "but most of us are building web applications". In a typical web application use case (yes, there are exceptions) you're only rarely looking at usage from old or cheap Android devices. Occasionally you'll see a tablet, but even that's rare. The vast majority of the time y…

I would also add that even in that last scenario React can be a great tool, there are many solutions that use React but make fully static exports (Nextjs/astro/gatsby/etc).

Pre-rendering everything has downsides of course, but it doesn't get much faster than that.

I think it's also a misconception that there is such a clear divide between app and content-oriented websites. Even the most content heavy websites, news sites for example, are highly interactive these days. Show me a popular content heavy site that doesn't have some sort of log in, interactive content, comment section, filtering, live blogs, alerts, notifications, search, and similar.

You also have to take into account the advantages of pre-fetching links, and only fetching and replacing the content instead of doing full page re-renders. All of these great things you can do easily with React and a React framework of your choice. You can even go further and have a hybrid of statically exported pages, SSR, and some SPA like highly interactive parts, reusing the same exact components in all these strategies.

All to say: React can be a great choice for a lot of use cases, also for content heavy websites.

Re: If not React, then what?

#354

I've been building sites since the 2000s and I'll let you know why React or jQuery "won." It's because when you write code using these libraries, your code looks nice . I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.) React will be unse…

I would completely agree and this is a large part of why I like Astro for static sites

Re: If not React, then what?

#355

Earlier quoted context omitted.

> Not a single file codebase. Yes it is. App.js is all the code there is. You can't count the two other files with 10 lines each. lol. Let's be honest here. And yeah for a tiny toy project like this you can get away with having zero design, zero architecture, zero object models, zero classes, and sure since everything is zero, we can throw in "Zero TypeScript" and "Zero Frameworks". Looks like some high-schooler's fi…

> App.js is all the code there is No, it's not. Chatbot.js is 3400 LOC. There's literally only 4 JS files in the whole repo and you couldn't be bothered to check how much code they have? Even after I told the other guy who made the same false claim "no, it's not a single file codebase"? Jesus you people are insufferable. So obnoxiously confident while being wrong about easily verifiable facts. > tiny toy project Huh?…

the expletive is unnecesary.

Re: If not React, then what?

#356

One of the under appreciated reason why spa took off is it exploits the lower cdn cost. Things that generate html on the server side need to pay for the higher bandwidth costs that are hard to cache well. In the other hand with spa, a well configured cdn can have a short ttl on index.html and cache the unique per deployment js bundles forever. The only server bandwidth cost is the actual api data

I don't think so. You can still generate a significant amount of your static HTML at build before pushing that to a CDN, and load dynamic content using JS; JAM Stack.

Re: If not React, then what?

#357

The fundamental problem with React and the like, is that it forced developers to unlearn the anchor tag. If you can change the url via js why use an actual hyperlink tag? Over the years, I'm seeing more and more unlearning of fundamental web from new frontend devs forged in boot camps.

The entire disappearance of semantic HTML tags has been sad to see. It's just all inside of inside of these days.

Re: If not React, then what?

#358
post #355

Earlier quoted context omitted.

> App.js is all the code there is No, it's not. Chatbot.js is 3400 LOC. There's literally only 4 JS files in the whole repo and you couldn't be bothered to check how much code they have? Even after I told the other guy who made the same false claim "no, it's not a single file codebase"? Jesus you people are insufferable. So obnoxiously confident while being wrong about easily verifiable facts. > tiny toy project Huh?…

the expletive is unnecesary.

Point taken. Edited.

Re: If not React, then what?

#359
post #3

React is not even a framework, really. It is a great starting point for simpler sites. Honestly still one of the best solutions out there.

Why wouldn't simple HTML be a great starting point for simpler sites? What's it missing that React solves, in your opinion?

Re: If not React, then what?

#360
post #135

Earlier quoted context omitted.

You're making the same mistake as the author. I get unnecessarily aggro too, but a plain reading of their comment isn't "they only cater to high net worth people" or they're advocating for such. Its "hey we're talking about 3G connections at this point, which are mostly shut down, and we don't cover developing markets" Note most of this is nonsensical too. His primary thing is "you don't need client side code because…

I keep hearing the "SPA is actually lightweight" argument but it's never materialized for me, the fastest sites are SSRs that are mostly static. The saving from HTML vs JSON just isn't that much over the wire and mobile CPUs and memory are a bottleneck. I have a newer iPhone and Safari is still full-refreshing pages constantly due to memory.

> "SPA is actually lightweight"

With utmost respect, that's not what I'm saying :)

I hold no hot take position on anything web dev, or any firm declarative position.

What I'm trying to get at is, indicia of an article being half-baked includes things like asserting all that's required to agree is to care about the user.

This feels good to say, but doesn't say anything, other than there's been at least some short-circuiting of thought. We can come up with many trivial cases where "caring about users" involves requiring client-side logic during rendering.

Post reply on HN