The hack for sveltekit specifically, is to first have Claude translate the existing code into a next.js route with react components. Run it, debug and tweak it. Then have Claude translate the next.js and react components into sveltekit/svelte. Try and keep it in a single file for as long as possible and only split it out once it's working.
I've had very good results with Claude Code using this workflow.
Not sure why there is so much hate on this thread. I found the post well written, insightful, and pragmatic.
Having built systems that process billions of events and displayed results, triggered notifications, etc in real time (not RTOS level, I'm talking 1 or 2 seconds of latency) you absolutely need to separate reads and writes. And if you can trust db replication to be fast and reliable, you can indeed skip distributed locks and stay on the right side of the CAP theorem.
Event sourcing is how every write ahead log works. Which powers basically every db.
Is the concern on this thread that they preoptimized? I thought they walked through their decision making process pretty clearly.
This is really good! It would be really cool to somehow get human designs in the mix to see how the models compare. I bet there are curated design datasets with descriptions that you could pass to each of the models and then run voting as a "bonus" question (comparing the human and AI generated versions) after the normal genAI voting round.
Apparently an unpopular opinion, but actually strong types are useful above and beyond editor linting errors.
- Jit optimizations
- Less error checking code paths leading to smaller footprints
- Smaller footprints leading to smaller vulnerability surface area
- less useful: refactorability
Don't get me wrong, I love the flexibility of JavaScript. But you shouldn't rely on it to handle your poorly written code.
This has led me to wonder if this is the last generation of "senior" devs. The thinking goes, if it takes a couple of years to educate and train a junior dev on average and LLMs can increasingly replace junior devs... There is no need for a company to hire junior devs, starving the ecosystem of talent that would have otherwise gone onto becoming senior.
In a world where the average work is the first to be displaced (due to training data availability), the last to be replaced are the ones furthest from distribution mean...
Ya, that seems about right for my project as well. Although mine won't be OSS so I'm more concerned with finding good ppl with Svelte skills vs React skills. I may need to bite the bullet once I'm closer to hiring. Thanks.
Why did you decide to rewrite this in react vs svelte?
As someone who loves svelte and whose been writing a fairly large svelte app but has been jealous of the react ecosystem, I'd love to hear your rationale.
I've had very good results with Claude Code using this workflow.