It just looks like stdx has copied stuff from crates and put it in a git repo.
It feels like this is worse than a package manager? As in why would I trust a random git repo to keep things up to date over the officially published channel?
UDP and TCP are Layer 3 protocols, and so is ICMP. They all fill the same bits within network packets, like at the same level. So sending an ICMP packet (protocol 1) is not the same as sending a UDP packet (protocol 17).
"Really cool" is not compelling enough for me to decide to build a product against something like this. Here is, at a minimum, I would require to even consider:
- Comparisons against other types of stacks, like laravel livewire or phoenix liveview
- Performance metrics/stats/benchmarks whatever. You need to be faster and more robust than the other things out there, or provide some other benefit
- First Class self-hosted on premise install version without dependency on any cloud provider. Kubernetes helm charts or docker compose stacks or whatever
- I do actually like that you have a time-windowed source available license. That is something that alleviates the concern if you go under
- Jepsen or similar analysis, need to make sure whatever consistency guarantees you are advertising hold up
This looks like a (not even) thinly veiled advertisement for their Convex product: https://www.convex.dev/.
I am interested in knowing who would make a decision to pay for something like this when there are a gamut of open source options available. Like what is the compelling reason to use something like this.
I don't consider this strictly open source if components it depends on (I.e, the LLM) is closed source. I've seen a lot of these Fauxpen source style projects around
I use Darktable quite extensively for underwater photos, but keen to try Ansel out and see if it's less friction.
An example of friction in darktable:
- I have an external strobe which means I have to put the exposure down to its lowest when shooting, otherwise everything is washed out. Darktable in newer versions has "Compensate camera exposure" on by default, which washes out all the images until I click it off. I'm sure there's a way to make this checkbox disabled by default, but why can't it accept what comes out of the camera?
- No favourites: there used to be a way to have all your panels in a favourites tab. This was great as I usually only use a handful of modules that I use. It's gone in later versions
- The "color balance" panel, not to be confused with "color balance rgb", it's not in any of the default tabs but useful for saturation adjustments. Why are some of these useful modules hidden? Shouldn't all modules be available by default. The only way you can get to it is by searching.
- White balance: there are now two modules and it warns you if you adjust one or the other: "white balance" the standard one on the "base" tab and "color calibration" tucked away on the "color" tab. Both modules are turned on by default, but if you adjust one or the other without turning one off it has a big red warning.
- One upgrade decided to reset export settings, and so my EXIF data was stripped out when exporting. It took me way too long to figure it out.
Thank you! I've tried to address your questions below. Most of these decisions stem from having the backend written in Rust, & using GraphQL. That decoupling in the end made it a lot easier to port from react.
- I am using a rust backend for the static files and didn't want NodeJS part of the request workflow. Most pages aren't changed all that much, like maybe once every few months & so having yet another service as part of the connection flow just adds resources/delay when it's not needed. It's a lot faster/easier/cacheable to serve a static file.
- The prerender doesn't take all that long, maybe a minute or so, it's fast enough for the site as it stands, but if it got super massive it'd be a different story. I throttle how often it happens currently, so that there is a bit of time between pre-renders.
- The frontend communicates to the backend via GraphQL & the backend is not part of svelte kit, it's an entirely separate service, and so things like `page.server.ts` won't apply.
I've moved my little hobby website to SvelteKit[1] from react and I am not regretting it.. yet.
The only main frustrations I have are:
- Library support is pretty lousy. You need to fudge things around to get working. I.e, with leaflet and others I have vendored in the libs and redone them.
- Incremental static refresh with svelte kit is not really there. I'd like a web hook or api callback that allows me to refresh certain static pages as I know that changes are made. Right now I'm doing a janky refresh using a file lock notifier & it's a blemish on an otherwise great framework.
- The URL routing in svelte kit is... a little ugly. It's really hard when you have an editor open with 5 `+page.svelte` files. I wish they re-introduced file name routes, rather than folder name routes. It is entirely a personal preference I know, but I have seen a lot of negative things around it.
~7 per day is on the low side for me. I will normally rerun the same search with different terms multiple times, especially if I'm looking for an answer to something highly technical, like easily 5-6 different searches for the same thing. And this happens multiple times per day.
There's something perverse with the incentives here: they make more money if you have to perform more searches.
It doesn't quite sit right in the same way github actions charges per minute: The slower their runners are, the more money they make.
And both of these scenarios there is no user agency to assist with that past a certain point.
It feels like this is worse than a package manager? As in why would I trust a random git repo to keep things up to date over the officially published channel?