The exact error is "Maximum call stack size exceeded" when the WASM- engine is replaced with this JS engine:
https://github.com/nuejs/nue/blob/master/packages/examples/s...
There is currently no demo about the crash, but you can setup this locally.
`events.push(...arr)` puts all arguments on the call stack before calling the method, which causes the error. Don't push tens of thousands of items at once.
If you're architecture is based on event sourcing, this is kind of the point
It has nothing to do with architecture, but rather understanding how the DOM works. The DOM is notoriously slow, so you should never render a huge number of rows at once. You can render millions of rows in plain JavaScript without impacting performance.
Here, I have recreated your JS example with searching and filtering and it does not crash. It's trivial to reuse a similar approach with the real backend and real events from the event source.
https://htmlpreview.github.io/?https://gist.githubuserconten...
*Update: Here is 1 million rows table with search, filtering and pagination. In plain Javascript:
https://htmlpreview.github.io/?https://gist.githubuserconten...
The point should not be using the spread operator at all costs. There are other ways in javascript to push multiple elements in an array that are more efficient than the spread operator.
The fact you didn't even stop to wonder why the error was a stack overflow when you weren't using recursive functions is also telling.
You're solving a problem nobody has. If you encounter this problem, you shouldn't think "ah, let's yeet the JS engine because it clearly isn't good enough for my awesome SPA", you should think "hm, maybe I shouldn't render 10000000000 records in the DOM".
What's next? "Oh I have a memory leak, let's get a subscription on RAM modules and just keep adding them!"