kwasm VS ag-Grid

Where we will go from here, is pretty obvious.

Now that we've realized SSRs cannot be an optional afterthought, we'll soon realize SSRs with running JS on the server is a nightmare to scale - https://engineeringblog.yelp.com/2022/02/server-side-renderi...

Just search HN for "scaling server side rendering" and you'll land on a bunch of practical complications.

That doesn't mean SSR is bad. It just means we know the solution but stuck with the wrong tools.

My hypothesis is that we'll capitalize WebAssembly to run our UI rendering logic and a tiny platform-specific rendering layer to translate rendering commands from WASM to platform. Interesting side-benefit: Language choices other than Javascript.

I've already started working on a proof-of-concept React-ish library that runs on a WASM VM. IT lets you specify your UI component declaration and behaviour in Kotlin - https://github.com/joelewis/kwasm

3. A platform specific embedder can then write a tiny layer of renderer that translates commands from the WebAssmelby VM into native UI updates.

This way we can liberate UI programming from being too close to a platform and possibly could run on servers (damn fast SSR)

I'm attempting a proof of concept and I've logged my thoughts as I'm working through the project - https://github.com/joelewis/kwasm/blob/master/notes.txt

In this post I’ll show you how, using the AG Grid component and Ably Spaces, you can create a React application that allows users to see not only who else is currently viewing the grid, but using a Flowbite Avatar Stack component, what row each user currently has selected.

something like ag-grid? https://github.com/ag-grid/ag-grid

I personally use https://www.ag-grid.com/ for all my data grid needs. It has a free community version (that should get you covered imo) as well as a paid one with advanced features.

To be fair, in any GUI toolkit, the "table" is abolutely the most complex general purpose widget. People really under estimate the difficult of an efficient implementation. Qt spents YEARS improving their QTableWidget class. The implementation is mind-bogglingly complex. I am sure many very smart summer interns (PhDs!) have tried to tweak that class to squeeze every bit of performance possible. The table class in GTK+ and MSFT DotNet's WPF are equally, freakishly insane.

Consider this idea: Most people who use a table class in a GUI framework assume it is essentially infinitely scalable (myself included!). I am talking about millions of rows or thousands of columns with all kinds of silly widgets injected into individual cells. It is a crazy hard computer science problem to solve. I would not doubt there are many PhD thesises written on the topic of fast, scalable table widgets.

Beyond desktop GUI toolkits, people have tried to do the same in a browser (HTML/CSS/JS). Have you seen AG-Grid? Woah, it is unbelievable how much goddamn data you can squeeze into that widget. Most Wall Streets web-based trading apps use it one way or another. It's just so hard to beat. Ref: https://www.ag-grid.com/ There must be 1,000 person years of optimisation sunk into that implementation.