Proposal: native XML object support.
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
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.
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.
I prefer JSON over XML any time but the only area where JSON can't compete with XML is UI.
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}}
})());
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.)
(that's not react's creator; that's redux's creator, who is now a member of the react core team)
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.
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
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.
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.
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.
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.
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.
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
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 ).
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
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.
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.
JSX doesn't necessarily need a vDOM.
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.
Hello,
I am proposing to support XML object native in JavaScript so the following code would be possible
Which creates an object called foo with name = "input" and value = "Ok", children = null, and constructor = null
constructorproperty would include a constructor to be called when a new XML object is created.While
childernwould 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,
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, -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190514/869f9d46/attachment.html>