Hacker News

Author here: Fair point—React’s baseline isn’t a monster. ~60KB compressed for a barebones Vite/React setup, or even ~25KB with Vue. Medium projects at 200-300KB are definitely workable.

But here’s the point: a single React/ShadCN button, straight from their official docs, still outweighs Nue’s entire SPA demo. Add more widgets—tabs, modals, whatever—and that gap only widens. Nue is flipping the script. Web standards let us start lean and stay lean—smaller codebases, faster HMR, quicker builds. That’s the win: efficiency that scales without piling complexity.

Isn’t using compressed numbers pretending that network bandwidth is the only cost of bloat?

All that JS, once decompressed, needs to be parsed and actually evaluated. That is where it hurts even people on gigabit connections.

I think frontend bloat has arrived at such an absurd level that it kind of makes me wish broadband and mobile speeds, and JS engine speeds, had paused their advancement for 15 years so that FE developers would have had to learn to write good code. Presently there is a whole generation of developers who built their whole careers in this era where you can get acceptably mediocre performance even with wildly inefficient code and an absurd amount of dependencies, most of them barely used on a given page. They’ve never been challenged to do any better, so i don’t really blame them.

> The bloat isn't coming from "huge frameworks" like React.

I agree. This is such a familiar cycle. People still blame Java for things that were really the fault of the average "enterprise Java developer".

The reality is that these frameworks don't automatically lead to bloated code shipping everything.

Just to add Svelte (`pnpm create vite -t svelte-ts`) ~8KB

  dist/index.html                  0.46 kB │ gzip: 0.30 kB
  dist/assets/index-yJpzg09Q.css   1.26 kB │ gzip: 0.63 kB
  dist/assets/index-CxtJFQC8.js   17.91 kB │ gzip: 7.72 kB

> You can create that kind of garbage with any framework, or without framework

I would think it would be quite a challenge to accomplish the given task without a framework?

Downloading =/= executing. Downloading 60 kb of compressed JavaScript isn't the problem, the problem is running that JavaScript, and all the resulting web calls that JavaScript will do, and all the resulting compute it will take to... I dunno, make the button round or whatever. Load time is no longer a solid metric for a good experience, that's very late 00's of anyone to say, the metric now is how long until the page is laid out, and the controls on it are responsive?

Edit: Also how hot is my phone?

>You can create that kind of garbage with any framework, or without framework.

The whole point of the framework is to make even absolute garbage stick together. (While making the developer replaceable.)

> a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies...

> (This is partly on React, or may be on the culture around React that has made all of this normal and acceptable.)

Yes, that, too. But you are forgetting that React makes all that opimizing work necessary in the first place.

Networks are fast. Machines are crazy fast. Almost 30 years ago I was doing on-line adaptation of Postscript print files. So some form input and re-rendering the Postscript with the updates from the form values. Basically instantaneous.

> a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies... > ... > b) the 300 tracking scripts every site has to try to squeeze as much revenue as possible

Having seen the dynamics up close, I'd say it's far closer to the truth to say that the reason developers don't have time for a) is because they are having to spend all their time on things like b). I've not met a developer who doesn't want to build a better experience. I have met many developers who can't do so, for reasons outside their control.

Characterising it as "if the developer cares" puts the blame in entirely the wrong place.

I would go farther and say it's not even a lack of "optimization", it's a bloat of spaghetti logic that no sane person would ever write, driven by teams that don't talk to each other and are constantly pushed by stakeholders to add more layers instead of cleaning anything up

It has nothing to do with the frameworks. Except maybe that they empowered developers, including the ones cranking out bad code

> developers don't taking any time to optimize, lazy load, cache, minimize dependencies...

I built much more performant apps without lazy loading or caching when using html and a sprinkle of JS.

> the 300 tracking scripts every site has to try to squeeze as much revenue as possible

Just the other day I was appalled by a new record, 1604.

I'm increasingly of the opinion this stuff needs to just be banned outright by law. None of the businesses I've talked to seem to be aware of how dishonest it looks to say "we value your privacy" while trying to get users to agree to get more companies than there were pupils in my secondary school to analyse them.

>the 300 tracking scripts every site has to try to squeeze as much revenue as possible

Let's say tracking for revenue is required and not an argument to be made. The question I never quite understand is why cant we have ONE scripts to rule them all? I remember there was a company / services that may be called Segment? And quick google search doesn't have anything familiar, that offers something like that.

Yeah, I think both these are true:

1. React is bigger and slower than it needs to be. There are likely better choices today. 2. Most websites will be bigger and slower than they need to be due to the endless September of new devs, and the rarity of being given space to focus on size/performance. As React is popular, it means even if React was tiny and fast, these websites would still be slow.

Now test it again on a 5 year old mobile device on a 3g connection with some packet loss, not in the sterile environment that is your office with a last-gen i7 processor.

I know I'm weird because I grew up in the 90s, but 2 MB of JS to show a dashboard with widgets still doesn't quite compute in my brain.

Transfer's only part of the story (and 2MB is a ton on anything but a great connection)—the rest is memory use, which will tend to be some multiple of the transfer size, plus whatever your code initializes, and processor cycles.

Well most stuff going wrong in apps is actually managements fault. At least in my experience. Either directly or hidden in their decision making.

Not every page or app needs framework. But building complex app without one would be very hard and time consuming, and your team would need to come up with ways to solve problems like architecture, code structure, routing, data management, state management, etc. So you would basically reinvent all the wheels on your own cost, and you will have a non standard solution, that would not be compatible with libraries out there (for example UI components) and neither with new devs. Before Angular and React came I was building apps with plain JS with jQuery (not a framework, just a lib) and I would never go back there.

I agree. In a recent small project, I ran an experiment: first, I built the app in React, then in Vue, and finally in vanilla JS. In the end, I stuck with the vanilla JS version because it was significantly smaller, easier to deploy, and much simpler to maintain long-term.

As someone who's worked on web apps with and without frameworks, yes, we need frameworks, especially if it's a large one or if there's a team of more than a few people involved.

The good ones these days like Vue or especially Svelte are barely any different to how you'd do things the "vanilla" way except they provide some sane QoL features like components (anyone who says web components are the answer has very obviously never used web components) and sane data flow management to and from said components.

I mean, more power to you if you want to handle complex states without the features a lib like Vue or Svelte provide you, but in my experience you eventually end up with a homecooked framework anyways, even for apps that aren't that complex. And at that point you're just doing React or Angular or Vue, but worse in every conceivable way. Yay for going at it vanilla, I guess?

> The real question is, do we actually need "frameworks"?

Yes. The advantage of having a common API across thousands of web apps shouldn't be a point of discussion.

I worked at a startup where one of the original devs had “strong opinions” on JavaScript frameworks. “It’s all bloat!!! We don’t need that crap”. So consequently all the new engineers had to learn this dude’s codebase, which turned into to be… A framework! Only instead of a documented one that had plenty of support it was an unholy mess that required extra time to build all the stuff missing from the it’s-not-a-bloated-framework-but-pure-JavaScript-framework.

Guess what happened the day after the dude left the company? All the engineers immediately started to replace the unholy mess of “totally not a framework” framework with an actual one.

Guess what happened to development productivity and product quality? They went up dramatically.

Author here: You’re right that Nue shines for simpler sites—like marketing pages, blog, and documentation. But calling it just a static site generator misses the mark. This latest release (check mpa.nuejs.org/app/?rust) handles a Rust-powered SPA with event sourcing over 150k records—far beyond ‘simple.’ For state-driven apps, Nue’s model-first approach keeps things clean and scalable—limitations are there, sure, but they’re not the foot-shooter you might think. Right tool, right job—totally agree—just saying Nue’s toolbox is bigger than it looks!

> So a solution should probably be done in software

In Chrome you can simulate a slow connection on a slow device via the dev tools. Firefox has a similar feature.

It's not entirely what you're suggesting (which is sort of like Chaos Monkey but for web apps I guess?)

Some frameworks though make it easy to fall into a good default, and others don't.

Thanks for the take—glad you think the project’s cool. I get where you’re coming from: React’s a rendering layer for folks who want control, while Nue’s tackling a broader scope, closer to Vue/Astro/Next combo. The ‘takedown’ vibe isn’t the goal, though—more like highlighting how web standards can slash bloat across the board, even for something as ‘simple’ as a button. Nue’s not here to just beat React at rendering; it’s rethinking the whole stack to avoid needing so many layers in the first place. Fair point on use cases—definitely food for thought as we push forward

fwiw, I did not have the same take away as you from that part of the comment. I think the intent, and the way I read it, was, "Even when eliminating bandwidth and latency as a factor it still takes 10 seconds to load."

"Instant" can mean different things to different people.

I have an HTMX/Flask/Bootstrap app that feels instant for most requests on the LAN, except when it doesn't.

Often React apps are pretty snappy, but if you want to do complex data validation on controlled forms, where the state updates for every keystroke, it can drag you down. There are good frameworks for doing uncontrolled forms in a disciplined way

https://react-hook-form.com/

but it's another thing to add to your bundle. React is also not fast enough to do animations so you have a lot of .show/.hide (or display: none) CSS has facilities to do transitions and animations that are pretty good but I always find it a little nervewracking for a JS application to have state in React state variables and any other kind of state. Some ImGUI frameworks have components that look superficially like React components but are fast enough to animate every frame, which makes me feel like I am in control and get the animation to look exactly what I want.

We also created fixi, which is sort of preact to htmx’s react:

https://github.com/bigskysoftware/fixi

a goal of fixi is to be smaller uncompressed than preact is compressed, to force us to be minimalist

> ... slapping TypeScript on everything—even CSS—which is overkill

Yikes, this framework will never fare well in any decent sized or above project.

Even Typescript is problematic sometimes, as it has several forms of coercion.

I manage 2 large scale production apps using Typescript (Along with the rest of the infrastructure) with a small team.

This simply would not be possible, had I not been guaranteed that things at least type check when reading diffs from PRs.

This seems incredibly shortsighted. If you're building an application by yourself you're gonna remember the relations and dependencies - but even on a small team (say ~4 devs) or even if you don't pick it up after a while, there is going to be stuff you forget.

It's also nice when you move stuff around, you can rely on the LSP to rename and fix everything that breaks. If you have a simple website it's fine, but when you start to have multiple components... Losing typing is a huge deal.

Having the author come out and say that being untyped is a feature, is definitely one way to kill of any potential interest for that framework.

Personally, I consider it a strike against a frontend framework if I can't type check my templates. They're entirely data-driven — exactly the kind of place where type checking is the least effort but still a a big help.

In any nontrivial project, templates become a large fraction of my LOC, and it's already challenging to confirm they work right and don't break. Type checking that I'm passing in the data they expect, and that they're reading valid properties, is a cheap way to get a big win.

Web standards are great, but I'm not sure what "heavy lifting" they do that would make me feel like type checking was unnecessary.

I am not on the React bandwagon, currently using HTMX

But I would very much prefer to see TypeScript in a framework. Optional TS is ok but "untyped by design" feels like an anti-pattern, even HTMX has TS types available.

> React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill

"We don't use Typescript because there are people that exist who use it for CSS when using React" is one hell of an argument that makes absolutely zero sense.

I probably have nearly the exact opposite opinion of where static typing is the most beneficial. I think it’s precisely at the UI rendering layer, because that tends to be where you’re dealing with the data types with the largest number of properties, deep nesting, etc.

I pretty much enjoy using MaterialUI with React (MUI) and have statically typed CSS: `<Stack sx={{ alignItems: "center"}}></Stack>` - I get full IntelliSense/autocompletion for the sx props (i.e. alignItems when typing 'al') and their value (i.e. 'center' when typing 'c') etc. Sx-props are composable, so you can centralize common used sx/css etc.

Any typos or invalid props/value will result in a compiler error.

I agree with most other commenters: Type safety is a great feature to have. And to intentionally dismiss it or only grant it to certain aspects of the application (where does business logic start and end anyway?) is a really bad sign for me.

how can "not typed" be "by design" and presented to us as a feature. Your project looked interesting but your presentation here makes me have big doubts

I worked with react before typescript, react with flow, angular 1 (large projects), and these days I mostly use react with typescript.

I don’t use it for css, but for the view components and code I find typescript actually makes me both faster and my code is more reliable. To me this is one of the killer features of react that other libraries are in various stages of catching up to: full static type checking end to end. (Also through the API to the backend with a little more work).

That's one way to find a niche audience.

Typed JSX is one of the handful of key innovations that made React successful, IMO. I think you need to really understand what you're replacing before you can replace it.

> slapping TypeScript on everything—even CSS—which is overkill

Nope. Hard disagree. I want the developer experience of autocompletion of CSS variables, and I want build errors when someone makes a mistake.

Type everything.

Frankly that's a good reason to never give Nue serious consideration. It's all fine when you're building small apps one view at a time. When you have an application with hundreds of views and you need to refactor, that's when you need the types, otherwise you'll never see the tail end of oh we missed that this needed to be renamed there too.

I honestly can't see what's wrong with using TypeScript anywhere in place of JavaScript. Unless you're making a simple script or a throwaway prototype, then you're pretty much always better off with it. It's invaluable during development and it's compiled away at build time.

Uh oh, you've summoned the typesetters

Nothing in your view is "web standards". And nothing in web standards can do the heavy lifting of showing things like "`nam` is not defined on object `user`"

At that point, why not just use vanilla JS and no framework? Literally zero build time and zero bytes of framework code. And it's fast as hell.

Jesus, this is a regression not a feature, for christ sake. Typed CSS via emotion/styled-components is an amazing feature to call it overkill. This alone is enough to dismiss nue.

Last time, I promise: please, PLEASE don't use ChatGPT (or others) on us. It's _extremely_ obvious, and it takes away 90% of your credibility. I'd much rather read a bit of broken English than read this kind of slop. It's a huge reason why I can't take this seriously.

ALL your docs are chatgpt. All of them. All your issues. Your comments here. Are you even real? Yes? Then TALK to us.

/rant.

There’s a lot of negativity around this so I just thought I’d chip in and mention my appreciation for it. Projects are allowed to not be typescript, and I actively stay away from it as much as possible when working with browsers.

I don’t work in TypeScript, I don’t write in typescript, and I (along with everyone) don’t deploy typescript. I have multiple different build processes in my project to remove different types from different dependencies that are incompatible with one another just to untype them.

So personally I find standard js a huge selling point :)

Vue with SFCs is not actually typescript because typescript can not parse the SFC syntax, you need a forked typescript called `vue-tsc` for that.

Shows what a hack vue really is.

Only since Vue 3 though, and the types are still not as good as React.

I mean a rapidly changing front end codebase is always going to be entangled mess no matter if it’s react, plain JavaScript or even “native app code”. Front ends are where the rubber meets the road and have to deal with fuzzy weird human shit and miles of edge cases. That is just the nature of the beast.

Even if you attempt to tame it and make “the prefect codebase” it’s still gonna be a mess.

If anything React and typescript help it from being an even larger mess full of homegrown idioms that are normally baked into the framework.

There is no such thing as not using a framework. You either pick an existing one or build your own. Very often the sensible choice is to pick an existing one.

No, the support is quit limited not as many features are supported.

Trust me, the function based components are way too simpler. Just a function that returns HTML. That's it. compose your UI as those functions. These functions can take arguments to customise their output (rendered HTML) as arguments (called props) or can call special functions from React (called hooks) such as asking the React to "remember" a value for you (state) or cache something for you (useMemo) so as to not compute it every time or trigger rendering if value of certain variables change (useEffect) or at the component start (useEffect with no dependencies mentioned) and that's all the React that you need to know for I would say your 95% of the needs.

React compiler (already used for Facebook and Instragram code base) further renders the use of certain hooks unncessary thus making React a lot more simpler.

Hooks require less boilerplate to set up and reuse stateful logic across components

If you havent watched it yet, the talk that introduced hooks explains much better than I can: https://youtu.be/dpw9EHDh2bM

Spreading arrays and objects is such a common performance hit. It works fine for small instances but falls over in large instances.

Here's the JS CRM engine https://github.com/nuejs/nue/blob/master/packages/examples/s...

I see a number of issues, but don't have time to look into them.

1. Spreading when you probably don't need a copy: sortEntries. Sorting is probably where the overflow happens. Just sort in place or use Array.from or slice.

2. Excessive use of array functions. In my experience, a C style for loop performs better when you need performance. Create an empty array before, perform your business logic inside the block, and push to the array.

3. I don't know how filter is called, but it potentially loops through all of the events three times in the worst case.

4. paginate manually creates a JSON string from the returned entries. I don't know why, it seems inefficient.

100% agree, I felt very put off by the tone, I think HTMX pull it off by not taking itself too seriously and also having good insights.

I wish the homepage talked more about how nue approach the problems rather than how better than other framework it is.

I think you're right on the marketing. I'll tone down.

The comparison uses the non-wasm version at mpa.nuejs.org

With SPA, all your backend has to do is spit out data and sometimes validate it, leaving your front-end completely in charge of presentation and user interaction. You can even have completely separate teams working on it. It feels a lot less complicated than the alternative.

SPAs are great for the hordes of B2B SaaS apps out there, which for the most part are just some fancy variants of a table. They're not a Photoshop, but they're still highly interactive.

If you look at the documentation at nuejs.org/docs, you'll see how Nue is really more about apps that focus on content rather than single-page apps (SPAs). However, this release is all about SPAs.

I recently thought about just using ASP.NET MVC with Razor pages for a quite simple app at work. But I'm already familiar with SPAs, so with that background I chose to "just use Vue as always (or Solid or Svelte, I like all three of them)" as SPAs have some advantages, e.g. separation of concerns, easier integration of libs like agGrid or eCharts.

Without that knowledge, I agree that good old SSR (MPA) is easier and more maintainable. And more robust.

IMO, most SPAs are bloated. MPAs are cleaner and more forgiving.

The only reason to still stick to an SPA instead of an MPA is that the app is so bloated you want the user to only have to load it once.

And people say "lazy loading!" but by the time you've implemented lazy loading in a SPA, you could have just used an MPA to keep things modular and memory efficient.

SPAs became popular at a time when companies thought everyone was going to move to progressive web apps. Then the bloated frameworks came along, PWA interest has faded, and here we are.

The above are all my opinions, apologize in advance if they come off as speaking objectively.

Both way can work fine, enough great examples out there. The real problem is, imho, we shouldn't need a (graphical) UI at all. That's where all this discussion comes from. When the whole "frontend" disappears in a year or 10, it will make a lot more sense.

This happened to a team I know. They built a flashy SPA dashboard because it was easy to copy-paste from templates. It worked great—until a real-world requirement, like a data grid, came along.

There's a crossover with crossplatform apps (like React Native), which is a force multiplier for some applications / orgs / etc.

Not the discussion, but SPAs are fundamentally safer against XSS, in the sense that data and code have different paths.

There is no such things as a true apples to apples comparison for libraries such as this. They all cherry pick something and ignore a ton of things such as:

  - accessibility
  - amount of libraries with plug-and-play solutions to common problems
  - security
  - scalability
  - rendering performance
  - maintainability
  - browser support
  - browser extension interference
  - hundreds of other niche edge-cases that someone will eventually run into but are non-obvious until it's widely used

  - htmx    = 14k as min.gz
  - solidjs = 7kb as min.gz

Is there a full-blown SPA demo made with htmx?

Because Vite emphasizes "Optimized build" in their marketing

Yes. React runtime included. Benchmark and details here: https://nuejs.org/docs/react-button-vs-nue.html

All I am saying is that being lightweight, when you have been around for less time than a mature solution, is a mute point.

It's a cop out way to differentiate because you are clearly not comparing apples to apples.

You have a fraction of the features and a fraction of the bug fixes. You are trying to make it sound like you are a 1:1 replacement, when you are not.

JS frameworks have often valued DX first over what it outputs. Frontend devs also frequently care more about a) their own tooling and b) how it looks, to a much higher priority than the performance and stability of their output. At least from my own experience in the community :)

Those points are only true if you're comparing to a React app that uses bloated frameworks and inefficient list manipulation (as other commenters pointed out, `list.push(...items)` causes problems)

Can you give some examples of some of these standards that make Nue stand out and other frameworks don't use? It seems that if other frameworks make use of these standards we would get a similar performance boost across the ecosystem.

Mention that you know you are missing dozens of features instead of blaming it on “web standards” would definitely help frame it better. Do you think Vite doesn’t know about web standards? It reads pretty naively.

Also I recommend just not making a web framework. There are many of them, some very similar to Nue. Your effort could be placed on improving what is out there. I suspect that is a lot harder and less fun than just making something new. But if you manage to contribute then you’ll be helping an entire community of people whereas a new web framework will likely see almost no adoption before it is abandoned.

It's like someone making a hello world in C using the std, then one hand crafting the console print but losing literally everything else. Of course, if my goal was to just write hello world then it would make sense but 99.9% of people in the world will use something else, invalidating the point.

Maybe don't compare apples to oranges at all. No one is using react for a single button.

Now do macOS Safari......

How is the SPA less than the button?

Is there any documentation about them?

For example what is this 200kb binary for?

https://github.com/nuejs/nue/blob/master/packages/examples/s...

Rendering and loading an entire new page just to open a dialog seems pretty unnecessary to me.

I know a guy whose middle name is "Almighty God".

I've actually wondered how that looks on a resume :D

it is time for a comeback

The new wording is much more nuanced, appreciated! Also the fact that you link to the actual code that broke down, making it possible to verify the claim. Less ammunition for the people who actually are skeptical of the project instead of just nitpicky like me ;)

Speaking of the code in question, it looks pretty sensible - there's a bit of low-hanging fruit where one could avoid creating redundant arrays by turning chained calls to map and filter into one for-loop and such, but that's about it.

What confuses me is that there's no point in the code where I see any recursion, here or in the other JS files that seem relevant, so how does one end up with a call stack overflow?

(not questioning that it crashed for you, it's just that I don't see any obvious flaws in the implementation, so I'm curious to lean what the "gotcha" is in case I ever bump into something like it myself)

What does event sourcing have to do with searching or "instant keypresses"? It's a storage pattern for recording events, not a way to search.

Like, you're searching a single table for text messages, not a stream of events.

It’s human failure 100%. Big frameworks just lower the baseline such that this failure becomes more acceptable, less immediately aware, and masks candidate selection.

If you want to achieve something smaller or faster you have to measure for it. Odds are if you cannot execute without a big framework telling you how to proceed you will not be able to measure it either way.

Yes. On that version, Chrome 134.0.6998.89's devtools on my Macbook (M2 Max) are indicating 100 to 250 millisecond interaction times and a 160 ms frame when entering text into the search field.

Loading the page on Fast 4G connection takes 9,61 seconds before I see _any_ content on the screen. This is loading the "all contacts" page that shows 12 items with a title, excerpt, time stamp and user name. Is this expected performance? Network shows the app downloading huge 4/1 megabyte chunks.

Absolutely, it would be nice if we found the right abstraction to get rid of that part as well. Basically every non-React framework's answer to that is Signals (aka change tracking), where React is doubling down on unidirectional data flow and thus dependency arrays. React Compiler indeed solves the 99% of performance related memo-s.

For effects you still will have to understand the mental model (which I'd argue is inherent in the domain and not incidental to the tech).

From reading Nue's docs on Interactivity, it seems to opt-out of the discussion by going back to good old manual UI refreshs. I personally would not choose that, too many pre-React debugging nights spent on chasing state<->UI desynchronization bugs.

All of them? It should feel instant. A UI does not benefit from artificial delays.

The videos. The very first video. Animations like this are done to hide the fact it’s slow by hiding it behind a fancy animation. Used to do this when we were stuck on 3g connections…

Fade in/out animation.

This refers more to tracking, not security directly, though I suppose there is some overlap

This is also doesn't explain why the browser would constantly need to redownload the same files assuming the original requester was the same.

The browser could also introduce an ersatz delay to throw off the tracking.

Here's the react-table example app with 112,500 records, just like your example. I am not really seeing much of a performance difference (and this is in dev mode - it would be faster if built for production):

https://n9vr4n-5173.csb.app/

it doesn't make sense.

I would love to check out the bundle size! Will you ever create a fair comparison, where your Nue implementation has all the same features as the versions you compare it to? All the comparisons I've seen so far are deceitful since they implement much less. If Nue actually produces smaller bundles, why not create an actually fair comparison?

A Vite button? You mean Vue? Vite is just a bundler lol.

Also, would like to see some comparisons to Preact, as that's an (almost) drop-in replacement for React with SUPER small bundles. I'd be impressed if you manage to beat that.

Make a demo with react-virtualized[0] and see if it crashes. Hint: It will not[1]. React can easily render 1 million rows with high performance without relying on WASM [2]

Here is the demo of react-virtualized[3], in which I entered 10m as the row count and scrolled to the bottom without crashing.

[0] https://github.com/bvaughn/react-virtualized

[1] https://www.youtube.com/watch?v=1JoEuJQIJbs

[2] https://medium.com/@priyankadaida/how-to-render-a-million-ro...

[3] https://bvaughn.github.io/react-virtualized/#/components/Lis...

*Update: Here I made a table with 1 million rows with search, filtering, and pagination. In plain Javascript:

https://htmlpreview.github.io/?https://gist.githubuserconten...

Could you give a code example? Also, by crash, do you mean the mentioned stack overflow error?

If so, why would the stack be involved when talking element count?

No. Back when supporting ie 9 we had tables with a million rows and dozens of columns and it runs fine.