- From: Brian Kardell <bkardell@gmail.com>
- Date: Thu, 13 Jun 2013 11:50:18 -0400
- To: Karl Dubost <karl@la-grange.net>
- Cc: François REMY <francois.remy.dev@outlook.com>, Tobie Langel <tobie@w3.org>, "public-nextweb@w3.org" <public-nextweb@w3.org>
> Yes. Community acceptance happens in many fashions. Right, and we've spelled out in numerous articles and a few talks now where the kinks in those have proven to be. We'd like to unkink. > 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. The purpose isn't to point at red flags so much as it is to learn from a long history of many less than perfect attempts and suggest something else. > >> 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. Your beginning statement is an answer to your question about how the community fleshes out an API... One way is by understanding what they can do with it - that takes some time and a lot of people trying to use it... Some will stretch or question it in new ways. You can listen to talks and hear lots of language/library developers talk about this - it's the adjacent possible (not a term I made up, can't recall who to credit): Each new thing makes new questions possible - people find use cases the author(s) never dreamed of. The longer you give them to really understand it and learn from one another - the farther they can stretch it. We love standards - they are excellent for a number of reasons. The one most developers care most immediately about though is interoperability. Our aim is to give them faster interoperability (because less is tied early to the browser) and let users start learning, using and stretching. Let them provide feedback into the system while actually accomplishing their real jobs and let ideas compete and sink or swim a bit... There should be no blind rush toward standardization, and in this model the impact of that is considerably lessened. > >> 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". > Yes, for sure... >> - 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. It isn't one or the other - we cannot add flexibility to the platform without changing some of the social structures. Just like an API, as I described above, with a new model comes some new challenges - I agree this is an interesting and exciting part. > > 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". I think that already exists, we're just broadening it. An immense number of people use HTML and CSS, a smaller but still quite large number of people use jQuery, a considerably smaller number still build plugins and so on.... I disagree with the "bourgeoisie" connotation. > * alienating non JavaScript developers (sense of feeling powerless) I totally disagree - this **greatly** empowers the average non-javascript developer by allowing them greater/faster access to proposals for higher-level things that deliver them immediate value now - which can in turn provide information about use-cases and adoption back into the system. > * having some browsers companies competing in releasing non-standardized primitives instead of the complete features Already a reality - less motivation for it in this model I think. > * having the possibility to standardize some well deployed JS design patterns as declarative forms (though JS legacy code will be already deployed) Yes. > * taking as long to reach *the social agreement* It's variable, right? It could be much shorter (<main> I expect could have happened relatively quickly and with less controversy) and it could be considerably longer. There is an important difference however in that the intermediate forms/slang provide actual value in the meantime. Is it better to wait years to get something which we know will be imperfect, or is it better to have usable proposals evolving over the same number of years? I'd chose the later any day and wager that the net result will be considerably better. > * being stuck with not well thought out primitives (moving the goal posts) Why do you say that? I mean, I suppose it is a risk, but low-level interfaces are often considerably dealing with more well-known sorts of ideas than the high-level ones we see. I think you should start a new thread on this particular topic if you would like to express something there. > All of that if I understood the proposal. As I said it looks interesting. I agree :) > > -- > Karl Dubost > http://www.la-grange.net/karl/ > -- Brian Kardell :: @briankardell :: hitchjs.com
Received on Thursday, 13 June 2013 15:50:50 UTC