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

 > You’re making this more complicated than it needs to be. Simplify the
problem domain.

I think we can all agree, we don't want another App Cache on our hands for
a standard. Sorry you feel an idea can be thrown out, immediately accepted
and pushed through simply because it seems obvious. In the real world,
things aren't always boiled down to the simplest solutions. Sometimes, we
need to have a bit of complexity and extra overhead in setting something up
to make sure it is robust and effective in as many situations as possible.

As has been said before, build a polyfill to show off your idea. I don't
think many vendors want to spend time building this out in-browser to test
when it is easily done in existing JS to get the idea down. We also need to
stop thinking purely about how things were built two years ago. ES6 and Web
Components introduce a lot of ground-breaking changes in this area, we
should see how they play out with framework vendors before jumping into
throwing it all into HTML and hoping it works well.

> So saying this is a “hard problem” just reeks of Javascript developer
laziness

This sounds very disrespectful. You're telling the people who are, writing
the standards, paying attention to give input to new standards and
modifying existing ones that they are lazy. They do this for a reason, most
have been bitten by some poorly thought out standard. This could end up
just another one. This kind of response does not encourage people to
continue to have a conversation on the proposal with you.

On Mon, Mar 30, 2015 at 9:08 AM, Andrea Rendine <
master.skywalker.88@gmail.com> wrote:

> 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:23:30 UTC