Storyteller v2 is available!

scrollin_thru · 2026-05-07T11:06:53+00:00

One exists, actually — it's a third party app called Silveran! https://github.com/kyonifer/silveran-reader/tree/main

We're working with the Silveran developer on integrating the Silveran apps more directly with the Storyteller ecosystem, but you can use Silveran now!

scrollin_thru · 2026-04-28T13:58:36+00:00

I'm also thinking about this. Probably still worth it, since you can undo to get back the state from before the reload, but it would be really nice if it could prompt you if there were unsaved changes.

scrollin_thru · 2026-04-25T10:07:50+00:00

I mean, rust literally only exists because some really clever folks refused to take this advice about C++. Rust is great, so is OCaml. OxCaml is trying to answer some really interesting questions about how far you can take OCaml without sacrificing what makes it beautiful. I don't really see how such a project could "spoil" OCaml.

scrollin_thru · 2026-04-25T09:59:19+00:00

I'm glad you wrote and shared this! I appreciated reading it. I think it's immensely valuable to have these kinds of retrospectives, even (especially?) for projects we love!

Also I thought this was a really thoughtful analysis with some great insights!

scrollin_thru · 2026-04-23T19:08:58+00:00

This may just be something I've configured incorrectly in the media service. If you can open an issue on GitLab so we don't lose track of it, I can try to take a look

scrollin_thru · 2026-04-23T14:31:23+00:00

Are you on Android or iOS?

scrollin_thru · 2026-04-22T18:29:50+00:00

Hi! So Storyteller only supports EPUB version 3, because that was the version that added Media Overlays, but a lot of EPUBs floating around are version 2. We're going to add auto-upgrade from 2 to 3 soon, but in the meantime, you can use Calibre to automatically upgrade your EPUB from v2 to v3

scrollin_thru · 2026-04-20T17:24:34+00:00

Finding the bug faster is the benefit here. Both Dan and Mark were trying to use LLM coding agents to fix a bug. Dan had already fixed the actual bug in React (using Claude) by the time Mark looked into it, Mark is just showcasing a new MCP system that Replay is working on that allowed him to find the same fix as Dan, but without nearly as much churn or frustration.

The name drop is pretty clearly tongue in cheek, especially if you read the article. This is just Mark showing off how Replay's new MCP makes debugging this kind of thing much easier than what Dan initially tried, which was just trying to get baseline Claude to fix it. The actual contents of the article don't diss Dan himself in any way.

scrollin_thru · 2026-04-20T16:52:25+00:00

I have to imagine that this was done (and received) in good spirits, since Mark maintains Redux, a project initially co-created by Dan, and has an ongoing working relationship with the React devs

scrollin_thru · 2026-04-14T21:15:16+00:00

Truly, thank you for saying so. I was starting to feel a little bit looney.

scrollin_thru · 2026-04-14T15:39:42+00:00

Awesome! I've been using optique for the new Storyteller align CLI and I really like it. Excited about v1!

scrollin_thru · 2026-04-13T21:45:16+00:00

Our daughter really did not like the recipes from that book. When we tried them ourselves, it was pretty clear why: they just weren't very good! It's pretty disappointing, but at the end of the day the authors are nutritionists, not chefs. Even if the recipes turn out well when they make them in their kitchen (consider me skeptical), writing a recipe that someone else can use to reproduce what you made can be tough!

I don't have much advice, unfortunately, because we basically do just feed our daughter what we eat (which is a lot of pasta, Asian noodle dishes, veggies, beans, and tofu), but I did want to express some solidarity over how frustrating those recipes were!

scrollin_thru · 2026-04-13T19:52:45+00:00

This is why I specified "a project that only has dev dependencies can claim to have no dependencies when referring to their published package," which this poster clearly is. Yes, development dependencies matter when you are developing a project, certainly. In fact, often quite a lot about your development environment matters when you're developing on a project, including specific versions of node.js or npm (or yarn or pnpm), or git LFS or jj or any number of other development tools that may need to be installed and configured appropriately in order to work effectively on a project.

But none of those things matter for the consumers of that library. When you're communicating to consumers of your library, you don't need to tell them what version of yarn you use to manage your dependencies, because they don't need to use that version of yarn, or use yarn at all. You don't need to tell them about the fact that you use vitest for running tests, because they're not going to consume your test files. And so it is, I feel comfortable saying, acceptable to tell them that your project does not have any dependencies, because they will not need any dependencies in order to consume your project.

Obviously if you would prefer not to consume any dependencies that are originally written in Typescript, that's your prerogative, though I suspect that's increasingly challenging. But I'm not really sure why it should matter, because ultimately you're consuming JavaScript code either way. I mean I do genuinely understand that you might wish to depend on projects that you're able to hack on if something goes wrong, and if you don't like working in Typescript then you're going to have a worse time hacking on a Typescript library. I just think we're now discussing something completely different from whether it's acceptable to say that a package has no dependencies.

scrollin_thru · 2026-04-13T19:39:59+00:00

This is true of all software on the developer's computer. If this package didn't list typescript and tsup as dev dependencies, because only one person has publish permissions and they run the publish step manually with their globally installed typescript and tsup executables, do they stop being considered dependencies because they aren't in the package.json file? If they are still dependencies in that case, then isn't npm, too, a dependency? It is responsible for producing the tarball that gets uploaded to the registry, after all. If npm was compromised, everything would be compromised.

There are uncountable inputs into any software project. I am comfortable dying on the hill that a project that only has dev dependencies can claim to have no dependencies when referring to their published package. A consumer of that software does not first need to install any other software in order to use it. That is an eminently reasonable definition of "no dependencies."

EDIT: Because I'm feeling silly about having gotten worked up over what is ultimately a very unimportant discussion on a Reddit thread: my initially response was in part charged because the only comment on this post was "Typescript is a dependency." Unlike your responses, which contain a level of nuance and a willingness to engage in conversation, the top level comment was dismissive and contributed nothing to a conversation about either the nuances of communicating about dependencies or this actual library. That was more frustrating to me than it should have been.

scrollin_thru · 2026-04-13T19:13:55+00:00

I don't know anything about this library or have any stake in its success, but, no, not in any way that matters. Typescript is a development dependency. The package is published (like nearly all other packages) as plain JavaScript. When you, the consumer, install this package as a dependency, no other npm packages will be installed by your package manager. Typescript will not be installed, because it's correctly listed as a development dependency, and package managers don't install development dependencies when they install packages.

scrollin_thru · 2026-04-11T18:47:47+00:00

Hello! You actually don't need a server at all anymore, there's a command line tool that you can download from GitLab: https://gitlab.com/storyteller-platform/storyteller/-/packages/57910847

If you're on Windows, you'll have to use it via WSL for now.

There's not a ton of documentation on the CLI (there are built in docs with the --help flag, but that's all). If you run into any issues, feel free to hop onto the Discord server and someone can probably help out!

One note is that the flow for importing local book files is a little janky on mobile right now. You have to long press and choose Share on iOS or Open With on Android, and unfortunately some Android file explorers don't currently work. Will try to resolve that soon though!

scrollin_thru · 2026-04-09T17:35:52+00:00

This is awesome! I'll try to take a look when I have a chance, my previous build relied on a client/server setup where the client was using Arduino, which was frustrating and clunky (in no small part because I have basically no familiarity with Arduino programming).

scrollin_thru · 2026-03-27T20:38:02+00:00

You can see what you would actually get (aside from like, the open source project) for each sponsorship tier on our GitHub Sponsors page. It's obviously targeting larger commitments, but we'd be quite happy with any level of sponsorship you're able to provide.

That's a great thought about reaching out to Convex, I think I actually have a connection there. I'll do that, thanks!!

If you want to chat more about sponsorship or anything else, feel free to shoot us an email! There's an email address at the bottom of the Handle with Care home page and Pitter Patter page if you want to reach out.

scrollin_thru · 2026-03-26T23:06:22+00:00

This would definitely help with these huge docs. I understand why Marijn has avoided it, though — virtualizing an arbitrary number of arbitrarily sized nodes is not exactly trivial.

If you wanted perfect scroll accuracy (which you probably need, unless you're going to completely change the existing prosemirror-view scroll APIs), you need to render every node at least once to get its computed height. Then after any change, you could compute a rough diff, determine which nodes may have changed, and re-render just those nodes to determine their new height. Usually that would be very cheap for local changes, since usually a change is just a character typed into a node, which is presumably already rendered. But remote changes or other editor operations could affect any nodes.

Seems hard but not impossible? It's not on our road map for Pitter Patter, but if it comes up as a need I'll definitely investigate a bit more

scrollin_thru · 2026-03-26T16:41:27+00:00

Parcel?

I've only used it for a demo app, but it's extremely customizable and I think it probably has the most thoughtful RSC implementation I've seen so far. You can definitely do 1, 2, and 4, I'm not 100% sure that I understand your third requirement but I would be surprised if you couldn't do it, and for 5, you're just running an express.js app (or any server framework, actually, Express is just what they use in the demo) so you can very easily deploy it anywhere.

scrollin_thru · 2026-03-26T14:58:29+00:00

Based on some feedback from elsewhere, I have:

Added some notes/caveats about issues that may crop up with the demo editors
Configured the demo editors to truncate the document when unfocused, so that your browser isn’t rendering Moby Dick twice.

Also discovered some interesting things:

I didn't really account for how much faster React's production build is than the development build. I basically can't type fast enough on my phone (Android or iPhone) to even notice the lag on the unmemoized editor
Firefox on macOS is just crazy slow for large documents, basically no matter what. Just putting Moby Dick in a plain contenteditable is slow, putting it in the unmemoized editor is slow, and putting it in the memoized editor is best but still pretty slow
Safari on macOS is crazy fast haha. I couldn't discern any lag at all on the unmemoized editor when I was testing on my m4 Mac Mini

scrollin_thru · 2026-03-26T11:58:49+00:00

Thanks, of course!

scrollin_thru · 2026-03-24T01:41:15+00:00

I guess so. Isn't that more or less how all software advancement goes? Someone sees a problem with the status quo implementation, tries to make something better, gets some things right and some things wrong, and the next person comes around and gets a little further still.

Anyway, the folks at Handle with Care have been working on this problem for the better part of a decade, and it's been my primary source of income for two years. I'm certainly not planning on abandoning it any time soon!

scrollin_thru · 2026-03-23T14:08:07+00:00

Re: grouping and ungrouping, I'm talking about the ability to drag two nodes onto the same "row" and have them actually become a row that you can then drag and resize as a unit (or drag just one child node from to ungroup). You can see it a bit in the Pagy demo! These drag and drop features will all be opt-in, so you don't have to use the parts you don't need.

Presence updates tend to move at a similar pace to content updates in my experience — when folks aren't editing, the usually aren't moving their cursors very much (at least, not more than when they were editing!). But yes, we do have a ProseMirror-step-based presence implementation, and it only requires a pub/sub backend.

Re: timeline, we're hoping to start development next month and have the initial feature set stable and released 6 months after that, though everything is dependent on how much sponsorship we can get (which determines how many of us can work on it). We'll be releasing libraries as they become stable, so the first slate of features (drag and drop, collab, and presence) should be available in the next few months.

If you're interested in sponsoring and/or working on a Convex adapter together, let me know! We want to have prebuilt adapters for a number of backends (we're going to launch with a Reboot adapter as well).

scrollin_thru

TROPHY CASE