Here are some other reasons, though I think they’re a bit less central than the ones in Habryka’s comment.
1. I think current AI systems find it much easier to help with NextJS web apps than they did our sui generis palimpsest of frameworks and approaches. It’s a bit unclear if this is on a trajectory to fix itself, but for now it seems like a relatively big difference. I think partly they’re just way more familiar with this newer stuff, and partly serverless stuff is a bit more architecturally suited to LLMs making narrow changes.
2. Another reason is that we had a lot of technical debt that we wanted to pay down. The project that became the hosting transfer was originally known as the “debungle”[1].
The codebase had a bunch of very particular ways of doing things (like you weren’t supposed to just write and export new React components, but call a registration function on them. You weren’t supposed to write direct queries against our GraphQL server, but use a system of helpers).
I don’t think this stuff is necessarily bad. But because Lightcone is largely composed of generalists, onboarding costs are a bit higher. If you have a blessed way to make a query, and that blessed way is itself changing (as it needs to shift for performance or feature reasons), someone who is working on LessWrong one month in three is paying more cost for keeping up with the internal, undocumented framework magic.
There have been several times I’ve asked a distracted Habryka what the Standard Way to do something in our codebase is, implemented his quick answer, only to get a PR review from Robert asking why I’m doing stuff in a semi-deprecated way.
3. Habryka mentioned wanting to use newer React features. I think possibly a bigger issue was the transitive out-of-date dependencies you get if you stick on an old React. You can’t update Material UI, you can’t update some other library, some of them have security holes, so you vendor the old version and patch it by hand, … That stuff starts to grow as a maintenance and jank burden over time.
In general, I’m pro things being crufty and janky and not spending too much time “rewriting thing to be nice”, and a lot of the stuff I listed above can be worked around. I think probably my list alone wouldn’t be worth the effort of the shift. To be clear, I’m unsure if the combination of my list, Habryka’s, the other arguments I’m aware of, and the expected strength of the arguments I’m not aware of, overall make this a worthwhile shift. I’m guessing yes, but it’s too soon to say.
Here are some other reasons, though I think they’re a bit less central than the ones in Habryka’s comment.
1.
I think current AI systems find it much easier to help with NextJS web apps than they did our sui generis palimpsest of frameworks and approaches. It’s a bit unclear if this is on a trajectory to fix itself, but for now it seems like a relatively big difference. I think partly they’re just way more familiar with this newer stuff, and partly serverless stuff is a bit more architecturally suited to LLMs making narrow changes.
2.
Another reason is that we had a lot of technical debt that we wanted to pay down. The project that became the hosting transfer was originally known as the “debungle”[1].
The codebase had a bunch of very particular ways of doing things (like you weren’t supposed to just write and export new React components, but call a registration function on them. You weren’t supposed to write direct queries against our GraphQL server, but use a system of helpers).
I don’t think this stuff is necessarily bad. But because Lightcone is largely composed of generalists, onboarding costs are a bit higher. If you have a blessed way to make a query, and that blessed way is itself changing (as it needs to shift for performance or feature reasons), someone who is working on LessWrong one month in three is paying more cost for keeping up with the internal, undocumented framework magic.
There have been several times I’ve asked a distracted Habryka what the Standard Way to do something in our codebase is, implemented his quick answer, only to get a PR review from Robert asking why I’m doing stuff in a semi-deprecated way.
3.
Habryka mentioned wanting to use newer React features. I think possibly a bigger issue was the transitive out-of-date dependencies you get if you stick on an old React. You can’t update Material UI, you can’t update some other library, some of them have security holes, so you vendor the old version and patch it by hand, … That stuff starts to grow as a maintenance and jank burden over time.
In general, I’m pro things being crufty and janky and not spending too much time “rewriting thing to be nice”, and a lot of the stuff I listed above can be worked around. I think probably my list alone wouldn’t be worth the effort of the shift. To be clear, I’m unsure if the combination of my list, Habryka’s, the other arguments I’m aware of, and the expected strength of the arguments I’m not aware of, overall make this a worthwhile shift. I’m guessing yes, but it’s too soon to say.
We had our eyes on a NextJS switch early on. But we thought it was valuable to do even without that.