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

511–520 of 756 posts

Re: If not React, then what?

#511

Post by crabmusket »

retropragma wrote: post #473
crabmusket wrote: post #371

Earlier quoted context omitted.

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/

Sadly not. I did find this article too while searching for what I remember. It is a close match in so many ways, but also not quite.

I remember the article very much taking the approach that you've never heard of React before, and walking through a series of problems and discoveries like "oh, what if we just render the state to the DOM every frame? let's see how that works".

Almost like a "you could have invented React" kind of vibe. I think there was a button-counter demo app.

Re: If not React, then what?

#512

Post by ZYbCRq22HbJ2y7 »

xcrunner529 wrote: post #346
afavour wrote: post #228

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…

It’s just embarrassing any image scrolling site will eventually just eat all the memory and crash and you lose your place. Used to kill me back in the Tumblr days and React perpetuates it.

That is an implementation issue, not a framework issue.

There are plenty of easy to use virtual scrolling libraries for React and vanilla JS. There is also `content-visibility` with CSS Containment now.

Re: If not React, then what?

#513

Post by 59nadir »

johnfn wrote: post #168

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…

There really are only a handful of things you could do that should passably take "hundreds of milliseconds" and loading a web page is not among them. Neither is displaying a few hundred thousand things on a screen, least of all what are essentially rects in 2D.

The only reason any of the above sounds fine to take this long is because the standards of web development are so incredibly low.

Re: If not React, then what?

#514

Post by slmjkdbtl »

lopatin wrote: post #143

I'll continue using vanilla React, for the same reason I use Java: it's reached the coveted "boring technology" status where it's mature, stable, fast enough, and has a huge community, resources, and ecosystem. I won't let go of that easily. However, this is a pretty epic rant nonetheless.

Java is way way better than React (hooks) in this regard. Boring tech is good, but React is the opposite of boring tech, it innovates new way to write software, but ends up in disaster.

Re: If not React, then what?

#515

Post by thecodrr »

React is not slow. React is not "big". React is not the reason your website is slow.

Any engineer who thinks that its React that is causing the slow renders and replacing it with X is deluded. Yes, there are ways to make slow React web apps. But there are also ways to make fast React web apps. It just requires effort and a little bit of foresight.

Re: If not React, then what?

#516

Post by matesz »

throwaway0123_5 wrote: post #289

I'm not a web dev at all, but when I need some web UI ClojureScript/Reagent works pretty well. I get all the pretty React components while being able to avoid JavaScript and JSX entirely (all XML-style DSLs that have closing tags I find incredibly verbose and ugly).

People don’t understand the beauty of closure!

Re: If not React, then what?

#517

Post by slmjkdbtl »

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 code looks good for clicker example, when building real application I think it's much harder to read than vanilla JS, especially when hooks and all the dependency arrays flying around, constantly worried about how many times will things fire and super easy to make mistakes no matter the skill level.

Re: If not React, then what?

#518

Post by LtWorf »

smrq wrote: post #377
LtWorf wrote: post #339

Earlier quoted context omitted.

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".

I think his definition of profoundly stupid probably differs from other people's.

Re: If not React, then what?

#519

Post by antris »

fleabitdev wrote: post #342
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…

You're completely right, but I think it's worth adding that the O(n^2) to O(n) change isn't specific to React or UI. That same improvement is often seen when migrating other code from a mutating style to a pure-functional style. "A pure function which transforms the entire input into the entire output" is obviously the simplest possible architecture for many programs, but people hesitate to use that architecture beca…

> "A pure function which transforms the entire input into the entire output" is obviously the simplest possible architecture for many programs, but people hesitate to use that architecture because of performance concerns. In practice, the baseline performance is often faster than they expect, and it can be made much, much faster using strategies like memoisation and fine-grained reactivity.

But before React came along, you just couldn't do this without major UX breaking bugs, because of how the DOM worked.

Say you have a form that you want to change depending on the state of the app. If the user is typing in a form field while an update to the app state comes, and a pure function that transforms (app state -> DOM/HTML output) resets the form (meaning removing the old out of state DOM and replacing it with the new DOM), the user loses focus on the form. So you have to add some kind of logic where the app remembers what form input the user was focused on, where in the field the focus was, etc. The more complex your app is, the more complex the DOM reset logic became, and you cannot abstract your way out of it with pure functions, because the DOM that relies on mutation slowly creeps into your pure functions anyway.

React changed this, because it gives you a pure function interface, but resets the DOM using mutation functions i.e. native DOM methods, surgically. This is achieved with the VDOM (Virtual DOM), by diffing VDOM states and then reflecting that to the actual DOM. This means when the DOM resets, there's no problem with elements getting removed and added back in, and the focus states etc. don't get thrown away with the DOM. Before React, nothing like this existed.

Re: If not React, then what?

#520

Post by halflife »

lucsky wrote: post #305
halflife wrote: post #285

Earlier quoted context omitted.

This is something that I just don’t get, in the olden days, when you wanted to encapsulate logic and state and share it between instances you would just use a singleton service. But now when classes are “bad” for some reason (when the whole point of a class is encapsulation of state and logic) you get weird stateful functions that makes everything hard to track with complicated API.

1. Nobody said that classes are bad. Yes you can encapsulate logic and state in a singleton, that's not the issue, the issue is how you then "apply" it. There was a fantastic diagram that (most likely) Dan Abramov posted on Twitter a while ago (before it became the olympic pool of diarrhea that it is today) that was demonstrating the superiority of hooks in a beautiful and obvious way but I cannot find it anymore...…

Nobody is saying that officially, but for the past 7-8 years the react documentation pretty much ignore class components. Today you have no way of knowing how to create a large class based react application because the ecosystem has moved on, it’s not the best practice.

I’m using weird and hard in a relative and not absolute way. Weird because functions can’t have state, and for years we’ve been taught to keep functions small and predictable. Hard because there are much simpler ways to write stateful code other than hooks. The problem with react is that instead of creating a powerful state library, powerful ui library, and creating a bridge between them, they chose to subjugate the state library to the UI library’s limitations.

Post reply on HN