I recently tried out https://daisyui.com/ (CSS only components, depends on tailwind) and so far I really like it.

It also highlights how far browser have come with new features such as dialogs, which I always implemented with (a lot of) JavaScript in the past

This library doesn't appear to be accessible. Just looking at two random components: The Drawer (https://daisyui.com/components/drawer/) doesn't trap focus inside itself (letting you tab to the page behind the drawer while it's open). The Accordion (https://daisyui.com/components/accordion/) first example is using radio buttons as a hack to avoid Javascript, which would be very confusing to screen reader users (announcing the radio buttons to them).

This is why there's so much complexity in libraries like Radix - accessibility in the real world usually requires a lot of Javascript.

> This is why there's so much complexity in libraries like Radix - accessibility in the real world usually requires a lot of Javascript.

I agree in many scenarios, but for the two you mentioned it seems like the <dialog> and <details> elements provide accessible solutions out of the box?

They do, most issues that arise from making things accessible are self inflicted. Some people just want to redesign things for the sake of design while ignoring a core principle of design (accessibility) over aesthetics.

Sounds harsh but maybe somethings SHOULDN'T be designed a certain way because it breaks a11y when there are other roads to be taken that can still look pleasant, be accessible, and way easier to maintain (less brittle JS to worry about).

StackOverflow always wanted less low-quality questions, which is now the case. Whether they still receive some high-quality ones...

But I'm sure the website still receives a lot of views, as it still is highly ranked in Google.

Do we know that it's fewer low-quality questions? Or is that just assumed because it's fewer total questions?

That was a tongue-in-cheek inference from the number of new questions going to near zero.

Yes the start menu is now very slow with the web stuff enabled.

If you disable it, it becomes snappy again. Pretty crazy to me that Microsoft allows the default option to be that slow

Or do not use caching at all until you need it

Creator of Kreya here, thanks for mentioning us! If you have any questions, I'm happy to answer them

Switzerland has this and for basically every other job as well. Apprenticeships are very common here, I did mine as a "programmer"

I further like how much diversity is packed into compsci programs in CH, e.g. time at the Paul Scherrer Institute

I'm one of the creators of Kreya [1]. We were one (or the) first to support a fully-offline, git-centric local data storage in this space.

Kreya is privacy-first since its first commit five years ago, since we were fed up with Postman and Insomnia. Happy to answer any questions

[1] https://kreya.app

This shouldn't be a problem with Windows 11 anymore? AFAIK, the "evergreen" version of WebView2 is installed by default.

It might even be better than that. It sounds like Microsoft pushed WebView2 to (at least some) Windows 10 computers (N.B. Steam says 32% of users are still on Windows 10).

Of course, the docs still say:

> Even if your app uses the Evergreen distribution mode, we recommend that you distribute the WebView2 Runtime, to cover edge cases where the Runtime wasn't already installed.

https://learn.microsoft.com/en-us/microsoft-edge/webview2/co...

I wish we knew how prevalent that situation was. Not sure what the failure mode would be. But it sure would be nice to be able to assume that a modern WebView always exists on Windows! That certainly wasn't the case back when I made my decision circa 2022.

It was added in 22H2 Windows 10.

> What is X11, Wayland, GNOME, KDE, d-bus, application ids, portals, etc. ... Compare that to developing for Windows, where most things "just work"

This is a weird complaint, and I'm saying this as a mostly-Windows developer. Windows has an insane number of technologies, many of them replacements for older replacements for older replacements ... etc going 30+ years back. Do you know how registration-free COM works, for example? Probably not, yet it is there, and if you go to the Windows section of MSDN and just start reading through the docs, you'll have to read through that too.

You can reasonably argue that it's not a thing that you actually need to know to write an app for Windows, and it's true. But similarly you don't actually need to know what d-bus is, never mind how it works, to write an app for Linux. If you use a reasonably high-level framework such as Qt, it takes care of all that for you. Hell, you can even go for .NET Core + Avalonia to get something very similar to WPF on Windows.

And then there's Electron, which lets you pretend that everything is just a browser...

Nah, writing the apps for Linux isn't difficult at all. OTOH you're right in that distribution is a pain, and end-user support across numerous wildly different distros can also be a pain (especially when they start packaging a patched version of your code in their package repos!).

> you're right in that distribution is a pain

Yeah that part is just bonkers. Take Discord, for example, probably the most popular "app" that people install on Linux these days. There is a Snap, a Flatpak, a DEB. I can't imagine how much work it is to maintain all of those. Screen sharing is broken in random versions. People say to install the DEB (if you're lucky enough to be on a Debian-based system), but oh, make sure you install via a terminal command with "--fix-broken" to install all dependencies (wouldn't the app store GUI do that? maybe not). Apparently the Flatpak is better, but don't forget to install something called "flatseal" so you can upload files (Flatpaks are sandboxed by default). I imagine Discord tech support gets a lot of angry emails from Linux users who didn't get the "flatseal" memo and think that Discord just sucks at developing software.

The train station in St. Gallen (Switzerland) has one too: https://en.m.wikipedia.org/wiki/File:Binary_clock_Swiss_rail...