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

On Mon, Mar 23, 2015 at 4:44 AM, Bobby Mozumder <mozumder@futureclaw.com> wrote:
[snip]
> Thanks for the feedback here. I just had a quick look at some of the past proposals (XForms, Microdata, & XSLT), and they all had clear usability & design issues to me.  For this, I focused on presenting the most obvious, usable solution, while trying to be very simple & intuitive to a web developer.  A usability test would be to see if people understand what I’m proposing.

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.  I will say that the XML nature
is problematic, as is SQL for reasons we can actually point to.

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.


[snip]
>> You’re looking at it from bottom-up.
>>They’re all trying to implement the missing MVC framework in browsers, and are just
>>working on implementation issues.
>>Javascript implementation have no real relevance to
>>HTML.  For example, would you implement React’s framework or API design in the
>>browsers if they solved everything?  What would be the next step in your statement?
> ...[snip] I think we really need a top-down focus on a separate HTML-based solution: find the problem, and solve for that.  Not, find a solution, and fit that into another problem domain.

It's certainly not the case that there is a "this is the agreed upon
standard concept" - there is MVVM, MDV, MVP and so on - angular, for
example, was "model view whatever".  Routing is also a concept in most
of these and a lot of the design that's come out is a lot closer as a
piece and contains useful paradigms for promoting recommendations
about URLs.  So there are some cow paths being tred, and their
competition and collaboration is actually a good thing in my mind -
all of them are getting better for it.

Note, I don't implement anything natively in browsers, that's
implementers and I am not employed by one.  React is not a proposal,
it's a framework - there's a pretty big difference.  If Facebook (or
ember or angular or anyone else) actually solved everything, worked
with others and developers were adopting it and it had some stability
and they submitted a proposal that captured a layered explanation of a
really useful paradigm, absolutely I'd support it.  The last effort I
saw at this was linked above (MDV) and that's being experimented with
in polymer, but I think it's currently withdrawn - but polymer is
working with angular and ember devs, and all of those are learning
things from React.  That's good in the long run, how many long,
hypothetical emails on a list like this would we have to have to
arrive there?

All of these frameworks have a lot of code, as you've noted, and a lot
of abstractions and hooks - therefore, they generally make for a
pretty complex proposal.  My own goal, however, is _absolutely_ that
wherever possible a proposal would come with a prollyfill which allows
users to try it, gain some experience and help improve it before it
becomes a standard and ultimately can serve as a polyfill for browsers
that don't support it yet.

High level things are great, I love them.  I have some, I'd like to
have more.  They're also hard to agree on and very closed-ended - the
potential to get it wrong is great - all the more so when the design
happens in a committee before anyone has implemented or tried to use
anything for real work. There are definitely pieces of your proposal
or frameworks that could be broken down and useful outside a whole MVC
proposal and stand a better chance of entering the collective DNA of a
possible larger solution and allowing us to create an adaptable
platform, and there are definitely inroads where we can be moving the
whole idea forward along the way (I think we are actually in a sense).

Again, it's just my 2 cents.



-- 
Brian Kardell :: @briankardell :: hitchjs.com

Received on Monday, 23 March 2015 18:19:23 UTC