The other thing they've missed in why people moved to react in droves is so simple it's possible we've just forgotten it because it's become such a de-facto approach: co-location of declaration, behaviour and styling.

React took us out of the "X belongs with all the X things" mental model and allowed us to create isolated "X does this and looks like this" things that require far less mental overhead to drop into while making changes to a potential foreign codebase.

This is _exactly why_ Facebook preferred React to the status quo. Engineers changing one thing in one place with predictable effects is wonderful for teams operating at wide/deep scales.

Again, I'm not advocating for any of this, I just don't think skipping over history or twisting it into an unrecognisable ball gives any forward momentum to conversations about the evolution of UI/UX.

Additional admin that will lead to more costs in a self-fulfilling cycle. This is a bad idea. People who are donating are already doing so with intent. Trying to gues where their money would be best placed is playing unnecessary financial games. They're a software developer, not a pension fund manager.

>Once someone stops donating, it is unlikely they will put up the effort of continually researching on which client/dev to support. This would be much better handled by Jellyfin maintainers.

They're already using the client just as they're using Jellyfin, how is this any more effort than what they've put into donating to Jellyfin directly?

You're either providing complex objects as properties or you're providing a list of complex objects. Worse, you can have a combination of both. Without a schema it is not possible to infer whether either or both is happening.

XML claims to solve the problem of attributes vs children but then falls short at the first hurdle by not discerning between a single complex object as an attribute and an array of complex objects as children.

JSON and YAML do not have this problem as they are explicit in their representation.

YAML example:

    parent:
        child: name

    parent:
      - child: name

>>“I need to configure this server and the server needs to know if this value is true or false.” >No, that’s bad. Don’t do that. That’s not a good use for XML.

First, the primary case that people use YAML for is not appropriate for XML? I don't agree with this but, taking it on face value, it creates a YAML strawman to attack.

Second, the rest of the argument boils down to "I don't like how floats are parsed in my language of choice". Guess what? You're storing your version strings in the wrong data type. Stop storing semver and it's variants in floating point types, that's not what they're for.

Finally, this is ultimately a "considered harmful" article, which is always a red flag.

Extremely broad and reliable rule of thumb: hardware safety features > software safety features

[0] https://www.reddit.com/r/unitedkingdom/comments/u2vu5x/i_thi...

For example, your workshop may be well ventilated during the day and completely closed up at night. All the safety features in the world don't add up to a 100% safe usage experience for any piece of hardware. You don't want your printer doing this for the same reason you don't leave your table saw running when locking up for the night. Technically safe, but unadvisable.

Pretty obvious slippery slope fallacy.

Starting with "I'm okay" was the right thing to do in context: an unexpected call from a child at an ominous time of day is the context, and knowledge of their safety is therefore paramount. But following it with a riddle about bulls is useless nonsense in the same context.

Putting that aside, I didnt really appreciate this either:

>Though a bit angry

Angry at your son for being in a car accident? Was this before or after finding out the reason for the accident? Where is this context and why isn't it provided in the same structure you just outlined several paragraphs earlier?

The fruits of labor grow ever higher. By which I mean: In the early days of a startup the problem space is ripe and plentiful, the impact you can have is outsized, and the pool of people with which to share it is the smallest it will ever be.

As a company grows, all three of these factors are subject to strain. The problem space becomes sparser, outsized impacts are recognised further up the ever-growing hierarchy, and the pool of people with which you're sharing your impact becomes larger and recognition becomes shorter lived and more diffuse.

Your halfway-house "build your life around your career" mentality appealed to me in my early 20s when I was on starter salaries and was unmarried and childless. That is no longer the case and you couldn't - as I've had the pleasure of telling several interviewers - pay me to return to it.