spx
js-framework-benchmark
spx | js-framework-benchmark | |
---|---|---|
1 | 65 | |
40 | 6,548 | |
- | - | |
9.3 | 9.8 | |
about 1 month ago | 8 days ago | |
TypeScript | JavaScript | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
spx
-
A Real World React – Htmx Port
I do indeed. The project is called SPX (Single Page XHR) which is a play on the SPA (Single Page Application) naming convention. The latest build is available on the feature branch: https://github.com/panoply/spx/tree/feature - You can also consume it via NPM: pnpm add spx (or whichever package manager you choose) - If you are working with Stimulus, than SPX can be used instead of Turbo and is actually where you'd get the best results, as Stimulus does a wonderful job of controlling DOM state logic, whereas SPX does a great job of dealing with navigation.
I developed it to scratch an itch I was having with alternatives (like Turbo) that despite being great are leveraging a class based design pattern (which I don't really like) and others which are similar were either doing too much or too little. Turbo (for example) fell short in the areas pertaining to prefetch capabilities and this is the one thing I really felt needed to be explored. The cool thing with SPX which I was able to achieve was the prefetching aspect and I was surprised no-one had ever really tried it or if they did the architecture around it seemed to be lacking or just conflicting to some degree.
A visitors intent is typically predictable (to an extent) and as such executing fetches over the wire and from here storing the response DOM string in a boring old object with UUID references is rather powerful. SPX does this really efficiently and fragment swaps are a really fast operation. Proximity prefetches are super cool but also equally as powerful are the intersection prefetches that can be used. If you are leveraging hover prefetches you can control the threshold (ie: prefetch triggers only after x time) and in situations where a prefetch is in transit the module is smart enough to reason with the queue and prioritise the most important request, abort any others allowing a visit to proceed un-interruped or blocking.
In addition to prefetching, the module provides various other helpful methods, event listeners and general utilities for interfacing with store. All functionality can be controlled via attribute annotation with extendability for doing things like hydrating a page with newer version that requires server side logic and from here executing targeted replacements of certain nodes that need changing.
Documentation is very much unfinished (I am still working on that aspect) the link in readme will send you to WIP docs but if you feel adventurous, hopefully it will be enough. The project is well typed, rather small (8kb gzip) and it is easy enough to navigate around in terms of exploring the source and how everything works.
Apologise for this novel. I suppose I get a little excited talking about the project.
js-framework-benchmark
-
Popularity is not Efficiency: Solid.js vs React.js
JavaScript benchmarks are instruments for measuring the speed and effectiveness with which a JavaScript engine—such as the ones found in web browsers—can complete particular tasks. Benchmarks are used by developers and browser vendors to evaluate various engines, find places in the code where improvements are needed, and make sure JavaScript standards are being followed.
-
Use any web browser as GUI, with Zig in the back end and HTML5 in the front end
Strange then that frameworks advertise how fast they are at rendering, mutating, and creating objects in the DOM, and one of the main JS benchmarks everyone likes to measure their performance by is literally a benchmark about DOM manipulation: https://github.com/krausest/js-framework-benchmark
Oh wait. It's not strange. Because state manipulation is a largely solved problem, and even the least performant state manipulation is blazingly fast. However, presenting components in the browser's DOM is tens of magnitudes of orders less performant than anything you can throw at state manipulation.
And every single framework is busy solving one single problem: how do we touch the DOM as little as possible?
- JavaScript-Framework-Benchmark
- GitHub - krausest/js-framework-benchmark: A comparison of the performance of a few popular javascript frameworks
- JavaScript Framework Benchmark
- Vue 3 now outperforms Svelte and React
-
Vue 3 is currently performing better than Svelte and React
It literally says at the bottom "Data from https://krausest.github.io/js-framework-benchmark/"
- Cample.js benchmark reactivity without VDOM
- Rust é uma linguagem que embora tenha uma curva de conhecimento considerável, entrega vários benefícios como segurança e produtividade, reduzindo consideravelmente a verbosidade
-
Imperative - 1.5kb React alternative using Generators
The standard benchmark for js frameworks would be best: https://github.com/krausest/js-framework-benchmark
What are some alternatives?
hyperview - Server-driven mobile apps with React Native
mikado - Mikado is the webs fastest template library for building user interfaces.
hieros - Egyptian hieroglyps and Eurasian languages
sycamore - A library for creating reactive web apps in Rust and WebAssembly
pjax-api - The advanced PJAX superior to SPA.
yew - Rust / Wasm framework for creating reliable and efficient web applications
htmx - </> htmx - high power tools for HTML
imba - 🐤 The friendly full-stack language
solid - A declarative, efficient, and flexible JavaScript library for building user interfaces.
Svelte - Cybernetically enhanced web apps
solid-heroicons
solid - A declarative, efficient, and flexible JavaScript library for building user interfaces. [Moved to: https://github.com/solidui/solid]