I’ve been using XML literals for JSX like effects on multiple projects using the monadic html library : https://github.com/OlivierBlanvillain/monadic-html
I love it, but one issue that comes up at times is the dependency conflict with the other scala xml libraries (since the scala.xml namespace is hardcoded in the compiler, but this is more the fault of jvm name spacing).
I am absolutely for removing this feature. I don’t think any kind of markup language parsing belongs in the core of the language.
As you say, JSX is a very limited language compared to XML.
I suspect it wouldn’t be dramatically difficult to implement a jsx"" string interpolator for Scala.js, bringing in the existing JSX parsers available in JS.
In general, big +1 for removing XML from the language. It’s a not a main concern of the language, and for this reasons bugs and evolutions are taken care of as a third-party library.
Half-joking. Obviously, XML is still used. HTML is still XML. But in my experience, JSON has quickly become more popular than XML. I didn’t even know of JSX until you mentioned it. So, why should XML be part of Scala, but not JSON? I believe neither of them should, but if one of them, then JSON.
Oh, I’m absolutely for removing xml from the core language, it’s not its place. The fact that xml is in the core language is certainly one of the reason for which XML lib stalled whereas json ones flourished (until ~2010, json wasn’t that much prevalent against xml).
Cheers!
Reactive HTML Templating is a widely used practice in frontend development. You create your HTML templates in a web design tool, then copy it into Scala source code and replace the mutable part to bindable XML interpolation.
An implementation of this approach is Binding.scala, one of the most popular Scala.js frameworks. A developer can create reactive DOM nodes from statically type checked XHTML literals, which are able to automatically change whenever the data source changes.
This approach produces very concise code. For example, a complete single page application TodoMVC written in Binding.scala has only 122 lines of code: https://scalafiddle.io/sf/dGkVqlV/9
As Martin Odersky written in The Goals of Scala’s Design:
Initially we had colon-equals for assignment—just as in Pascal, Modula, and Ada—and a single equals sign for equality. A lot of programming theorists would argue that that’s the right way to do it. Assignment is not equality, and you should therefore use a different symbol for assignment. But then I tried it out with some people coming from Java. The reaction I got was, “Well, this looks like an interesting language. But why do you write colon-equals? What is it?” And I explained that its like that in Pascal. They said, “Now I understand, but I don’t understand why you insist on doing that.” Then I realized this is not something we wanted to insist on. We didn’t want to say, “We have a better language because we write colon-equals instead of equals for assignment.” It’s a totally minor point, and people can get used to either approach. So we decided to not fight convention in these minor things, when there were other places where we did want to make a difference.
The proposed xml"<html></html>" syntax seems like another colon-equals debate to me. Why do we fight against the widely accepted XML literal syntax, which has been proven success in ActionScript, JSX, TypeScript, LiftWeb, monadic-html and Binding.scala?
XML is a verbose language in comparison to JSON or ScalaTags, and it looks very different from native Scala code. However, the verbose syntax also provides an explicit visual boundary when mixing an XML-based embedded DSL inside Scala. I guess it’s the reason why popular GUI frameworks tend to use XML-like syntax for layout.
Did you consider why JSX is so successful even when it is barely a simple syntactic sugar and does not support XML namespaces and many other “standard” XML features?
To me, the reason of JSX’s success (in comparison to ScalaTags) can be found in the same article:
For example, something like Java’s use of curly braces, which might make C and C++ programmers feel more at home than if Java had used some other block demarcation scheme.
Scala 2 compiler performs a symbol-based transformation for XML literals in the parser phrase. On the other hand, JSX and TypeScript perform name-based transformation for XML literals. The symbol-based transformation is the cause of XML lib stalling. Instead of removing XML literals, we can create an SIP to allow name-based XML literals transformation, similar to the -Yvirtpatmat flag.
I don’t know how anyone could make that comparison. I wouldn’t be surprised if the percentage of scala.js developers using ScalaTags is greater than the percentage of javascript developers using JSX…
I am not really sure what to do about XML in a language (and to be honest I never used it in Scala).
I am working almost daily with JSX (which is not HTML; e.g. class vs className and so on) for a year now and on one hand it is nice, that you can inline creation of HTML elements, on the other hand I still prefer Angular (2+) templates (IMO nicer iteration, conditional rendering, clearer async). I prefer clear division of concerns (template mostly just for rendering, almost all logic, except trivial one, should be in a component, not in a template). But I admit for very small components (e.g. a line of HTML) it was nicer to use template field in a component decorator (annotation).
Out of curiosity, are there some statistics of how XML in those mentioned languages (and also in Scala) is actually used? When I was toying with HTML rendering in Scala, I was using ScalaTags (so not XML) and was quite enjoying it. It felt natural, unlike JSX which I still find a bit “weird”.
As someone else noted, I too think success of JSX should be attributed to similarity to a technology people in that field already know, not a grand design.
For me the main argument to move XML from the language to a library-supported string-interpolator is that it will make it possible to have alternative XML libraries. Right now, the XML parser and the supporting scala.xml library are dependences if the Scala compiler itself. Since the overlap between people who care about XML and people who can change the Scala compiler is 0 this means that there will be no evolution of Scala’s XML support as long as it’s a language feature.
Technically that could be solved by changing the desugaring rules of XML, similar to JSX. A simple change would be to say that the expected names like Elem are not fully qualified, so if you import scala.xml._ you get the current behavior but you could import something else as long as it has the right constructors. I’m not advocating for it, just pointing out a possible counterargument…
Is there any way to push XML to libraries? For example allowing names like <a> and maybe some macro magic when necessary, to make it work?
Not 0.
There are third-party libraries for XML literals. Binding.scala internally converts XML literals to DOM nodes:
@dom def myButton: Binding[HTMLButtonElement] = {
<button>text</button>
}
https://scalafiddle.io/sf/jTAPDnW/0
Note that this feature cannot be implemented in xml"<button>text</button>" without white box macros, because the types of XML literals in Binding.scala vary according to the tag names of elements.
HTML is not XML
If you want HTML templating, supporting XML is neither required nor sufficient.
Is HTML XML? The W3C has adopted both a recommendation that HTML be XML as well as a later recommendation that acknowledges that HTML may or may not be XML. So, yes, HTML is not necessarily XML, but it may be and it is better if it is.
I mean, I was just mentioning HTML to acknowledge that XML is not dead yet. 
I’m not sure what you mean by sufficient for HTML templating. You can (and maybe should) make your HTML XML. Or do you mean not sufficient for templating?
If it was up to me, rather than embedding XML or anything like that in my Scala code, I’d much rather have the ability to direct the compiler to include an external file as a String literal.
And instead of inventing some templating language, if I wanted to create a web framework, I would rather have a valid HTML document with sample values and the framework replaces those sample values with real data.
While HTML5 has a lot of leeway (quirks mode IIRC), I would presume that with Scala XML would be used XHTML5.
Also when looking at the alternatives, JSX is also not HTML and I don’t think it is XML as well.
I’m not clear how removing a feature makes it possible to have alternative xml libraries. There have already been multiple attempts at alternative xml libraries.
By making this change, you’re essentially saying that the existing Binding.scala and Liftweb users don’t matter.