Re: [whatwg] HTML6 proposal for single-page apps without Javascript

Am .03.2015, 04:48 Uhr, schrieb Bobby Mozumder <mozumder@futureclaw.com>:

> […] And many, many people are using these advanced frameworks to just  
> improve on this basic web user experience.
>
> If you look at https://builtwith.angularjs.org you’ll see that many of  
> the sites are just using Angular to improve page load speeds.  They’re  
> not doing anything more advanced than showing a blog or processing  
> forms.  They’re not building advanced interactive GUI applications like  
> Google Maps or building games or anything like that. They’re just using  
> these frameworks to fix the web's full-page refresh latency problem.
>
> That’s it.  Nothing more. And they call them “apps” because of they use  
> Angular.
>
> The Ember.js framework is being helped/funded by Bustle. Check out  
> bustle.com, and you’ll see that they’re not doing anything more advanced  
> than showing articles from a CMS. That’s it.  They just get to serve  
> these articles really, really quickly. They don’t have to do that, but  
> they do because a responsive website helps the user experience.

The shorter load time comes at a price. For example, these pages are  
difficult to archive by sites like the Internet Archive or WebCite. It's  
much more difficult to process these pages with bots – instead of a simple  
script reading a text file bots need to be half a webbrowser to make sense  
of them. In my perception, these sites are inherently less accessible  
because they dissociate a resource from its URI.

Furthermore, my user experience suffers on these sites quite often. In  
your example https://builtwith.angularjs.org , when I navigate to "page 2"  
using the page navigation bar at the bottom, and then hit my browser's  
back button, I don't get back to "page 1", but to where I was before  
accessing builtwith.angularjs.org. That's unexpected and a bad user  
experience. I can't rely on the browser's user interface with those sites,  
but have to learn each site's individual user interface.

Authors/editors of websites are on their own site during much of their  
time and tend not to realize theses things, as they know their own site  
very well, but readers do not. Readers' user experience is very often  
worse than authors think it is. Those things that bother readers might  
well be more important than the latency issues that concern you as an  
editor.


> That’s the read/write web.

I understood the concept of read/write web as "the Web as a space for  
collaboration and not just a one-way publishing medium" (cited from  
http://www.w3.org/Amaya/). Making pages load quicker seems to be something  
different, and dissociating content from URIs actually makes cross-domain  
collaboration less reliable in my opinion.


> So why isn’t the web this responsive by default?

I admit that I don't know much about HTTP, but I understood that HTTP/2 is  
supposed and being developed to improve this *a lot*. HTTP seems to be the  
right layer to solve this to me, not HTML.


> Why does the web have to load full pages? That’s clunky and not app-like.

You don't have to reload CSS, JavaScript, fonts or presentational images..  
These are cached. You only have to load a page with content and some  
structural HTML markup. That may not be app-like, but it's fine in my  
opinion, and prevents the bad user experience surprises I discussed above.


> The default condition should be the best condition.

Sure, but I bet people disagree what the best condition is. I know I  
disagree with the notion that receiving a content loading script  (whether  
written in JavaScript or using a new mechanism) would be better than  
receiving the content itself when requesting its URI.

Martin

Received on Monday, 30 March 2015 12:33:20 UTC