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

On 02.04.15 22:05, Bobby Mozumder wrote:
>
> On Apr 2, 2015, at 12:11 PM, Martin Janecke <whatwg.org@prlbr.com> wrote:
>>
>> On 02.04.15 04:59, Bobby Mozumder wrote:
>>
>> I understood that the motivation for your proposal is a shorter loading time for content on webpages. Your proposal might be one way to achieve this, but to me it's not obvious that we *need* a built-in MVC framework in HTML to make content load quicker, or that it is the best way to do it. Your proposal is a pretty huge, much encompassing thing for a very particular problem.
>
> I’m open to other solutions, and looked at several other proposed solutions as previously mentioned. For my solution I gave:
>
> 1. Allows high-speed dynamically loaded webpages via JSON APIs.  Makes the web as fast as native apps.
> 2. Doesn’t require initial loading of an external Javascript framework (or multiple frameworks)
> 3. HTML only - broadening usability.  Doesn’t require the web developer to code in Javascript.
> 4. Allows advanced Javascript developers to tinker with model data directly via its own model-access API if needed
> 5. Stateful model object.  Browsers can manage this model data if needed. (save it for offline use, etc..)
>
> I get that my proposal is a huge change, but I don’t see any other path to hitting these goals other than putting in MVC in HTML.  You have any other ideas or other frameworks?

I pointed at HTTP/2 in the discussion on the w3.org public html mailing 
list. It speeds things up without putting an MVC in HTML. I think it 
works for more use cases. It works on a very different layer (which 
implies that it can be combined with further mechanisms of course, 
including your proposal).


>> Are you going to create a working demonstration/polyfill for your proposal, so that people can try it, as has been suggested?
>
> I would recommend Angular with some of its directives as probably the closest polyfill to this in terms of the view layer.

That's not what I meant. I meant: Are you or is somebody else going to 
provide a (JavaScript) script that interprets the markup from your 
proposal and makes it work without being natively build into browsers yet?

Such a polyfill may be build using Angular of course.


> You know what would be better than a polyfill?  If the browser vendors tackled the issue directly.

I disagree. I'm convinced that it's better to identify and solve as many 
of the concept's problems as possible before it is natively implemented 
in browsers.

Why are you dismissive of a polyfill? I don't know how likely your 
proposal is to make it into HTML at the end, but whatever the chances 
are, they appear to be higher with a polyfill than without one as a 
considerable portion of the people who commented on your proposal asked 
for one and explained why they consider it necessary.

If your proposal get's included in HTML, the polyfill would allow people 
to already use your concept and enjoy most of its benefits during a 
transitional period when there are still many old browsers around who 
don't support the native implementation.

If your proposal didn't become part of HTML, the script would enable 
everybody who likes your approach to use it anyway, with all the 
benefits except for point 2 in your list above.

Making the polyfill wouldn't be in vain in any case.

The only disadvantage I see in developing the polyfill is that it costs 
its developers time and energy. But it saves multiple browsers' 
developers' time and energy, so I don't consider this argument to be 
highly relevant.

Happy Easter
Martin

Received on Sunday, 5 April 2015 12:46:55 UTC