Building a bookmark manager on top of the browser's own bookmark tree — no bookmark database required

irène — Tue, 25 Aug 2026 15:06:26 +0000

When I started building Bookmash, one architectural decision shaped almost everything else: the browser stays the source of truth.

No import step. No Bookmash-side copy of your bookmarks. The extension talks directly to the browser's native bookmarks API, and the dashboard reads and writes through that same layer.

Bookmash doesn't store your bookmarks, or its own representation of them, in a database. The only user data stored server-side is what's needed for the account itself, such as the user's email to give access to the dashboard.

That constraint sounds simple. It wasn't free because of how browser's bookmark tree is handled.

Here's what it meant when building features like Collections and MyMash without introducing a second bookmark model.

The problem with the native bookmark tree

Chrome and Firefox expose bookmarks as a tree through their extension APIs.

That tree reflects the browser's own structure: bookmarks live inside folders, which in turn live under browser-defined roots such as the bookmarks bar and other bookmarks.

For example:

Browser bookmarks

├── Bookmarks Bar
│   ├── Development
│   └── Daily
│
└── Other Bookmarks
    ├── Design
    └── Research

That separation makes sense for the browser UI, but it doesn't necessarily represent how I want to navigate those bookmarks inside another interface.

I wanted Bookmash to provide a different view over that same data without reorganizing it into a Bookmash-specific structure.

That meant the problem wasn't:

How do I import this tree into Bookmash?

It was:

How do I derive a more useful interface from the tree that already exists?

Collections: a view computed from the tree

Bookmash reads the current bookmark tree from the browser and runs a flattening operation over it.

Conceptually:

Browser tree

Bookmarks Bar
├── Development
└── Daily

Other Bookmarks
├── Design
└── Research

        ↓ flatten

Bookmash

├── Development
├── Daily
├── Design
└── Research

The browser's top-level separation disappears from the Bookmash view, while the meaningful folder hierarchy underneath it remains intact.

Nothing needs to be copied into a Bookmash database to make that happen.

The Collection view is the result of an operation over the current tree.

Every time Bookmash needs that view, it starts with what the browser says exists now and derives the representation from it.

If a folder is renamed, moved or deleted using the browser itself, Bookmash doesn't have a second version of that folder to reconcile.

It reads the tree again. This approach makes the dashboard always fresh.

There is no:

browser state
      ↕
sync layer
      ↕
Bookmash bookmark state

There is only:

browser state
      ↓
Bookmash view

That distinction ended up removing an entire category of synchronization problems.

The cost: computation moves to read time

Of course, not storing a derived bookmark model doesn't make the work disappear.

It moves the work.

A more traditional architecture could normalize the bookmark tree once, store the result, index it and query that representation later.

Bookmash instead reads the current tree and transforms it when it needs to display it.

So the trade-off becomes:

store and synchronize state on writes

versus

recompute a view from the source on reads.

I chose the second.

For bookmark-sized datasets, the cost has been small enough that I prefer doing the computation to maintaining another stateful representation of data that already exists somewhere else.

If that assumption ever stops being true, the performance side can be revisited.

But I didn't want to introduce synchronization complexity before there was a reason to.

MyMash follows the same idea

MyMash is Bookmash's quick-access view for bookmarks you use frequently.

The important part architecturally is that adding something to MyMash doesn't create a second copy of that bookmark in a Bookmash database.

The bookmark remains part of the browser's native bookmark structure.

MyMash is another way of presenting and accessing that structure through Bookmash rather than a separate library of bookmarks owned by the application.

That distinction matters because I wanted features like MyMash to change how you interact with your bookmarks, not where your bookmarks live.

The browser still owns the bookmark data.

Bookmash provides another interface over it.

Chrome and Firefox: similar APIs don't mean identical behavior

One thing I underestimated was how much browser-specific behavior would still matter.

Chrome and Firefox expose comparable bookmark APIs, so initially I expected most tree-related bugs to reproduce in roughly the same way.

They didn't.

Folder-structure edge cases and the behavior around bookmark updates were different enough that the same transformation logic could surface problems in one browser and not the other.

So "works in Chrome" was never a safe proxy for "works in Firefox," even when both implementations were built around the same basic WebExtensions model.

That reinforced another part of the architecture: the transformation layer should make as few assumptions as possible about what the tree should look like.

Read what the browser gives you, normalize what the UI actually needs, and preserve the underlying structure everywhere else.

Why this mattered more than it might seem

None of this is about avoiding a database out of purity.

Bookmash has server-side concerns — authentication, for example — where persistent storage makes perfect sense.

Bookmarks are different.

The browser already stores them. Bookmash doesn't need to store them again.

The moment Bookmash stores its own copy of the bookmark structure, it takes on responsibility for keeping that copy correct relative to a tree the user can change without going through Bookmash at all.

They can edit it from the native bookmark manager.

Another extension can change it.

Browser sync can change it.

Bookmash would then need to decide which state is current and how discrepancies should be resolved.

By treating the browser tree as the source of truth and computing Bookmash's views from it, that synchronization problem largely disappears.

The trade-off is that more work happens when the data is read.

And that's the architectural lesson I've taken from building it:

If you're building a UI on top of data that already has an authoritative owner, think carefully before creating your own representation of that data.

You can store your own model and own the synchronization problem.

Or you can derive your model from the source of truth and own the computation problem.

For Bookmash, I chose the second.

So far, it's been the simpler problem to own.

Bookmash is a bookmark manager for Chrome and Firefox built around this architecture. There's also a public demo if you want to see how the browser tree is presented without installing anything.

I'm also happy to write a follow-up about the extension-to-dashboard communication layer or the differences I ran into between Chrome and Firefox.

JavaScript Questions and Answers - core concepts

irène — Sat, 23 Mar 2024 07:16:47 +0000

Hey! I want to share this collection of JavaScript core concepts.
I created a repository for it and every contribution will be appreciated.

The repository link: Welcome to JavaScript Questions and Answers

Intro

This is a collection of the concepts I have encountered throughout my career's path and the questions I have asked about them. Some questions might seem redundant but the purpose of this is to investigate, where present, the connections between different concepts that make this language so interesting and flexible. There are also practical examples of topics whose definition is known but perhaps have never been used in practice. These questions and answers can be used to prepare for an interview or for personal study and lecture.

In writing the answers I was helped by AI and the book "JavaScript: The Definitive Guide" by David Flanagan.

Motivation

I've encountered many times a list of questions and answers written for preparing an interview. I began to get the feeling that the answers were accurate but that the concepts were not connected.
In the real world when we use JavaScript at work or for one of our projects it is important to understand the connection of the concepts between them. For example: what is the connection between closures and high order function? How important is the comprehension of all the event flow phases in order to understand a single event?

See the connections is decisive for completing a task in the most efficient way, that's because you can understand WHY and not only HOW to do a thing in a determined way.

Additions

You can find in this repository some practical example of some concept like Proxy. You can find the definition of it but have you have used it in practice? You can find practical usages for that and understand, in some cases, you can use it as a store instead of installing new state managers.

Contributions

As mentioned, this repository is open to contributions. The only thing to have in mind is the purpose is to explore the nature of a concept and not only to add a definition of it.
I hope this can be useful for someone of you as it was for me to ask myself these questions.

So, Welcome to JavaScript Questions and Answers! 🤓

DEV Community: irène