W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2015

Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github

From: Michael A. Peters <mpeters@domblogger.net>
Date: Tue, 24 Mar 2015 16:50:48 -0700
To: Bobby Mozumder <mozumder@futureclaw.com>,WHATWG <whatwg@whatwg.org>
Message-ID: <8659f1d6-e99f-4940-ac5f-aeb52e4bc005@email.android.com>
I see JavaScript as a useful tool that is seriously abused by many devs, I'm against this. But if you do it, make damn sure it has proper CSP support.

On March 24, 2015 2:18:53 AM PDT, Bobby Mozumder <mozumder@futureclaw.com> wrote:
>I’ll be updating that Github with more ideas and refinement about the
>proposal with occasional feedback into this list.  Since this is
>getting some attention it’s probably better to place the ideas in a
>setting that can be updated/modified than to discuss it informally via
>email over here.  This is still at the concept phase and I’ll be
>looking at feedback from other people as well as other frameworks to
>see the good they offered as well as what caused them to fail.  
>In this version, a key change is that I added an MREF property to <A>
>elements to separate the canonical URL from an API URL, and a RECEIVER
>property to specify where the API data loads:
>	<A href=“http://www.mywebsite.com/article-2.html"
>mref=“http://api.mywebsite.com/article-2" receiver="MyArticleData">
>The MREF will maintain backwards compatibility.  You can use the same
>web page in an older browser and it operates fine, it just won’t load
>API endpoints, but will reload full page from the HREF.  And previously
>I had a MODEL property in place of RECEIVER, but that's the overall
>model’s outlet for all elements, not a receiver model, which can be
>different.  Adding a MODEL property would load the model’s properties
>into the HREF and/or <A> element.
>I also changed the fixtures in the example from XML to JSON.  I always
>thought XML was more readable when mixed with HTML, but it looks like
>people prefer reading JSON?
>Meanwhile, it looks like the people most into Javascript are against
>this, and the people that prefer to avoid Javascript like this. 
>I get that most people here are in the “Javascript everywhere!” camp
>but there definitely is a large class of people out there that prefer
>to minimize their use of Javascript whenever possible and just want to
>deal with the declarative HTML system.  These are content managers, and
>Javascript components are largely in the UI design domain, not the
>content domain that many web developers are coming from. How many UI
>design experts are out there?  And how many of them like working with
>Javascript, instead of Swift or something else?  You’re competing
>against that.
>Also I feel you shouldn’t have to prototype new HTML elements as
>Javascript components to advance HTML.  That’s a huge barrier to its
>development, as now you need to do that first.  Very few people will do
>so for a standards body.  The components they make are going to be very
>specific to their needs.  Plus, browser makers aren’t going to write
>them, so you just forced them to wait for someone else to design these
>components first, when they already know the problems their users are
>experiencing and can fix them already.  And if your site can do it with
>a custom component then why bother putting it into the standard?
>Finally, aren’t people already doing this sort of prototyping anyways
>with the Javascript frameworks?  At a high-level, they’re all basically
>prototyping an entire MVC use model, with just implementation
>differences between them.  Isn’t that enough to cause HTML to be
>updated to fit this MVC design pattern?  It’s a basic issue in the
>design of the web.
>Bobby Mozumder
>FutureClaw Magazine
>mozumder@futureclaw.com <mailto:mozumder@futureclaw.com>
>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>

Sent from my Android device with K-9 Mail. Please excuse my brevity.
Received on Wednesday, 25 March 2015 00:26:01 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:29 UTC