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

> 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