8 ms·

XML, Java, and the Future of the Web (1997)

42 points by mxschumacher 5y ago

gjvc 5y ago
> "This is a far cry from the systems that were built and proven during the 1970s and 1980s." I wish the author had enumerated some examples here.
im3w1l 5y ago
Seeing this here, I can't help but feel that there were some good stuff in the vision for the future of xml. I'm not saying we should bring back xml, but maybe a few of the ideas should be salvaged.
- vbezhenar 5y ago
  Namespaces, schema. Though I think that namespaces are pretty trivial to add to Json. At least in a primitive form. Just add key “namespace” to some object. And there’re multiple efforts to make Json Schema. But so far most of APIs that I saw, do not use those.
  - brundolf 5y ago
    GraphQL could almost be seen as an attempt to standardize on that
  - eyelidlessness 5y ago
    JSONSchema is alive and well, at least in OpenAPI.
  - lmm 5y ago
    Namespaces and schema were exactly what was wrong with XML.
  - jdeisenberg 5y ago
    XML Schema, unfortunately, won out over RelaxNG (https://relaxng.org/ https://relaxng.org/) which has a much more solid mathematical basis and (in my opinion) is much more direct and simple than XML Schema.
- rjsw 5y ago
  Has XML gone away ? I'm working on a project that uses it.
  - agumonkey 5y ago
    not gone away, just not the revolution on top of which everything computing will be based on
  - tdhz77 5y ago
    I’m working with it. It’s not really that advantageous for this project. US code is outputted in XML and I’m having to write a of code to find certain attributes to render on a page. Seems like it will break very easily on xml updates.
  - Devasta 5y ago
    Its temporarily retreated on the web, but its still used heavily in finance. The SWIFT network is looking to migrate to XML in the next few years, and to my knowledge FedWire is looking to do the same.
  - im3w1l 5y ago
    Well we certainly didn't build an xml semantic web rendered to xhtml using xslt stylesheets. And xmlhttprequest is mostly used to fetch json. And I don't think xml is used that much for new protocols or fileformats anymore either.
- stickfigure 5y ago
  I'm pretty comfortable saying we should bring back XML. Not for RPC-ish protocols; JSON is a much better fit. But certainly every single place that YAML is used.
eezing 5y ago
And then we tried to use it.
jpgvm 5y ago
Looking back at XHTML I am reminded again and again that the best technical solution often loses out. Instead we have HTML5 which contains nothing that couldn't have been easily expressed in XHTML but have none of it's strictness that would have enabled much simpler and better browser implementations. The arguments against XHTML amounted to "but wahh it should still work even if the syntax is wrong". Thing is none of the major proponents of XHTML were advocating for exterminating the existing doctypes and their associated quirks modes. People could continue to use that but XHTML would be there, ready for the advent of non-shit programming to hit the web. People are starting to come around the ideas of strictness in programming languages again with Typescript and co rapidly gaining in popularity. It's just such a massive shame the entire Web community forced this massive wheel-reinventing cycle on us for no damn reason, completely ignoring the lessons learnt -literally everywhere- else.
- abraae 5y ago
  It's the cycle of innovation. Like a cat retching up a hair ball. It repeats over and over, until finally something is coughed up. Except in technology it takes years instead of seconds. Just like MongoDB gaining mindshare - because webscale - only for people to realise those relationships and structured types were actually quite good at keeping your data clean.
- stickfigure 5y ago
  HN folks whine about browser monoculture but it was this decision (and thousands more like it, but this one is pretty big) that meant you cannot have a simple browser implementation. Any 2nd year CS student could write an X(HT)ML parser. Writing an HTML5 parser requires FAANG resources.
  - jazzyjackson 5y ago
    Could you elaborate at all on what makes HTML5 so much more difficult to parse?
    - mynameismon 5y ago
oofbey 5y ago
XML was a dumpster fire from day one. It burned hot for a while but thankfully has all but faded away.
- tablespoon 5y ago
  > XML was a dumpster fire from day one. It burned hot for a while but thankfully has all but faded away. Thankfully we got rid of it and replaced it with data formats that got rid of the anti-features like comments.
  - oofbey 5y ago
    Douglas Crockford explicitly refused to allow comments in JSON because he saw people using them to faithfully encode XML metadata in them. So actually you could blame XML for that too. Now YAML is mostly replacing JSON in places where you want human readability, and JSON is only used for data exchange.
- deleted 5y ago
  [deleted]
narrator 5y ago
Everything XML wanted to be, JSON did better. Xml validation and namespaces were kind of half way there solutions that just made things more complex than they needed to be.
- murukesh_s 5y ago
  >half way there solutions Care to explain more? I though they were over engineered compared to bare bones JSON. For e.g. JSON schema is still catching up to XML schema and the ecosystem it had back then (XSLT, XPATH) etc. XML is of course heavy weight, but we should compare YAML against XML, not JSON - JSON doesn't have for e.g. comments, CDATA etc.
  - narrator 5y ago
    DTD validation and XML schema were overly complicated solutions that didn't cover a lot of validation cases and should have just been implemented via libraries in the target language instead of making developers maintain yet another half-baked DSL. In the end, everything is JavaScript was the better way.
- thaumasiotes 5y ago
  - XML starts with a version designator. - JSON allows arbitrary integers to be represented as numeric values. That works fine on its own, but it causes serious problems if you trust the name of the format, "JavaScript Object Notation". You can't do that in JavaScript objects. - JSON has no comments. Or version designators. The big problems in XML are named closing tags and the weird distinction between children and attributes. JSON did those things better, by not having them at all. But XML is a long, long way from "like JSON, but worse in every way". (Another big problem in XML-considered-as-an-ecosystem is the prevalence of people who want to deal with it by using regular expressions. As far as the technology goes, this is a non-issue -- it's a problem with the user, not the technology. But I do have to admit that the JSON equivalent appears to be loading the data into a parser that doesn't work, as opposed to loading the data into a non-parser that doesn't work.)
  - 5y ago
eyelidlessness 5y ago
XHTML was my preference, even had some of the semantics I wish weren’t lost (<h/>). It’s not a hill I want to die on, but I do very much wish there was a successful push for its strictness.
- Mikhail_Edoshin 5y ago
  What's that <h/>?
  - eyelidlessness 5y ago
    It’s h1-n but its hierarchy was determined by semantic parent structure rather than its own declaration. IIRC you could use similar semantics to the existing h-tags within a given hierarchy with an attribute. And I’m pretty sure this lived through some of the early HTML5 process, but ultimately didn’t make it through.
    - zozbot234 5y ago
      You can do that in HTML5 via the <section> and <article> tags. An h1 tag within one of these elements is equivalent to a subheading, and nesting <section> elements to create a deeper structure is also allowed.
      - Klaster_1 5y ago
        Here's an article on the topic: https://www.smashingmagazine.com/2020/01/html5-article-section/ https://www.smashingmagazine.com/2020/01/html5-article-secti... . Unfortunately, browsers do not support this case properly.
      - eyelidlessness 5y ago
        IIRC this doesn’t actually change the semantic hierarchy of the headings, and e.g. screen readers/reader mode will still treat both h1s as equivalent.
nivertech 5y ago
Going back to the late 90s, I think these are the only interesting bets taken by the industry: - Ericsson's Erlang/OTP - Sun's "The Network is the Computer" and "Utility Computing", IoT - "Jini" (Internet-connected toasters;), and non-PC devices - smartphones, set-top boxes, smart cards - JavaCard is still popular. - Bell Labs/Lucent's Plan 9 and Inferno OS (neither is gained adoption) - Semantic Web (which never took off). IMO, XML and Enterprise Java were regression, but so is REST, JSON and dynamic scripting languages. The most recent example is GoLang. EDIT: the XML itself is a good family of specs (especially XSD, XPath and XSLT), the problem was with abusing XML by forcing it onto everything: from configuration to logs to over-the-wire format like in XMPP. I remember IBM even sold XML Accelerator appliances ;)
- pjmlp 5y ago
  Altought one could say that "The Network is the Computer" kind of won out, in the jungle of RPC protocols that we use nowadays. Part of Inferno OS lives on what Go took from Limbo, and Go still isn't capable of using dynamic libraries like Limbo did.
  - nivertech 5y ago
    If I'm not mistaken the only part of Limbo that survived in Go is named typed channels. In Limbo/Inferno one could either download the module and run the code locally or execute the code remotely without downloading it.
    - pjmlp 5y ago
      Yes, and some would argue that named typed channels is one of the Go key features. The migration into variable_name type_def also had already taken place, although the Limbo does require : as separator.
- cies 5y ago
  > IMO, XML and Enterprise Java were regression From what? (especially XML as im not even sure what E-Java means) I think (as you also mention yourself) that XML is quite good at some things (it's schema based, can mix schemas, has namespaces, etc). Just (as you mention as well) it was overused at some point. Given we agree so much: what is it that XML was a regression from? JSON is a regression from XML wrt schemas/strictness; but then it was very low overhead (which was needed as is it gain momentum used in places where the client (JS browser app) and the server (serverside of said browser app) are both maintained by the same organization).
cratermoon 5y ago
XML suffered from the verbosity of having both open and closing tags and the weird uncertainty around attributes vs. child tags, but the real problems came from consultant-driven programming wanting to put XML everywhere and use if for everything. Ant & Maven. SAML. XML for configuration and DI frameworks. *ML everything. Did you know there was a thing called VoxML[1]? Basically XML for phone menus (remember those? Press 1 for English, Press 2 for ... Press 9 to hear these options again). SAX was the hammer applied to every problem. 1. http://xml.coverpages.org/voxML.html http://xml.coverpages.org/voxML.html
occoder 5y ago
XML is the finest example of cargo cult engineering. "The Web was a huge success, there must be a reason. Oh I know, it must have been HTML. We need more of that, and bigger, extensible! Behold, XML!" I remember shaking my head in wonder during the height of the XML hype. What were all those supposedly very smart people thinking? To me, HTML was already a huge mistake, the Web succeeded in spite, not because of it. What could you do in HTML/XML that you couldn't in s-expression, only simpler, more readable, and more writable? How many man-years have we collectively wasted having to read/write/generate/process/validate/... the mess that is HTML/XML, as opposed to a simpler, more sensible format such as s-expression?
jazzyjackson 5y ago
> The current CSS effort provides a style mechanism well suited to the relatively low-level demands of HTML but incapable of supporting the greatly expanded range of rendering techniques made possible by extensible structured markup. The counterpart to XML is a stylesheet programming language that is...Published in April, 1996, DSSSL is the stylesheet language of the future for XML documents. I started building a custom JSON representation of HTML templates with embedded functions for importing fragments and generating markup etc and soon realized I was re-inventing XSLT [0] but kept going anyway. I haven't really seen another template language that can translate one DOM tree to another. It seems like XSLT is the eventual implementation of DSSSL in TFA, I'd be curious if anyone can speak to why it never caught on. [0] https://en.wikipedia.org/wiki/XSLT https://en.wikipedia.org/wiki/XSLT
- christkv 5y ago
  Having used XSLT professionally in the early 2000s I think it was that most developers found it hard to reason about due to the recursive nature of the language.
  - Devasta 5y ago
    Absolutely, so many tried to go about it procedurally and fought the language rather than adapt to its way of thinking. Once you understand apply-templates though, it becomes much easier.
    - spiralx 5y ago
      For me it was understanding the differences between creating output by digging down from a root or by transforming a document by matching parts of it and letting the default rules handle the rest. Which is the basis of my stylesheet that turns an HTML file into its own formatted and highlighted source code: https://gist.github.com/spiralx/dcb7e5fa4e5dedd800e292848ed22aa9 https://gist.github.com/spiralx/dcb7e5fa4e5dedd800e292848ed2...
- vbezhenar 5y ago
  CDuce is a sane XSLT alternative. Although it's mostly research project, AFAIK.
Mikhail_Edoshin 5y ago
XML is language-oriented, it's like a typical programming notation but without a parsing step (or, rather, with a standard parsing step). It's a very unusual thing in this aspect and, I guess, this is the source of all the misunderstanding. E.g. it's very successful in things like layout/UI description, which is naturally language-like. And not that successful in data exchange applications, which is not language-like. (To exchange data with a language-like medium is like integrating programs by constructing their command lines; possible, but way less convenient than by using a library.) If we are to compare it with something it would be Loglan or Lojban, not JSON. The difference is that it's a working and widely used Loglan. Something like this will have to be central to navigate a vast sea of documents, which is what Web was supposed to be. Web has changed quite a bit, but those documents didn't go anywhere and the problem is as acute as ever. More acute, I would say; in 1997 there wasn't that much content there.
higon 5y ago
Idea of XML being superior to anything was the plague nearly everyone at the time caught. Evangelists would be the chosen one or so they thought. But they turned out to be a bunch of con men chasing easy fame. Having once been vaccinated with dynamic programming languages and coding-by-convention, who will ever go back there? Oh... typescript... you...!!!
Devasta 5y ago
Custom elements, CSS Namespaces, client side templating, all things that we had decades ago and were just dumped. Abandoning XML and XHTML is and continues to be the webs biggest mistake. People can pretend there were good reasons to stick with HTML but having "On Error Resume Next" baked into your language was a known bad practice even then... I am optimistic for XMLs future though, as the rise of stuff like TypeScript and Rust shows that people do appreciate strict languages nowadays, and WASM means that modern versions of XSLT can be utilized on browsers even if the browser vendors cannot be bothered implementing them.
usrusr 5y ago
It's so easy to look back at XML with ridicule, sitting on the hill of json pragmatism success. But take a moment to consider what we had before XML. Yes, XML was awesome. Back then you'd consider yourself lucky working with data available in a format that had implementations across multiple operating systems.
BiteCode_dev 5y ago
I loved xHTML, but it failed for a very simple reason: people designing it were working on a DSL to structure a document. But the vast majority of users were actually trying to make things look pretty. Most websites are currently blobs of div. Why ? Because the idea of a web page being mainly a document completely missed the part were artists fiddling with messy code would produce things that customers would like better. It's the same reason we currently see giant images on home pages and 10mo static assets to load. Because in the end, the best technical decision doesn't win. The one that gives the result the customers end up preferring wins. If you have 3 hours to get a design done, you have the choice between making it look great, or having a clean semantic and maintainable markup, you will have to drop one. And the market will select according to the result.
- pjmlp 5y ago
  Another reason for div blobs is that HTML is not a language to describe GUI applications rather documents. So one ends up with a soup of divs, made pretty with CSS and then replicate the behaviour of a beatiful dropdown fully in JavaScript, ignoring the browser builtin infrastructure. Naturally because this breaks down in every browser, it is then extended with hacks for every corner case.
- Thiez 5y ago
  > If you have 3 hours to get a design done, you have the choice between making it look great, or having a clean semantic and maintainable markup, you will have to drop one. And the market will select according to the result. Depends on whether accessibility is a priority. Depending on where you live it may be mandatory by law, for larger organizations.
  - BiteCode_dev 5y ago
    Nah, what will happen is that accessibility will be dropped 9 times out of 10. And one day, many years from that decision, they will receive a notification from the state, stating the site is not accessible. And then the site will be made that way. Maybe. The situation were a website is made accessible from the start is such a tiny rare occasion it cannot be used to explain why xhtml failed.

42 points by mxschumacher 5y ago

gjvc 5y ago

> "This is a far cry from the systems that were built and proven during the 1970s and 1980s." I wish the author had enumerated some examples here.

im3w1l 5y ago

Seeing this here, I can't help but feel that there were some good stuff in the vision for the future of xml. I'm not saying we should bring back xml, but maybe a few of the ideas should be salvaged.

vbezhenar 5y ago
Namespaces, schema. Though I think that namespaces are pretty trivial to add to Json. At least in a primitive form. Just add key “namespace” to some object. And there’re multiple efforts to make Json Schema. But so far most of APIs that I saw, do not use those.
- brundolf 5y ago
  GraphQL could almost be seen as an attempt to standardize on that
- eyelidlessness 5y ago
  JSONSchema is alive and well, at least in OpenAPI.
- lmm 5y ago
  Namespaces and schema were exactly what was wrong with XML.
- jdeisenberg 5y ago
  XML Schema, unfortunately, won out over RelaxNG (https://relaxng.org/ https://relaxng.org/) which has a much more solid mathematical basis and (in my opinion) is much more direct and simple than XML Schema.
rjsw 5y ago
Has XML gone away ? I'm working on a project that uses it.
- agumonkey 5y ago
  not gone away, just not the revolution on top of which everything computing will be based on
- tdhz77 5y ago
  I’m working with it. It’s not really that advantageous for this project. US code is outputted in XML and I’m having to write a of code to find certain attributes to render on a page. Seems like it will break very easily on xml updates.
- Devasta 5y ago
  Its temporarily retreated on the web, but its still used heavily in finance. The SWIFT network is looking to migrate to XML in the next few years, and to my knowledge FedWire is looking to do the same.
- im3w1l 5y ago
  Well we certainly didn't build an xml semantic web rendered to xhtml using xslt stylesheets. And xmlhttprequest is mostly used to fetch json. And I don't think xml is used that much for new protocols or fileformats anymore either.
stickfigure 5y ago
I'm pretty comfortable saying we should bring back XML. Not for RPC-ish protocols; JSON is a much better fit. But certainly every single place that YAML is used.

eezing 5y ago

And then we tried to use it.

jpgvm 5y ago

Looking back at XHTML I am reminded again and again that the best technical solution often loses out. Instead we have HTML5 which contains nothing that couldn't have been easily expressed in XHTML but have none of it's strictness that would have enabled much simpler and better browser implementations. The arguments against XHTML amounted to "but wahh it should still work even if the syntax is wrong". Thing is none of the major proponents of XHTML were advocating for exterminating the existing doctypes and their associated quirks modes. People could continue to use that but XHTML would be there, ready for the advent of non-shit programming to hit the web. People are starting to come around the ideas of strictness in programming languages again with Typescript and co rapidly gaining in popularity. It's just such a massive shame the entire Web community forced this massive wheel-reinventing cycle on us for no damn reason, completely ignoring the lessons learnt -literally everywhere- else.

abraae 5y ago
It's the cycle of innovation. Like a cat retching up a hair ball. It repeats over and over, until finally something is coughed up. Except in technology it takes years instead of seconds. Just like MongoDB gaining mindshare - because webscale - only for people to realise those relationships and structured types were actually quite good at keeping your data clean.
stickfigure 5y ago
HN folks whine about browser monoculture but it was this decision (and thousands more like it, but this one is pretty big) that meant you cannot have a simple browser implementation. Any 2nd year CS student could write an X(HT)ML parser. Writing an HTML5 parser requires FAANG resources.
- jazzyjackson 5y ago
  Could you elaborate at all on what makes HTML5 so much more difficult to parse?
  - mynameismon 5y ago

oofbey 5y ago

XML was a dumpster fire from day one. It burned hot for a while but thankfully has all but faded away.

tablespoon 5y ago
> XML was a dumpster fire from day one. It burned hot for a while but thankfully has all but faded away. Thankfully we got rid of it and replaced it with data formats that got rid of the anti-features like comments.
- oofbey 5y ago
  Douglas Crockford explicitly refused to allow comments in JSON because he saw people using them to faithfully encode XML metadata in them. So actually you could blame XML for that too. Now YAML is mostly replacing JSON in places where you want human readability, and JSON is only used for data exchange.
deleted 5y ago
[deleted]

narrator 5y ago

Everything XML wanted to be, JSON did better. Xml validation and namespaces were kind of half way there solutions that just made things more complex than they needed to be.

murukesh_s 5y ago
>half way there solutions Care to explain more? I though they were over engineered compared to bare bones JSON. For e.g. JSON schema is still catching up to XML schema and the ecosystem it had back then (XSLT, XPATH) etc. XML is of course heavy weight, but we should compare YAML against XML, not JSON - JSON doesn't have for e.g. comments, CDATA etc.
- narrator 5y ago
  DTD validation and XML schema were overly complicated solutions that didn't cover a lot of validation cases and should have just been implemented via libraries in the target language instead of making developers maintain yet another half-baked DSL. In the end, everything is JavaScript was the better way.
thaumasiotes 5y ago
- XML starts with a version designator. - JSON allows arbitrary integers to be represented as numeric values. That works fine on its own, but it causes serious problems if you trust the name of the format, "JavaScript Object Notation". You can't do that in JavaScript objects. - JSON has no comments. Or version designators. The big problems in XML are named closing tags and the weird distinction between children and attributes. JSON did those things better, by not having them at all. But XML is a long, long way from "like JSON, but worse in every way". (Another big problem in XML-considered-as-an-ecosystem is the prevalence of people who want to deal with it by using regular expressions. As far as the technology goes, this is a non-issue -- it's a problem with the user, not the technology. But I do have to admit that the JSON equivalent appears to be loading the data into a parser that doesn't work, as opposed to loading the data into a non-parser that doesn't work.)
- 5y ago

eyelidlessness 5y ago

XHTML was my preference, even had some of the semantics I wish weren’t lost (<h/>). It’s not a hill I want to die on, but I do very much wish there was a successful push for its strictness.

Mikhail_Edoshin 5y ago
What's that <h/>?
- eyelidlessness 5y ago
  It’s h1-n but its hierarchy was determined by semantic parent structure rather than its own declaration. IIRC you could use similar semantics to the existing h-tags within a given hierarchy with an attribute. And I’m pretty sure this lived through some of the early HTML5 process, but ultimately didn’t make it through.
  - zozbot234 5y ago
    You can do that in HTML5 via the <section> and <article> tags. An h1 tag within one of these elements is equivalent to a subheading, and nesting <section> elements to create a deeper structure is also allowed.
    - Klaster_1 5y ago
      Here's an article on the topic: https://www.smashingmagazine.com/2020/01/html5-article-section/ https://www.smashingmagazine.com/2020/01/html5-article-secti... . Unfortunately, browsers do not support this case properly.
    - eyelidlessness 5y ago
      IIRC this doesn’t actually change the semantic hierarchy of the headings, and e.g. screen readers/reader mode will still treat both h1s as equivalent.

nivertech 5y ago

Going back to the late 90s, I think these are the only interesting bets taken by the industry: - Ericsson's Erlang/OTP - Sun's "The Network is the Computer" and "Utility Computing", IoT - "Jini" (Internet-connected toasters;), and non-PC devices - smartphones, set-top boxes, smart cards - JavaCard is still popular. - Bell Labs/Lucent's Plan 9 and Inferno OS (neither is gained adoption) - Semantic Web (which never took off). IMO, XML and Enterprise Java were regression, but so is REST, JSON and dynamic scripting languages. The most recent example is GoLang. EDIT: the XML itself is a good family of specs (especially XSD, XPath and XSLT), the problem was with abusing XML by forcing it onto everything: from configuration to logs to over-the-wire format like in XMPP. I remember IBM even sold XML Accelerator appliances ;)

pjmlp 5y ago
Altought one could say that "The Network is the Computer" kind of won out, in the jungle of RPC protocols that we use nowadays. Part of Inferno OS lives on what Go took from Limbo, and Go still isn't capable of using dynamic libraries like Limbo did.
- nivertech 5y ago
  If I'm not mistaken the only part of Limbo that survived in Go is named typed channels. In Limbo/Inferno one could either download the module and run the code locally or execute the code remotely without downloading it.
  - pjmlp 5y ago
    Yes, and some would argue that named typed channels is one of the Go key features. The migration into variable_name type_def also had already taken place, although the Limbo does require : as separator.
cies 5y ago
> IMO, XML and Enterprise Java were regression From what? (especially XML as im not even sure what E-Java means) I think (as you also mention yourself) that XML is quite good at some things (it's schema based, can mix schemas, has namespaces, etc). Just (as you mention as well) it was overused at some point. Given we agree so much: what is it that XML was a regression from? JSON is a regression from XML wrt schemas/strictness; but then it was very low overhead (which was needed as is it gain momentum used in places where the client (JS browser app) and the server (serverside of said browser app) are both maintained by the same organization).

cratermoon 5y ago

XML suffered from the verbosity of having both open and closing tags and the weird uncertainty around attributes vs. child tags, but the real problems came from consultant-driven programming wanting to put XML everywhere and use if for everything. Ant & Maven. SAML. XML for configuration and DI frameworks. *ML everything. Did you know there was a thing called VoxML[1]? Basically XML for phone menus (remember those? Press 1 for English, Press 2 for ... Press 9 to hear these options again). SAX was the hammer applied to every problem. 1. http://xml.coverpages.org/voxML.html http://xml.coverpages.org/voxML.html

occoder 5y ago

XML is the finest example of cargo cult engineering. "The Web was a huge success, there must be a reason. Oh I know, it must have been HTML. We need more of that, and bigger, extensible! Behold, XML!" I remember shaking my head in wonder during the height of the XML hype. What were all those supposedly very smart people thinking? To me, HTML was already a huge mistake, the Web succeeded in spite, not because of it. What could you do in HTML/XML that you couldn't in s-expression, only simpler, more readable, and more writable? How many man-years have we collectively wasted having to read/write/generate/process/validate/... the mess that is HTML/XML, as opposed to a simpler, more sensible format such as s-expression?

jazzyjackson 5y ago

> The current CSS effort provides a style mechanism well suited to the relatively low-level demands of HTML but incapable of supporting the greatly expanded range of rendering techniques made possible by extensible structured markup. The counterpart to XML is a stylesheet programming language that is...Published in April, 1996, DSSSL is the stylesheet language of the future for XML documents. I started building a custom JSON representation of HTML templates with embedded functions for importing fragments and generating markup etc and soon realized I was re-inventing XSLT [0] but kept going anyway. I haven't really seen another template language that can translate one DOM tree to another. It seems like XSLT is the eventual implementation of DSSSL in TFA, I'd be curious if anyone can speak to why it never caught on. [0] https://en.wikipedia.org/wiki/XSLT https://en.wikipedia.org/wiki/XSLT

christkv 5y ago
Having used XSLT professionally in the early 2000s I think it was that most developers found it hard to reason about due to the recursive nature of the language.
- Devasta 5y ago
  Absolutely, so many tried to go about it procedurally and fought the language rather than adapt to its way of thinking. Once you understand apply-templates though, it becomes much easier.
  - spiralx 5y ago
    For me it was understanding the differences between creating output by digging down from a root or by transforming a document by matching parts of it and letting the default rules handle the rest. Which is the basis of my stylesheet that turns an HTML file into its own formatted and highlighted source code: https://gist.github.com/spiralx/dcb7e5fa4e5dedd800e292848ed22aa9 https://gist.github.com/spiralx/dcb7e5fa4e5dedd800e292848ed2...
vbezhenar 5y ago
CDuce is a sane XSLT alternative. Although it's mostly research project, AFAIK.

Mikhail_Edoshin 5y ago

XML is language-oriented, it's like a typical programming notation but without a parsing step (or, rather, with a standard parsing step). It's a very unusual thing in this aspect and, I guess, this is the source of all the misunderstanding. E.g. it's very successful in things like layout/UI description, which is naturally language-like. And not that successful in data exchange applications, which is not language-like. (To exchange data with a language-like medium is like integrating programs by constructing their command lines; possible, but way less convenient than by using a library.) If we are to compare it with something it would be Loglan or Lojban, not JSON. The difference is that it's a working and widely used Loglan. Something like this will have to be central to navigate a vast sea of documents, which is what Web was supposed to be. Web has changed quite a bit, but those documents didn't go anywhere and the problem is as acute as ever. More acute, I would say; in 1997 there wasn't that much content there.

higon 5y ago

Idea of XML being superior to anything was the plague nearly everyone at the time caught. Evangelists would be the chosen one or so they thought. But they turned out to be a bunch of con men chasing easy fame. Having once been vaccinated with dynamic programming languages and coding-by-convention, who will ever go back there? Oh... typescript... you...!!!

Devasta 5y ago

Custom elements, CSS Namespaces, client side templating, all things that we had decades ago and were just dumped. Abandoning XML and XHTML is and continues to be the webs biggest mistake. People can pretend there were good reasons to stick with HTML but having "On Error Resume Next" baked into your language was a known bad practice even then... I am optimistic for XMLs future though, as the rise of stuff like TypeScript and Rust shows that people do appreciate strict languages nowadays, and WASM means that modern versions of XSLT can be utilized on browsers even if the browser vendors cannot be bothered implementing them.

usrusr 5y ago

It's so easy to look back at XML with ridicule, sitting on the hill of json pragmatism success. But take a moment to consider what we had before XML. Yes, XML was awesome. Back then you'd consider yourself lucky working with data available in a format that had implementations across multiple operating systems.

BiteCode_dev 5y ago

I loved xHTML, but it failed for a very simple reason: people designing it were working on a DSL to structure a document. But the vast majority of users were actually trying to make things look pretty. Most websites are currently blobs of div. Why ? Because the idea of a web page being mainly a document completely missed the part were artists fiddling with messy code would produce things that customers would like better. It's the same reason we currently see giant images on home pages and 10mo static assets to load. Because in the end, the best technical decision doesn't win. The one that gives the result the customers end up preferring wins. If you have 3 hours to get a design done, you have the choice between making it look great, or having a clean semantic and maintainable markup, you will have to drop one. And the market will select according to the result.

pjmlp 5y ago
Another reason for div blobs is that HTML is not a language to describe GUI applications rather documents. So one ends up with a soup of divs, made pretty with CSS and then replicate the behaviour of a beatiful dropdown fully in JavaScript, ignoring the browser builtin infrastructure. Naturally because this breaks down in every browser, it is then extended with hacks for every corner case.
Thiez 5y ago
> If you have 3 hours to get a design done, you have the choice between making it look great, or having a clean semantic and maintainable markup, you will have to drop one. And the market will select according to the result. Depends on whether accessibility is a priority. Depending on where you live it may be mandatory by law, for larger organizations.
- BiteCode_dev 5y ago
  Nah, what will happen is that accessibility will be dropped 9 times out of 10. And one day, many years from that decision, they will receive a notification from the state, stating the site is not accessible. And then the site will be made that way. Maybe. The situation were a website is made accessible from the start is such a tiny rare occasion it cannot be used to explain why xhtml failed.