Proposal: native XML object support.

# Ed Saleh (7 days ago)

Hello,

I am proposing to support XML object native in JavaScript so the following code would be possible

let foo = <input type="button" value = "Ok"\>

Which creates an object called foo with name = "input" and value = "Ok", children = null, and constructor = null

constructor property would include a constructor to be called when a new XML object is created.

While childern would include any inner XML items inside the XML element.

It's nature to support XML as object natively next as JSON format is already supported natively.

Supporting XML would open new possibilities notably in the UI side as we would be able to merge UI with Controller logic code.

This is similar to React framework.

Thank you,

# Sanford Whiteman (7 days ago)

let foo = <input type="button" value = "Ok">

This is a retread of E4X (en.wikipedia.org/wiki/ECMAScript_for_XML) so I can't imagine it would be resuscitated in a (for better or worse) JSON-centric world.

—— Sandy

# Ed Saleh (7 days ago)

Thanks for reply. Didn't know that it existed before! I don't think we can say that we live in a JSON centric world when things like React show up and revolutionize web development. I think JSON has its uses and XML has its uses. UI shouldn't been ever seperated from controller since one can't exist without the other.

# Sanford Whiteman (7 days ago)

I don't think we can say that we live in a JSON centric world

But we do.

It's not that there aren't powerful XML-based applications still being developed. And XML still buttresses some of the most important back-end components of the modern (as well as ancient) web.

But surely you cannot have missed the fact that modern API development has so standardized on JSON that one doesn't even need to mention the response type anymore!

In any case, if E4X died back when we all used XML all the time, it seems vanishingly unlikely that it would come back now… but I'm not on TC39 so this is just my take.

—— S.

# Ed Saleh (7 days ago)

I prefer JSON over XML any time but the only area where JSON can't compete with XML is UI.

# guest271314 (7 days ago)

I prefer JSON over XML any time but the only area where JSON can't compete with XML is UI.

XML is also currently specified as the language used by SSML.

Why does a JavaScript plain object need to be created when the XML document itself (returned by DOMParser, or the response and responseXML of XMLHttpRequest) can be used to read/write XML values?

const createXMLPlainObject = xml_string => Object.create(null, (() => {
  const xml = (new DOMParser()).parseFromString(`<?xml version="1.0"?>${xml_string}`, "application/xml");
  const element = xml.documentElement;
  return {name:{writable:false,value:element.nodeName},children:{writable:false,value:element.children}}
})());
# Isiah Meadows (5 days ago)

Fun fact: React elements are plain JS objects that are nearly JSON-compatible. The only reason why they aren't is because of the presence of a $$typeof: Symbol.for("react.element") property on React elements, to prevent people from using non-array object results of JSON.parse(jsonString) directly as a child. The rationale for this is explained in this blog post by React's creator: overreacted.io/why-do-react-elements-have-typeof-property

I would say that we live in a JSON-centric world for APIs, SGML/XML-centric for UIs. (I wish XHTML efforts actually stuck, to be honest. <script src="..." /> is one reason XML would've been better than SGML IMHO.)

# Jordan Harband (5 days ago)

(that's not react's creator; that's redux's creator, who is now a member of the react core team)

# ViliusCreator (3 days ago)

XML in JS without React could totally bring usage in Node js, not only JS. For example, you could pass XML object as parameter to website from server and server would change it to right way, so XML object would be turned to HTML element. However, in non web-development environment, it would have no usage. Since sometimes Node js is used for general-purpose and not web-development, XML would be practically useless and JSON would be used. And things such as E4X already exist. The benefit of XML is that you can do <a b="c">d <e></e></a>(which is equivalent to

{
    '//name': 'a',
    '//inner': ['d ', {...}],
    b: 'c'
}

) and it’s more readable than JSON version of it.

# Jacob Bloom (a day ago)

And things such as E4X already exist.

Building on that, JSX is just a code transformation that can be used without React. You can swap React out for another compatible library with a pragma: babeljs.io/docs/en/next/babel-plugin-transform-react-jsx#pragma -- JSX + a React-like library that creates vanilla DOM elements could be used to achieve a lot of the requested functionality

# liorean (19 hours ago)

You could already do something like this:

 let
  RawXML=xml`<some-element some-attribute="${some_variable}">some

content</some-element>,XMLApplication=rss<rss version="2.0"> <channel> <title>RSS Title</title> <description>This is an example of an RSS feed</description> <link>www.example.com/main.html</link> <lastBuildDate>Mon, 06 Sep 2010 00:01:00 +0000 </lastBuildDate> <pubDate>Sun, 06 Sep 2009 16:20:00 +0000</pubDate> <ttl>1800</ttl> <item> <title>Example entry</title> <description>Here is some text containing an interesting

description.</description> <link>www.example.com/blog/post/1</link> <guid isPermaLink="false">7bd204c6-1655-4c27-aeee-53f933c5395f</guid> <pubDate>Sun, 06 Sep 2009 16:20:00 +0000</pubDate> </item> </channel> </rss> ` // rss example courtesy wikipedia

And all you'd need is an XML parser for EcmaScript tagged templates, or for a specific XML application such as RSS, an application specific handler which would probably be layered on top of such an XML parser. And XML is actually not that hard to parse, in difference to HTML, thanks to its draconic error handling. It's actually the XML application handlers that might get more involved.

# Ed Saleh (18 hours ago)

With strings and even E4X, you don't get the same experience that react supports. Things like property completion in XML mode, XML internal logic, etc.

# ViliusCreator (14 hours ago)

With strings and even E4X, you don't get the same experience that react supports. Things like property completion in XML mode, XML internal logic, etc.

Pretty sure you can do this:

// ... xml function definition
/**
 * @type {Element}
 * @prop {string} href
 */
const xmlObj = xml`<a href="...">something</a>`

This should make editor auto-complete Element object properties and other stuff for you. Assuming XML literal translates to HTML object in web, we need to use Element type. If it's for Node JS, you can make custom XMLElement definition and use it.

I understand that new feature in JS is good thing, but I don't think XML should be one of them. Stuff like Node JS and other non-browser V8 implementors may not even have usage for XML feature.

# Andrea Giammarchi (13 hours ago)

That'd give you info after declaration, which I believe was the major concern in using strings instead of literals.

FWIW, I also wish E4X was still a thing, despite these handy and successful template literals based libraries (hyperHTML, lighterhtml, or heresy for the client, viperHTML for NodeJS).

However, since () => <node /> is always new node while () => html<node />`` is a unique literal, I think E4X would be a performance nightmare on

the client, it could still smehow shine in NodeJS though.

# ViliusCreator (13 hours ago)

the client, it could still somehow shine in NodeJS though.

The only way it can shine is only passing HTML objects as arg to website. That’s it. And still, you can use string to do that for you. People already use JSON and I don’t think they would use XML in Node js. There are already tons of libs for XML stuff, yet they don’t have a lot of downloads, as far as I remember.

So basically, Node js doesn’t need XML. That would be useless.

# Isiah Meadows (6 hours ago)

My bad. I should've known that. :-)

(I've looked way too deeply into the React/Redux ecosystem to have any sort of excuse on this one.)


Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com

# Michał Wadas (5 hours ago)

I'm not sure why is that discussed. XML is natively supported in browsers and there are npm packages to bring exactly the same interface to Node.js and other server envs.

If you want Node.js to include some kind of XML parser in its core library, I suggest using their bug tracker (but it was rejected 4 years ago - nodejs/node#2709 ).

# kai zhu (an hour ago)

fyi, a notable xml-based web-api holdout is wechat-pay, with a billion active users [1],[2]. arch-rival alipay otoh uses json.

-kai

[1] official wechat-pay documentation pay.weixin.qq.com/wiki/doc/api/download/wxpay_document.zip

[2] swagger documentation for wechat-pay kaizhu256.github.io/node-swgg-wechat-pay/build..beta..travis-ci.org/app