- From: Martin Janecke <whatwg.org@prlbr.com>
- Date: Sun, 05 Apr 2015 14:46:30 +0200
- To: mozumder@futureclaw.com, whatwg@lists.whatwg.org
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