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

Bobby, the major criticism you have received about your proposal is that
you aren't considering at all any other party involved in this subject.
Correct me if I'm wrong, you cite no user agent responsible for support,
nor working groups or anything loosely resembling to that.
You are providing a very useful insight on how *you* see the web. And you
also provide a feedback based on the experience of high-school Tumblr girls
(why should she learn how to use Angular? However, there's nothing bad if
she learns something new).

The fact is, your proposal cannot be labeled as HTML6 Web needs something
new. And however your last messages do show that the proposal itself is not
strictly related to read/write Web as you claim. In fact, the main reasons
you cite behind your proposal are responsiveness and full-page reload
latency. Which are real problems, for sure, but not in the sense of
read/write, they're rather a matter of UX. A relative matter which does not
make the Web "largely unusable", and if you have doubt about it just have a
look at ChromeExperiments and see what can be done with current poor
methods.

If what you need is localised content load, you have some features you can
use as of now. For example, you can use nested browsing contexts, which
also offer a layer of protection in the form of CORS restrictions,
sandboxing and MIME type declaration.

You want to get rid of these things? Use XHR, its support is native. As you
said, you are not against JS itself, but against "writing more Javascript
than necessary". If you have the means, push towards a more pervasive
standardisation of current JS implementation, so that there will be
decreasing need for polyfills and syntax standardisers (with your proposal,
there'd be a need for a polyfill as well until it doesn't become supported
on new UA versions *and* new UA versions completely or substantially
replace legacy versions).

You still want more? Don't focus on changing a web page content. HTML is
still a declarative language after all, and there's nothing bad with it.
It's the purpose which originated it. Of course there's more now, but the
examples of websites or web apps you cited don't generally change the
content of a page, they integrate it, adding more items to the page as time
passes and events happen. So, as I said some messages ago, why not focusing
on <template>? It can add new elements to the existing document, it's HTML5
so you will have no chance of proposing "your" language, but you can still
work fairly well with it and with its margins for improvement. Current spec
suggests how to use it with a JS framework, why don't you elaborate a
proposal where <template> is able to load and parse "its" own
content-to-be"? (Of course you can even imagine loading a page which is
initially empty, with just a declaration for a template, which adds content
at runtime. But it is different from altering current content, a kind of
operation that no web designer would desire to be natively executed).

And finally, consider that JS complexity and JS memory load are 2 different
aspects you will have to face with a brand-new language or featureset:
 - complexity deals with richness of use cases. When dealing with external
content load you have to consider its origin, format, language, connection
delay time (you focus on mobile experience, so you know what I mean), its
parsing. You have your mind standards, but you can't think things go always
ideally, nor you can consider that everybody uses the same structure you
have in mind. JS is flexible in this, as it manipulates current DOM
structure. Would your native implementation be flexible as well? (side
note: if you look at <template>, its content is really flexible, as it
allows as content model lists, tables, subsets of tables, menus and
definitely all flow content subsets you can imagine.) It also deals with
security. HTML cannot be stretched to execute direct SQL commands (what if
those commands are maliciously altered? Do you guarantee instructions
integrity? Or perhaps you provide a level of abstraction between "HTML6"
instruction and DB instruction? This only translates complexity from one
language to another, you see), nor to directly respond to server-triggered
events (you can imagine the issues of maintaining an open channel with the
server in order for it to fire content loading events, both on the side of
performance and security).
 - memory load is a completely different case. Yes, in order for a
framework to work, you have to deal with downloading and "compiling" it,
then it has to be executed. A native feature doesn't need downloads, but it
makes UAs heavier when they have to deal with all the subtleties of content
handling. You are suggesting that a UA behaves as a client for a specific
server of your web app, in a 2-way interaction (you can talk about "page"
and all, but the actor in a MVC as "view" and "controller" is the browser
itself). Can you guarantee that the additional work managed by the user
agent does not translate in worst overall performances? (It is retorical.
You can't, as far as vendors are not involved in this discussion.)

This is just a series of ideas. I generally like native implementations,
but there aren't any scenarios where the purpose of HTML can be subverted
completely IMHO.
Regards (and sorry for verboseness).

2015-03-30 5:45 GMT+02:00 Bobby Mozumder <mozumder@futureclaw.com>:

> I have no idea why people say this is a “hard problem.”  You’re making
> this more complicated than it needs to be. Simplify the problem domain.  We
> just need a declarative, native MVC framework in the browser.
>
> I gave a solution that’s optimal in every case.
>
> There is no case where using Angular or Ember or React would be a better
> solution than having a native MVC framework in HTML.  It’s easier
> (declarative syntax), it’s responsive (no need to download large Javascript
> frameworks), and uses less power (uses native code).
>
> Most of the issues around the current frameworks are due to Javascript
> itself and its interaction with the DOM.  React’s framework has a virtual
> DOM implementation to help speed things and other frameworks are being
> rewritten to do the same.  A user doesn’t have to worry about this.
> They’re experimenting and redesigning because they’re solving Javascript
> problems.
>
> So what exactly is incorrect about the proposed solution?  If there are
> technical problems with it, do explain.  Do you feel the response codes
> need to be defined now?  We have standard response codes in HTTP, should we
> standardize on them here? Maybe we need to define the authentication
> mechanism first?  Or maybe the models need more data-type options? All of
> these would be fleshed out as the spec is defined.
>
> And we already serve JSON API endpoints, so I don’t know why you feel this
> adds more work to the server?  This proposal would use the same data that
> API servers already provide.  And if you need backwards compatibility, it’s
> there as well.
>
> I’d like to see where this solution causes something to break.  Or where
> Angular or Ember or React would be a better solution than this.  With this
> proposal, you can still use Javascript for more advanced applications, you
> just don’t have to worry about loading in another MVC framework.
>
> So saying this is a “hard problem” just reeks of Javascript developer
> laziness, stuck in local-minima comfort-zone.  But this comfort zone
> doesn’t matter to non-Javascript people.  (note that i’ve written thousands
> of lines of Javascript, but have no desire to write more Javascript than
> necessary.)
>
> -bobby
>
> > On Mar 28, 2015, at 1:19 PM, nw@nwhite.net wrote:
> >
> >
> > Bobby,
> >
> > I think your enthusiasm to question and challenge the status quo is
> great. Many individuals like you challenge the standards in this mailing
> list. I'm constantly learning from the discussions that takes place from
> such proposals and I value it immensely.
> >
> > However, I'm kinda pissed off on how you went about sharing your
> insight. Unlike you everyone has encouraged discourse while respecting the
> enormous amount of effort it took to get here. Posting a title with HTML6
> is hyperbolic and link bait at best. HTML5 is a living spec, changing the
> version with no dialog from committee members is disrespectful. The trash
> statistics you used to "support" your argument reeks of laziness, they
> waste everyones time. Give us a case study or some large sample of data
> before asserting such nonsense.
> >
> > If you really want to make this happen write a polyfill. Many proposals
> and even standards are implemented as a proof of concept before ever
> reaching a vendor. Your proposal can be implemented with javascript right
> now with not much effort. This is the beauty of javascript and why we have
> so many frameworks. No one agrees on how we solve these really hard
> problems. Everyone is experimenting and testing. That's my biggest gripe
> about your proposal, oversimplifying the problem domain. What you propose
> pushes tighter coupling and implementation details to the servers. Your
> just moving the problem not removing it.
> >
> > Your core argument for your proposal asserts JavaScript is hard and
> slow. Yet at the same time you want HTML to act like such because single
> page apps are fast.  Do you see the fallacy in this argument? Please
> provide some data especially on the slow bloated part. I often find
> optimizing even a few images will yield file size savings that far exceed
> the payload size of an entire sites JavaScript. Yes, JavaScript is hard but
> the problems associated with web are really hard. There are so many layers
> and ways to solve. In my opinion your proposal is simply not generic enough
> to be called a standard, it would be classified as a framework much like
> the ones you attack. This is the beauty of the standards we have, we have
> wiggle room to create, explore and learn. They do not tell us how to solve
> the problem, I think this is what frustrates you.
> >
> > If you want to continue this dialog please take sometime and read
> through how others addressed proposals to the community. Like I said I'm
> not against you sharing your view point but try and respect the process.
> This will save everyone time.
> >
>
>
> ---
> Bobby Mozumder
> Editor-in-Chief
> FutureClaw Magazine
> mozumder@futureclaw.com <mailto:mozumder@futureclaw.com>
> +1-240-745-5287
> www.futureclaw.com <http://www.futureclaw.com/>
> twitter.com/futureclaw <https://www.twitter.com/futureclaw>
> www.linkedin.com/in/mozumder <http://www.linkedin.com/in/mozumder>
>
>

Received on Monday, 30 March 2015 13:09:23 UTC