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

Bobby,

I think your enthusiasm to question and challenge the status quo is great. Many individuals like you challenge the standards in this mailing list. I'm constantly learning from the discussions that takes place from such proposals and I value it immensely.

However, I'm kinda pissed off on how you went about sharing your insight. Unlike you everyone has encouraged discourse while respecting the enormous amount of effort it took to get here. Posting a title with HTML6 is hyperbolic and link bait at best. HTML5 is a living spec, changing the version with no dialog from committee members is disrespectful. The trash statistics you used to "support" your argument reeks of laziness, they waste everyones time. Give us a case study or some large sample of data before asserting such nonsense. 

If you really want to make this happen write a polyfill. Many proposals and even standards are implemented as a proof of concept before ever reaching a vendor. Your proposal can be implemented with javascript right now with not much effort. This is the beauty of javascript and why we have so many frameworks. No one agrees on how we solve these really hard problems. Everyone is experimenting and testing. That's my biggest gripe about your proposal, oversimplifying the problem domain. What you propose pushes tighter coupling and implementation details to the servers. Your just moving the problem not removing it.

Your core argument for your proposal asserts JavaScript is hard and slow. Yet at the same time you want HTML to act like such because single page apps are fast.  Do you see the fallacy in this argument? Please provide some data especially on the slow bloated part. I often find optimizing even a few images will yield file size savings that far exceed the payload size of an entire sites JavaScript. Yes, JavaScript is hard but the problems associated with web are really hard. There are so many layers and ways to solve. In my opinion your proposal is simply not generic enough to be called a standard, it would be classified as a framework much like the ones you attack. This is the beauty of the standards we have, we have wiggle room to create, explore and learn. They do not tell us how to solve the problem, I think this is what frustrates you.

If you want to continue this dialog please take sometime and read through how others addressed proposals to the community. Like I said I'm not against you sharing your view point but try and respect the process. This will save everyone time.


> On Mar 23, 2015, at 9:44 PM, Bobby Mozumder <mozumder@futureclaw.com> wrote:
> 
> 
>> On Mar 23, 2015, at 2:18 PM, Brian Kardell <bkardell@gmail.com> wrote:
>> 
>> At some level,  you can safely say that you will tend to like your own
>> design and find others a bit harder to understand.. Having experience
>> with a whole lot of previous attempts, but not yours, for example, I
>> can't say that I find yours to be especially simple or intuitive, but
>> I won't claim to represent the norm any more than I ask you not to -
>> so I agree, actual data is required.  
> 
> The data I have is the outside virality of this.  We could probably even quantify this.  I have to rely on outside feedback as well, and do take into considerations people's comments and iterate on the proposal as needed.  Obviously Javascript developer are against it, but regular web developers look like  they’re into it.
> 
> This really should be part of the out-of-the-box HTML default use model. 
> 
>> I will say that the XML nature
>> is problematic, as is SQL for reasons we can actually point to.
> 
> I’ll change the example to JSON.  The SQL section could come later as well.
> 
>> Additionally, I will say that your list is pretty short, you'd also
>> have to include things like XBL and MDV
>> (http://mdv.googlecode.com/svn/trunk/docs/design_intro.html) and a
>> whole bunch of other stuff that had powerful support and lots of
>> investment, and give them some serious consideration as to why they
>> failed to get agreement, implementation, adoption and staying power -
>> then think about how your proposal would not fall victim to the same
>> pressures.  For me, personally at least, I think there are existing
>> proposals which I already prefer more.  I'm not seeing how an element
>> is a 'controller' for example or how you make a controller
>> non-imperative - even models generally have a data layer in a lot of
>> frameworks which would currently confound me as to how to accomplish
>> relation/request management declaratively.. I know we can get there, I
>> want to get there - I just haven't seen the right proposal yet that
>> answers all of those things.  It definitely seems like for now you'd
>> need a pretty rich JS API which you haven't even hinted at here.
> 
> For this proposal, the controller isn’t an element.  It’s the browser itself. 
> 
> The user interacts with the document View layer.  He clicks on a link: <A href=“http://api.mywebsite.com/data-endpoint”>
> 
> The view layer notifies the browser of a click. 
> 
> The browser fetches http://api.mywebsite.com/data-endpoint and loads data into the model objects.   
> 
> The model objects update the document View layer.
> 
> So, when you consider the browser to be the controller, this design and use model makes sense, and follows the same use model as now.  Instead of loading a new page, you load data objects now.  All the logic to do that is in the browser.  
> 
> Plus, the browser already has a whole Javascript framework that can be used to enhance its behaviour.  If I want to do some processing on the models, just write some Javascript callback code to do so. Bam. Done and done.
> 
> People are freaking out about the idea of separation of concerns with the HTML acting as logic, but it isn’t doing logic here.  The browser is still responsible for logic, and it has default behaviors for these models ("Clicking on this link loads external data into this model") which you can extend ("convert the Markdown model data into HTML", or "load API data at a scroll point”)
> 
> -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>

Received on Saturday, 28 March 2015 17:19:43 UTC