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

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:
>https://github.com/mozumder/HTML6
>
>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
>---
>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>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Received on Wednesday, 25 March 2015 00:26:01 UTC