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

> On Mar 24, 2015, at 8:07 AM, Neal Gompa <ngompa13@gmail.com> wrote:
> 
> 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.

I’d like to hear the arguments against it, and in particular, how usability is better without it. I gave several reasons why these frameworks exist in order to fix whats wrong with the web.

> 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.

It’s just an URL syntax that now allows for SQL statements.  It’s not the actual connection to a database.  If you connect to a remote server, the server can decide to grant you whatever authorization it wishes, through OAuth tokens in the header, through the URL syntax, or whatever.  And, for local databases, you can have full control if you want.

> 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.

I never said the client would be consider trusted.  Not sure where you got that?

Right now, if when you request data via an API endpoint URL, the remote web server transforms that into an SQL query.

This proposal lets you request data via an SQL syntax.  The remote web server would still need to transform that syntax into an SQL query that’s fit for the server.

For example:

 SELECT first_name, last_name FROM users;

would be transformed into:
 
 SELECT first_name, last_name FROM users WHERE manager="Boss Man";

And this proposal also eliminates the need for a transformative app server when accessing local databases.

> 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).

In the latest version (on the GitHub), I added an MREF property to links to separate the model API endpoint from the canonical URL:

 <A href=“http://www.mywebsite.com/article-2.html" mref="http://api.mywebsite.com/article-2" receiver=“myArticleData">

When you click on a link, the browser fetches JSON data from "http://api.mywebsite.com/article-2".  It then loads that data into “myArticleData", and the URL bar becomes “http://www.mywebsite.com/article-2.html” in the pages domain.  The HREF URL is the canonical URL for this piece of data, like always, and this is what people can share and link to from external sites.

Does that work?  Any problems behind that?  

-bobby
---
Bobby Mozumder
Editor-in-Chief
FutureClaw Magazine
mozumder@futureclaw.com
+1-240-745-5287
www.futureclaw.com
twitter.com/futureclaw
www.linkedin.com/in/mozumder

Received on Tuesday, 24 March 2015 20:49:40 UTC