- From: Brian Kardell <bkardell@gmail.com>
- Date: Mon, 23 Mar 2015 14:18:56 -0400
- To: Bobby Mozumder <mozumder@futureclaw.com>
- Cc: "public-html@w3.org" <public-html@w3.org>, WHATWG <whatwg@whatwg.org>
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