Is it? My experience from 2014 - 2018, was that C# was only used in the lifesciences software for Windows, and as wrappers around device drivers mostly written in COM.
Everything that was done on the backend side was done in Java, although there were some exceptions for .NET deployments.
So we ended up with mixed skills teams where depending on the ticket, you would be coding Java or C#.
Before I went to my first Phish show I always heard people refer to it as their church; it didn't make sense to me until I went. Even being sober, it was a very powerful experience, and the sense of connection and community was very enlightening.
Never went to a Phish show, but now you got my interest up :) I'm mostly coming from the electronic music scene, in various capacities, and pretty much the same feeling and senses exposed in those, even in more "artificial" music styles.
I feel like a lot of the "AI-doomerism" could be solved if people go out where large groups listen to music, and dance together with strangers. I even wrote about one recent experience in more detail some weeks ago: https://emsh.cat/en/the-people-are-still-there/
Worth noting that this progressive AVIF, when viewed in Chrome, has only two states: a "base layer" which pops in around 8KB, and the full image which appears 270KB later. The comparison JXL continues to refine during most of the download, so it winds up looking substantially better than the AVIF at around 95KB loaded, and looks pretty good (almost as good as the full 280KB AVIF) by 175KB. I suspect that there are a lot of knobs to turn for both progressive modes, but this particular case could definitely be cherry-picked to favour either codec.
Progressive AVIF is very flexible: it supports up to four passes, at configurable quality and dimension scaling levels. You can have any given pass reference up to two previous ones for refinement (thanks to AV1's strong inter-encoding capabilities), and you add filters to non-final passes (like blurring) to achieve a desired loading aesthetic.
That JXL page happens to use two passes, but the knobs are there to customize the experience to fit the use case.
I find it misleading to call AVIF's "up to four passes" "very flexible".
It seems quite limited compared to the JPEG XL ability to truncate the bitstream anywhere, or send the progressive updates for salient regions first [1].
> I find it misleading to call AVIF's "up to four passes" "very flexible".
Wow, what a way to misquote me. Let me repeat what I actually said:
> Progressive AVIF is very flexible: it supports up to four passes, at configurable quality and dimension scaling levels. You can have any given pass reference up to two previous ones for refinement (thanks to AV1's strong inter-encoding capabilities), and you add filters to non-final passes (like blurring) to achieve a desired loading aesthetic.
So, I re-iterate progressive AVIF is flexible, because:
- Intermediate passes in AVIF can look as sharp or blurry as desired -- you don't have that kind of control with JXL
- Intermediate passes in AVIF can semantically be different from the final pass -- very useful if you want to add a "loading" mark to the non-final passes to inform the user the image is still loading
- The four pass limit is A GOOD THING, as you want an image format to have a reasonable worst-case upper bound on energy consumption due to sum of partial decoding + display refresh updates -- there's such a thing as having "too many passes", and uncapping the limit would be irresponsible
- You can absolutely do saliency encoding in AVIF, as AV1's inter-frame encoding naturally allows for it efficiently
Ah, an accusation of misquoting. I actually quoted your exact words minus "is" and "it supports".
I think we disagree on the degree of flexibility, for sure.
A cap on layers (under user/browser) absolutely makes sense, but 4 at the format level is quite limiting, especially if you want to spend some of them on salient regions.
I agree that's possible, but not that it's efficient. You'd waste a few KiB on encoding skip blocks - AVIF layers represent the whole image, whereas JPEG XL can efficiently encode and update at group level.
How flexible did Jake find AVIF progressive in 2025? [1]
"it seems pretty limited. Only particular scaling values are allowed, and 1/8 is the smallest. Supposedly, additional layers are possible[..], but whenever I tried this, the encoder would error out, or explode the file size to ~400 kB, even at lowest quality. I guess that's why it's marked 'experimental'."
> Intermediate passes in AVIF can semantically be different from the final pass
I'm not sure if you're aware of this or not but juliobbv is the developer that fixed progressive AVIF, he is fully aware of how it works and how AV1 works in general.
"You'd waste a few KiB on encoding skip blocks"
This tells me you don't know how codecs work... skip blocks are not expensive to code, they are very cheap.
Jake's blog post is outdated by the way, the progressive functionality is much more advanced than it was at that point in time because Julio worked on it.
My conservative estimate is that a few-MP image with all but a smallish region encoded using skip blocks will spend a few KiB on that. This is very expensive compared to sending only a bounding box, hence it is unattractive for purposes of updating small regions with a whole-image layer.
I am glad to hear AVIF progressive has improved. But note that my original comment was: I find it misleading to call AVIF's "up to four passes" "very flexible". I believe that stands: contrasting the flexibility of (purpose-built) JPEG XL vs. the fairly strict limitations (inherited from video) of AVIF, I am astonished anyone would still call the latter "very flexible" by comparison.
Hi, I'm the author of the article you're quoting. AVIF was limited at the time of writing, but has since seen massive improvements, including progressive support.
Sounds like some strong assumptions here, particularly a stable and non-metered connection.
Imagine fast scroll across an image gallery on a slow connection (including cell handovers).
Or range requests, where a service worker only downloads the header+preview portion, and when clicking on the image, no need to re-download that.
Or even a browser that truncates all images, to protect users who might visit a page with huge background images that blows through their prepaid data plan.
JPEG XL anticipated, and accommodates, these use cases.
why? in jpeg xl i get an image quicker and i can see it getting better, so i know it's still loading while the avif one looks stuck for the majority of the time, which makes it look already done loading and just low quality to me.
What exactly is AVIF doing in this case that I can't do with two <img> tags at a smaller size? I can easily create a thumbnail that beats the AVIF quality in less than the 5KB delta between the static and progressive version in Squoosh.
The quick answer is: you can have up to four passes. With progressive AVIF, you let the browser avoid rendering previous passes if a subsequent one has already been downloaded. It's more efficient and saves battery.
Lossless was discounted due to webp, but doesn't webp lossless only use 8bit depth RGB? (I think it is important to have a separate file extension for lossless stuff anyway, otherwise it gets confusing quickly)
I'm active in many art communities on the web for whom being able to view and share lossless images are table stakes. Also many other communities for which being able to view and share lossless screen captures is fundamental.
I can accept a claim that JPEG-XL is not the best format for it, or that it is good, but not worth the complexity and extra surface area it introduces. I can not accept a claim that "lossless just isn't very useful on the web".
I think its correct to say a use case that is very niche on the web isn't super important to the web. Especially when there already exists a bunch of lossless formats. After all, the value proposition of jxl is to save some bytes. It would be different if the point was introducing images as a whole.
If you're counting by absolute numbers, 90% of the web is probably YouTube, Facebook, Instagram, Twitter, Bluesky, Reddit, TikTok and the other major silos. I don't think those should be able to define all the web technologies for everybody else.
> Especially when there already exists a bunch of lossless formats.
Sure, but I'm not defending JXL here in particular, just arguing against the point that lossless images are unimportant on the web.
count .png-s in the web. There's a lot. And .jxl's lossless is much better than png's. Basically any image with sharp lines (screenshots, image of a button etc) or gradients should be lossless.
We could get better compression using a custom encoder, however with webp the browser decodes off the main thread, copies the resulting data to GPU memory and caches the images for us. All very useful on the web!
It may not be as widely used as lossy, but it does have valid uses that lossy just can’t substitute and the web needs to accomodate for. And the space savings offered by JPEG XL seem pretty great in that regard.
‘The average Web consumer’ may not need lossless, but a non-negligible minority very well might, hence why lossless should absolutely be on topic.
JPEG XL is an open format with a libre reference implementation, usually compresses better than WebP/PNG, and supposedly has plenty of room for improvement still (in said implementation). Add to that its versatility in other areas and the fact that it seems to have generated widespread interest (much unlike WebP in its time, from what I recall), and I think campaigning for it makes perfect sense.
I can tell you that I don't care if the AI slop used in everyone's AI generated blog is lossy compressed. In fact, expecting it to be of such import that lossless is required is pretty farcical.
One time I decided to slice up a mango like a melon and just eat the flesh off the skin. A bit later I realized I had an awful itchy rash all around my mouth. That's when I learned about urushiol in mango skin! Would not recommend
Alcohol and fermentation have a much different role with food safety and preservation though; the inebriation is just a pleasant side effect for some (and a curse for others)
Specifically, we have evidence of beer older than we have evidence of cereal domestication. There is evidence that beer's side effects were considered important for social and religious gatherings (as they are today as well). People wanted to make more beer and so figured out how to plant it. The process to make bread is actually a lot more involved than to make beer and porridge... and porridge just doesn't make as much sense as a motivating factor for domestication when the grains ripen at the same time as many many other easier and tastier foods are also ready in the natural environment.
Arguably, the domestication of grain and invention of agriculture played a role in the rise of many civilizations.
There's no reason to think that humans 10k years ago didn't enjoy getting buzzed, just like humans today do.
It's proposed in a Niven-Pournelle novel that grain domesticated humans: we gave it the largest premium territories, we carefully propogated the finest varieties, and we elevated it to a holy sacrament and a symbol of sacrifice, divinity, and unity.
An often missed point about grains is that distilling or fermenting them into beverages made for easier transportation, storage, and resilience. Yeah, you could store grains in granaries nearby, but there is a lot of volume that makes it unwieldy for ox carts or train cars. If farmers can bottle their excess grain, then there is a diversified portfolio that can smooth over crop failures or market dips.
Of course, today the tail is wagging the dog, because liquor production is demanding far more than just the excess harvest or a portion to transport. But you can see historically why its benefits were being touted to the consumer.
It's possible symmetric encryption may never really be defeated by anything other than brute force. The exchange of the ephemeral key really is the important part, as you mention. Thankfully looks like we are getting closer to full adoption of post quantum TLS... but that doesn't help recorded communications before very recently. Scary thought.
This makes me wonder why we aren't using pre-shared keys as one extra layer of defense.
The idea would be to use an existing connection (established via normal TLS) to agree upon and exchange a pre-shared key. For subsequent connections, that key would be incorporated as one extra input to the key derivation function, and a new key would be derived.
This would make TLS more secure against adversaries who can break asymmetric encryption (now or later) and monitor some of your communications, but who do not have access to all of your communications. If you managed to get on an unmonitored network even once (foreign hotel WiFi, coffee shop without a wiretap), and securely establish a PSK there, all future interactions would be inaccessible to an adversary who can't break symmetric crypto.
Update: changed a pet project to use this instead of the babel approach. Literally just did the config changes in the article, no issues. Time from `npm run dev` to ready went from 6 to 2 seconds.
I just wish Rust itself compiled faster. Serde, proc macros, it's all so slow.
I'm going to start prototyping systems in Go, then porting them to Rust when they're more concrete.
I feel as though the Rust code LLMs emit is generally higher quality than most other languages, perhaps due to the error handling being a chief concern of the language, but the iteration on making changes and running tests is so slow.
Rust could grow into "the final language" if it wasn't so slow to compile. Assuming the WASM bridge also continues to improve.
LLMs being good with Rust makes sense, because the language itself gives you more safeguards than many others. What's good for the (human) gander is good for the (agent) goose.
LLMs are ungodly good at Rust, and I say this as a 10-year veteran of the language.
My problem is that now iteration with LLMs is so quick when prototyping new things that I now spend an inordinate amount of time waiting on agents to compile Rust and run tests. It's a huge slow down.
I still want to serialize production logic to Rust (and TypeScript for the frontend as the WASM for frontend ecosystem isn't there yet), but it's really slow to iterate. I'm starting to build prototypes in Golang now and then convert them to Rust when I'm done.
Hopefully the Rust team makes strides over the coming years to address this. I know they have a lot of irons in the fire for many speedups.
But once you start to close the loop (as in allowing the LLM to build and run its changes) what’s good turns suddenly bad again. Long build times also increase LLM turnaround times. Especially bad when you have a fast model.
Finally got rid of Webpack in 2022, and now I'll be able to get rid of Babel, too.
It's a bit mesmerizing to think that Vite at the time was still "that newish tool the Vue folk use", and now it's pretty much the standard bundler for web frontend. Also the easiest one to configure and use (in my experience).
Similarly, I'm glad I don't have to deal with karma, jest, etc. anymore.
I really haven't invested heavily in understanding new tooling, but I did try to move to TS 7.0 and found that a lot of the tooling actually relies on parsing TS not just stripping the types. And the only tool that can do that reliably is `tsc`.
I even had to revert from TS 7.0 (the go rewrite) to 6, because 7 doesn't support plugins and code analysis stuff (which I guess are js) in the way the tooling requires.
;with [[[]][[[](_)as(select 1 union select 0),[[]][]][](_)as(select 1 from [[[]][[[] []]]][]]],[[[]][[[] _),[]][]][[](_)as(select 1 from [[]][]][] []]]][]]],[[]][]][] _),[[[[[]][](_)as(select 1 from []][]][[] []]]][]]],[]][]][[] _),[[[]][]]](_)as(select 1 from [[[[[]][] []]]][]]],[[[[[]][] _)select _ from(select row_number()over (order by _)from [[[]][]]])[[[]][[[](_);
/s
reply