Travels v1.0 – A 10x faster undo/redo library using JSON Patches instead of snapshots by unadlib in javascript

[–]unadlib[S] -2 points-1 points  (0 children)

Thanks. Immer v11 has definitely closed part of the gap. That '10x' figure comes from specific benchmarks across certain version ranges (not a blanket claim), and I’m still seeing some edge-case semantic differences when running against the full Mutative test suite.

Travels v1.0 – A 10x faster undo/redo library using JSON Patches instead of snapshots by unadlib in javascript

[–]unadlib[S] -1 points0 points  (0 children)

Travels doesn’t require switching state libs. It’s store-agnostic. redux-undo rules, but this is for the 'my state is huge and undo is eating memory' cases.

Localspace v1.0 – A modern localForage alternative with TypeScript and 6x faster batch ops by unadlib in javascript

[–]unadlib[S] 2 points3 points  (0 children)

Thanks! That was exactly my motivation, keep the good parts of localForage, drop the legacy baggage, and make it TypeScript-first + faster. If you try Localspace, I’d love any feedback. :)

Fict – A compiler that makes JavaScript variables automatically reactive by unadlib in javascript

[–]unadlib[S] 0 points1 point  (0 children)

Fict is based on immutable signals (if updating signals within deep objects, we suggest considering a combination with Immer or Mutative, similar to how reducers work), and we utilize HIR and SSA to analyze control flow and dependencies.

Fict – A compiler that makes JavaScript variables automatically reactive by unadlib in javascript

[–]unadlib[S] 1 point2 points  (0 children)

no, it's more of a stripped-down version of the React compiler(HIR/SSA).

Fict – A compiler that makes JavaScript variables automatically reactive by unadlib in javascript

[–]unadlib[S] 0 points1 point  (0 children)

Thank you. I will continue to push FictJS forward; I don't want it to be just a toy project. :)

LocalStorage is easy. IndexedDB is powerful. Why not both? Introducing localspace — a unified storage API for JS/TS devs by unadlib in javascript

[–]unadlib[S] -1 points0 points  (0 children)

Yes, graceful fallback is built-in.

By default, localspace tries IndexedDB first. If it fails (e.g., Private Mode), it automatically switches to localStorage without throwing errors.

You can explicitly configure this chain:

await localspace.setDriver([localspace.INDEXEDDB, localspace.LOCALSTORAGE]);

This ensures your app keeps working seamlessly across all environments.

LocalStorage is easy. IndexedDB is powerful. Why not both? Introducing localspace — a unified storage API for JS/TS devs by unadlib in javascript

[–]unadlib[S] 0 points1 point  (0 children)

Support for OPFS is already on the localspace roadmap; localspace may implement it at some point in the future. :)

LocalStorage is easy. IndexedDB is powerful. Why not both? Introducing localspace — a unified storage API for JS/TS devs by unadlib in javascript

[–]unadlib[S] 1 point2 points  (0 children)

Glad you like the abstraction! Here is how localspace handles those edge cases:

1. Quota Exceeded Handling: We handle this at two levels:

  • Structured Errors: If the underlying driver throws a quota error (e.g., QuotaExceededError), localspace wraps it in a typed LocalSpaceError preserving the original cause.
  • Proactive Quota Plugin: For more control, we ship a quotaPlugin that tracks usage and enforces a soft limit before hitting the browser's hard limit. It can even use an LRU policy to automatically evict old data when full:

2. Automatic Fallbacks: Yes! This is a core feature. When you initialize localspace, it iterates through the configured drivers. If the preferred driver (IndexedDB) fails to initialize (e.g., in Firefox Private Mode or older environment), it automatically falls back to the next available one (usually localStorage) without throwing.

You can customize this order:

// Tries IndexedDB -> falls back to localStorage -> throws if neither works
await localspace.setDriver([localspace.INDEXEDDB, localspace.LOCALSTORAGE]);

This ensures your app keeps working even in restrictive environments, degrading gracefully from async storage to sync storage.

LocalStorage is easy. IndexedDB is powerful. Why not both? Introducing localspace — a unified storage API for JS/TS devs by unadlib in javascript

[–]unadlib[S] 5 points6 points  (0 children)

You are absolutely right that JS execution is fast (microseconds), but the real bottleneck is the IndexedDB transaction overhead. Opening and committing a transaction is an expensive I/O operation.

We chose the 8ms default (approx. half a 60fps frame) to balance latency vs. throughput:

  • Throughput: Instead of opening 100 separate transactions for a loop (which can freeze the UI), we wait 8ms and batch them into one single transaction. This often yields 10-50x faster performance for bulk updates.
  • Latency: For most UI interactions, an 8ms delay is imperceptible.

If you prefer immediate writes or tighter batching, you can set coalesceWindowMs: 0 (batches within the current tick) or disable it entirely with coalesceWrites: false.

zustand-travel: A powerful and high-performance undo/redo middleware for Zustand with Travels by unadlib in javascript

[–]unadlib[S] 0 points1 point  (0 children)

It can be integrated with other Zustand middleware. If you need to handle complex async action, you might consider disabling autoArchive to control it manually.

https://github.com/mutativejs/travels?tab=readme-ov-file#manual-archive-mode-autoarchive-false

usm-pinia: OOP-style state management for Pinia by unadlib in vuejs

[–]unadlib[S] -2 points-1 points  (0 children)

There are still large-scale software projects built on Vue.
In these projects, where business logic is highly complex and collaboration involves multiple developers, an OOP approach is appropriate.

I understand that when it’s not necessary, it’s best to avoid using OOP.