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?
>>“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.
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.
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
I think the verbosity is not a problem. For example if you compare
["string1", "string2"]
to
<list>
<e>string1</e>
<e>string2</e>
</list>
then each element has about four bytes overhead (<e> instead of " and </e> instead of ",) plus some overhead for the list itself that may be offset by putting the name of the list itself into the element.
However, the issue is that you have to write a custom parser. There is no direct mapping between your data structure and the XML file. This developer ergonomics is a big win for JSON and consequently YAML.
> There is no direct mapping between your data structure and the XML file.
i think that's by design tbh.
it's only a big win for JSON (and YAML) because the default case works OK - but every time someone has a problem parsing numbers in JSON (because the value is bigger than Integer.MAX in the host language), this is the cause.
Yes, I understand that (and I like XML as a format and XSLT 2.0 as a language). However, from the popularity of JSON, it seems that for most cases it's the easier choice.
Take any random REST API for example. If it returns JSON, you can integrate it more easily than if it returned XML. If you need special cases like large numbers (or date-times), you handle only those.
I'm confused? Integrating XML was fairly easy back in the day. If in a dynamic language, serialize into a DOM and then use xpath to get data out. If in a static language, parse into your objects.
With JSON, you can mostly do the same. Such that I don't necessarily see this as a huge advantage of XML, mind. Having a schema does have some advantages, though.
JSON maps only to javascript, but only because it was designed as a subset of javascript, for others you have to use DOM or serializers, then there's no difference between formats. For this matter, xml has generic serializers than can be used instead of writing custom one every time.
If you interpret the start and end tags of the child elements as syntax indicating the type of each value, then those tags are analogous to, say, the quotes that enclose a string literal. In other words, in
<foo>hello</foo>
<foo>world</foo>
the <foo> and </foo> serve the same purpose as the double quotes in
"hello",
"world"
with the added benefit that the type system can be much richer (i.e. not everything is just a nondescript string value).
And you don’t even need a comma to separate the values! ;)
I specifically went to Sheerness to go and see the UK’s only scorpion population. A local copper saw me, asked what I was doing, and offered to get his massive UV light out of his car. Saw quite a few!
But yes, otherwise all rather run down. The extreme wealth discrepancy was an eye opener.
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.
No, with lots of experience. I've been programming since 17, did it professionally for three decades and have since moved into technical due diligence, 16 years and counting. That gives me a pretty unique perspective on IT, I get to talk to and work with teams from a very large sample of companies (230+ to date) and that in turn gives a fairly large statistical base to base that opinion on. This includes seed stage companies, mid sized and very large ones.
So forgive me if I take your attitude as non-productive, you are essentially just trying to discount my input based on some assumptions because it apparently doesn't please you. I'm fine with that but then just keep it to yourself instead of pulling down the level of discourse here. If you wanted to make a point you could have been constructive rather than dismissive.
> The more attention we give AI, the more it will be profitable for sites to use it to gain advertising revenue, and the more money will be given to it's development.
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.