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

Liam R. E. Quin wrote:
> 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.

Ok... why might this not be a good thing?

>
>>    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.

Care to comment further about this?  To me, the read/write web is about 
the web as it started out, and as it's supposed to me - a 2-way medium, 
where it's as easy to publish content as to consume it.

Back in the earliest days, it was pretty easy to publish a page of text, 
with some embedded links, and if you wanted to get ambitious, add some 
text formatting.  Easy enough for the average writer (well, generally 
technical writers, back in the day).

HTML was pretty simple and straightforward, and there were more than a 
few things WYSIWYG editors.  (Heck, Composer is still part of my 
preferred Browser, SeaMonkey.)  Pretty much like writing a paper in 
Word, then hitting "publish."

The fact that writing a simple document has become a programming job - 
between a lot more HTML functionality, CSS, and JavaScript - is (IMHO) a 
HUGE barrier to the basic concept of a read/write web.

So how is this not related?

>
> [...]
>
>> 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.

The most recent seems to be xqib (www.xqib.org) - a javascript library 
that implements XQuery.  There's an older Firefox plugin (XDIB) that 
seems to be defunct.
>
> 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.

Ain't that the truth.  Sigh...

<snip>
>
>
> 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.

It seems like the trend is to do more and more in the browser, and 
perhaps more accurately in a document itself (WebApps and all that) - 
which I'm a huge fan of.

Which, of course is leading to (IMHO) the overuse of JavaScript, to the 
point that things have become painfully complex, and painfully slow.

It's also lead to moving platform technology to the browser (e.g., 
PouchDB as a client-side implementation of CouchDB) - REALLY cool tools 
(IMHO).

It seems like moving XML related technologies, particularly XQuery, and 
as you point out, XProc, to the client side, would be continuation of 
the trend.

> But the right answer here
> is to develop something and show people it works.

Well... I guess I'd say that the growing set of applications based 
around XQuery, built on server-side platforms like eXist-db, kind of 
demonstrates how to build apps on top of XML technologies; and things 
like XQIB demonstrate client side implementations (if not actually 
embedding the functionality directly in the browser).  So the 
demonstrations are there.

Personally, I've been rethinking my approach to a couple of projects - 
shifting from PouchDB/CouchDB + JavaScript as the platform for a couple 
of distributed applications, to thinking seriously about XQuery as a 
simpler platform for what I'm trying to do (broad class of problems - 
asynchronous, distributed editing of structured multi-author documents).

But my original comment, and question was intended to raise the question 
of whether 'XML technologies in the browser' is really pretty close to 
what Bobby's HTML6 proposal is shooting for.  Any thoughts on that?

Miles




> Liam
>
> W3C XML Activity Lead
>
>
>> Miles Fidelman
>>
>>


-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

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