Skinney

This JEP is essentially about caching the JIT's generated code for later runs. The JIT is still free to discard the cache if it deems it worthwhile.

> Doltlite, like most software nowadays, has been touched by LLMs, but dismissing this project as "vibe coded" seems harsh

From the article, at the end of the second paragraph:

> Could a team of agents pull it off? It only took about 2,000 pull requests but DoltLite going Beta proves a team of agents certainly could.

The first PR was merged March 17th.

"vibe coded" seems pretty fitting

It only has to ask if the cookies are used for behaviour not relevant for the site (like specialized ads), so it probably doesn’t have to ask.

> That's why most client-side routing libraries support lazy loading.

Trading off total size with more network requests.

> does HTMX make fetches magically faster or what?

With backend rendering (htmx) you'd do all of that on the initial render, which would be faster than first fetching the app, then fetching the data, as you'd typically do in a single page app.

React itself, or Preact for that matter, is just the baseline. You still need the application itself, which in every application I’ve worked on is quite a bit bigger than the framework itself.

So you need to download the app, maybe have that app perform some fetch requests, then have the app generate html to show to the user. This is going to be slower than just retriving the resulting html directly.

If you’re in a place with unreliable or plain out bad signal, the difference will be quite noticeable.

* spaghetti or not depends on how you structure things, not on the framework/library used. * HTMX doesn’t introduce a new language. It extends HTML with props, which is less than what React is doing. * unpredictable state? You rely on the browser and (partial) page-refreshes.

How?

Everything served under one domain doesn’t have to use one technology.

Use backend rendering when you can, use HTMX where you need a little bit more, use React on the actual bits where it matters.

As a side-benefit, the React bits might end up less complicated as React doesn’t need to handle every single use case.

Thank you :)

I think I'm handling this as well, though. I have my own personal retrospective every once in a while where I evaluate the different things I work on and if they're worth continuing, or if there are other things (or just rest) I need to replace one of them with.

> So logically, if AI can help us complete tasks 2-100x faster than before, we should be UNDERWORKED and experiencing ZERO burnout, right?

Got to admit, I stopped reading here.

In my experience, burnout isn't related to the amount of work, but to your confidence in being able to do your job and if you find your job meaningful (like, does it even matter?).

I'm probably doing twice as much work now compared to the period just before I burned out, but I'm also nowhere near a burnout. Part of that is general experience, but it's also because I feel like I know what I'm doing (so, no imposter syndrome) and because I've chosen my job based on what I find meaningful to do (is it ethical? does it make a difference in society? is it interesting?).

I understand why LLM assisted development can lead to burnout. You now have a machine that "does most of the work for you". It's a gateway to questions like "how good are you really at your job?" and "anyone could push these buttons, couldn't they?" and "is this what the rest of my life should be?". It probably also reduces how interesting or fulfilling the job is for many people. You've been reduced to a cog in the machine, and you might be questioning your ability to be anything but.

This is required in order to implement value classes in Java (project valhala).

vibe has improved _a lot_ during the past few months, fyi.

The new Mistral Medium 3.5 is also a big improvement over devstral-2