Our great sponsors
-
voby
Discontinued A high-performance framework with fine-grained observable-based reactivity for building rich applications. [Moved to: https://github.com/vobyjs/voby] (by fabiospampinato)
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
ag-Grid
The best JavaScript Data Table for building Enterprise Applications. Supports React / Angular / Vue / Plain JavaScript.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
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
Actually that's just a common misconception, which I believed too.
The complex compile-time transforms enable almost no performance improvements.
As a proof just take a look at the js-framework-benchmark table [0], my framework (Voby [1]) is faster than both in the framework despite having an API very similar to Solid and no requirement for a Babel transform or other compile-time transform (though the basic React-like JSX transform is supported for convenience).
Those transforms actually exist 99% just for providing some convenience features to the developer. If that weren't the case it would be possible to make something similar without a transform that's faster than both. In fact Svelte is actually quite a bit slower than both Voby and Solid.
[0]: https://krausest.github.io/js-framework-benchmark/current.ht...
[1]: https://github.com/fabiospampinato/voby/
I wandered into the comments to find or write the correct "before times" bit, and I think this covers everything I would've mentioned.
I'll add that looking back, EXT seemed to be a bit ahead of its time. Its data/table view rivals AG Grid [0] of today. If we could've just standardized on a table view by now, but alas.
AG Grid - [Ag Grid, agnostic JS table framework](https://www.ag-grid.com/)
Maybe you will like https://svelte.dev/, I find it more close to good old html. For example, a component that is not interactive is basically an html file with an tag and some html markup.
I'm not sure where you are getting 10,000 dependencies from.
https://www.npmjs.com/package/react
Maybe I'm missing something but npm suggests it's only one dependency, which also only had one dependency.
I get that create_react_app pulls in a ton of dependencies, but React itself is not a culprit of dependency hell.