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

I think I can firmly say that I'm not in the "JS all the things" camp. I do
see the reasoning behind this, but I'd like to point out that not everyone
in the world would like to use the MVC model. Personally, I don't mind it
(since it offers a logical separation of data, presentation, and
operational logic), but I know of those who hate it.

Also, I'm a little terrified of having SQL directly in the markup. There's
so much potential for that to go horribly wrong. Personally, I feel things
that involve data retrieval should be better handled by endpoints that
return HTML, XML, or JSON. Putting it in the user-accessible markup is
dangerous.

Some of these things you're asking the browser to do, I don't think the
browser should be doing. Fundamentally, web sites are a client/server
model, and we shouldn't heap on too much into the client side. Part of the
problem with that is the computational complexity (which is a problem in
developing countries where low end devices are the norm). The other part is
that you are essentially trusting the user device to be secure, which is a
terrible idea no matter how you slice it.

The main reason that browsers get so much heaped onto it these days is
because we've not really evolved the role of the server in website design.
It's been the same for years, which is fine, except that it's clearly not
good for the mobile world (as more complex processing moves from the server
to client). I don't know the appropriate forum for discussing that
particular issue, but I think we need to make the server side of this more
intelligent, too.

I think it makes sense to extend HTML to support "single document" website
models like this, but I'm extremely wary of mandating the browser to
process data directly. An individual developer can make that choice
himself/herself, but I'd rather not mandate that workflow. Instead,
enabling partial refreshing and using endpoints with URI request
information to retrieve the desired portions of the page to load up makes a
lot of sense. But we also need this to be a linkable model. I'm not sure
how you can make a desired "variant" of the page linkable from an external
source (such as Wikipedia or a news organization site).



On Tue, Mar 24, 2015 at 5:18 AM, 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>
>



-- 
真実はいつも一つ！/ Always, there's only one truth!

Received on Tuesday, 24 March 2015 12:08:02 UTC