Jonathan
@jonathan-frere.com
I've used classes for state objects in SolidJS a few times, although I've mostly moved away from it because I prefer the way hooks compose to how classes compose. But yeah - classes are a poor man's closure and vice versa!
October 26, 2025 at 1:25 PM
I've used classes for state objects in SolidJS a few times, although I've mostly moved away from it because I prefer the way hooks compose to how classes compose. But yeah - classes are a poor man's closure and vice versa!
I'd love to see more frontend tools lean into disposables. It's such a simple but powerful mechanism. But I think there's a good reason why almost every framework sharply turned away from classes when React hooks came out - hooks compose so nicely compared to anything class-based.
October 26, 2025 at 4:14 AM
I'd love to see more frontend tools lean into disposables. It's such a simple but powerful mechanism. But I think there's a good reason why almost every framework sharply turned away from classes when React hooks came out - hooks compose so nicely compared to anything class-based.
But like I said before, it's way more intuitive, and you only really need to think about it when you start doing weird stuff with the reactivity system. And you have the tools to manipulate it yourself (getOwner/runWithOwner) when needed.
October 26, 2025 at 2:53 AM
But like I said before, it's way more intuitive, and you only really need to think about it when you start doing weird stuff with the reactivity system. And you have the tools to manipulate it yourself (getOwner/runWithOwner) when needed.
It's similar to React because you've got this "secret" global scope that opens when you call certain functions, but it's different because you don't have the same ordering issues where if a scope gets created multiple times, it needs to have the same children added in the same order.
October 26, 2025 at 2:53 AM
It's similar to React because you've got this "secret" global scope that opens when you call certain functions, but it's different because you don't have the same ordering issues where if a scope gets created multiple times, it needs to have the same children added in the same order.
You're right, I'd forgotten that creating a new component doesn't create a new owner. But effects/memos still need to be called with a global ownership scope, so that SolidJS knows when to clean them up (i.e. when the given owner is disposed). That ownership scope is the hook-like invisible one.
October 26, 2025 at 2:53 AM
You're right, I'd forgotten that creating a new component doesn't create a new owner. But effects/memos still need to be called with a global ownership scope, so that SolidJS knows when to clean them up (i.e. when the given owner is disposed). That ownership scope is the hook-like invisible one.
But you're right that this is very different from React's signals in that calling one hook inside a component body won't affect the other hooks - there's no sense that hooks are ordered. There's just a single parent scope that hooks internally attach themselves to.
October 25, 2025 at 9:05 PM
But you're right that this is very different from React's signals in that calling one hook inside a component body won't affect the other hooks - there's no sense that hooks are ordered. There's just a single parent scope that hooks internally attach themselves to.
Signals are (mostly) regular objects without hidden state, but effects, memos, cleanups etc all rely on an invisible scope mechanism that allows Solid to track which effects/computations are owned by which components, and when they can be cleaned up.
October 25, 2025 at 9:05 PM
Signals are (mostly) regular objects without hidden state, but effects, memos, cleanups etc all rely on an invisible scope mechanism that allows Solid to track which effects/computations are owned by which components, and when they can be cleaned up.
With Solid you can use onCleanup and createComputed inside memos which gives you some of the lifecycle stuff, but I had a look at some other libraries and I don't think they have the same tools. So maybe the ability to do this is SolidJS specific?
October 21, 2025 at 1:20 PM
With Solid you can use onCleanup and createComputed inside memos which gives you some of the lifecycle stuff, but I had a look at some other libraries and I don't think they have the same tools. So maybe the ability to do this is SolidJS specific?
I work on an Excel-clone that uses SolidJS signals under the hood for the cell reactivity, and it works quite well, but it gets a bit brain-bending sometimes, which I think is a sign that there's probably a simpler approach out there.
October 20, 2025 at 9:02 PM
I work on an Excel-clone that uses SolidJS signals under the hood for the cell reactivity, and it works quite well, but it gets a bit brain-bending sometimes, which I think is a sign that there's probably a simpler approach out there.
In practice, there's diminishing returns making things more fine-grained because of the increased complexity of trying to figure out which variables are being tracked when and where and how. There are some tools that can help a bit (c.f. solid-primitives), but nothing as simple as SolidJS for HTML
October 20, 2025 at 9:02 PM
In practice, there's diminishing returns making things more fine-grained because of the increased complexity of trying to figure out which variables are being tracked when and where and how. There are some tools that can help a bit (c.f. solid-primitives), but nothing as simple as SolidJS for HTML
In theory, SolidJS or any other signals library should be able to do this. You can define your sources as signals, and create derived data using computed/memo values. To make it fine-grained, you can nest computed values, and control the reactivity that way.
October 20, 2025 at 9:02 PM
In theory, SolidJS or any other signals library should be able to do this. You can define your sources as signals, and create derived data using computed/memo values. To make it fine-grained, you can nest computed values, and control the reactivity that way.
Ooh, the getter trick is really clever. I also like DisposableStack#move(), which is really useful when writing a function that creates a bunch of resources and returns them. It lets you automatically dispose the resources if the function fails, but not if it succeeds.
October 9, 2025 at 2:18 PM
Ooh, the getter trick is really clever. I also like DisposableStack#move(), which is really useful when writing a function that creates a bunch of resources and returns them. It lets you automatically dispose the resources if the function fails, but not if it succeeds.
There's an excellent podcast, More or Less, about numbers in the news, and one of the questions they always ask is "is this a big number?" E.g. is it a big percentage increase but for a small number? Or does it sound big but need to be divided by the population. It's the basics of stats literacy.
August 1, 2025 at 6:00 PM
There's an excellent podcast, More or Less, about numbers in the news, and one of the questions they always ask is "is this a big number?" E.g. is it a big percentage increase but for a small number? Or does it sound big but need to be divided by the population. It's the basics of stats literacy.
In uni we did a course on parsing natural language with Prolog, and there were explanations of different types of language and how Prolog was designed to parse then, and then at the end of the course the prof showed us all the reasons Prolog can't parse English because it doesn't work like that.
June 20, 2025 at 6:47 AM
In uni we did a course on parsing natural language with Prolog, and there were explanations of different types of language and how Prolog was designed to parse then, and then at the end of the course the prof showed us all the reasons Prolog can't parse English because it doesn't work like that.
This is a bit of a historical artifact though. Natural languages are parsed (haha) very differently from programming languages, even though a lot of the ideas come from the same discipline. They also behave differently and are apparently even processed by different parts of the brain
June 20, 2025 at 6:47 AM
This is a bit of a historical artifact though. Natural languages are parsed (haha) very differently from programming languages, even though a lot of the ideas come from the same discipline. They also behave differently and are apparently even processed by different parts of the brain
The less you interact with a page, the less likely it is for the browser to do something funky, so the more stable your tests will be
June 18, 2025 at 5:11 PM
The less you interact with a page, the less likely it is for the browser to do something funky, so the more stable your tests will be
Also (and possibly controversially): do less stuff directly in playwright. Particularly for tests, have e.g. one test that tests the login form,and then all other tests that log in can fetch tokens via the API directly or use a dev-only shortcut to skip login
June 18, 2025 at 5:11 PM
Also (and possibly controversially): do less stuff directly in playwright. Particularly for tests, have e.g. one test that tests the login form,and then all other tests that log in can fetch tokens via the API directly or use a dev-only shortcut to skip login
I think the flakiness is part of e2e/browser interaction in general. But playwright is typically pretty good at mitigating problems. Stick to the locator API as much as possible, even for complex logic, and use a linter to check for missing `await`s, and it's usually pretty stable.
June 18, 2025 at 5:11 PM
I think the flakiness is part of e2e/browser interaction in general. But playwright is typically pretty good at mitigating problems. Stick to the locator API as much as possible, even for complex logic, and use a linter to check for missing `await`s, and it's usually pretty stable.
Which model are you using for this? And do you notice significant differences between the models? I've been looking into Claude Code, but it's difficult to know which plans/models make the most sense.
June 7, 2025 at 10:57 AM
Which model are you using for this? And do you notice significant differences between the models? I've been looking into Claude Code, but it's difficult to know which plans/models make the most sense.
It's also in NodeJS as of Node 24, so you can use it without any sort of transpiling or polyfills.
May 30, 2025 at 8:36 PM
It's also in NodeJS as of Node 24, so you can use it without any sort of transpiling or polyfills.