Proposal: native XML object support.

# Ed Saleh (8 months ago)


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 (8 months ago)

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

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

—— Sandy

# Ed Saleh (8 months 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 (8 months 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 (8 months ago)

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

# guest271314 (8 months 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 (8 months 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:

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 (8 months ago)

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

# ViliusCreator (8 months 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 (8 months 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: -- JSX + a React-like library that creates vanilla DOM elements could be used to achieve a lot of the requested functionality

# liorean (8 months ago)

You could already do something like this:

  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></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></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 (8 months 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 (8 months 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 (8 months 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 (8 months 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 (8 months 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,

# Michał Wadas (8 months 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 (8 months 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.


[1] official wechat-pay documentation

[2] swagger documentation for wechat-pay

# Andrea Giammarchi (8 months ago)

People use JSX, which is basically E4X, so I'd argue the word useless is not really appropriate. You can use E4X to produce HTML, the fact we're talking XML is merely about the E4X background, but as you could produce strings out of E4X you could do the same and have better templating out of the box.

But like I've said, I already use template literal tags, but those strings don't get hints or highlights as if these were E4X, XML, or plain HTML, which is the only cool thing I'd personally find useful.

Maybe it's just a tooling issue though.

# kai zhu (8 months ago)

jsx is not terribly javascripty ... vs direct manipulation of the dom (using static-functions/handlers).

it requires two extra ux-workflow transformations -- 1) transpilation and 2) virtual-dom manipulation, for the sake of oft-quoted faster dom-performance, which some like me are skeptical is true in modern browsers.

# Jacob Pratt (8 months ago)

JSX doesn't necessarily need a vDOM.

# Wes Garland (8 months ago)

As a data point -- I was writing JavaScript applications with GPSEE, a server-side Spidermonkey embedding, for several years until recently. The design pattern was, for all intents and purposes, CGI.

GPSEE has E4X capability. I used it a few times to generate xhtml documents. I never found a compelling application. Being able to use XML object literals honestly caused more problems than it solved.

If I really needed XML interchange today, I would try really hard to represent it internally with javascript objects and render/parse it at the network boundary.

The only two things I ever found useful in E4X was template strings (which we have in ES6 backticks now) and for each.