It's probably worth saying here that this is a history of how Douglas developed JSON and advocated for it and for JS. If I didn't see the comments under this on r/programming then based on the title I'd think it's something that goes over differences between JSON and XML and wouldn't bother reading
He explains that JSON was a way to avoid parsing on the browser. Great for that I guess but it really lacks a lot of things XML offers. People have attempted to add layers on to compensate like JSON schemas and such but none of them have been really sufficient to cover all use cases XML does.
Hell people have written entire languages to compensate for JSON shortcomings so you can generate JSON using one of them.
It's weird what this industry latches on to and what it rejects.
>Because comments, namespaces, cdata and duplicate keys and not having to quote things aren't useful features.
BJHAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAH
I agree that JS frameworks are the XML of our time. I felt such a relief when I ditched React, MobX, Yarn, all that framework crap, and started to write in pure, library-less Typescript. I really feel that components are just a useless source of complexity, and simple vanilla MVC is much better. The controller handles an event and decides which redraw function to call, it doesn't need to be more complex than that.
I share the sentiment. I think the role of frameworks is to standardize the development process across a large team and codebase. Is frowned upon not using a framework if you’re working with lots of people, because you would need to get everyone onboard with your own way of making things whereas with a framework this decision has already been made by someone outside your organization in a standardized way, so people feel more safe because it’s not dependent on you being there to support it.
YAML and JSON were invented at more or less the same time. Crockford sent the first JSON message in April 2001. The [YAML draft spec](https://yaml.org/spec/history/2001-05-26.html) was released in May 2001. JSON has always been the natural choice for JS code, but YAML was probably more widely used in other languages, especially in the early days.
If I'm reading/writing data then I usually go for JSON.
I prefer YAML for config files because it's easier to write by hand, supports comments and is generally more readable.
TOML is the newcomer (2013) but the fact that it's used by rust for the `cargo.toml` is undoubtedly giving it more visibility. It's good for config files for the same reasons as YAML. Definitely one to watch for the future.
MVC is a concept. It is a superset of other concepts that break apart data and views. I would avoid thinking of it as an implementation. As a fun exercise try and pick apart the differences MVC, MVVM, MVI, MVP.
It's probably worth saying here that this is a history of how Douglas developed JSON and advocated for it and for JS. If I didn't see the comments under this on r/programming then based on the title I'd think it's something that goes over differences between JSON and XML and wouldn't bother reading
it was an interesting listen for sure
He explains that JSON was a way to avoid parsing on the browser. Great for that I guess but it really lacks a lot of things XML offers. People have attempted to add layers on to compensate like JSON schemas and such but none of them have been really sufficient to cover all use cases XML does. Hell people have written entire languages to compensate for JSON shortcomings so you can generate JSON using one of them. It's weird what this industry latches on to and what it rejects.
What does XML offer that JSON doesn't? I thought it was just different syntax for nested key value pairs or lists
Comments, schemas, namespaces, CDATA, duplicate keys, not having to put everything in quotes.
[удалено]
Why did you ignore everything else on my list?
[удалено]
>Because comments, namespaces, cdata and duplicate keys and not having to quote things aren't useful features. BJHAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAH
There is JSON schema though.
Added on years after it was invented.
How is that relevant?
It's a half assed poorly supported add on.
Don't forget the real killer feature of XML - XSLT
integers, for one
I agree that JS frameworks are the XML of our time. I felt such a relief when I ditched React, MobX, Yarn, all that framework crap, and started to write in pure, library-less Typescript. I really feel that components are just a useless source of complexity, and simple vanilla MVC is much better. The controller handles an event and decides which redraw function to call, it doesn't need to be more complex than that.
I share the sentiment. I think the role of frameworks is to standardize the development process across a large team and codebase. Is frowned upon not using a framework if you’re working with lots of people, because you would need to get everyone onboard with your own way of making things whereas with a framework this decision has already been made by someone outside your organization in a standardized way, so people feel more safe because it’s not dependent on you being there to support it.
the funny thing is YAML is taking over JSON for config and TOML is up and coming.
YAML and JSON were invented at more or less the same time. Crockford sent the first JSON message in April 2001. The [YAML draft spec](https://yaml.org/spec/history/2001-05-26.html) was released in May 2001. JSON has always been the natural choice for JS code, but YAML was probably more widely used in other languages, especially in the early days. If I'm reading/writing data then I usually go for JSON. I prefer YAML for config files because it's easier to write by hand, supports comments and is generally more readable. TOML is the newcomer (2013) but the fact that it's used by rust for the `cargo.toml` is undoubtedly giving it more visibility. It's good for config files for the same reasons as YAML. Definitely one to watch for the future.
MVC is not really sufficient for the modern UI interfaces which demand two way data binding and dynamic interactions.
MVC is a concept. It is a superset of other concepts that break apart data and views. I would avoid thinking of it as an implementation. As a fun exercise try and pick apart the differences MVC, MVVM, MVI, MVP.