Move to a better type system #1448
Description
Activity
I am 100% onboard with this. It's past time we get both a better developer experience, and a more solid frontend.
I think the first step towards that goal is to introduce a build + package step, while keeping as much of the code unchanged as possible. Ideally after this first step we should be able to run things like
npm run dev -- examples/official-siteto work on SQLPage with live reload,npm testto run the full test suite (rust + frontend) with unified and minimal reporting (very useful for agents),npm run buildto build everything. Maybe we could switch to a unified tool like https://rsbuild.rs/ which could also replace biome. The goal for this first step would be to improve the build infrastructure, and maybe even to delete more lines of code than we introduce (the build system would what we do manually in build.rs).Then once we have that, open a second pr with the typescript switch, that almost does not touch the build pipeline, just adds annotations to the frontend code. We could even strive to make this a PR with a net negative line count, replacing jsdoc annotations with inline ts annotations.
AI agents can do most of the migration, but from experience, they have a tendency to very quickly overbloat this kind of projects, trying to keep backwards compatibility in places that do not make sense, and ending with overcomplicated designs. If you do it, please keep your agent on a tight leash, maybe even with an explicit goal of ending on a diff that is a net negative line of code count, even if that needs making compromises.
Some ideas for next steps that a good build infrastructure would allow:
- always up to date documentation:
- I'd love our
configuration.mdto move to a page on the official site that is autogenerated from the rust configuration datastructure, so that it's always up to date - documenting components directly from comments at the top of handlebars files instead of inside .sql migrations
- documenting sqlpage functions directly from the rust source code
- writing component examples as .sql files, and automatically turn them into browser tests, with custom assertions
- I'd love our
- producing a JSON Schema for sqlpage.json that's always in sync with the rust code
- formatting and minimizing the builtin .handlebars components. Currently the components include many whitespaces that are useful when developing, but waste network bytes when serving large pages (this one may not be worth it, we would need to measure the actual whitespace footprint after compression first)
- PR previews (rendering the entire documentation site as static pages and serving them on each PR), very useful for frontend PRs
- tracking frontend byte size in tests, so that an innocent looking PR that accidentally introduces a super heavy dependency turns the CI red
- always up to date documentation:
- added sub-issues
on Sep 16, 2026 SQLPage's README says it's Vanilla JavaScript though... which has the lowest weighted geometric mean (lower is better) at the benchmark link below...
https://krausest.github.io/js-framework-benchmark/current.htmlhttps://github.com/sqlpage/SQLPage#contributing says "We welcome contributions! SQLPage is built with Rust and uses vanilla javascript for its frontend parts," to prove the claim above.
The most competitive TypeScript framework on that list then is thane-v0.1.1 (I think it's at https://github.com/timlouw/thane) followed by marko-v6.3.28 (https://github.com/marko-js/marko is much more famous than Thane in GitHub stars and is just .01 higher in the weighted geometric mean). However, the weighted geometric mean is 1.08. Perhaps it is better to ship SQLPage in 2 variants? 1 variant would be for raw closest to 1 weighted geometric mean speeds, while the other variant would be TypeScript-based to gain access to the 2 limitations and 4 benefits listed in the OP's first comment at #1448 (comment)? Additionally, which TypeScript framework, if any, would be best to use for SQLPage? I would assume pure vanilla JS, which I think SQLPage has implemented currently per the README is a 1.00 weighted geometric mean, since vanillajs-lite is 1.01, but I may be wrong.
Another option is to go into JavaScript's Vue ecosystem, another popular JavaScript framework with a 1.13 weighted geometric mean if using vue-jsx-vapor-v3.6.0-beta.17 at https://github.com/krausest/js-framework-benchmark/tree/master/frameworks/keyed/vue-jsx-vapor. However, this isn't native Vue. Native Vue is a 1.30 weighted geometric mean at https://github.com/krausest/js-framework-benchmark/tree/master/frameworks/keyed/vue ("vue-v3.5.39"). The React alternative is at 1.31 weighted geometric mean at https://github.com/preactjs/preact labeled as "preact-classes-v10.29.8" on the benchmark page. But do we even want to branch into any of these framework ecosystems in the first place? Or is SQLPage's sole goal is to just show data from tables to many users as fast as possible?
I will note CTRL+F'ing "React" there isn't quite easy to find the clear native React base as easily as Vue though... even if I inspect element then ctrl+f for "https://react.dev/" or even just "react.dev" I get 0 results apparently. Native React was lasted ranked in 2023 from what I can see at https://krausest.github.io/js-framework-benchmark/2023/table_chrome_119.0.6045.105.html if you CTRL+F "react-v" to see the weighted geometric mean at 1.43. Even then, the swap rows benchmark is quite rough there. CTRL+F for "Angular" is at best 1.54, CTRL+F for "next" is at best 1.43, CTRL+F for "express" doesn't exist in the 152 version of Chrome benchmark or in the "current" link as of September 21, 2026, Ctrl+F for "Svelte" is at 1.17. Perhaps some random blog post of the most famous JavaScript frameworks are not actually a proper measurement of popularity of them at https://blog.nobledesktop.com/popular-javascript-frameworks but I don't know.
Just as another reference point, https://iggy.apache.org/ -> also if you go here apparently Apache Iggy is capable of processing millions of messages per second with ultra-low latency with a ~0.5 ms average write latency. However, the Web UI is built using SvelteKit. Svelte is 1.15 weighted geometric mean at https://krausest.github.io/js-framework-benchmark/current.html or 1.23 for classic. The 1.17 mention in the previous message is me swapping between 152 and "current.html" which is an unknown Chrome version at least shown at the top, but appears to be between (inclusive) 153 and 156 then if different than 152. Maybe this can spark more ideas?
Apache Iggy's repo is at https://github.com/apache/iggy and since it says QUIC is supported in the README, that basically means HTTP/3 and WebTransport may be viable if inspirations from here were to be implemented into SQLPage, no? I made a discussion for the web framework server side here: #1472
I'm not quite sure I understand @bluelightspirit . This issue is related to moving off of JSDoc to TypeScript for better typing on the frontend. Plus with Rolldown (#1458), we still compile TypeScript to JavaScript and serve gzipped results via the Rust backend.
As for the frameworks you mention, I'm not sure if that applies here. SQLPage does not use any frameworks for the frontend and won't need to use any after the migration to TypeScript is done. If we were to move to a framework, my strong preference would be React (now owned by linux foundation) with Base-UI (follows web standards, built on react, and has chart components being built out). But again, we currently don't use any frameworks as front end chart components come from apexcharts.js
I'm not quite sure I understand @bluelightspirit . This issue is related to moving off of JSDoc to TypeScript for better typing on the frontend. Plus with Rolldown (#1458), we still compile TypeScript to JavaScript and serve gzipped results via the Rust backend.
Well, I just mention frameworks of JavaScript and TypeScript since certain ones optimize certain capabilites such as replacing all rows, creating rows, swaping rows, removing rows, and clearing rows found at https://krausest.github.io/js-framework-benchmark/current.html - pure vanilla JavaScript is not a framework so of course it isn't going to be listed. I don't know if any of the lightweight ones may be more suitable for SQLPage or not for speeds.
As for the frameworks you mention, I'm not sure if that applies here. SQLPage does not use any frameworks for the frontend and won't need to use any after the migration to TypeScript is done. If we were to move to a framework, my strong preference would be React (now owned by linux foundation) with Base-UI (follows web standards, built on react, and has chart components being built out). But again, we currently don't use any frameworks as front end chart components come from apexcharts.js
I understand the "need to use any" thing - I just am thinking in terms of raw speeds. I don't know if doohtml or vannilajs-lite or vanillajs-3 or sonnet-v0.0.33 have random extra features that can make SQLPage ever so slightly faster than generic vanilla JavaScript if that makes sense.
thanks for digging into the numbers!
optimize certain capabilites such as replacing all rows, creating rows, swaping rows, removing rows, and clearing rows
so SQLPage never does this on the frontend. that's done on the Rust backend and rendered via handlebar templates. the client only ever sees the streamed HTML
you are right that we still do have JavaScript in the repo, but that's for progressive enhancements like table sorting, filtering, number formatting, maps, toasts, etc.. if your seeing inefficiencies in your testing I would recommend opening an issue downstream in apexcharts.js. I have only sent minor patches to the repo, so I can't really speak to how they internally handle these kinds of things.
- added a sub-issue
on Sep 23, 2026 @bluelightspirit please do not paste llm walls of text here :)
Let's keep the discussion focused on actual issues people have and how to fix them.
Whatever is well conceived is clearly said, and the words to say it flow with ease.
- linked a pull request that will close this issuerefactor(frontend) :: enable `noImplicitAny` #1517
on Oct 1, 2026 - linked a pull request that will close this issuerefactor(chart) :: import and use 3rd party ApexCharts types #1516
on Oct 1, 2026 - linked a pull request that will close this issuefix(frontend) :: remove `any` types from `sqlpage.ts` #1515
on Oct 1, 2026 - linked a pull request that will close this issuerefactor(map) :: import and use 3rd party Leaflet types #1514
on Oct 1, 2026
Currently the front-end is a bunch of JavaScript files typed with JSDoc which has limitations such as ::
@legacytag jsdoc/jsdoc#2139If we switch the frontend over to Typescript, it will cost us a build step but we gain ::