So after downloading from the official downloads page and stripping away all the mjs files and "bundler-friendly" files, a minimal sqlite wasm dependency will be about 1.3MB.
For an in-browser app, that seems a bit much but of course wasm runs in other places these days where it might make more sense.
It's pretty compressible at least, sqlite3.js+wasm are 1.3MB raw but minifying the JS and then compressing both files with Brotli gets them down to 410KB.
A lot of HTML's nowadays have 100 - 300 kb. That's only the HTML (!!).
Adding 400 for such a high quality piece of DB actually borders reasonability.
And makes me think: what the hell are frontend devs thinking!? Multiple MB's in JS for a news website. Hundreds of KB's for HTML. It's totally unreasonable.
> what the hell are frontend devs thinking!? Multiple MB's in JS for a news website. Hundreds of KB's for HTML. It's totally unreasonable
They're thinking, "adding [some fraction of existing total payload] for such a high quality [feature] actually borders reasonability". Wash. Rinse. Repeat.
> They're thinking, "adding [some fraction of existing total payload] for such a high quality [feature] actually borders reasonability". Wash. Rinse. Repeat.
Context makes all the difference here. If you're considering a big chunk of size for a relational database engine, you need to ask: are you making a complex application, or a normal web page? If it's the latter, then it's not reasonable at all.
And anything that makes the HTML itself that big is almost certainly bloat, not "high quality", and shouldn't be used in any context.
1.3MB seems perfectly reasonable in a modern web app, especially since it will be cached after the first visit to the site.
If you’re just storing user preferences, obviously don’t download SQLite for your web app just to do that… but if you’re doing something that benefits from a full database, don’t fret so much about 1MB that you go try to reinvent the wheel for no reason.
If the other comment is correct, then it won’t even be 1.3MB on the network anyways.
Given how hefty images are, a full database doesn't seem too bad for the purpose of an "app" that would benefit from it, especially when compression can being the size down even lower.
We are past the stage where every piece of JS has to be loaded upfront and delay the first meaningful paint. Modern JS frameworks and module are chunked and can be eager/lazy loaded. Unless you make the sqlite DB integral part for your first meaningful page load, preloading those 1.3MB in the background/upon user request is easy.
It's a good consideration, together with the fact browsers already have IndexedDB embedded. One use case still for in-browser apps like Figma / Photoshop-like / ML apps, where the application code and data is very big anyway, 1.3Mb may not add that much
Also worth considering parsing of wasm is significantly faster than JS (unfortunately couldn't find the source for this claim, there is at lease one great article on the topic)
When we built our frontend sync system we tried a few different options. We had a fairly simple case of just trying to store entities so we could pull incremental updates since you were last online. The one we ran in production for a while was IndexedDB but found the overhead wasn’t worth it.
I played around with warm sqlite too. That was really nice but I decided against it due to the fact that it was totally unsupported.
The thing to keep in mind is that the WebAssembly sandbox model means that in theory the program (SqlLite in this case) can run wherever it makes sense to run it. That might mean running it locally or it might mean running on a central server or it might mean running nearby on the “edge”.
Is there a way to statically compile an application with SQLite and the result WASM was smaller. So for example I have an app that would use only a specific subset of SQLite. Could the SQLite's WASM be built with this in mind cutting down on code that is not used? Or is there a way to prune it having the used API surface?
In a regular compiler/linker scenario it would just be a static compilation. Here we have a JS app and WASM library.
> Could the SQLite's WASM be built with this in mind cutting down on code that is not used?
The pending 3.47 release has some build-side tweaks which enable a user to strip it down to "just the basics," but we've not yet been able to get it smaller than about 25-30% less than it otherwise is:
cd ext/wasm
make barebones=1 ; # requires GNU Make and the Emscripten SDK
Doing that requires building it yourself - there are no plans to publish deliverables built that way.
The build process also supports including one's own C code, which could hypothetically be used to embed an application and the wasm part of the library (as distinct from the JS part) into a single wasm file. Its primary intended usage is to add SQLite extensions which are not part of the standard amalgamation build.
> Or is there a way to prune it having the used API surface?
Not with the provided JS pieces. Those have to expose essentially the whole C library, so they will not be pruned from the wasm file.
However, you could provide your own JS bindings which only use a small subset of the API, and Emscripten is supposedly pretty good about stripping out C-side code which neither explicitly exported nor referenced anywhere. You'd be on your own - that's not something we'll integrate into the canonical build process - but we could provide high-level support, via the project's forum, for folks taking that route.
Since SQL takes arbitrary strings as input, this would require explicit compiler flags to disable the knobs you don't want. Can't rely on excluding unused symbols really.
That's correct, people in this thread are comparing single compressed dependency of sqlite+wasm of 400KB to the total size of web pages which run in MB. I did some actual tests while trying to use sqlite and it does adds noticeable delay on first page load on mobile due to big size+decompression+ additional scaffolding of wasm.
Pages that run into MB have small files that are downloaded concurrently so the delay is not noticeable. I wrote about this and my other expriments with in browser db in my last article but it did not get any traction here.
Thanks! That reminds me I did bring up the thing about long lists and he said that's even more reason to use checkboxes since the multi-select has such a tiny scroll window it makes it hard to scroll through to find what you need when there are a bunch of options.
Listening to the piper demos [1] and comparing to coqui [2], I'd say coqui sounds better to me, but I'd love to hear others' opinions.
Looks like Piper's latest commits were 3 months ago [3] while Coqui's were 8 months ago [4], so they both seem similar in recency.
In terms of ease of use though, especially with this project, personally Piper seems way less overwhelming.
For anyone who is interested, CoquiTTS (formerly, MozillaTTS) was great, but the project isn't maintained anymore (athough there's been some confusion about whether or not it's active. See: https://github.com/coqui-ai/TTS/issues/4022).
When traveling to other countries, and sometimes even just to other major cities, I always enjoyed seeing the different billboards. Often they would be for local businesses that I wouldn't otherwise know about, and they also convey some of the local culture. I enjoy seeing the creative typography to style a foreign language, the appeals to this or that "ideal", the quirky attempts at humor. It always seemed to me to be part of the antidote to the "this city looks like all the other cities" trend of cultural homogenization that seems to be eating the world. Sure, there are also the ubiquitous global or luxury brand ones, but you take the good with the bad like everything else, and even these will often have a different twist based on the country you're in.
The state of the art of 3d pose estimation and pose transfer from video seems to be pretty accurate. I wonder if another approach might be to infer a wireframe model for the character, then tween that instead of the character itself. It would be like the vector approach described in the article but with much, much fewer vertices, then once you have the tween, use something similar to pose transfer to map the most recent character's frame depiction to the pose.
Training on a wireframe model seems like it would be easier, since there are plenty of wireframe animations out there (at least for humans) you could use and remove in-between frames to try inferring them.
I like how this uses something familiar (Kanban) in a novel way to address the real-time tracking of a budget.
I wonder if maybe another useful feature would be to schedule a card to be automatically moved to another column at a certain date for things like contract fulfillment, or schedule a recurring card to be added each month for paychecks and monthly bills. Or is that already a feature? I could also see building upon that to see a rudimentary forecast of the state of finances at specified dates in time.
Thanks TiredGuy! Automated card is my exact next feature :D. Because I'll be using it to track my subscriptions. I'm actually super close to including it in my mvp, but decided to cut it so I could launch sooner. Thanks for the feedback!
One suggestion:
I see in request, preflight request, and preflight response, you've organized the headers into required and optional, while the response headers are not organized as such. Would be nice to show which are required for response headers.
Thanks for the suggestion but I think I did. The preflight response node lists all required and optional headers. The same as in the preflight request node.
Let me know if I missed something.
I was about to download this but then realized it's only for Apple! Are you planning on having an Android release?
Also on that front intro page I don't see any link anywhere that actually takes you to the apple app store to download the app. I thought the "App" link at the top might but it just takes me to another description section.
We are developing native apps and have limited resources. Therefore, we had to focus on a single platform at a time. However, we will release an Android version soon.
We have a download badge on the homepage, but I will ensure it is visible.
Thanks for comment!
For an in-browser app, that seems a bit much but of course wasm runs in other places these days where it might make more sense.