octantes

great! will be following it then

Hah, great idea, would be great to see it applied to more characters

I don't have a mac but seems like a fun concept! I remember loving the pepsiman pet as a kid

Yeah, imo the only way this is changing at all is if for some reason organization is inherent to the value offered. I guess Notion kinda did that, Obsidian too.

don't be evil!

every bit of humanity went with the motto

I love finding good UI, but i HATE not being able to repurpose it.

I've been working on a project that lets you export any piece of web and hotwire it into anything you want on a portable, single-file HTML that works anywhere.

Fully open source, no-deps, four single-file tools.

https://github.com/octantes/scavenger

Hey! I've been building along the same premise but from the other side (local-first, no host). My document is a wiring canvas that can be quined or exported by removing the editor layer. Different tradeoffs from yours, but it is interesting how much it converges.

I'm curious how you solved storing state in the document. If your answer is attributes, we reached the same conclusion.

The part I've spent most of my time on is harvesting, you might find it interesting.

https://github.com/octantes/scavenger

There is something to this.

But I think at least in front-end engineering, the bigger question is what a new dev values.

LLMs make the browser itself easier to understand in depth, if that's something you want. Building in vanilla-everything, no deps, is now doable at speed and scale for beginners too.

Once you understand the web stack and the principles, you can migrate to any framework and understand their "magic" fast. I think that's not a bad learning path at all, if you use it well, and results in a more competent web-dev than the previous pre-LLM cycle produced.

But if the beginner values output aesthetics and speed more than building their mental model, it is possible to spend years building things without developing any understanding.

For me, at least, the more interesting question is how can we make beginners more interested in the former path than the latter.

I love finding interesting widgets and components on the web. I could screenshot them, or view the source and spend an afternoon failing to make them work anywhere else. I wanted a third option.

That's what Scavenger is. Four single-file tools, local-first, no deps, no frameworks.

You open a page, run the bookmarklet, and harvest whatever you want straight off the live DOM. Paste it onto the patchbay canvas, wire the pieces into something new, and export a single HTML file that works anywhere.

What I'm happiest about is the harvesting. It lifts a rendered component off a live page and reconstructs it as an independent web component - resolving the styles the browser actually applied, and carrying the cascade, responsive units, variables, pseudo-elements, fonts, assets, form state and layout behavior with it.

The patchbay is where harvested pieces get wired together. It's one HTML file whose entire state lives in the DOM - the wiring is just attributes. Save and you get a quine: editor and work in one file, reopening exactly where you left it. Publish and you get the document without the editor. This means that anything you build inside it is a portable environment.

Any of it can also be live. A small local node server reads values - or whole components - off their source pages on a schedule and feeds them in as named channels, so a harvested widget can keep updating from where you found it, or re-harvest itself and morph in place without losing its wiring.

One thing worth stating: a harvest has its scripts stripped, network paths removed - so a harvested component can't phone home, but also loses some of the logic. Authored components and the mutator node are the opposite: they keep their <script> so you can build stuff using the compiler tool.

Happy to go deeper into any part of it!