Marvin Hagemeister
@marvinh.dev
I build simple and fast things. Part of Preact team.
Agree, I'm really hoping structs will make it someday to JS too. Might also help a lot in teaching devs to write faster code by default in general.
November 22, 2025 at 3:07 PM
Agree, I'm really hoping structs will make it someday to JS too. Might also help a lot in teaching devs to write faster code by default in general.
This describes it perfectly. When reading these LLM texts I catch myself often thinking: "what are they even trying to say?" 👀
November 21, 2025 at 10:33 AM
This describes it perfectly. When reading these LLM texts I catch myself often thinking: "what are they even trying to say?" 👀
Reposted by Marvin Hagemeister
one downside of LLMs in OSS is _huge_ walls of text in issues, where the text does technically make sense but reads like a student trying to meet a character limit 😅
November 21, 2025 at 9:27 AM
one downside of LLMs in OSS is _huge_ walls of text in issues, where the text does technically make sense but reads like a student trying to meet a character limit 😅
Oh that's a good point! I think this is probably it. I went a bit through their code and had a feeling that it's not a logic bug in the JS
November 21, 2025 at 8:19 AM
Oh that's a good point! I think this is probably it. I went a bit through their code and had a feeling that it's not a logic bug in the JS
My most odd bug report:
Enabling the @vuejs.org devtools extension breaks Strava
github.com/vuejs/devtoo...
Enabling the @vuejs.org devtools extension breaks Strava
github.com/vuejs/devtoo...
Enabling extension breaks strava.com in Firefox · Issue #1008 · vuejs/devtools
This is what https://www.strava.com/dashboard (requires being a member) looks like with the extension being enabled: This is what the same URL looks like when I disable the extension:
github.com
November 20, 2025 at 9:33 PM
My most odd bug report:
Enabling the @vuejs.org devtools extension breaks Strava
github.com/vuejs/devtoo...
Enabling the @vuejs.org devtools extension breaks Strava
github.com/vuejs/devtoo...
I'm a fan of the coordinator/god concept for tooling. I pretty much want nothing more than TS to be mainly a library to pull in where the coordinator thing decides which files to pass to it.
The only thing left to figure out is how can we avoid everyone having to ship their own fork of TS.
The only thing left to figure out is how can we avoid everyone having to ship their own fork of TS.
November 20, 2025 at 9:24 PM
I'm a fan of the coordinator/god concept for tooling. I pretty much want nothing more than TS to be mainly a library to pull in where the coordinator thing decides which files to pass to it.
The only thing left to figure out is how can we avoid everyone having to ship their own fork of TS.
The only thing left to figure out is how can we avoid everyone having to ship their own fork of TS.
Reposted by Marvin Hagemeister
A couple of weeks ago at @perfnow.nl I gave a talk called "Fine-grained everything". It's about @svelte.dev (obviously), and the new frontiers of framework-land, but it's also about some stubborn misconceptions in web performance circles
Gift link: conffab.com/presentation...
Gift link: conffab.com/presentation...
Fine-grained everything
<p>Modern frameworks like Svelte are fast thanks to signal‑based fine‑grained reactivity, but performance is more than 60fps. This talk covers new approaches to build fast, reliable, data‑efficient ap...
conffab.com
November 13, 2025 at 9:03 PM
A couple of weeks ago at @perfnow.nl I gave a talk called "Fine-grained everything". It's about @svelte.dev (obviously), and the new frontiers of framework-land, but it's also about some stubborn misconceptions in web performance circles
Gift link: conffab.com/presentation...
Gift link: conffab.com/presentation...
I like where your head is at. I've been feeling similar. This works really well for leaf components. For business logic I'd still use something like signals, but for leaf components just calling some update function in an imperative way is totally fine imo.
November 13, 2025 at 12:00 PM
I like where your head is at. I've been feeling similar. This works really well for leaf components. For business logic I'd still use something like signals, but for leaf components just calling some update function in an imperative way is totally fine imo.
That kind of stack gets you pretty far. If that's your jam there is nothing stopping you.
November 13, 2025 at 11:59 AM
That kind of stack gets you pretty far. If that's your jam there is nothing stopping you.
- component state always requires to be able to reconstruct component tree
- client needs to be able to ask server for new UI + new data at the same time for on the fly updates
- want to avoid sending html + layout in both HTML + JS as much as possible
- client needs to be able to ask server for new UI + new data at the same time for on the fly updates
- want to avoid sending html + layout in both HTML + JS as much as possible
November 13, 2025 at 9:18 AM
- component state always requires to be able to reconstruct component tree
- client needs to be able to ask server for new UI + new data at the same time for on the fly updates
- want to avoid sending html + layout in both HTML + JS as much as possible
- client needs to be able to ask server for new UI + new data at the same time for on the fly updates
- want to avoid sending html + layout in both HTML + JS as much as possible
I don't have fully formed thoughts yet:
- most sites are still MPA at heart + light interactivity
- Modern CSS replaces a lot of what people use JS for, also popover + invoker commands
- most app state is better in a global store/models like redux -> makes hmr easier too
- most sites are still MPA at heart + light interactivity
- Modern CSS replaces a lot of what people use JS for, also popover + invoker commands
- most app state is better in a global store/models like redux -> makes hmr easier too
November 13, 2025 at 9:18 AM
I don't have fully formed thoughts yet:
- most sites are still MPA at heart + light interactivity
- Modern CSS replaces a lot of what people use JS for, also popover + invoker commands
- most app state is better in a global store/models like redux -> makes hmr easier too
- most sites are still MPA at heart + light interactivity
- Modern CSS replaces a lot of what people use JS for, also popover + invoker commands
- most app state is better in a global store/models like redux -> makes hmr easier too
That's an interesting approach to use tagged values instead of special sigil characters to differentiate binding types! What are the pros and cons you have experienced so far with this approach?
November 13, 2025 at 9:03 AM
That's an interesting approach to use tagged values instead of special sigil characters to differentiate binding types! What are the pros and cons you have experienced so far with this approach?
But data binding and templating are always the missing pieces. Given the current constraints of the platform I find the approach chosen by data-star quite interesting, although I'm not so sure about storing expressions in HTML. But for basic "bind this signal to attr/prop" it seems neat.
November 13, 2025 at 7:29 AM
But data binding and templating are always the missing pieces. Given the current constraints of the platform I find the approach chosen by data-star quite interesting, although I'm not so sure about storing expressions in HTML. But for basic "bind this signal to attr/prop" it seems neat.
I'm mostly interested in the templating and binding aspects. Context and async rendering can always be done on top. I find myself moving away from the classic react component model more into basic model + view, maybe a global store kind of thing. Makes HMR easier to implement too.
November 13, 2025 at 7:26 AM
I'm mostly interested in the templating and binding aspects. Context and async rendering can always be done on top. I find myself moving away from the classic react component model more into basic model + view, maybe a global store kind of thing. Makes HMR easier to implement too.
I like it. I've been eyeing your various DOMTemplate proposals for quite a while. I think it's definitely the right direction for data binding from JS.
November 12, 2025 at 10:06 PM
I like it. I've been eyeing your various DOMTemplate proposals for quite a while. I think it's definitely the right direction for data binding from JS.
Agree, magic at times is great, but there are times when less is more. I feel like we're in a transition phase in the whole web scene where it's a good idea to simplify things.
November 12, 2025 at 8:43 PM
Agree, magic at times is great, but there are times when less is more. I feel like we're in a transition phase in the whole web scene where it's a good idea to simplify things.
I want to explore making frameworks less "framework-y". I'm curious how far you could go in that direction.
I want simpler things and less to worry about.
I want simpler things and less to worry about.
November 12, 2025 at 8:32 PM
I want to explore making frameworks less "framework-y". I'm curious how far you could go in that direction.
I want simpler things and less to worry about.
I want simpler things and less to worry about.
Yeah you can just tell that the folks behind it put a lot of thought into it.
November 12, 2025 at 11:48 AM
Yeah you can just tell that the folks behind it put a lot of thought into it.
I'm totally not the target customer for this, but I keep coming back to this site just to marvel at how quickly it loads: www.mcmaster.com
I wish more sites were like that.
I wish more sites were like that.
November 11, 2025 at 7:58 PM
I'm totally not the target customer for this, but I keep coming back to this site just to marvel at how quickly it loads: www.mcmaster.com
I wish more sites were like that.
I wish more sites were like that.
Reposted by Marvin Hagemeister
Yesterday at TPAC I publicized my draft proposal for adding a declarative templating API to the DOM.
github.com/justinfagnan...
The repo has:
📖 Explainers for the templating API and DOM scheduler API
🏗️ Full prototype implementations
⚗️ a JSX transform
⚛️ a mini React-like framework
github.com/justinfagnan...
The repo has:
📖 Explainers for the templating API and DOM scheduler API
🏗️ Full prototype implementations
⚗️ a JSX transform
⚛️ a mini React-like framework
github.com
November 10, 2025 at 11:04 PM
Yesterday at TPAC I publicized my draft proposal for adding a declarative templating API to the DOM.
github.com/justinfagnan...
The repo has:
📖 Explainers for the templating API and DOM scheduler API
🏗️ Full prototype implementations
⚗️ a JSX transform
⚛️ a mini React-like framework
github.com/justinfagnan...
The repo has:
📖 Explainers for the templating API and DOM scheduler API
🏗️ Full prototype implementations
⚗️ a JSX transform
⚛️ a mini React-like framework
We have so many frameworks because we're trying to optimize for ease of development (locality of behavior), but the underlying platform is optimized for delivery.
November 9, 2025 at 11:30 PM
We have so many frameworks because we're trying to optimize for ease of development (locality of behavior), but the underlying platform is optimized for delivery.
Long overdue! This was super annoying and I could never figure out how to get back to a particular comment on a commit.
❗ Breaking: notifications from @ mentions in commit messages will be removed next month. 👀
https://github.blog/changelog/2025-11-07-removing-notifications-for-mentions-in-commit-messages/
https://github.blog/changelog/2025-11-07-removing-notifications-for-mentions-in-commit-messages/
November 8, 2025 at 8:33 PM
Long overdue! This was super annoying and I could never figure out how to get back to a particular comment on a commit.
Hands down the best SSG and it's rust based. It's ridiculously fast!
Zensical – a modern static site generator.
We're excited to release @zensical.org, our new SSG that is compatible with Material for MkDocs:
– 5x faster rebuilds
– Modern design
– Blazing-fast search
Read the full announcement on our blog:
squidfunk.github.io/mkdocs-mater...
A thread ⬇ 1/7
We're excited to release @zensical.org, our new SSG that is compatible with Material for MkDocs:
– 5x faster rebuilds
– Modern design
– Blazing-fast search
Read the full announcement on our blog:
squidfunk.github.io/mkdocs-mater...
A thread ⬇ 1/7
Zensical - A modern static site generator - Material for MkDocs
We are thrilled to announce Zensical, our next-gen static site generator that addresses and overcomes the technical limitations of MkDocs
squidfunk.github.io
November 6, 2025 at 11:15 AM
Hands down the best SSG and it's rust based. It's ridiculously fast!
Whenever I wrote something clever, it comes back to bite me in the end. Dumb and simple code always wins.
November 3, 2025 at 3:54 PM
Whenever I wrote something clever, it comes back to bite me in the end. Dumb and simple code always wins.
Reposted by Marvin Hagemeister
Neat lil learning from today’s @perfnow.nl (via Umar Hansa):
You can now throttle individual requests in Chrome!
Neat for experimenting with stuff like
- lazy-loading: does the UI look okay if this chunk takes MUCH longer to arrive
- resilience: what happens if this specific CDN is extremely slow
You can now throttle individual requests in Chrome!
Neat for experimenting with stuff like
- lazy-loading: does the UI look okay if this chunk takes MUCH longer to arrive
- resilience: what happens if this specific CDN is extremely slow
October 30, 2025 at 5:29 PM
Neat lil learning from today’s @perfnow.nl (via Umar Hansa):
You can now throttle individual requests in Chrome!
Neat for experimenting with stuff like
- lazy-loading: does the UI look okay if this chunk takes MUCH longer to arrive
- resilience: what happens if this specific CDN is extremely slow
You can now throttle individual requests in Chrome!
Neat for experimenting with stuff like
- lazy-loading: does the UI look okay if this chunk takes MUCH longer to arrive
- resilience: what happens if this specific CDN is extremely slow