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

> Polyfills aren’t going to cover all possible scenarios, either, since
they’re going to be limited by test coverage.
Some messages ago you suggested that Angular would serve as a proof of
concept for your proposal
I'm sure you didn't mean to replicate Angular.js with HTML.
No polyfills will actually cover all use cases, but it's also true that you
are not required to build something usable here and now. You just need
something working so that authors and possible collaborators can follow
your proposal.
I'd suggest you a simple script with modern DOM methods that can be run,
say, on Safari/Chrome/Opera latest versions (no need for legacy support),
just for Web designers who wish to test how it works. It's easy - an XHR to
simulate "native" call, a server-side script for the API and a bit of DOM
traversing for content substitution. Just in order to let people know that
your proposal is not a bunch of words.

2015-04-03 6:04 GMT+02:00 Bobby Mozumder <mozumder@futureclaw.com>:

>
> > On Apr 2, 2015, at 1:16 PM, Brian Kardell <bkardell@gmail.com> wrote:
> >
> > Many of simple cases that I see that you could potentially do with
> > your approach as described, at least my understanding of what I've
> > seen so far, can in fact be done today with several frameworks
> > declaratively.. There is competition in the space of how to express it
> > and that is fundamentally no different than if we discussed it on a
> > mailing list, there would be different ideas.  The difference is that
> > one involves speculation, no testing and is useless to people in the
> > meantime (and the meantime means years) - very frequently only at the
> > end of that do you find out that 'whoops, that isn't actually what
> > developers need for 70% of real cases' and that scenario is a
> > fundamental loss at almost every level.  The issue is that that those
> > simple cases are, in fact, not the norm, you exceed them very quickly
> > and the question immediately becomes 'then what?’.
>
> You adapt and change things as needed.  But for now you work with the
> information you have.
>
> Again, I’m not trying to create a large comp-sci project with all sorts of
> theoretical options.  I just see a basic user experience problem and
> figuring out a solution designed to fix that.
>
> I hope you agree that there is full-page reload is a problem with the
> web?  If you agree that it’s a problem then we can fix it.
>
> Ideally the solution would work with all parameters I previously mentioned
> (JSON API interfacing, no loading additional JS files, high-school kids can
> understand it, etc..)
>
> Other solutions don’t meet these parameters.  Angular/React/etc. requires
> loading in an extra Javascript file, as well as JS programming, which is
> why they’re not widely adopted except for JS developers.  XSLT doesn’t have
> a statefully persistent model object & operates around weird XML.  MDV also
> needs JS and the models seem tied too close to the DOM, and so on..
>
> The fact that so many people are trying to solve this problem isn’t a good
> thing.  It means there’s a problem with HTML itself that needs to be
> addressed.  HTML really needs to just go ahead and fix it.
>
> > There's a lot of
> > competition and collaboration figuring out how you create a well
> > reasoned system that allows users the proper balances of power and
> > simplicity and ability to adapt.  To answer the same sorts of
> > questions that they answer every day, your solution will involve
> > JavaScript too - as well as SQL and some server-side specifications
> > which will require their own languages and probably frameworks.
>
> Those are optional features.  The basic proposal offers dynamic pages
> without Javascript, using pure HTML.
>
> > I'm honestly not trying to dissuade you here or perpetuate an
> > argument, I'm just saying that your insistence on drawing this line to
> > say 'it's so simple' is, surely you can appreciate, a 'big' statement
> > and it doesn't seem unreasonable for people to ask you to actually
> > show them.  Believe it or not, participants in standards bodies have
> > limits to the amount of time and monetary investment they can make
> > into something and there's a lot to do.  Getting something started
> > often requires first-movers to show something, even browser makers
> > usually don't just throw an idea out there, they work out a proof of
> > concept with the proposal and show people what they are talking about.
> > It's not unreasonable to think that people ask you to do a little more
> > leg-work before they commit to ...well... even reading more if you see
> > what I mean... we've all got limited time.
>
>
> Right now I’m trying to figure out advanced scenarios or use models where
> this proposal would be a bad idea. You have any ideas on that?  Polyfills
> aren’t going to cover all possible scenarios, either, since they’re going
> to be limited by test coverage.
>
> -bobby
> ---
> 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 Friday, 3 April 2015 12:55:32 UTC