Live data from Hacker News

If not React, then what?

infrequently.org

471–480 of 756 posts

Re: If not React, then what?

#471

Earlier quoted context omitted.

what do you use for routing? I built Routerino for just exactly this purpose, to use with vanilla React. maybe it'll be useful for you! https://www.npmjs.com/package/routerino

I actually use the history API. I've been thinking about modernizing by replacing it with React Router. I'll check out Routerino also.

React router is a nightmare.

Lots of massive paradigm shifts with little backwards compatibility.

I’ve gone through like 3-5 times where there is some massive changes between versions.

Right now they are pushing some new routing mechanisms…

Re: If not React, then what?

#473

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…

I never want to go back to a non-declarative rendering framework. Does anyone remember a blog post from maybe 2016-ish which described the process of "building your own" react-like rendering loop? I remember it being a fantastic explanation of what the virtual dom is and does, and why the "UI is a function of state" paradigm is great. I remember it having a live example to the right side, with prose and code on the l…

This? https://pomb.us/build-your-own-react/

Re: If not React, then what?

#474

Earlier quoted context omitted.

Most of the apps I've worked on were very business oriented, and about people getting work done, rather than "website" type stuff that's mostly static. So for example, being able to refresh a part of the screen with new information from the server, is critical. Doing page reloads would destroy the experience. I have 35yrs exp so yes I've used most of what you mentioned.

You’re just proving the point. This stuff was easy when it was called Ajax. You don’t need React for that simple thing lmao.

I just use the 'fetch' command to get data from the server. That's basically like Ajax. Where React comes into play of course is taking care of all the page updates, which would be a nightmare for any large app, unless you have a framework being used.

Re: If not React, then what?

#475
post #311

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…

> 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 parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on l…

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 task to improve it and our company was trying to be an example of great performance.

Re: If not React, then what?

#476
post #249

Earlier quoted context omitted.

Ironically the first question you ask is the question people should be asking about React. Specifically, what problem does it solve, and do I have that problem? The problem most teams tend to face, and I believe part of the authors argument is that people reach for React out of an almost superstitious or orthodoxy-based belief. Likely many developers don’t even know how to build something without React. They don’t kn…

Meh. What is that self-evident alternative supposed to be? I ask as someone who crafted HTML with my father's lisp parens on computers running linux kernels which were still delivered with the pl suffix, and as someone who occasionally still occasionally tries to deliver frontend code, much to my dismay. I've made websites in so many stacks and varieties that it would be intensely boring to list or read them, and I h…

Meh, indeed :) Thank you for your response, it's a fair question and critique.

It'd be rather challenging to write guidance on which technology to use to build an application. Thorough guidance would need to consider far too much. You wouldn't have a tome, you'd have an anthology. You'd have to consider what is being built and by whom at the very least.

It becomes "self-evident" when you have enough knowledge and experience to make the selection and you successfully de-bias yourself from the "shiny" or the "common" (Which React was and is now respectively).

So, what would I recommend? Aside from the pat, "it depends" answer, I would recommend starting with a server-rendering based framework. I prefer Rails, personally, because Ruby works well for me and my team, but many others would do just fine.

Then, fight all superfluous interactivity for interactivity's sake in your applications. Stick to server rendering and form submissions until you need something more elaborate. Then, look for something you can use to augment behavior. I use Turbo/Stimulus, with which we are able to do a lot with very little. Others like HTMX. If one really needed the interactivity and declarative nature of something like React, then the list that the author mentioned would be good to explore. Most folks don't, and I think that's the main point that's lost on many.

Oh, and if you're building Google Maps, Miro, Linear or the like then disregard the above suggestions, they don't apply. Etc. (again, it depends)

As an aside, I was historically a huge React fan. I used it for quite a while. I'm still a fan of the declarative nature and one-way data flow. It's super powerful stuff. We actually get something somewhat similar with Turbo and the much more sophisticated Phoenix LiveView (can't recommend this one personally, haven't used it in anger). Procedural-based UI code for complex, highly interactive applications is a fool's errand in my opinion. For the basics though? Totally fine.

Re: If not React, then what?

#477

Earlier quoted context omitted.

Maybe Angular is still used a lot, in legacy projects. I just mean for starting a new project, imo most people will choose React or Vue in 2024, right? I never used Angular myself, but have used both React and Vue a lot.

If you’ve never used it don’t declare it dead. Angular is updated regularly every 6 months. While react is busy thinking how to create more SSR apis, the angular team keeps improving developer experience. IMO right now it’s easier to start an angular project with much less foot guns than react.

I call plenty of things dead without ever having used them. FORTRAN for example.

What I mean by dead is it's a VERY unlikely choice for any new app. People will choose React or Vue most of the time. You don't see Angular used hardly ever for a new project.

BTW: Vite is the new best way to manage the build pipeline, and makes React super easy to start using.

Re: If not React, then what?

#478
post #108
post #4

> Frameworkism isn't delivering. It isn't? I find React to be great to work with.

If React is so great how come Amazon isn't using it in their store? I think last year an Amazon frontend engineer wrote some tweets explaining they tried React and it was too slow. So they keep using Java for SSR and sprinkle vanilla JS. They were still using jQuery until a couple of years ago and probably still are in some parts of their site.

Most of their app is a mismatch of web views and native with spinners galore. It doesn’t seem like performance is a high priority for them anymore.

E-commerce is fundamentally small data once the user lands on a product page, so every subsequent link and click should be instant.

Re: If not React, then what?

#479

Earlier quoted context omitted.

Me too. lol. People who don't think type-safe languages are important are the ones who simply haven't yet run into the problems you run into without type safety, and no amount of HackerNews posting is going to suddenly give them the experience to understand.

Awfully funny considering our major security issues in code these days are from a type safe language.

Yeah because any systems or OS programming is done in type-safe languages. lol. And BTW correlation is not causation.
Post reply on HN