coryvirok

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.

For sure. Event logs in a transactional dbs are weird. I was surprised that they weren't using something like kafka for this.

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.

Shameless plug for https://rollbar.com

Good luck out there!

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.

Hey! Cory, (Co-Founder/CTO) from Rollbar here.

Just wanted to say I think this is awesome and I love what you're doing here! :D

And to the author, I'd love to chat - drop me a line at cory@rollbar.com

Also, check out https://rollbar.com for free error monitoring.

(Ps. I'm one of the founders :)

One of the things I love about node.js is that it forces you to come up with a style and stick with it for things like this. At http://ratchet.io our API servers are written in node.js and we chose the foo(err, callback) method.

I personally love this style even though it makes you write more boiler-plate code, it forces you to write exception-safe code from the start. Also, it forces a structure on all of your code that you can instantly recognize as missing if someone forgets to check for err in the callback.

If you can stick with the style, it's fairly difficult to write code that doesn't deal with errors gracefully.