KnobbleMcKnees

Hard agree. They also glossed over JS using a single threaded model precisely to avoid the huge mental overhead of dealing with multi-threaded models (I'm saying this is why it happened and this is the problem they aimed to solve, not advocating either way).

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.

>Not happy about this post. Instead of asking to stop, they should do just what they suggest, without further ado - distribute the income to the ecosystem devs the way they see fit. Make it transparent, make application to these funds possible, make feature bounties, write it besides the donation button.

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?

The qualities of sets that arrays don't have (and vice versa) are irrelevant to the point of neither being implicitly representable in XML.

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.

Yeah this was what I was going for, same point stands

No you've misunderstood my point. This doesn't work for cases where one child is in fact a property that is a complex object.

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

vs

    parent:
      - child: name

Try converting each of these to JSON. The former will give you an object property called child, the latter will give you an array property called child with one element

This is a bad take. Let me sum up.

>>“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.

That arrays point is such a weakness in XML that I rarely see addressed. Arrays and lists are such a common data structure in almost every programming language of the past 40 years that not having first class syntax for representing them is absurd and a huge weakness that makes XML a non-starter for me.

I agree with this, and also in a complimentary way, but it all seems very non-idiomatic for Go. But I am not a Go expert by any means.

Which, they didn't. Per the aforementioned hardware safety features.

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

I couldn't have guessed that Sheerness had a natural scorpion population and yet somehow it isn't surprising either.

There are lots of hardware features that enable cutoff (such as thermal runaway detection) but that's irrelevant to situations in which the environment has not been prepared for printing.

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.

Oh, so, without experience. Understood.

It also works where you don't have ssh to tunnel files, which is true for many servers in many professional environments.