Re: [whatwg] HTML6 proposal for single-page apps without Javascript

On Fri, 2015-03-27 at 16:04 -0400, Miles Fidelman wrote:
> I'm amazed that nobody has yet commented on the implicit
> premise, which I read as:
> 
> - JavaScript is a processing pig
> - with the addition of a few, well-defined constructs to HTML, with
> support from browsers, we could do a lot of what we want (or what 
> people
> are doing) - without the overhead imposed by JavaScript
> 
> To me, this seems like a very good thing.

I'm not sure it's entirely true and, even if it is, I'm not sure if it 
matters as much as we might think, even those of us who started out 
with PDP11 assembler.

>   It seems like:
> 
> - It's getting harder and harder to do simple things.  Too many
> JavaScript frameworks and libraries.  Too much complexity. Authoring 
> should not require extensive programming skills. (Whatever happened 
> to the read/write web?).

The frameworks make mindblowingly complex things possible or even 
easy. I don't think they make anything harder, unless it's choosing a 
framework.

The read/write Web is not related to this at all.

[...]

> As to the specifics, it sounds like the proposal is to move some XML 
> processing functions into the browser.  To me, Xpath, XSLT and 
> XQuery, maybe a basic XML database - all in a browser, instead of 
> server-side - sounds like a viable alternative to JavaScript for a 
> lot of applications.  Implement first as a JavaScript library, as a 
> test and transition path.  Could be kind of cool.  Might also end up 
> being just as much of a processing pig as JavaScript.

XPath and XSLT are already in Web browsers, albeit very, very old 
versions of XPath and XSLT.

There have been interesting experiments with e.g. SaxonCE and 
frameless.io in having a more recent XPath and XSLT in Web browsers, 
and I know people have embedded XQuery in browsers with plugins.

We (the XML community, if there's such a single thing) did a really 
bad job of selling XML to the Web community. Partly it was because, at 
the time, the people working on XML were professionals in information 
design, and from that perspective HTML was like one more word 
processing format - not what you want to use for your domain-specific 
information but a possible output format, and not very interesting.

In the meantime lots of people took XML and ran with it in other 
directions, some good and some really bad, and even at W3C it seems (I 
wasn't working at W3C at the time) people had weird ideas like "XML is 
intended to replace HTML" that were both incorrect and confrontational.

Ideas such as separating script and content ("unobtrusive"), 
separating style and content, declarative languages, were all part of 
XML and SGML and inherited (in theory) by HTML from SGML. These ideas 
have been slow to take hold on the Web, in general, but are pretty 
firmly there now. We're seeing a resurgence in domain-specific 
languages and various functional and declarative languages are coming 
out of that, too.

Although I certainly have use for XSLT and XQuery in Web browsers the 
languages weren't designed with that in mind. XSLT is actually fairly 
widely used on the Web today, and XPath even more so. You can also 
find people (and organizations) using the model-view-controller design 
pattern with XForms in the browser. It would be interesting to develop 
something XProc-like to be reactive to client events -- XProc is 
essentially a declarative dataflow language. But the right answer here 
is to develop something and show people it works.

Liam

W3C XML Activity Lead


> 
> Miles Fidelman
> 
> 

Received on Saturday, 28 March 2015 04:27:58 UTC