Live data from Hacker News

XML is the future

bitecode.dev

81–90 of 408 posts

Re: XML is the future

#81
post #30

It's easy to just mark XML off as one of the many fads in tech given how many there are. But I think it's much more worthwile to dive into the particulars of why it failed. While they're all fads, some of them share commonalities that, in hindsight, I think we can say were major catylsts to their downfall. With XML, it failed because something like JSON was much simpler. Time and time again I see people saying that j…

> With XML, it failed because something like JSON was much simpler.

No. XML was introduced as a simplified SGML subset/profile to become the base for new markup vocabularies on the web; both SVG and MathML were specified using XML (and later integrated into HTML 5). The intent was also to replace HTML by XHTML.

The idea to introduce service payloads as custom, non-UI XML and then transform those payloads into XHTML was induced by XML, but distinct from it.

However, W3C went crazy with SOAP and XML (and RDF), attempting to establish entirely new and unproven paradigms such as XForms with XHTML2 rather than merely simplifying syntax, which was bound to fail, and laid ground for browser vendors to evolve HTML outside W3C.

Then XML heads somehow felt insulted, refused to change course or learn new things. Most even didn't realize XML is just an SGML subset, and that everything that was possible using XML is by definition also possible using SGML (plus handling HTML and markdown and a couple other things making SGML more complex compared to XML). To this day, we're hearing XML heads dogmatically advertising their overly strict and verbose red-headed stepchild of a markup language, and wondering why nobody wanted to bow to XML. The article is about this kind of people who want to use their tool under all circumstances, project requirements be damned.

Re: XML is the future

#82

Earlier quoted context omitted.

I've watched this happen to so many coders in the land where people write code for companies that sell code . Personal advice: Write code for any other kind of company. They're much more resistant to fads. They don't care how you accomplish the new feature. They just want to get it done. And they certainly don't want to change their stack, ever , although in a new project you'll have more flexibility to pick the righ…

I work for a company which sells code and we are a counter example. We make gradual changes in the development stack and processes, every change needs a reason, and even though some changes are necessary, they will not be implemented soon. Some possible factors are that the company is not that big and we have a feature list to deliver. We are not VC, so we cannot afford to burn money. The devs churn is low, so we don…

Hah. That sounds like my dream job. A software company that's not controlled by VC, not burning money, actually shipping a product, and (presumably?) turning a profit... that's an actual unicorn these days...

Re: XML is the future

#83
post #64

Earlier quoted context omitted.

The original XMLHttpRequest introduced in Microsoft's IE was intended to transport XML messages from a backend to a frontend, since JSON didn't exist at the time. Realistically, originally it was just used to directly inject blobs of html into the page. Ajax just referred to utilizing that feature along with JavaScript's async functionality to create dynamic webpages. It wasn't really a technology, and I've very rare…

I had the equivalent of XMLHttpRequest LONG before XMLHttpRequest existed, back in the IE4 days. I did it by creating a tiny iframe with the target URL and then retrieving its contents. Never mind that I could also read users' hard drives, but I had AJAX long before AJAX was launched. Unfortunately there was a period of time when Microsoft patched the security issues with iframes and that was no longer possible, but…

I product I developed in the early 2000's used that technique for a dynamic tree control. That product wasn't retired until 3-4 years ago. It still worked as intended in modern browsers but you could, in theory, fire up Netscape 4.0 in 2019 and that dynamic tree would still work.

Re: XML is the future

#84
post #30

It's easy to just mark XML off as one of the many fads in tech given how many there are. But I think it's much more worthwile to dive into the particulars of why it failed. While they're all fads, some of them share commonalities that, in hindsight, I think we can say were major catylsts to their downfall. With XML, it failed because something like JSON was much simpler. Time and time again I see people saying that j…

>but I think it's much more worthwile to dive into the particulars of why it failed If you’re going to deep dive, define your terms: what did it fail at? At being the future? Kind of a straw man, even if some people did argue that. As a document interchange format? Between RSS — including podcasts! — Microsoft Office, and LibreOffice it seems to have done reasonably well. As a data interchange format? Undoubtedly JSO…

The X in AJAX is there because the devs had to put it in MSXML, because they couldn't add it to IE itself due to a code freeze, and because XML sounded cool back then. https://web.archive.org/web/20170424220609/http://www.alexho...

While there probably were some pages using XML in AJAX, many were just sending HTML fragments.

Re: XML is the future

#85
> The cloud is often just as complicated as running things yourself, and it's usually ridiculously more expensive.

This was obvious to anyone who was willing to do the maths from the beginning. One big reason for the success of the cloud that no one has talked about is that developers often have a disdainful view of the IT department and the operation people. So pushing DevOps, let them go around those people and have the instant gratification of getting all the computing resources they want when they want it immediately without going through the IT department and operation people.

Ironically, some of those developers are starting to get sick of managing the operations and want to just go back to focusing on development. Thus, the pendulum swings back.

Re: XML is the future

#86
What a cracking article. I nodded so much my neck hurts.

I'm 50 and although by HN standards, not a proper nerd (I'm a ..."web generalist?" - more project manager who can dabble in code than anything ey) and I've seen all this stuff come and go for 30+ years in the web industry.

The thing I've always done is stuck to the core trio of technologies: html, CSS and a smattering of JS when you need it. Then it's PHP for serverside.

For a very large proportion of cases, this is perfect. It's solid, known, reliable and built to last.

Granted, I build websites and not web apps. But for me this highlights the oft-quoted truism that you use the right set of tools for the job. There's no reason for me to go all SPA on my builds because that's not what I need. Ditto with React or Kubernetes or Docker. It's just adding complexity in my scenario that isn't needed.

Then there's another side which I have in spades same as every other nerd - curiosity. So yeh, I've fiddled with htmx and docker and microservices but because I'm interested in finding out more.

The crucial point comes when these two parts collide. And then really the only way is to ask - boringly - "is this the right tool for the job?", when I take in all the factors: sustainability, ease of deployment, documentation, etc.

So yeh, beware the bling of new tech blindness. Most of the time it's the boring old stuff that is best suited for the job. There's a reason after all why these technologies are still around...

Re: XML is the future

#87
post #30

It's easy to just mark XML off as one of the many fads in tech given how many there are. But I think it's much more worthwile to dive into the particulars of why it failed. While they're all fads, some of them share commonalities that, in hindsight, I think we can say were major catylsts to their downfall. With XML, it failed because something like JSON was much simpler. Time and time again I see people saying that j…

To offer a different perspective: I find XML simpler in that it tends to correspond more closely to most arbitrary data models. From ADTs to C structures, there are product types and sum types to encode, along with more or less arbitrary basic types, which have text representation. With XML you get a straightforward way to encode all those, while in JSON there is no single agreed upon method to encode sum types, but you get something like string-indexed arrays (or hash tables) instead, which are normally implemented on top, using simpler types (and are not restricted to strings). And a few arbitrary built-in types, but you have to use strings for others anyway. And no built-in extensibility, so ad hoc hacks are used when it is needed. It would be particularly awkward to use for documents, too.

I preferred JSON initially myself, since it seemed a little less verbose, I did not care about extensibility, did not consider its usage for documents, validation, did not care about using it for different data models, and it just seemed simple (FSVO) and straightforward. But then more of XML made sense. It is not perfect for everything, either, but the decisions behind it seem more justified to me than those behind JSON (though JSON still fits JS, at least).

Re: XML is the future

#88
XML is very much misunderstood. The hype that surrounded it was for a good reason, because XML is somewhat unique as a concept. There was nothing like it and still isn’t. It is not a data format or something like that. It is a notation tool. Normally you invent some syntax and parse it to get what is called “abstract syntax tree” (AST). With XML you work directly with an AST. Parsing from text is convenient because you can get a rather concise and elegant result. XML is normally way more verbose, although not that much, if well done. Yet the expressiveness is exactly the same.

Notation is what you need when you manually compose some data for machine processing. XML as a data interchange format is a misuse. Yet XML as a data description format is what it is very good at. The difference is that data interchange goes from one machine to another, but data description is what goes from a human to a machine. Data input, in other words. Complex data input. Language-like data input.

This is why XML is widely used, for example, in user interface frameworks where you need to describe very elaborate data structures. Markup is another obvious example; here you also have complex data structures tied to a piece of text. Yet markup is just a special case.

So if we are to add something to this article’s sentiment it could be an observation that we are also prone to misunderstanding things and jumping too quickly to conclusions.

Re: XML is the future

#89
post #7

I've been working in the tech industry in the US for about 5 years. Ever since I knew myself I've been coding. From middle school to high school, given any problem, like Sudoku, or keeping up daily chores, my solution was Programming! Programming wasy homebase. Then I studied it in uni, thought I was kinda good at it, and loved it. But when I started working in the industry, I realized that it's absolutely exhausting…

I checked terraform and lambda stuff in 2016 and then decided to continue with ECS bcz as an entrepreneur i find it to wonderful and time and money saving you know.

Easy to deploy and also you can utilise cheap spot instances to fullest.

Re: XML is the future

#90
post #55

I really love this review of the past 20 years. It gets to the heart of the hype/FOMO cycle that's driven so many of these stacks to short-lived superstardom, and then quickly into irreversible technical debt. I have never really understood this. My favorite comment I ever got on a coding board when I was debating the pros and cons of building my next project in the trendy platform of the day was >> STFU, go out and…

I wouldn't call XML entirely a hype or FOMO, it has become part of what we call the modern web even today. 1. The very language that websites are written in today (HTML5/XHTML) are nothing but XML dialects. 2. React's JXS language which many sites use today is also an XML dialect. 3. RSS and ATOM standards used to publish your blog or website feeds are XML standards. 4. JSON replaced XML only as an efficient transpor…

I wasn't speaking specifically about XML. If anything, XML is a poor metaphor for the 2010s hype cycle, as it was a much broader early vision to unify storage and web services than what existed at the time, and garnered a lot of industry backing as a potential standard. The fact that we ended up with JSON as a standard really seems like an historical anomaly. But who cares, I used to deal with SOAP, and AMF (which passed actual types, sometimes)... I'm just happy there's a standard, even if it sort of sucks. XML was bound to be a bad standard because it was too eXtensible, but those were the early days of the web.

On the other hand, JSX is a fucking abomination on its face. All it does is flip the ugly paradigm of writing inline javascript calls inside your HTML, so now you write your HTML inside JS. It will die in a few years, and so will React just like Angular, because tightly coupling logic to display is nifty but it always exponentially increases technical debt.

Post reply on HN