I’ve been running Jev for about three years now, first as a curiosity, then as the thing that quietly holds together two of my side projects. It’s the kind of tool you stop noticing after a while, which is the highest compliment I can give software. So when the 1.14.0 release landed in my feed alongside a separate “experimental features for dreamers” track, I did what I always do: skimmed the changelog, installed it on a throwaway branch, and spent a weekend poking at it.
This post is my honest read. Some of it is good. Some of it I think is a mistake. And one part of it I’m genuinely excited about, which surprised me, because I went in skeptical.
Let me start with the stable release, because that’s the part most people should care about.
The headline change is a rework of how Jev handles incremental state. In prior versions, if you killed a long-running process and restarted it, you’d often pay a full recomputation cost even when nothing meaningful had changed. That was the single most annoying thing about the tool for me. I hit it constantly when I was iterating on config-heavy projects — tweak one line, restart, wait two minutes for Jev to rediscover things it already knew.
1.14.0 fixes most of that. State is now persisted in a way that survives a clean shutdown, and on restart Jev checks a cheap fingerprint before deciding whether to recompute. In my tests, a restart that used to take roughly ninety seconds now takes about four. That’s not a benchmark, that’s me with a stopwatch and a cup of coffee, so treat it as a vibe rather than a number. But the vibe is very good.
There are smaller things too. Error messages got a pass, and they’re noticeably better — they now point at the specific line in your config rather than the block, which sounds trivial until you’ve spent twenty minutes hunting a typo. The plugin API picked up a couple of new hooks that I haven’t needed yet but can see myself using. And there’s a batch of dependency bumps that I won’t pretend to have audited.
If you use Jev and you don’t care about experimental anything, upgrade to 1.14.0. It’s a solid release. The incremental-state fix alone justified the upgrade for me.
Here’s where I get ambivalent.
The project is shipping a set of features under an explicitly experimental banner, aimed at what the release notes call “dreamers” — people who want to push Jev into territory it wasn’t designed for. I understand the impulse. Every tool I’ve ever loved has been stretched past its original intent by someone with more imagination than patience. That’s how ecosystems grow.
But I’ve been burned by experimental tracks before, and I want to be honest about why this one makes me nervous.
The dreamer features are, as far as I can tell, three things bundled together: a speculative execution mode, a looser validation path that lets you feed Jev partially-formed inputs, and a set of hooks for scripting behavior that the core team hasn’t committed to keeping stable. The first two I think are genuinely useful. The third is where I’d caution anyone to slow down.
Speculative execution, in particular, is a real quality-of-life win if you’re doing exploratory work. Instead of failing fast on an ambiguous input, Jev will guess and keep going, flagging the guess so you can review it later. For prototyping, that’s great. For anything that touches production, it’s terrifying. The guess is usually right. “Usually” is not a word I want anywhere near a deploy pipeline.
The loose validation path is similar. It’s the difference between a linter and a rubber stamp. Useful when you’re sketching, dangerous when you forget you turned it on.
And the unstable hooks — I’ve seen this movie. A scripting surface gets labeled experimental, people build on it anyway because it’s the only way to do the thing they need, and then a year later there’s a breaking change and everyone’s weekend is ruined. I’m not saying the Jev team will do that. I’m saying I’ve watched it happen to projects with better track records, and the “experimental” label has never once stopped anyone.
If you’re running Jev in anything that other people depend on, here’s my advice: take 1.14.0, skip the dreamer build.
If you’re doing solo exploration, or you have a sandbox where a wrong guess costs you nothing, the dreamer features are worth a look. I’ve been using speculative execution on a personal project for a few days and it’s changed how I sketch — I move faster because I’m not fighting the tool for permission to be sloppy. That’s a real benefit. It’s also exactly the kind of benefit that quietly becomes a dependency, and then one day you ship the sloppiness by accident.
The way I’m handling it: dreamer features live behind a flag that’s off by default, and I’ve written myself a note to re-read that flag every time I start a new project. It’s a small ritual, but it’s the difference between a tool and a trap.
One thing I want to call out, because I think it’s the most interesting part of this release and nobody’s talking about it: shipping stable and experimental in the same announcement is a deliberate choice, and I think it’s a good one. It respects the people who just want the bug fixes, and it gives the curious crowd something to chew on without pretending the two audiences are the same.
Plenty of projects would have buried the experimental stuff in a separate repo with a README nobody reads. Jev didn’t. That’s a small act of honesty, and I appreciate it.
My only gripe is that the release notes are a little too enthusiastic about the dreamer features for my taste. They read like the experimental stuff is the main event and 1.14.0 is the appetizer. I’d flip that. The incremental-state fix is the thing that will affect the most people, and it deserves top billing.
Yes, to 1.14.0. The restart cost fix is the kind of improvement you feel every single day, and the better error messages are a nice bonus. It’s a low-risk upgrade for a tool that’s earned some trust.
The dreamer build is a different question, and the answer depends entirely on what you’re doing and how much you care about your weekends. If you’re curious, try it in a sandbox. If you’re shipping, wait. And if you do try it, keep the flag off by default — future you will thank present you.
I’ll be over here with 1.14.0 on my real projects and speculative execution on the toy one, quietly hoping the Jev team resists the urge to break the unstable hooks before I’ve had my fun.
Is 1.14.0 a breaking change? Not in my experience. My existing configs ran without modification. I’d still skim the changelog before upgrading anything critical, because dependency bumps can bite in ways that don’t show up until they do.
Can I use the dreamer features in production? You can. I wouldn’t. The whole point of the experimental track is that the team hasn’t committed to its behavior, and speculative execution makes guesses you didn’t ask for. That’s fine for sketching and bad for anything with a blast radius.
How do I turn the experimental features off? They’re off by default in my install, and I’d keep them that way unless you’re actively experimenting. If your setup differs, check the release notes for the exact flag — I don’t want to quote a config key I might be misremembering.
Will the unstable hooks break? Probably, eventually. That’s what “unstable” means. If you build on them, build in a way that’s easy to rip out.
Should I wait for 1.15.0? No. The incremental-state fix is worth having now, and waiting for the next release is a habit that never pays off.
I've built and abandoned more note-taking systems than I can count. Evernote, then Notion, then Obsidian, then a brief and embarrassing detour into a folder of
I've been running a bilingual blog for about six years now — English on one side, Chinese on the other. Not translated copies of each other, which is a trap a l
I've moved my notes between these three apps more times than I'd like to admit. Notion was my home for two years. Obsidian has been my daily driver for about th
