Agree on Astro. It's great for documentation/blog sites but quite unopinionated so can easily be used for varied site structures. Unlike certain other frameworks, there is no magic in Astro. It generates very straightforward HTML.
There is actually a fair bit of magic in Astro, like its proprietary use of its own frontmatter-like section, magic MDX parsing (but only in some parts of certain files), the way it handles componentization and imports, etc. Especially if you want to use it with islands for React/Vue/Svelte, or integrate web components. "Collections" are also magic, especially when used with the separate Gatsby-like documentation engine (Starlight: https://astro.build/themes/details/starlight/).
It works great for simpler sites and blogs. But for more complex setups, the magic often gets in the way of doing simple things in a way that more mature frameworks like Next figured out through trial and error and have documented, either officially or in user reports. Astro doesn't quite have the reach yet and the docs are minimal, so when you stumble into a situation, it's really hard to find help.
The lack of proper IDE debugging also makes it really really hard to step through errors on the server side.
Don't get me wrong, I'm very happy that Astro is an option, especially for simpler sites where Next etc. are overkill. But it's still a framework with a fair bit of magic, and for any moderately complex site, you'll likely eventually hit a use case where the magic gets in the way and there's no clear way to solve it.
You are correct about compile time magic. Runtime magic is minimal (the code runs when and where you think it does). And yes, Starlight is a foot gun IMO. It takes a framework that is designed to be easily learned and makes it even easier to use, but at the expense of the learning.
I made CSVFiddle because I wanted a quick way to query CSV files with SQL and share the results with other people.
The app runs 100% in-browser, so the data you import and the queries you write are never sent to a web server. When you share the URL to a workspace, all of its queries and references to CSV files are just encoded in the URL fragment.
In-browser querying is made possible by DuckDB-Wasm, which has been an awesome project to work with:
There are definitely limitations with CSVFiddle (e.g. sometimes the auto-parsing feature doesn't accurately interpret the imported files), but so far it's been useful for a range of data tasks.
One of the feature ideas I have is letting people to view CSV files.
I don't want to implement my own csv viewer and would rather integrate with tools like csvfiddle.
I.e. the user would right-click on a .csv file in my file manager, one of the options would be "View in CSVFiddle".
When chosen, I would create publicly visible, CORS-compatible url for the .csv file (so that you can fetch() it) and launch cvsfiddle.io?url=<url> in a new window.
Does it work with really large files? Like, >100mb or so. I was considering making something similar but with sqlite.js [1], but the problem with it is that it loads everything in memory, so I wasn't entirely sure how it will deal with larger workloads.
For personal notes, check out Nvalt [0]. The search is blazing fast. I linked it with SimpleNote [1] so changes sync instantly between my laptop and phone. It also plays well with the Typora [2] markdown editor
Have you set up your UUID and HASH according to the post? You'll actually need to run the app through mitmproxy yourself to get your unique credentials. Then, just drop those into the variables at the top of the script.
I just added some error handling to the script to make this a bit more obvious!
[0] https://astro.build/
[1] https://trumpordertracker.com/