Yep, as the sibling said, it’s to prove the point in a snarky manner. The yellow-on-white color, the wobbling, upside down path of text, the font choice, the unrelated image; all of these serve to make the concept actively hard to process.
Hopefully this sparks a little “wow I wonder if my image of text was also hard to read like I just experienced” moment.
We use the WASM build of DuckDB quite extensively at Count (https://count.co - 2-3m queries per month). There are a couple of bugs we've noticed, but given that it's pretty much maintained by a single person seems impressively reliable!
I'm confused, nothing about their pricing looks that weird. Businesses don't typically have large BI teams so you can ride that $199/mo $2400/year for a long time which is so small most SMBs can probably expense it without approval.
Author here. Thank you all for the comments. I take full responsibility for stupidly using an image for posting the code snippet. Sorry for that! Also, the article was originally posted almost 2 years ago (and "resurrected" with the recent migration to Medium). This is why a fairly old DuckDB version is referenced there. Some of the issues I observed are now gone too.
Obviously, many things have changed since then. We've experimented extensively and moved back and forth with using DuckDB for our internal cloud processing architecture. We eventually settled on just using it for reading the data and then handling everything else in custom workers. Even using TypeScript, we achieved close to 1M events/s per worker overall with very high scalability.
However, our use-case is quite distinct. We use a custom query engine (for sequence processing), which has driven many design decisions.
Overall, I think DuckDB (both vanilla and WASM version) is absolutely phenomenal. It also matured since my original blog post. I believe we'll only see more and more projects using it as their backbone. For example, MotherDuck is doing some amazing things with it (e.g., https://duckdb.org/2023/03/12/duckdb-ui) but there are also many more exciting initiatives.
> [wasm] is executed in a stack-based virtual machine rather than as a native library code.
Wasm's binary format is indeed a stack-based virtual machine, but that is not how it is executed. Optimizing VMs convert it to SSA form, basic blocks, and finally machine code, much the same as clang or gcc compile native library code.
It is true that wasm has some overhead, but that is due to portability and sandboxing, not the stack-based binary format.
> On top of the above, memory available to WASM is limited by the browser (in case of Chrome, the limit is currently set at 4GB per tab).
wasm64 solves this, by allowing 64-bit pointers and a lot more than 4GB of memory.
The feature is already supported in Chrome and Firefox, but not everywhere else yet.
The JVM is designed around Java. That's really the main difference, and it brings some downsides for the goals of wasm, which include running native code - think C++ or Rust. The JVM is great at Java, which relies on runtime inlining etc., but not at C++, which assumes ahead-of-time inlining and other optimizations.
In the past few years there was this blog post[0] that clarified this. It moved the restriction on serving a "disproportionate percentage of pictures, audio files, or other large files" to another part of the TOS dedicated specifically to the CDN part[1] and clarified that, if you're using Cloudflare add-on services Stream, R2 (their S3), or Cloudflare Images, then you won't be at risk of termination.
In this case 25 lines of code is 50 kB of image binary.
Also it cannot be searched via search engine. Nor can it be read with screen reader.