Hacker News new | ask | show | jobs
by jsiepkes 525 days ago
"Serve your app as XML"

As someone who started his professional career in 2005: All the old is new again.

7 comments

It sort of proves the point that certain technology choices are not the result of some monotonic "progress" towards a theoretical optimal but rather a random walk under stochastic influences in what we might call "conventions space".

Serious randomness is induced by the decisions of whatever entities happen to be influential, typically (but not exclusively) by having the most successful economic model. Causally that earnings model need not be at all related with the tech. After all, most 'big tech' is not actually selling the tech itself.

People mostly code for money so they are attracted and incentivized to use the more visible money-making conventions (be part of wining teams) irrespective of particular technical merit.

But there are additional more objective dimensions that complicate things. E.g. SPA conventions did solve a user experience problem at the time. It was not pure lemming behavior. In retrospect we know that it could have been solved otherwise but at that time we didn't.

I think webapps should be xml (with all the data to display) transformed into html on the client side with XSLT generated by framework templating system).

There's a really nice binary XML format that browsers haven't implemented yet: https://en.m.wikipedia.org/wiki/Efficient_XML_Interchange

Symphony CMS [1] was based on this idea over a decade ago.

The developer experience was amazing, you could easily inspect the data backing any page. XSLT was hard but probably easier than React these days.

[1] https://getsymphony.com

What a blast from the past. We did exactly this in '99-2000 (yes), and it was ridiculed as being over-engineered. At the time, it was the future because "XML will underpin all data transfer everywhere", and therefore we would be set up to run on any device, should any other device begin to exist. Needless to say, the winds changed way sooner than that became a real use case.
I originally had this idea about 20 years ago. I still think it's good. At least better than brotli compressed json loaded with JavaScript.
How would such a webapp make API calls and act on the responses? Even for a static website, HTML isn't very good at handling arbitrary sizes, which I think was part of the original motivation for React.
Literally. I wrote a fair number of Konfabulator widgets in the early aughts this way. I did a bit of Adobe Air like this as well, everyone insisted it was THE FUTURE, it wasn't.
The web is, was, and forever will be stuck reinventing shitty versions of things that they could have had decades earlier if they stuck with XML.

Custom elements, client side templating, form validation against schemas, they had it all and threw it away.

Yup. They’re learning why XML needed to be complicated, one simplistic bolt-on HTML/CSS/JS layer at a time in a musical chairs fashion.
Someone will inevitably create an app to create apps using Brainfuck encoded in Morse code running on a 16-QAM wireless protocol... just beam your app with your data.
I wonder what going back to the 90's will bring up.
Was going to say "please no XMPP again," but apparently that was 2000.
JSON is same as XML.
No it isn't, XML is an ecosystem with things like dedicated transfer protocols (EXI), schemas (XSD), transformers (XSLT) that JSON still doesn't have standardized/normalised even though JSON has been the norm for nearly 20 years. There's some projects of course (JSON Schema, OpenAPI), but they're separate and not part of the same standardization committee.
I don't remember anything about the XML ecosystem, but XML is already a totally different format from JSON without considering that.

  <body myattr="yeah">
    <thing>hi</thing>
    <thing thingattr="cool">hi2</thing>
    <otherkindathing>hi2</otherkindathing>
  </body>
can be thought of as nested objects, each having a typename, text content, and children. It doesn't translate nicely to JSON. Maybe:

  {"type": "body", "attrs": {"myattr": "yeah"},
   "children": [{"type": "thing", "content": "hi"}, ...]}
As someone who works with JSON every day and almost never deals with XML directly, it’s important to realize saying they are the same is like saying a pocket knife and a Swiss army knife are the same because they both have an extremely useful tool (and why would anyone ever use the thing with all that extra stuff I never use?). Not a perfect analogy but the one I think of for simplicity.
And XML is essentially lobotomized and extra verbose Lisp S-expressions, going back to the 1960’s
don't talk about my thesis, written in LaTeX, like that...

/j

Back in my day, real cowboys wrote their papers in PostScript, making their papers as inaccessible as possible for user of consumer-grade devices. /s

PS won on human readability and editability but lost on portability to Adobe's own internal competitor, PDF, and because it fought and lost to (La)TeX -> PDF & (La)TeX -> DVI -> PS.

PS: I once printed out and bound the PDF 1.3 spec[0] on 24 lbs. bleached dead trees on an HP LaserJet IIIP with over a million page count. Some of the nuclear engineers and scientists an office containing <50 people routinely printed thousand page documents every week.

0. https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard...

JSON is great in it's own regards but the features are not comparable.
At least with XML, you can have custom datatypes, not just strings and numbers and booleans.

In all seriousness, everything in JSON can be expressed as XML; but not necessarily the other way around.

So incredibly true. And that one time you see what XML can do that little else can.

Like that time there were hundreds of forms to build, refused, held a silent protest until a reasonable way presented itself.

Enter "XML Form Template" or "XML Form Definition.", A form is generated from the XML in html, filled in, and on submit, the XML is filled back in.

Built one form renderer and done. Never got old watching it.

XForms (W3C standard)

https://www.w3.org/TR/2003/REC-xforms-20031014/slice2.html

Other way around works too (I gave an example above), it's just not pretty in either direction.

XML makes sense for open-ended, human-written things like documents or apps. It doesn't work so well for APIs and other machine-read/written things where you'd normally use JSON.

Text is the same as JSON.