Hacker News Reader

Comment by onion2k | Hacker News Reader

We need to look at it from two sides: if it’s good for developers and if it’s good for users. React was great at former and terrible at later.

React is not "bad for users". Developers build complex, fast apps with React all the time. It can be fast, but if you make mistakes with it then it's easy to make something very, very slow.

The app I work on is huge. It's ~8MB of uncompressed React + Redux in development (much smaller in production though), and pages include a lot of assets so they can weigh in at 23MB in the worst cases. A complex page can have up to 60,000 DOM nodes under React's control with thousands of event listeners. It starts in about 3s and never drops below 60fps.

View on HN

> A complex page can have up to 60,000 DOM nodes under React's control with thousands of event listeners. It starts in about 3s and never drops below 60fps

Can one really make such affirmations regarding client rendered web apps? I'm assuming these numbers aren't solely measured on localhost in some state of the art development machine/device so won't it depend on the client's machine specs, browser, usage, bandwidth, etc?

I don't know what bandwidth has to do with react managing the DOM.

A naively built app will do things like take some user input from a form, send it off to an API and await the response, and then update the UI when if the request is successful or display an error if there's a problem. That means the user has to wait for the request to complete before moving on to their next task. In other words, the DOM update waits for the network. If you have a slow connection that feels horrible (snarky frontend dev note - if you build a server-side rendered app it's how everything in the app works. Sucks if you have a slow connection.)

It's better for the user if the UI assumes the request has been successful and updates the UI with a temporary success state, and then undoes the update if the request fails and gives the user the option to recover their update and try again. Most of the time there won't be a problem (especially with good client side validation) so they'll never see the recover state, and they'll never need to wait for a network request to finish either. Obviously you shouldn't use that sort of UX pattern for critical things though.

Ugh, this has got to be one of my biggest bugbears with SPAs. This pattern fails far more than you obviously think it does, and when it does fail, it's usually handled so poorly it's worse than the 'cure' you're peddling.

Give me a clean, server-side form submission any day over the "has it worked, hasn't it?" inconsistency of SPAs.

This is how i manage more than 60,000 DOM nodes https://github.com/developit/preact-virtual-list ; actually i think i could handle 600,000 and still have no problem.

You just removed an usefull features from the user.

The virtual list make ctrl+f not working anymore, and I hate every single react page using it. Suddendly, on this webpage using virtual list, you ctrl+f something, dont find it, because the element does not exist.

A vue or angular manage your 60k elements list without any issue, you dont need to virtualize your list, and the search feature your your browser keep working.

And if your don't use a virtual list, react get performance issues starts when you get only a few hundreds of elements and you want to filter them.

Also, it start 'instantly' with other frameworks, not in 3 seconds, but below 500ms.

There is a find feature in the specs already. My users actually need to be able to interact with a lot of rows.

I can just bind ctrl-f to my search feature.

Also, it doesn't take 3 seconds to load but few ms as well.

See, you don't just pick a tech, you need to start from the specs and get what the user need.

Also, in pure HTML (because i tried it) ; the same rendering would be hanging anytime you try to act on something.

Now it doesnt work:

- On mobile, using menu to search in browser menus.

- When users use F3 to search, an alternative to ctrl+f.

You added a few bytes to reimplement a browser feature, and spend time on a feature that already exist, because of your tech choice. There is still probably some accessibility issues.

You can have easily 60k rows in HTML without any performance issue, you just need to pay attention...

What are you talking about ? Are you saying a search feature is not necessary in my specs because you like using f3 or ctrl-f ?

"On mobile, using menu to search in browser menus" -> This is not a sentence.

I do add a "few bytes" to "reimplement" a "browser feature" ; but the reality is that i HAVE to implement search because it is hitting on 730000 per year records;

How is you ctr-f or f-1 feature is gonna search on 2190000 rows in 3 years ?

Again, you are too happy about your opinion that you spite it out like truth without even understanding specs.

Specs is what allow you to understand what's required, it makes no sense what so ever to talk about technology without understanding WHY you use it in the first place.

Is it meant for public ? employees ? How many rows do they deal with in their actual everyday workflow ?

You are pushing your workflow so much that you don't even consider about your users and that's another red flag for me.

PWAs have given so much in term of capabilities and mastery that I honestly wonder why I'm still talking about such things on HN while proper workflow about architectural design are ignored here.

""On mobile, using menu to search in browser menus" -> This is not a sentence. " -> Sorry, I meant using the browser search feature by invoking it from the contextual menu of your browser, which is the only way to spawn the search toolbar on mobile.

" but the reality is that i HAVE to implement search because it is hitting on 730000 per year records;" -> True, there should be a search feature with a backend API.

"Again, you are too happy about your opinion that you spite it out like truth without even understanding specs."

Yes I want too far, your use case does require extra logic, because it's not good to send that much data to the user. I'm not pushing a workflow, im not a front end dev, but i do maintain frontend apps sometimes, i'm simply angry at React, because it cause pain to me as an user.

It's noticably slower (https://medium.com/dailyjs/a-realworld-comparison-of-front-e...).

The virtual list may be required for your use case, but as a user, I often met virtual list:

- Used for less than 100 elements

- ctrl f is not hooked on the 'webapp search feature'

- the 'webapp search feature' is noticably slower than the browser.

Also, here some reading, from a framework I don't use, about the virtual dom:

https://svelte.dev/blog/virtual-dom-is-pure-overhead

Now, not as an user, but as a software engineer, my soul cry when I see the architecture principle of such a framework fixed with a workaround.

Thanks for the read ! I didn't know svelt and it seems like it has solid motivations. I should definitely check it out.

I'm actually more of a preact fan and the community Jason Miller has created, their work have inspired me a lot in concern of front-end and javascript dev.

ctrl-f hook is effectively something that has to be considered when implementing such feature.

I'd argue that the list & search feature it self is hard, not as something to put on and program and get working, but as a user-experience and design perspective (I'd like to thank you about pointing that out by the way, I will definitely spend some time making sure it's there for my app)

The reason I can think of, is that we do actually take control over parts of the applications in a way that was not imagined when browsers implemented search function.

It almost feels like the "With big power comes big responsibility", but i don't like the word "power" in our case, so I'd change it to something alike to "With features that have extra consequences we need to have an equal amount of extra care to even considering them." as if it was hidden and we needed to understand the tool better to have it properly done.

I guess front-end dev is easy to get in and understand, but hard to master, and that could be why we end up with these rampant "half-done" apps that do not take those extra steps.

In the end, the rushed dev will probably just look to have it's app working and will not check these kind of "bugs" that have been caused by his decisions,

Tbh, without this discussion i'd probably have missed it too

This is admittedly nit-picky, but you're not managing 60k DOM nodes if you're using a virtual list, that's the whole point of virtualization. You might have 60k items in your list but you're only ever rendering a tiny subset of those items based on what is visible (with some overlap).

It's not virtualized. It's not even a list. It's a very large SVG with lots of foreignObject bits in it. The app is a diagramming tool - imagine Visio but for lawyers to map out contracts and ownerships between hundreds of corporations.

You might get better performance with the <canvas> element instead of SVG. I've noticed React can struggle with SVGs containing complex subtrees.

Sorry, someone else mentioned a virtual list component and I assumed it was you without looking at the username.

That's pretty impressive, I've run into perf issues with far fewer actual DOM nodes than that!

Can you share a link to a react app that is both complex and fast?

Reply on news.ycombinator.com