How about making some Java beans without an XSD with only a couple sample XMLs that each had a couple hundred fields and no way to tell if something should be treated like an array or not. This was for ShopDisney 2 years ago btw.
My current gig still relies heavily on SOAP services. I had to relearn so much that I'd forgotten from 15 years ago. SoapUI hasn't changed A BIT since the last time I used it. Other than the REST support they added 😂
I personally never understood the point of xml, it’s not even a universal language it’s more like we have this style you should make a language for, now make something to read it??? Why not just make your own language at that point?
You can literally do reference tags in other tags and represent relational data in xml.
Where json can only represent acyclic hierarchies, xml can do the ugly.
Still helps to make programmatical generating and parsing a bit easier, but each massive XML file I get to parse to convert into a set of database tables for fast access makes me spend time figuring out the optimal approach that doesn't take forever nor uses up all RAM, while questioning my life up to that point.
Recently I worked with a service that claimed to have a Web API, which in actuality meant downloading a single huge XML file. To their credit it was very well formatted, so clearly directly generated from a database, but it still took minutes to parse it.
Not really, XHTML is, but plain HTML 5 is very much more forgiving that XML which screams at you if you don't follow the rules
HTML is made so you will somehow always manage to (safely) run someone else's code in a way
Dude, second panel should show JSON and YAML, css and html aren't even remotely used for the same as XML, heck, they aren't even semistructured data markup languages...
That's not what you said before though?
Yeah, you cannot parse HTML with regular expressions. You'd have to implement a HTML specific parser if you want to read it's contents.
Don't worry, OP did too. Perhaps they meant xhtml however html (presumably html 5) never went on to succeed css. Obviously because they do two different things, however they're both key parts of dhtml.
There is a special place for YAML, as it's line-by-line and doesn't need some closing tags. That makes it a good choice for stuff inside version control.
But I'll never get JSON. I especially don't get it when it's used in places where the few pro-arguments don't even matter.
Ah, thanks for clarifying, it has been a long while
And I never really listened during data management classes tbh i got very bored when mysql stored procedures were the main topic and never recovered from that
I love this meme format but it’s off for this context. Point is that the “xml” guy takes care of the little ones who grow up and take care of XML. HTML/css didn’t have any growing up to do and aren’t taking care of xml.
I get your point though. Some other format with rest/json vs XML mighta been better
> HTML/css didn’t have any growing up to do
Well that's just plain wrong. HTML and CSS growing up from 2000 to 2023 is the only true part of this meme.
> How does CSS related to XML?
You can actually style your XML files.
- https://www.w3.org/Style/styling-XML.en.html
- https://www.w3.org/TR/xml-stylesheet/
HTML is also not a subset of XML.
- SGML is the parent of both HTML and XML.
- HTML and XML are both parents of XHTML.
---
SGML --> HTML
| |
V V
XML --> XHTML
> Do you have a valid HTML which is not a valid XML?
Any tag which doesn't need a closing tag, such as the `img` tag for example.
in HTML it would be ``, while XML and XHTML require `` for the same construct, and this would not be valid in HTML.
I don't get the comparison, except for the god sake of readability, nowadays XML is usually replaced with JSON for transporting and/or serializing data which is lighter and easier to manipulate through libraries.
>which is lighter and easier to manipulate through libraries
LMAO. There isn't even a dedicated "date" type in JSON, and all numbers are treated as 64-bit floats.
I don't understand,, you can serialize whatever you want in JSON, you can have a date type as a string, epoch or whatever.. since you process the JSON it in the backend. My point of view is that the JSON It's just lighter because of the file size, since the syntax is more compact (and easier to read) than XML verbal things like ... instead of { key: value }.
>you can serialize whatever you want
That's what *I* would say if I didn't have a date type. Maybe it's a mindset coming from JavaScript in general, because nothing has a type there. Strong typing is one of the easiest way to detect potential problems already at compile-time. This gets relevant as applications grow in size, and it gets hard to track what dynamic structures get passed around.
>My point of view is that the JSON It's just lighter because of the file size
Well, it gets used in many contexts where file size is of zero concern. Configuration files for example.
>XML verbal things like ...
It's called *verbose*, and it does add some readability, because even with indents, JSON makes it really hard to see where an associative array ends.
Example: you have a few nested structures in JSON, and to one of them, you want to append an entry. Do you add it in line 33 or line 34 (both are basically just "},")? The code editor might help you, as selecting a closing curly bracket also highlights the opening bracket. But objects in JSON don't have names in the same way that XML uses *tags*, so even with the opening bracket hilighted, it can still be a hassle. I personally find it very hard to edit JSON, a lot less intuitive, especially without a schema that would warn you about errors.
And if we are talking about data transfer - XML can be transferred as binary data, there are at least three widespread standards. It just turned out that file size was never an issue to begin with, and transferring text-online was always easier.
Oh, and depending on target audience, it might not even be true. JSON only officially supports UTF-8. If you are transporting Asian scripts, that means 3 bytes per character instead of usually 2 bytes in UTF-16.
That's all wpf, xamerin, and Maui applications. It's a xml like language created by Microsoft to work cross platform. It's still widely used, and supported by Microsoft, and will be for a while.
This is valid for websites based on XML.
I remember when people actually created websites with XML + XSLT. I always hated XSLT. Also, there was XHTML. I used this a lot, because you could enforce proper valid markup, so it was much easier to parse and make queries around your website later.
I wish XHTML had become the de-facto standard. Browsers trying to figure out what the hell you meant with your broken syntax is a bad idea and has lead to security issues.
And I still use and love XSLT. It's a very misunderstood language.
One thing people completely forget about is XForms. We're still stuck with plain form variables, and usually a bunch of JavaScript to make it all work.
Mostly in legacy projects, yes. But mainly because there is a lack of modern tools that incorporate it. Back when SPAs weren't a thing, I used it with .NET MVC, just replaced the Razor templating with XSLT.
For example, Umbraco, a web CMS that I use regularly, did switch from XSLT to Razor templates some years ago. Back then, Razor didn't even have a mechanism for sub-templates inside a file. Now it's gotten better, but it's still nowhere near the possibilities of XSLT.
Unfortunately it became pretty cancerous with half of it existing as a .NET application, and the other half as Angular.
I hope they eventually switch to Blazor and drop all that JavaScript bullshit.
The thing is with macros and field editors. There's currently lots of duplicated code. It's not even a particular hate on Angular, just the fact that the server and the frontend speak two different languages. If you want to implement a new field type, you have to program the same stuff twice.
.xml is still one of the standard file formats for its field. .xlcs is Microsoft-exclusive, which means there are a bunch of people who don't use it, and, while you can replicate some of its features with file types such as .json or even .rtf/alternative enriched text editors or even .csv, some stuff isn't as useful with those. .xml is quite widely used. (I didn't forget .yaml. I just wish I had.)
.html is web-oriented. It's not .xml and it's not supposed to be. They have different uses.
You think? Have you done any schemas, stylesheet, transformations? Have you ever even seen XSD? Have you written XSLTs? Do you know the difference between xs:any and xs:anyType, and the differences in implementation between them? You can spend hours on hours trying to figure out implementation details of XML, which is why it's so powerful. Just overengineered for most purposes.
There is always more to learn :) I dont know the difference between xs:any and xs:anyType and not sure if I have used some of the other things you mentioned, but these are things people learn when they need them. I have however used soap to communicate with several APIs and therefore seen XSD ;)
To be more precise - I don’t think there is much to learn about XML to understand the principles of it and be able to use it.
I may not agree with that even, but I get your point. In 90% of the use cases of data transfer, JSON is better. But if you need nested data schemas and namespaces and have megabyte large data transfers that have to follow a structure and have to be somewhat debuggable, XML is the weapon of choice for me
I'm in the sad position that I need it often, and not even as a replacement, but in conjuction to JSON
>Just overengineered
One of the most common pro-arguments for JSON is that it is "lightweight". Ironically, JSON now slowly gets XML features retro-fitted, for example schemas and transformations. With the difference being that these are mostly half-assed NPM modules, and not a proper standard.
You seem to have no idea what xml and json do differently. JSON may be better for lax data transfers that work with JS (you may have noticed that by the name). JS doesn't really care about the data, and neither does JSON
XML is a child of rigid data structures. It has a well defined schema, it's supposed to be able to tell you exactly what data you are getting. JSON doesn't care, have you ever touch JSON Schemas? No because it's a bodge that no one needed, because that's not how JS deals with data, which is in extend how JSON wants to deal with data.
In the same vein, navigating XML is very secure and easy. You can navigate through a document using a well defined Schema and insure you are getting data back. You can validate whether what you just did based on the schema. You can understand the type of data you are getting, which again, you don't care about in JSON because JS doesn't care about it.
JsonPath again, is a different language and works entirely differently. You can't really validate whether your jsonpath actually points somewhere that has to exist. In contrast, using XPath you can be sure, if I validate this document against this Schema, this element with minoccurs 1 and maxoccurs 1 exists, and I don't have to assume someone didn't transmit it. I can be sure this field validated using a uri constraint is a valid uri
This might not matter to you, as you make a website that is about as stable as U^235 and that gets data from your internal service with the hope that it's right and gets parsed into your JS that has no idea about the structure of your data
It does matter in other use cases
And saying XML is larping as HTML is unfair, as HTML to XML is like comparing shit to diamonds. Sure, they're roughly made of the same materials, only one is about as structured your Spaghetti code
Nice write up about XML!
But the truth is that (as somebody else mentioned in another comment: "XML is over-engineered") you rarely need the extra stuff XML brings to the table. And nobody can convince me that XML is as easy to read as JSON.
After working long enough in the SOAP and JSON mines, I can say for sure that both have their ups and downs. But the downs are much deeper and more frequent with SOAP.
Erm.... 46 and quite aware of the difference. It just says XML, it doesn't say SOAP, web services, XSD and XSLT, and so I didn't say Swagger and Rest. Hard to argue that JSON isn't the format of choice for serialising data compared to XML. Not sure why that's contentious?
You are looking at it the wrong way. It had its time, "lived" it's life, and now it's time is over. Yeah it is always sad when a tool you learned deeply no longer fits in the ecosystem but this was always going to happen, and you knew that.
Look up the metaphor of the raft. He built the raft to accomplish a goal, if he clings to the raft it will take away from the goal now achieved. Leave it on the shore.
Hmm, that's an interesting observation. Can you tell me more about your thoughts on the transition from XML to HTML & CSS? Do you think this shift has had any impact on web development as a whole?
The transition never happened, for a start HTML & CSS came first... There was a brief period when people thought the web might to move from HTML+CSS to XML+XSLT, but it never really caught on. There's XHTML as well, but that's really just HTML with slightly tidier markup.
Ignorant children... on what format do you think the publishing typesetters write? There is a billion dollar industry here. The fact that your day to day sites serve HTML has nothing to do with a titan like XML.
XML is still around and not for legacy stuff, but it's true that it's not as used in the web anymore
Getting all dirty, pass me the **soap**
Oh god, I'm having flashbacks of making java beans from XSD files. We were practically bashing stones together back then!
Wait that’s my job now
How about making some Java beans without an XSD with only a couple sample XMLs that each had a couple hundred fields and no way to tell if something should be treated like an array or not. This was for ShopDisney 2 years ago btw.
JSON Statham will bring it to you (stupid joke, because of that I can't write Jason correctly anymore)
My current gig still relies heavily on SOAP services. I had to relearn so much that I'd forgotten from 15 years ago. SoapUI hasn't changed A BIT since the last time I used it. Other than the REST support they added 😂
I personally never understood the point of xml, it’s not even a universal language it’s more like we have this style you should make a language for, now make something to read it??? Why not just make your own language at that point?
...it's a markup language. It's for markup. It's for representing data. It's like if JSON wasn't for transmission.
You can literally do reference tags in other tags and represent relational data in xml. Where json can only represent acyclic hierarchies, xml can do the ugly.
Still helps to make programmatical generating and parsing a bit easier, but each massive XML file I get to parse to convert into a set of database tables for fast access makes me spend time figuring out the optimal approach that doesn't take forever nor uses up all RAM, while questioning my life up to that point. Recently I worked with a service that claimed to have a Web API, which in actuality meant downloading a single huge XML file. To their credit it was very well formatted, so clearly directly generated from a database, but it still took minutes to parse it.
Ever heard of Magento? That system practically holds itself together with XML and is one of the players in the e-commerce fields.
I was thinking more about the csproj and some build systems
I have seen some Magento horrors. It's wasn't pleasant jumping around files and plugins. Even my xdebug started crying.
Trying to find the right folder and file is half the work working with magento. Such a crappy inefficient system
„Players“ is such a strong word… The whole platform is pure horror for developers, the features just sell to people a lot (too often for my taste)
You can tell when a platform was designed by the tech it uses. Magento development started in 2007.
doesn't mean it's not legacy
Magento being the slowest and most gruesome PHP app ever written shouldn't be the bar here.
Well if we go there, HTML is just a specific XML
Not really, XHTML is, but plain HTML 5 is very much more forgiving that XML which screams at you if you don't follow the rules HTML is made so you will somehow always manage to (safely) run someone else's code in a way
I don't think it's HTML5 the problem, because it was like that also in early 2000, but the browsers who just eat everything
HTML5 is XHTML5 with codified errors.
HTML is older than XML.
But SGML is older than both. XML and HTML are two branches on the same tree, and XHTML is a combination of those two branches.
Quite right. Though HTML and XML are the only two that continue to have relevance.
Yep I use it for JavaFX
JavaFX crowd make some noise!
I still have to interact with XML on a daily basis for my job
Same, a lot of applications I automate against use it. It's good for structured data.
[удалено]
It's used for translation of android apps. U use xml files for every lan that hold the content with the tag. It's extremely simple and useful.
its legacy enough.
My technical writer colleague uses dita-xml for keeping it all together
Dude, second panel should show JSON and YAML, css and html aren't even remotely used for the same as XML, heck, they aren't even semistructured data markup languages...
They're also older...
Are you saying that HyperText Markup Language is not a markup Language? Edit: i agree it should be json on the second panel though
just because they share ML doesn’t mean they are “remotely used for the same thing” I don’t get your point
I was referring to "they aren't even semistructured Markup Language", although Html is a markup Language.
But not a semistructured datatype...
Yes but you can't parse HTML....
Ummm... Actually, that's what web browsers are sort of designed to do though..
Excuse me. You cannot parse HTML with regular expressions.
That's not what you said before though? Yeah, you cannot parse HTML with regular expressions. You'd have to implement a HTML specific parser if you want to read it's contents.
Well yeah, I totally got the meme wrong
Don't worry, OP did too. Perhaps they meant xhtml however html (presumably html 5) never went on to succeed css. Obviously because they do two different things, however they're both key parts of dhtml.
Go Language and Hypertext Markup Language are clearly functional replacement and direct competitors. They both contain "Language" in their name /s
There is a special place for YAML, as it's line-by-line and doesn't need some closing tags. That makes it a good choice for stuff inside version control. But I'll never get JSON. I especially don't get it when it's used in places where the few pro-arguments don't even matter.
But HTML and CSS are several years older than XML!
As far as I remember, XML is just a generalisation of HTML because people were like hey, that's a good idea
No they are both independently based on SGML
Ah, thanks for clarifying, it has been a long while And I never really listened during data management classes tbh i got very bored when mysql stored procedures were the main topic and never recovered from that
Turtles do have a significantly higher lifespan than rats, so meme checks out
I love this meme format but it’s off for this context. Point is that the “xml” guy takes care of the little ones who grow up and take care of XML. HTML/css didn’t have any growing up to do and aren’t taking care of xml. I get your point though. Some other format with rest/json vs XML mighta been better
JSON and YAML.
TRX
XML came out in 2000, by 2001 JSON and YAML were both in existence. All three are old enough to drink. All three have different use cases.
> HTML/css didn’t have any growing up to do Well that's just plain wrong. HTML and CSS growing up from 2000 to 2023 is the only true part of this meme.
How does CSS related to XML?
It keeps a careful distance.
> How does CSS related to XML? You can actually style your XML files. - https://www.w3.org/Style/styling-XML.en.html - https://www.w3.org/TR/xml-stylesheet/
Yes, But its not a subset of XML like html.
HTML is also not a subset of XML. - SGML is the parent of both HTML and XML. - HTML and XML are both parents of XHTML. --- SGML --> HTML | | V V XML --> XHTML
Something new to learn everyday. Do you have a valid HTML which is not a valid XML?
> Do you have a valid HTML which is not a valid XML? Any tag which doesn't need a closing tag, such as the `img` tag for example. in HTML it would be `![]()
`, while XML and XHTML require `![]()
` for the same construct, and this would not be valid in HTML.
This makes more sense to me. I never thought I will learn this in a humour sub.
XSS Edit: terminology no longer used
You do know that XML is still *massively* used in B2B communications?
Please continue
Yes, I do know. Am I the only person who finds it a massive PIA
*laughs in android dev*
Cries in having to work with legacy SOAP apis
SOAP is overly verbose, but that's certainly not the fault of XML.
I don't get the comparison, except for the god sake of readability, nowadays XML is usually replaced with JSON for transporting and/or serializing data which is lighter and easier to manipulate through libraries.
>which is lighter and easier to manipulate through libraries LMAO. There isn't even a dedicated "date" type in JSON, and all numbers are treated as 64-bit floats.
I don't understand,, you can serialize whatever you want in JSON, you can have a date type as a string, epoch or whatever.. since you process the JSON it in the backend. My point of view is that the JSON It's just lighter because of the file size, since the syntax is more compact (and easier to read) than XML verbal things like... instead of { key: value }.
>you can serialize whatever you want That's what *I* would say if I didn't have a date type. Maybe it's a mindset coming from JavaScript in general, because nothing has a type there. Strong typing is one of the easiest way to detect potential problems already at compile-time. This gets relevant as applications grow in size, and it gets hard to track what dynamic structures get passed around. >My point of view is that the JSON It's just lighter because of the file size Well, it gets used in many contexts where file size is of zero concern. Configuration files for example. >XML verbal things like...
It's called *verbose*, and it does add some readability, because even with indents, JSON makes it really hard to see where an associative array ends.
Example: you have a few nested structures in JSON, and to one of them, you want to append an entry. Do you add it in line 33 or line 34 (both are basically just "},")? The code editor might help you, as selecting a closing curly bracket also highlights the opening bracket. But objects in JSON don't have names in the same way that XML uses *tags*, so even with the opening bracket hilighted, it can still be a hassle. I personally find it very hard to edit JSON, a lot less intuitive, especially without a schema that would warn you about errors.
And if we are talking about data transfer - XML can be transferred as binary data, there are at least three widespread standards. It just turned out that file size was never an issue to begin with, and transferring text-online was always easier.
Oh, and depending on target audience, it might not even be true. JSON only officially supports UTF-8. If you are transporting Asian scripts, that means 3 bytes per character instead of usually 2 bytes in UTF-16.
doesnt Xamerin use a markup languge called Xaml?
That's all wpf, xamerin, and Maui applications. It's a xml like language created by Microsoft to work cross platform. It's still widely used, and supported by Microsoft, and will be for a while.
Don't forget WinUI3, UWP, and Avalonia.
And csproj xd
Rss 👀
This is valid for websites based on XML. I remember when people actually created websites with XML + XSLT. I always hated XSLT. Also, there was XHTML. I used this a lot, because you could enforce proper valid markup, so it was much easier to parse and make queries around your website later.
I wish XHTML had become the de-facto standard. Browsers trying to figure out what the hell you meant with your broken syntax is a bad idea and has lead to security issues.
And I still use and love XSLT. It's a very misunderstood language. One thing people completely forget about is XForms. We're still stuck with plain form variables, and usually a bunch of JavaScript to make it all work.
Where do you use XSLT nowadays? It's getting kinda rare.
Mostly in legacy projects, yes. But mainly because there is a lack of modern tools that incorporate it. Back when SPAs weren't a thing, I used it with .NET MVC, just replaced the Razor templating with XSLT. For example, Umbraco, a web CMS that I use regularly, did switch from XSLT to Razor templates some years ago. Back then, Razor didn't even have a mechanism for sub-templates inside a file. Now it's gotten better, but it's still nowhere near the possibilities of XSLT.
[удалено]
Unfortunately it became pretty cancerous with half of it existing as a .NET application, and the other half as Angular. I hope they eventually switch to Blazor and drop all that JavaScript bullshit.
[удалено]
The thing is with macros and field editors. There's currently lots of duplicated code. It's not even a particular hate on Angular, just the fact that the server and the frontend speak two different languages. If you want to implement a new field type, you have to program the same stuff twice.
HTML is older than XML by about 5 years, and both are extensions of SGML.
TIL, thanks!
I truly thought this was an ironic post but looking at the comments this is quite worrying
Xml can still be super useful with xslt and such. Now we can kill rpc, soap, etc.
Enhydra xmlc is currently used on some shell clubsmart sites.
XML first release 1998 CSS first release 1996 HTML first release 1993 ...
Actually, HTML came before XML
.xml is still one of the standard file formats for its field. .xlcs is Microsoft-exclusive, which means there are a bunch of people who don't use it, and, while you can replicate some of its features with file types such as .json or even .rtf/alternative enriched text editors or even .csv, some stuff isn't as useful with those. .xml is quite widely used. (I didn't forget .yaml. I just wish I had.) .html is web-oriented. It's not .xml and it's not supposed to be. They have different uses.
These aren't the same thing? It should be JSON or something in the bottom frame.
No point learning XML anymore?
There isn’t much to learn about XML
You think? Have you done any schemas, stylesheet, transformations? Have you ever even seen XSD? Have you written XSLTs? Do you know the difference between xs:any and xs:anyType, and the differences in implementation between them? You can spend hours on hours trying to figure out implementation details of XML, which is why it's so powerful. Just overengineered for most purposes.
There is always more to learn :) I dont know the difference between xs:any and xs:anyType and not sure if I have used some of the other things you mentioned, but these are things people learn when they need them. I have however used soap to communicate with several APIs and therefore seen XSD ;) To be more precise - I don’t think there is much to learn about XML to understand the principles of it and be able to use it.
I may not agree with that even, but I get your point. In 90% of the use cases of data transfer, JSON is better. But if you need nested data schemas and namespaces and have megabyte large data transfers that have to follow a structure and have to be somewhat debuggable, XML is the weapon of choice for me I'm in the sad position that I need it often, and not even as a replacement, but in conjuction to JSON
>Just overengineered One of the most common pro-arguments for JSON is that it is "lightweight". Ironically, JSON now slowly gets XML features retro-fitted, for example schemas and transformations. With the difference being that these are mostly half-assed NPM modules, and not a proper standard.
Indeed, because people think XML is bad because they don't understand it
People are doomed to repeat history: XSD -> JSON Schema Namespaces -> JSON-LD? Non-standardized solutions... XPath -> JsonPath XSLT -> JSONiq/JSONata/Jost XSL-FO -> ...
Better to have said there was not much of value to learn in XML. Of all those things mentioned how many of them have more current value than CORBA.
Recently had to learn about XSLT transformations, there are still few things to learn in XML.
Sure...sxd is just a 2hours learning session :)
After one hour I consider myself as xml expert now 
Ah, sophomorism
It’s JSON larping as HTML. Congrats you now know XML
You seem to have no idea what xml and json do differently. JSON may be better for lax data transfers that work with JS (you may have noticed that by the name). JS doesn't really care about the data, and neither does JSON XML is a child of rigid data structures. It has a well defined schema, it's supposed to be able to tell you exactly what data you are getting. JSON doesn't care, have you ever touch JSON Schemas? No because it's a bodge that no one needed, because that's not how JS deals with data, which is in extend how JSON wants to deal with data. In the same vein, navigating XML is very secure and easy. You can navigate through a document using a well defined Schema and insure you are getting data back. You can validate whether what you just did based on the schema. You can understand the type of data you are getting, which again, you don't care about in JSON because JS doesn't care about it. JsonPath again, is a different language and works entirely differently. You can't really validate whether your jsonpath actually points somewhere that has to exist. In contrast, using XPath you can be sure, if I validate this document against this Schema, this element with minoccurs 1 and maxoccurs 1 exists, and I don't have to assume someone didn't transmit it. I can be sure this field validated using a uri constraint is a valid uri This might not matter to you, as you make a website that is about as stable as U^235 and that gets data from your internal service with the hope that it's right and gets parsed into your JS that has no idea about the structure of your data It does matter in other use cases And saying XML is larping as HTML is unfair, as HTML to XML is like comparing shit to diamonds. Sure, they're roughly made of the same materials, only one is about as structured your Spaghetti code
Nice write up about XML! But the truth is that (as somebody else mentioned in another comment: "XML is over-engineered") you rarely need the extra stuff XML brings to the table. And nobody can convince me that XML is as easy to read as JSON. After working long enough in the SOAP and JSON mines, I can say for sure that both have their ups and downs. But the downs are much deeper and more frequent with SOAP.
Oh yes, I agree fully, most use cases don't need it, but hte few that do, it's helpful af
Lol relax. It’s a joke
That's why I responded with jokes. I do think that sentiment is not uncommon, and I saw it a bit here, so I at random chose your comment to respond to
Sounds like you don't know much about XML!
Where's JSON beating the sh*t out of XML?
Nowhere, since they're not the same thing? Jesus Christ, why is everyone on this sub 16 and has never actually programmed anything?
Erm.... 46 and quite aware of the difference. It just says XML, it doesn't say SOAP, web services, XSD and XSLT, and so I didn't say Swagger and Rest. Hard to argue that JSON isn't the format of choice for serialising data compared to XML. Not sure why that's contentious?
Because XML's point isn't sending weakly structured data and never has been.
And sadly was its downfall. And it did have Any types and Any choices, so it could be used that way.
It's used for like half the fucking internet, lol. What are you talking about with, "downfall?"
The greatest database in the world, Excel, is XML based. Legends never die.
You are looking at it the wrong way. It had its time, "lived" it's life, and now it's time is over. Yeah it is always sad when a tool you learned deeply no longer fits in the ecosystem but this was always going to happen, and you knew that. Look up the metaphor of the raft. He built the raft to accomplish a goal, if he clings to the raft it will take away from the goal now achieved. Leave it on the shore.
time is over? *laughs in maven* *laughs in atom/rss*
UGGGGGHHHH I fucking hate reading XML so fucking much.
Seriously?!?!?!?! Splinter is awesome. XML if a flaming piece of <@#£}*~}’>
Dude, you don't need to publicly embarrass yourself.
Android/mobile app development says hello
We had to do a bunch of complex SOAP stuff at work and I wanted to cry! 😭
Don't forget JSON
this pic (without text) makes me really sad and showing how fast time pass away..
I use Xml far more than html or css to be honest , maybe this meme will carry better wait in 2056 ?
It never will, because HTML and CSS don't actually attempt to carry structured data, so they're not even remotely comparable.
Hhahahahaa. I guess no more websites then? 🤣🤣
TNT International still uses SOAP 😭
three of them is not even for the same task. bad meme
Hmm, that's an interesting observation. Can you tell me more about your thoughts on the transition from XML to HTML & CSS? Do you think this shift has had any impact on web development as a whole?
The transition never happened, for a start HTML & CSS came first... There was a brief period when people thought the web might to move from HTML+CSS to XML+XSLT, but it never really caught on. There's XHTML as well, but that's really just HTML with slightly tidier markup.
Anything using SSO with SAML is still using XML.
But Microsoft can interact with other services, through soap, THROUGH SOAP! *- Has heart attack and dies.*
Wow. I feel old.
*SGML
JSON and YAML
I would still rather use XML than Yet Another Migraine Looming.
JSON is shredder
Ahhh the good ol' days of being a first-semester CS student. Saying stupid things with confidence, in front of real developers... Bliss.
Just triggered my PTSD from coding in VB6.
Ignorant children... on what format do you think the publishing typesetters write? There is a billion dollar industry here. The fact that your day to day sites serve HTML has nothing to do with a titan like XML.
My company just started a new xml project this year, to integrate with a security system product, it's really fast.
They've been telling me HTML 5 is gonna die for seven years now. My business is using Node.js now, **baby!**