Re: The Extensible Web Manifesto [via Extensible Web Community Group]

Brian,

Thanks for explaining. It's what I thought, but was not sure at first.

Brian Kardell [2013-06-13T08:36]:
> Iteration is key, it depends upon community acceptance.

Yes. Community acceptance happens in many fashions. 

* a proprietary feature released in a product (XMLHttpRequest)
* a half-baked feature (css properties not finalized with -vendor-)
* a marketing campaign (demo sites associated with music bands)
* a code library (ex: jquery), a design pattern (ex: using tables for layout, blockquote for indenting), etc … 
* a spec being released and implemented by authors (wcag) and/or implementers (DOM)
* etc.


> The current model is hostile to this in two ways: 


see above, it doesn't only happen in one way. My goal is not to say "do not criticize w3c, ecma, ietf", not at all. My goal is to address the issues where they are and not to use "red flags" as the focus point.

> first, the process to getting something for users to evaluate and provide feedback

Yes and no (apologize from my Normandy origins).
Some features need time to be understood, some deserve a very quick feedback loop. What I'm not sure to understand in the sentence here is the term "users". User of a Web site (with no knowledge of the technology), many of the constituencies of a Web agency (from bizdev to Artistic Direction to Back-end, Front-End, JS lib developers, etc.). Basically there are many users and the impact of a long/short feedback loop is different.

> and demonstrate use cases for takes too long;

Again here not sure, what it is aimed at.

> second, it currently requires native impl in browsers

Yes and… hmm not only. In the Web stack in general, except if you exclude servers, proxies, and clients which are not "traditional browsers".


> - and once that is done it is infinitely harder to change.  Thus, together, the two are fatal.

OK my issue I guess starts here. If I understood the proposal for the Manifesto. You are saying that browsers will go from "CISC to RISC" metaphor, aka a set of primitives which gives extension points, so that JavaScript Developers (and not the mythical "Web developer") can experiment with new features. Or as another metaphor saying that HTML is a set of "div/span with class and id", and let the users create vocabularies. And later on when large adoptions, standardize some vocabularies. So you are adding a point of flexibility in the *Platform*, not the social structure of standards organizations. It's why I'm saying it is unrelated to the organizations.

What we do not know yet and it's how socially it will unfold. That's the interesting (exciting?) part. It will create its load of new issues, good and bad outcomes. 

My gut feelings (we will see in times what will happen):

* giving more freedom (power) to a certain class of JavaScript developers. New "bourgeoisie".
* alienating non JavaScript developers (sense of feeling powerless)
* having some browsers companies competing in releasing non-standardized primitives instead of the complete features
* having the possibility to standardize some well deployed JS design patterns as declarative forms (though JS legacy code will be already deployed)
* taking as long to reach *the social agreement*
* being stuck with not well thought out primitives (moving the goal posts)

All of that if I understood the proposal. As I said it looks interesting. 


-- 
Karl Dubost
http://www.la-grange.net/karl/

Received on Thursday, 13 June 2013 13:43:10 UTC