On 02.04.15 22:05, Bobby Mozumder wrote:
On Apr 2, 2015, at 12:11 PM, Martin Janecke <whatwg....@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
