@stevehume Every issue immediately affects all users. Just like in nature monocultures are not very resistant. It’s a fair point.
And it’s funny, because I think a major reason why that monoculture exists is to fight the browser monoculture we would have otherwise.

@stroughtonsmith The two main reasons to use List's are:
a) reusable rows
b) row actions
[c) standard editing behaviours]
It's more like you _have to_ reach for ScrollView, because SwiftUI List is still weirdly b0rked after all those years.

@stroughtonsmith This claim is very weird: "The List vs. ScrollView Reality Check - Many of us have been defaulting to List the second we need a scrolling column of data. The team made a point to clarify that List should really be reserved for highly specific, uniform data structures, or when you absolutely need built-in swipe actions. For almost everything else? You should be reaching for a ScrollView paired with a LazyVStack or LazyHStack."
#SwiftUI

@simonbs I'm running my website and stuff (like irc.noze.io) on a tiny VM on #Scaleway for some 10+ years. Worked well for me (they originally attracted me w/ cheap $3/m 4-core ARM based dedicated servers). I use their "S3" for SwiftPM Catalog.
But recently they killed my tiny-VM tier ($5/m) and apparently the only "automatic" transition was to a $35/m instance. I wasn't amused. Probably going to switch away over that. To Hetzner I suppose.

@marchyman Since you are talking about file URL's, are those actually file:// URL's and you load them synchronously in the tasks? Never do that. For loading things from the FS, use a dedicated thread pool / concurrent GCD queue.
Swift Concurrency uses a limited size thread pool and expects guaranteed forward progress. "maxConcurrentTasks" is nothing you have control over w/ the shared concurrent pool.

@martinhoeller @obrhoff I don't. I put an egg on it ;-) (on a regular Schnitzel, not an actual Wiener one)