React components might eventually be removed in favor of making the templating system as fast and as elegant as possible but for the time being they provide flexibility.
> Also exhibits the curious quality of being faster than over a decade of engineering at Facebook in some cases
Vertex is faster in 2 tests (12% and 32%), and slower in 2 other tests (149% and 200%). Very curious wording on the OP when react is an order of magnitude faster than vertex in some cases.
1kloc is a bit abstract ; it seems you are in a great position to give a true bundled weight ; preact is about 3kb which is my fav for years - good job for the effort and results !
The library is actually ~1400 lines of code, and 51KB in size. Not very slim by JS framework standards, so focusing on that for the headline feels misleading.
We could remove 3kb by removing the router but that's not gonna happen.
You're more than welcome to minify+brotli it yourself if you use vertex.js in production.
A bit surprised to see a new framework boasting to ship as UMD. Are developers still using commonjs? I'm sure some continue to CDN inject libraries. But even then ESM is well supported.
Yes, and every other flavor too. "Developers" isn't a single hive-mind entity, and there are many different purposes for javascript, and many different kinds of systems where javascript can be used.
ES6 modules. Tooling can take care of generating UMD from that as a single source of truth and since it’s the language standard for years now it’s the best supported format in the ecosystem. At this point UMD/CommonJS/etc are historical artifacts only useful to legacy codebases and by now they’ve all adopted whatever ESM->legacy compilation pipeline they need.
Courier New is a bad font that no one should choose to use. In typical font-weight terms, where Regular should be 400, it’s 200–250, because it was improperly digitised, not taking ink bleed into account. Windows put some hacks into ClearType to make it render a little less badly, but they’re not dependable these days.
(“Courier”, as provided by macOS, is fine. But Courier New is irredeemably bad.)
Concerning font-family declarations, if you’re doing something like `"Courier New", Courier, monospace`—please just write `monospace`.
It renders terribly on sizes below ~14px, even on a Retina display. No anti-aliasing setting can save it.
A modern typeface like IBM Plex Mono [1] or Office Code Pro [2] that offers more weights and can still render nicely at 10px size would be a better choice, maintaining the same aesthetic.
Beauty /is/ in the eye of the beholder. The rationale /here/ is that the more text in a page the more code you'll fit in your head the more you'll get done, the more confidence you'll have and again the more you'll achieve.
The predominant monitor in existence is your average 24" 1080p monitor, sat at, on average, 32" away from the head. The average person has worse than 20/20 vision.
You must test your website in such conditions and make sure it is readable, and also make sure it meets at minimum WCAG A, but preferably the whole way to AAA if possible.
Thank you but the predominant monitor's probably a smartphone. The average professional is probably using a 4k monitor at the moment.
Everything in the free documentation I've provided you out of my own time and money that you're referring to exists in relation to the other elements in that page, so to get the experience you're after simply ctrl+scroll and change the CSS zoom level like the riot at parties that you could be or catch up with circa 2013-2014 and invest in a 4k display please.
"Zoom in" or "buy a different monitor" is not an appropriate response to people bringing up the plethora of objective & subjective a11y issues on the page.
If you really don't care about providing an accessible experience, try this: no one will use the tool if they can't read the docs. With my monitor and eyesight, it's entirely illegible.
read the rest of the author's responses here. Everything comes across as very defensive and "take it or leave it". OK, you're the one trying to get me to adopt yet another SPA framework in 2026 so I guess I'll leave it.
Huh, interesting... why have both React components and Mustache-style templates in the same framework? They perform the same function?
What's the use case for mixing them?
React components might eventually be removed in favor of making the templating system as fast and as elegant as possible but for the time being they provide flexibility.
You can read https://lukeb42.github.io/vertex-interop.html for more info.
> Also exhibits the curious quality of being faster than over a decade of engineering at Facebook in some cases
Vertex is faster in 2 tests (12% and 32%), and slower in 2 other tests (149% and 200%). Very curious wording on the OP when react is an order of magnitude faster than vertex in some cases.
1kloc is a bit abstract ; it seems you are in a great position to give a true bundled weight ; preact is about 3kb which is my fav for years - good job for the effort and results !
The library is actually ~1400 lines of code, and 51KB in size. Not very slim by JS framework standards, so focusing on that for the headline feels misleading.
9kb (minifier+brotli)
We could remove 3kb by removing the router but that's not gonna happen. You're more than welcome to minify+brotli it yourself if you use vertex.js in production.
A bit surprised to see a new framework boasting to ship as UMD. Are developers still using commonjs? I'm sure some continue to CDN inject libraries. But even then ESM is well supported.
>Are developers still using commonjs?
Yes, and every other flavor too. "Developers" isn't a single hive-mind entity, and there are many different purposes for javascript, and many different kinds of systems where javascript can be used.
Would you prefer to see ESM or neither?
ES6 modules. Tooling can take care of generating UMD from that as a single source of truth and since it’s the language standard for years now it’s the best supported format in the ecosystem. At this point UMD/CommonJS/etc are historical artifacts only useful to legacy codebases and by now they’ve all adopted whatever ESM->legacy compilation pipeline they need.
Annoyingly there's already a framework called Vert.x for JVM but there's also Vert.x Node.js
I was going to say that font is unreadable, but its Courier New.
By my own extensive testing[1], it's optimal at minimum 18px, you're at 13.5px.
[1]: https://github.com/Diablo-D3/dotfiles/blob/master/fontsizes....
Courier New is a bad font that no one should choose to use. In typical font-weight terms, where Regular should be 400, it’s 200–250, because it was improperly digitised, not taking ink bleed into account. Windows put some hacks into ClearType to make it render a little less badly, but they’re not dependable these days.
(“Courier”, as provided by macOS, is fine. But Courier New is irredeemably bad.)
Concerning font-family declarations, if you’re doing something like `"Courier New", Courier, monospace`—please just write `monospace`.
(I’m not going to address the font size.)
It renders terribly on sizes below ~14px, even on a Retina display. No anti-aliasing setting can save it.
A modern typeface like IBM Plex Mono [1] or Office Code Pro [2] that offers more weights and can still render nicely at 10px size would be a better choice, maintaining the same aesthetic.
[1] https://fonts.google.com/specimen/IBM+Plex+Mono
[2] https://open-foundry.com/fonts/office-code-pro
I find it very readable. Macbook Air M2 with chrome set to default 90% zoom.
edit: I just noticed a newer comment from OP saying that changed the font size.
Beauty /is/ in the eye of the beholder. The rationale /here/ is that the more text in a page the more code you'll fit in your head the more you'll get done, the more confidence you'll have and again the more you'll achieve.
OP has a valid point. On my Mac, it's unreadable without zooming in. I immediately left the page.
Thanks for the valuable feedback. I've added a mediaquery for your use case. This should be more legible now: https://lukeb42.github.io/vertex-manual.html
Send me a screenshot via https://catbox.moe if it's unreadable and I'll get this done and dusted before leaving the thread. Thanks.
>> is that the more text in a page the more code you'll fit in your head the more you'll get done
I don't know in what world that makes any sense. Or why someone would want to "fit code" in their head...
Zero code is in your head if you can't read it.
The predominant monitor in existence is your average 24" 1080p monitor, sat at, on average, 32" away from the head. The average person has worse than 20/20 vision.
You must test your website in such conditions and make sure it is readable, and also make sure it meets at minimum WCAG A, but preferably the whole way to AAA if possible.
Thank you but the predominant monitor's probably a smartphone. The average professional is probably using a 4k monitor at the moment.
Everything in the free documentation I've provided you out of my own time and money that you're referring to exists in relation to the other elements in that page, so to get the experience you're after simply ctrl+scroll and change the CSS zoom level like the riot at parties that you could be or catch up with circa 2013-2014 and invest in a 4k display please.
"Zoom in" or "buy a different monitor" is not an appropriate response to people bringing up the plethora of objective & subjective a11y issues on the page.
If you really don't care about providing an accessible experience, try this: no one will use the tool if they can't read the docs. With my monitor and eyesight, it's entirely illegible.
read the rest of the author's responses here. Everything comes across as very defensive and "take it or leave it". OK, you're the one trying to get me to adopt yet another SPA framework in 2026 so I guess I'll leave it.