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

I shall add a color note to this thread, just because it emerged elsewhere.
I shall be brief, and I hope my intervention causes some smiles here and
there.
During the last days I suggested a possible... let's say, improvement for
another feature (namely, an interface for <meta refresh> so that scripts
could read the refresh time value and even stop the native HTML page
refresh in order to enable finer tuning, e.g. timeout delay, or timed AJAX
for specific modifications). I was answered that relying on <meta> is poor
coding, because it introduces a native form of automation which is not
disabled when JS is turned off, while it is "well known" (according to the
writer) that when users disable JS, it's because they want to stop
animations, automation etc. inside the page.
Now, I have never meant "disabling JS" that way (it would be incompatible
with today scenarios, with CSS animations and transitions, form validation,
native HTML widgets such as <details>, or features currently under
implementation such as context menus). This project, on the other hand,
brings too much automation inside pages. It makes unsure not only what is
added to pages themselves after they're loaded, but also what remains of
the initial content when it is "updated" on a DB basis.
I'll end up with one extra cent, the same I added to the "added on GitHub"
list thread (it was worth 2 cents at the time, but you know, inflation...):
instead of creating methods/elements/features that "modify" actual content
(that's somehow scary), why not trying to improve an element that currently
*exists*, a powerful element which is made to define a model for adding
content to the page, and that heavily relies on JS? I'm talking about
<template>, of course. That's something which could maybe benefit from
adding automation, IMHO.
Cheers
Andrea

2015-03-27 21:04 GMT+01:00 Miles Fidelman <mfidelman@meetinghouse.net>:

> I've been reading through the discussion thread, all of which seems to
> jump immediately into the weeds of specific details of the proposal.
>
> 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.  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?).
>
> - JavaScript seems to encourage poor programming style, or at least
> resource-intensive programming.  It seems like 2/3 of the web pages I visit
> either freeze up, or just take incredibly long to load. Granted, that a lot
> of this is this stems from all the little click monitoring apps, and
> widgets, and who knows what else people put on their pages - and waiting
> for those various sites to respond - but it's the proliferation of more and
> more JavaScript that enables this.  (Which is not to say that some folks
> write well behaving pages, nor that JavaScript isn't useful - just that it
> seems to be leading to more and more problems).  One would think that
> commercial developers would know better than to release pages that drive
> users away, but no.
>
> 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.
>
> Miles Fidelman
>
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.   .... Yogi Berra
>
>
>