[eska]

I’m not a frontend dev so I just stick to vanilla html and js.

I created a simple table with 40k rows, slapped an input box above it, and had some vanilla js set CSS visibility on all rows depending on whether they matched. This would update live as I was typing (10ms trigger delay). No optimizations.

So what are frontend devs doing that they break all of this so badly? Are they just trying to be too smart, I wonder?

[Scottopherson]

Filtering a list is easy when all the data exists on the client and has no advanced filtering controls.

I'd love to slap an input box above a table and call it done but the product owners and designers that fill my backlog have other ideas.

I'd love to make sure this CSS visibility filtering worked well for screenreaders and other accessibility tools but that ticket was pushed down the backlog in favor of replacing native inputs with custom inputs that better match our branding guidelines.

I'd love to make sure these new custom inputs we cranked out last sprint work well for screenreaders and mobile devices, but we had another marketing lead join the company and now the branding guidelines are changing again.

I'd love to just focus on some HTML and CSS, maybe improve some of the touch support for mobile users, but now the release engineering team wants to have a meeting about micro-frontends?

I'd love to get past the existential crisis I had during that micro-frontends meeting and start working on the UI again, but first I have to debug all these failing Docker containers that's required to run our backend.

Really not sure where I'm going with this comment I'm going to stop now.

[sgarman]

Where you are going is that software often the result of a complex blend of different stake holders and requirements.

[bgdkbtv]

Good lord, are you me?

[theandrewbailey]

You're shaving yaks all the way down.

[sabellito]

Assuming you're arguing in good faith, managing complexity of large applications requires "something". What something is takes many different shapes, some of them trade performance for complexity management.

Having said that, it just looks like you're arguing about something you don't know much about, while at the same time trying to put down people who have been doing this for a while.

[arendtio]

Doesn't sound like you tested it on a mediocre mobile phone, sounds more like a laptop/desktop.

However, regarding your question: For one thing, many pages are being build for mobile devices first nowadays. So you would not simply push 40k rows but use some kind lazy loading which is a lot harder to build and can easily degrade the desktop experience.

Furthermore, people often use libraries to get rid off the browser differences and if you use too many of them, use them inappropriately or just a few that are not optimized for performance you can easily ruin the performance. In addition, the whole npm ecosystem makes it very easy to load and combine libraries. Often you need only a few functions but if your tree-shaking doesn't work correctly you end up with a lot of code that has to be loaded even if it will never be used.

So frontend development is a messy place and it is easy to fuck up the performance. Even though that should be no excuse for any frontend dev to write crappy code...

[vaughan]

I wonder if pushing 40k rows to mobile is such a bad idea. Phones have tons of space now. HD video streaming pulls tons of data. I guess mediocre mobiles complicate matters. Usually there are other factors making it implausible. Such as not compressing/compacting the data on the server, and not being able to limit large blob data columns, unable to control the parsing of data, and lack of normalized relational caching on the client. Usually it’s a collection of backend and frontend frameworks that complicate all this. I’m feeling more and more we need thick efficient clients.

[skybrian]

A web page that uses too much memory will cause other browser tabs to be unloaded. If you were writing a comment in another tab, you lose your work.

[onion2k]

I'd have thought background tab would be written to it's domain-partitioned bit of the cache before being unloaded. I'm very surprised you lose the current state. To be honest, that sounds like a bug.

[skybrian]

Tab unloading is by design. The difference is that it happens more often on low-memory devices. I use Chrome, but it looks like they all do it:

https://www.chromium.org/chromium-os/chromiumos-design-docs/...

https://hacks.mozilla.org/2021/10/tab-unloading-in-firefox-9...

https://www.reddit.com/r/ipad/comments/gidzwc/why_does_safar...

[xmprt]

I had similar fears when implementing a large table with some data visualization during one of my first forays into web development. I had noticed how slow things with 100 elements were let alone 1000. When I wrote my code that handled much more than that, I was surprised how responsive it was. How does a company with thousands of employees manage to make something that runs more poorly than something I wrote in an afternoon?

[vaughan]

Frameworks.

[nawgz]

I'm not sure what you are asking. You can of course build a trivial use-case with a native feature and have it perform as one would expect from a native HTML element.

However, it's not like the UI guys in the article didn't do that and implemented some crazy shit poorly. They just slapped a table on the page, incidentally with 38k elements - sounds a lot like what you did actually, and it lagged the page due to browser painting/layout issues.

Now, finally: how exactly is what you did not just the same as this, except they were actually making a usable front-end so the addition of CSS broke the browser rendering engine? Because it sure doesn't sound like you would know what to do in the situation the article discusses...

[xmprt]

Usable has many meanings and to me personally, a website that isn't very responsive and lags when you scroll doesn't seem very usable.

[nawgz]

Did you read the article and the comment I was replying to? Both basically rendered 40k element HTML <table>s. Difference is, the Google UI lags because it is hampered by browser painting/layout computations taking forever, despite the <table>s in discussion having near-identical complexity, so one can conclude the Google UI bug is more-or-less a bad interaction between the UI's CSS and the browser rendering engine.

So, pray tell, how does parent comment decrying UI developers for supposedly not just rendering HTML tables make any sense in light of this context? It is just sass from someone who likes to rail against UI development, there is no insight

[dan-robertson]

I think this is actually a little subtle: if you don’t have fixed-width columns then changing the visibility (or more strictly the display property) of rows can require column widths to be recalculated which is often pretty slow. It’s easy to say that obviously you should just set fixed widths but it is pretty hard to decide what they should be in practice if you want the page to still work when someone resizes their window.

[Cthulhu_]

It's easy to underestimate how fast a plain vanilla HTML table can be. It gets a lot more heavy if you start doing things like sorting, column resizing, filtering, and of course it depends on what you have inside of them.

One perf issue I ran into on an older application I'm maintaining was that on render, a callback would iterate over ALL cells to add a drag handle to them, so that a user could change the column width anywhere. That quickly ran a few hundreds of thousands of times.

[nitwit005]

Presumably, almost all of the rows are tagged with "display:none" then? From the timings I did in the past, rendering tables with thousands of rows and a many columns can take whole seconds.

[beebeepka]

Table rendering/updates used to be all or nothing, so loading big sets meant waiting for the entire thing. Not sure if that is still the case in all browsers

[FastEatSlow]

They just all need to have the latest shiny thing, spurred on by the idea that a huge amount of abstraction is a good thing.

Abstraction is great, our modern world wouldn't exist without them, but it's a website.

Let's put our tinfoil hats on, and use this to discover that managers promote inefficient development to force higher management to put more funding into projects. It's clear now, the bloated hobby websites are just from that idea spreading.

[rasz]

>table with 40k rows

Oh I have one with 6K rows, 300ms to insert into a page if I try to measure, but in reality browser freezes for 3 seconds (1.8s style, 900ms layout, 300ms update tree). Freezing goes away with position: absolute, but it still takes 3 seconds to show up after .appendChild. I tried replacing Table with Flex divs, even worse speed.

[robbiejs]

If your table is simple (values, no markup), try DataGridXL: here's a One Million Cells Demo that loads in an eyeblink: https://www.datagridxl.com/demos/one-million-cells. (Disclaimer: I am the maker)

[rasz]

Its not real. What good is virtual table if I cant search for contents of last row, "2000;1", after loading the page :( Still, this gives me an idea. Dump contents of my table as text under virtual one so search will at least scroll down to appropriate offsets.

[robbiejs]

Version 2 (december) will have a very fast search feature. But you're right: CTRL+F does not work, as it is virtual. I don't really understand your idea, can you elaborate?

[cerved]

did your test consist of other things found on a site such as the one with the Google data grid or did you just slap a table on an empty page? Is the table fixed height? What are the scroll settings?

[otrahuevada]

Hi! Frontend dev here. What we are doing is covering several other industry standard use cases.

I mean, yes. Sometimes, to some degree, you can get away with something like that, but most of the time real clients have complex requirements.

EDIT: Removed most of the substance of my comment. If my astoundingly fragile downvoters can't be arsed to discuss anything of substance, I don't find bringing said substance to the table worth it. Yay community.