Thank you, appreciate the comment. txiki is good, but more of a nodejs but small (and slow). tinyjs.app is the thing I wrote on top of that great foundation for all the windowing stuff.
Very impressed, especially with the markdown/visual syncing. Tried it myself in an app (see tinyjs.app - nib example) and it's hard. Also the copy/paste from other places can be complex woop!
Appreciate the app size - including releasing separate Intel/ARM versions - no need for giant binaries! Thanks.
I realise you're not trying to be Obsidian (ie markdown is everything) but wondering how you are saving your priority etc? In a side directory like VSCode does or just internally in the app?
Thank tarwin! The app saves metadata like priorities, tags and rank/orders, pin status, favorite status (for files) and sorting (for folders) inside the app itself, technically in ONE simple .json in the app's macOS data folder (might have different locations on Intel and Apple silicon macs):
It's a simple key-value JSON, simply a list of every file, and the according prio, tags, etc. (if set). The notes themselves are not touched and there are NOT any .files or so.
Regarding speed: To be honest i rebuild the app multiple times from scratch, every single time for performance reasons. ;)
Can I suggest an option to allow saving a .nodes-plus/ directory in any open directory? And save the metadata there? That way you have a portable collection?
From reading your page is the big thing that this is trying to do is give sandboxed access to a fake system? Plus your iphone?
So you connect your iphone (using your app) and then you can see the system browser + the iphone browser looking at a site that an agent is working on?
It looked like there was also functionality for some kind of other sandboxed apps inside superagent "move windows" mentioned but I didn't quite understand what that was about?
Sorry a quick addendum. Yes, a lot of it was built with me + Claude. I'd like to think that I authored it, but understand if others feel differently about that. 100s of hours of work was put into ideas, testing, understanding etc.
Thanks. The markdown editor is "almost there". Needs a tiny bit more work before I can really say it's the best (specifically for docs). But it does have automatic updates so if you get it now promise it will be better very soon.
If you want this experience but don't want Spotify may I suggest my "amp" app - you can get it on tinyjs.app
It's small ~10mb. Yes, takes a bit more memory, but it plays all your local files including rarer things like FLAC + Cue, midi and all the tracker files you could want!
And includes a bunch of viz - and you can write your own too.
It doesn't do Winamp skins; decided I wanted to add more than they could support.
"flabbergasted" ? That's quite a strong reaction. It's somewhat normal for nerdy mc-nerdfaces, which the writer definitely is (in all the good ways), to tell people about their hardware. Or at least it used to be? Seemed pretty geek-norm to me even if it was jarring.
I chose not to write it earlier but my candid thoughts were that he seemed too old to still be doing this. Its just younger enthusiasts and professional gamers that do this, and the younger enthusiasts eventually get enough money for a mac and choose that.
The PSU is completely overkill, as if he was going to get GPU's. But then he has this completely outdated and old, power inefficient GPU in it instead, which is nothing to brag about and doubly warrants an explanation if the rig is to be explained at all. All while newer GPU's from the same company solve all of his driver and OS problems.
As web developers, we heavily rely OSS packages. One popular example is Day.js, a JS lib for parsing, validating, manipulating, and formatting dates. It's a widely-used alternative to Moment, with over 17mil weekly downloads on npm.
A critical bug was discovered in Day.js (see: https://github.com/iamkun/dayjs/pull/2118) causing incorrect date manipulation (add, subtract) when in UTC TZ. This could have severe implications for any project relying on Day.js for date-related functionality. However, the maintainer of the project appears to be unresponsive, leaving the bug unresolved and the future of the library uncertain.
This raises some important questions for our community:
- At what point should we consider a widely-used OSS project "abandoned" if the maintainer is unresponsive?
- Is forking the project the best solution, or should we first try to reach out to the maintainer through other channels?
- Are there established community guidelines around responsiveness expectations for widely-used OSS projects?
- What are successful examples of community-driven forks or maintenance after a maintainer stepped away?
I am very aware that many of these developers give their spare time for free for these projects, with little or no payment, and I am very thankful for all their work. This developer does get some money (a small amount?) through OpenCollective, and possibly also works for a company (in China?) that makes a UI library, which I think uses Day.js internally.
