I have the same setup, with some speakers, and it works great. So happy with solution. I also use a DP instead of HDMI, so I can daisy-chain multiple monitors

I had the exact problem, and found and expensive but clean solution: I bought a U2723QE Dell screen, acting as a Hub. All my devices and RJ45 are plugged to the screen.

My laptop uses the charging USB-C port. My desktop requires 2 cables: 1 DP cable (so I can chain another screen) and 1 usb-c cable to the usb-c upstream port.

Whenever I want to switch, I just need to change the input source on my screen, between DP (desktop) or USB-C (laptop). All USB devices and internet are automatically routed to the right computer.

It works like a charm, really happy with this (but once again, that's an expensive screen)

Aren't you talking about DRF's Serializers ? Django itself does not have serializers. But otherwise, I completely agree with that statement.

I do agree with that, problem is all the other django-related packages that come with it, especially Django Rest Framework (framework is in the name here). I like some parts of it, e.g. Authentication, permissions, but IMO we often have to bend our code so it fits DRF views, and above all their serializers (which I despise). Obviously we could drop this part of DRF, but it would mean to drop DRF entirely, and I'm not sure everyone is ready to do just that.

What do you despise about their serializers? What would make them better or what would be a better approach for you?

(Genuinely curious as someone who's working on a similar idea in a different language)

- They're slow (like really slower than almost any other package, if you use their ModelSerializer) - They're quite verbose - Above all, they're trying to do way too much. A serializer should just be about (de)serialization, i.e. converting from a generic format (e.g. JSON) to / back a python object, with some validation. When you use a DRF serializer inside a view, it can do complex queries to retrieve / modify the model instance, save the instance in database, modify the serializer instance with db values (for example because of default values) and return the modified object in the HTTP response. All this logic should not be defined inside the serializer. Obviously you don't have to do it, but it means you cannot use the DRF mixins, nor the viewsets.

On the opposite, I'm in love with pydantic. Like any other package, it has issues, but it tries to solve a single problem, it's concise, validators are explicit and readable.

Obviously I don't mean any disrespect towards DRF maintainers, they're doing an impressive job, a lot of people use and love their work (and I still use it everyday)