3 ms·
How does your framework handle re-rendering large components? E.g. a table with 1000 rows. I can't see any obvious mention of virtual DOMs so I assume you're no
by Philip-J-Fry 5y ago
How does your framework handle re-rendering large components? E.g. a table with 1000 rows. I can't see any obvious mention of virtual DOMs so I assume you're not using them.
You might say virtual DOMs are exactly what you're talking about when you talk about the design choices of popular frameworks.
It fundamentally comes down to the idea of writing functional components. I declare exactly what I want my UI to look like as if render() is called every frame. But I don't care _how_ it gets there.
The complexity comes from taking this declarative UI and making it performant.
I don't doubt that 90% of web pages could get away with not using React or Vue or Angular. But as someone who loathes writing complex applications with pure HTML and JavaScript, they do serve a purpose.
I've written web apps that are basically just one large render() function with pure JS/HTML and it gets the job done. But at some point you do need to optimise and then it all falls apart.
- josephg 5y agoVirtual doms are a cute idea, but virtual dom diffing will always leave a lot of performance on the table. It’s complex, slow, and entirely unnecessary - especially now we have frameworks like svelte. It can still work well enough when developers don’t go crazy with divs, and when they use shouldComponentUpdate. But nobody uses that stuff; and modern pages are bloated like crazy. For my money I think the problem is cultural. Theres a community and culture around frontend engineering now which seems to entirely disregard performance to the throne of closing tickets as fast as possible. Lots of frontend devs I meet at conferences and meet ups have no idea how the browser works, and no real desire to learn. The result is disasters like the new reddit homepage - which needs more horsepower to render smoothly than AAA video games did a few years ago. The GP is right. There’s an insane amount of performance being left on the table. I don’t think it’s a technical problem. It’s a cultural problem.
- unleashit 5y agoI love how the new Reddit gets frequently used as a straw man in arguments of front end developers are bad, the state of front end is a mess, etc. If you care to look at the actual reasons that Reddit and so many modern websites really are terrible, you'll see that it comes from the top and in many cases is on purpose. Reddit (and many others) don't want you to use their website. Especially on a mobile browser. They want you using their app where they have access to more of your data and generally keep you longer. And also where the initial payload of advertising and analytics cruft feels faster to you because you probably are more inclined to be patient with the mobile install/update lifecycle than you'd be with a browser. The GUI changes too were much more likely to come from product management than your lowly front end bootcamp graduate.
- josephg 5y agoWe might have to agree to disagree on this. I bet a huge percentage of Reddit’s traffic comes from their website. And if they didn’t want people using the website, they wouldn’t have bothered putting so much effort and attention into the redesign. Why bother redesigning something you want nobody to use anyway? And if your argument is that they made it bad on purpose, they may as well have just made their old site worse. Also, if their business model is analytics and ads, why do they allow 3rd party reddit clients like Apollo? I hear what you’re saying, but I stand by my perception of what’s going on.
- rglover 5y agoI do use a virtual DOM but I only use it to patch the HTML in the browser (no synthetic events or anything like that). The meat of it starts here: https://github.com/cheatcode/joystick/blob/development/ui/src/component/class.js#L360 https://github.com/cheatcode/joystick/blob/development/ui/sr.... My focus for v1 is on developer ergonomics and solidifying an API (this will be frozen after v1 with the only changes being additions if absolutely necessary—a component you write today will look identical to one you write in 10 years). All future major versions will be solely focused on performance and security (my way of saying: I haven't stress-tested renders, but for the time being it will work well for the majority of use cases). Edit: the lack of mention of how I do it is intentional. The last ten years saw brilliant inventions turned into mush because all of the leading project devs got into an unacknowledged dick measuring contest with one another (i.e., passive-aggressive jockeying for dominance that was ultimately a distraction from building software that was usable).