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

371–380 of 756 posts

Re: If not React, then what?

#371

Post by crabmusket »

lihaoyi wrote: post #243

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 left. I can't for the life of me find it now :(

Re: If not React, then what?

#372

Post by tekla »

no_wizard wrote: post #214
ToucanLoucan wrote: post #211

Earlier quoted context omitted.

They don't say "I'm sick of React websites," they just say "Wow websites are getting slower and slower." or they complain about specific tabs or just the browser in general sucking up tons of RAM and CPU.

I’m also aware they won’t make the direct references and I’m willing to bet the OP is too. There are very few instances I can think of for the last 4 years where I heard anyone complaining like this about the general state of these things. There’s a few offenders I can think of, like Salesforce, but I haven’t heard from any non technical users especially about things like Gmail being slow or their browsers being too…

Then you are in a bubble. I was recently asked by my elderly parents why they are paying for 5g internet when the internet resources they use are so slow, slower than what they remember from 1997.

They ask me to call our ISP because it makes no sense that the sites they have used for decades feel so slow

All I could say was that there was nothing I could do.

Re: If not React, then what?

#373

Post by ivanjermakov »

peutetre wrote: post #365
harrall wrote: post #297

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…

> React will be unseated like jQuery got unseated when someone makes something that looks nicer. The solution is WebAssembly. Make your code look as nice as you want, as readable as you want, in whatever language you want. No more JavaScript limitations.

Interesting take. On the other side, many library developers drop TypeScript[1] because it requires a build step and might be tricky to deliver to library users.

I wonder how much would WebAssembly suffer from this and compatibility issues. I hope browsers to improve WASM ecosystem so that it can be used more widely and without the need to ship the whole runtime with your website.

[1]: https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...

Re: If not React, then what?

#374

Post by agumonkey »

cies wrote: post #349
agumonkey wrote: post #326

Earlier quoted context omitted.

To me it goes beyond the looks. Angular terminology and semantics were always very alien. React is no angel either, but it seems influenced by older, more tested concepts (FP and such). That said, I think client side UI/UX is about to see yet another large wave of change. Hearing chats from solidjs devs make me feel that there's a whole new and saner space to describe simple and fast programmable interactions.

React does very little. You still need other libs to go with it before you can compare the set of them to Angular.

I stopped following the angular world long ago, how much is included in it ? (on my way to read their docs but I'm still open to a short summary :)

Re: If not React, then what?

#376

Post by crabmusket »

simonw wrote: post #37

A fun thing about reading Alex is that you can tell he's had the same arguments over and over again for a decade now and he's frustrated with having to keep on making the same points and getting the exact same responses. Most of the people commenting on this piece won't have read this whole article (it's long, and internet attention spans are short). As a result, you'll find plenty of the comments here were exactly p…

I think most responses to his posts are missing that this is the most important part:

> In practice, the only thing that makes web experiences good is caring about the user experience — specifically, the experience of folks at the margins. Technologies come and go, but what always makes the difference is giving a toss about the user.

> In less vulgar terms, the struggle is to convince managers and tech leads that they need to start with user needs. Or as Public Digital puts it, "design for user needs, not organisational convenience"

This is the most important thing. The entire article series is making this point in great detail, and also being very angry at orgs (especially public services!) that don't get this.

I think this message does get a bit buried under invective against React. Surprise surprise, if you do start with user needs, then sometimes that does lead to you building a React-based SPA. I think from Alex's perspective working with organisations, looking at it from the other direction: for any given React SPA, it is unlikely that React was chosen because of user needs.

Re: If not React, then what?

#377

Post by smrq »

LtWorf wrote: post #339
johnfn wrote: post #315

Earlier quoted context omitted.

I've spent plenty of time optimizing performance. It almost always comes down to a backend issue, unless the frontend is doing something profoundly stupid, like making multiple API requests in serial when they could be batched or parallelized.

Yes because loading 500 different css and js files is not a problem for performance.

They literally just said "unless the frontend is doing something profoundly stupid".

Re: If not React, then what?

#378

Post by hombre_fatal »

hasanhaja wrote: post #278
jakubmazanec wrote: post #265

Great, another misinformed rant about React; meanwhile React developers get stuff done without inventing yet another template language. Also, website aren't slow because of React, they are slow because of shitty developers or insufficient budgets.

Why do you think bad developers or teams without sufficient budget may produce bad experiences when using React? What should those teams be caring about that React doesn't solve for them?

Interactive UI development just isn't easy nor simple regardless of the platform and framework.

A tool like React can shrink the space you need to be vigilant about to ensure performance (not just speed but also UX), but you still need vigilance and attention to detail to make sure you're not making mistakes like running something on every re-render that you meant to do just once.

And it has its own idiosyncrasies that you need to be vigilant about. Like if you write a hook `const x = useMyHook({ optionA, optionB })` then you need to handle the cases (either at the call site or inside the hook) where the options object is new one every render and when optionA or optionB are non-primitives that change every render.

Re: If not React, then what?

#379

Post by lolinder »

xcrunner529 wrote: post #348
lolinder wrote: post #314

Earlier quoted context omitted.

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…

The top sites using react are all e-commerce or social sites. I would bet the majority of react sites and devs that use them are not building apps that require SPA or something like React. Which is the problem.

> I would bet the majority of react sites and devs that use them are [n]ot building apps that require SPA or something like React. [edited to restore what I assume is the ended meaning]

On what basis do you bet this, though?

Sure, you see sites that bug you by being slow in contexts where you'd choose something else, but most devs are working on sites and apps that you will never see, because you're not the target demographic.

I don't have survey data one way or the other, but anecdotally everywhere I've worked on an SPA has been a clear case where trying to do it in backend+JQuery would have been a huge failure.

Re: If not React, then what?

#380

Post by quantadev »

baobabKoodaa wrote: post #329
quantadev wrote: post #316

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?…

Even considering chatbot.js, it's still a small enough toy project to just barely get by without type safety. I don't consider a project "large" until it's in the 30K to 50K LOC at least, where it becomes impossible to literally remember where each use of any given variable is. Type Safety catches most typos at build time, and also allows ease of refactoring. Only these small projects can get by without type safety, but EVEN the small projects DO benefit from catching errors at build time. It's just a self-foot-shoot to find bugs at runtime instead of build time.
Post reply on HN