

The Extensible Web Manifesto - porker
http://extensiblewebmanifesto.org/

======
agentultra
It makes sense to me on some level. I realize that not everyone is a fan of
Emacs but there's some truth to the old jab: "it's a decent operating that
just needs a good text editor." It's more like a decent lisp that provides a
kernel for implementing a text editor. I think it would be interesting if the
web took that bottom-up approach (what I call the, "Emacs Philosophy," for
lack of a better word): establishing a kernel for implementing a web browser.
The interesting thing about Emacs is that there are several implementation of
web server that are fully capable of interacting with the rest of the
"environment" inside of your running Emacs process: it can serve up a web page
that renders your currently active buffer for instance.

The problem with this approach is the trade-off with standardization: some
vendors will implement things in different ways and libraries may not always
work together without a little effort on the part of the user. Standardization
does have its benefits... we almost went down the rabbit hole of active-x and
"this site is made for Y," in the web world and it would be a shame to repeat
that nasty bit of history (but we're already looming fairly close). The
problem is that not everyone will cooperate and fickle web developers
concerned with elegance and prettiness will go off and write three different
incompatible implementations of the same thing. Users don't care about that
stuff.

------
porker
There's an accompanying blog post by Yehuda Katz covering the reasons behind
the manifesto: [https://medium.com/the-future-of-the-
web/2fcd1c1bb32](https://medium.com/the-future-of-the-web/2fcd1c1bb32)

------
MatthewPhillips
I'm not sure how this manifesto differs from how things work today. Today we
get a mix of high level (AppCache) and low level (Touch Events) APIs. Is this
manifesto saying always start with the low level ones? There are strengths and
weaknesses no matter which way you go. Does this manifesto have a solution for
the problems that exist when we don't have high level APIs, namely that the
most common scenarios aren't well served, and library support is usually weak
for new (less than several year old) APIs? For example in 2013 it's still a
pain in the ass to detect a `tap` that works on both a touch screen and
keyboard/mouse. The solution for this particular problem is a high level API
(Pointer events).

So it's not clear to me that this manifesto is actually the right choice. For
every high level API misstep there is a corresponding low level one as well.

~~~
slightlyoff
Hi Matthew,

So, first, it's not the mark of failure for their to only be a high or low-
level version of some capability in the platform; at least not immediately.
The issue arises when, having exposed one or the other, we
[users|vendors|spec-authors] think the job is done.

It's like saying you've got a map of a continent having mapped either the
outer shoreline or the inland lakes. It's a nonsensical thought, but it's
where we tend to leave things today.

Your brought up AppCache -- which, as it happens, is a topic near and dear to
my heart as I'm currently trying to engineer its low-level explanation:
[https://github.com/slightlyoff/NavigationController](https://github.com/slightlyoff/NavigationController).

AppCache had relatively well-known, overwhelming deficiencies early in
life...yet instead of attempting to peel the onion and explain the layers
below the manifest format, the spec process rewarded piling into the clown-car
of declarative configuration. It's the natural thing to do, after all.

What we're after here is _connecting_ the high and low levels. Creating a
fully descriptive map that has texture, color, and major features marked and
named.

We must always start somewhere, but we must also be anxious to know and
describe what we can sense but can't yet explain. And that requires a sense of
urgent investigation.

And THAT is what is missing today.

Regards

~~~
MatthewPhillips
I'm afraid I still don't understand what you're getting at.

> What we're after here is _connecting_ the high and low levels. Creating a
> fully descriptive map that has texture, color, and major features marked and
> named.

A low level AppCache API doesn't exist though. So there is no connection to
happen, right? I realize people wish AppCache had been designed differently. I
wish Touch Events had been designed differently. The web is littered with
mistakes, I don't think a manifesto is going to prevent them from occurring.

What is the essence of this manifesto? I read it as favoring low level APIs.
Ideally we could have both but there aren't the resources to make that
practical.

~~~
slightlyoff
This misunderstands what happens inside implementations. There ARE low-level
bits "down there", but they aren't spec'd. That what the Navigation Controller
is: a spec for the low-level bits.

As a part of that process (and Web Components before it), the goal isn't to
throw out what has come before (we don't get that luxury out here on
successful, non-proprietary platforms), but to re-cast it in the light of a
lower-level thing that explains it.

You can go the other way too. Noodle on this to get a sense for it: how much
of the <audio> element can be implemented with some JS and the Web Audio spec?
Since those connections make sense, why isn't <audio> spec'd _in terms_ of Web
Audio, such that you can plug in/out the bits you need when you need something
slightly different?

~~~
MatthewPhillips
So you are saying that the low level bits should eventually be spec'd (but not
necessarily first)? That is what this manifesto is about? If so, I can agree
with that, but wish it was more explicitly stated in the manifesto.

------
_greim_
What would be some examples? Low-level (sax-style?) access to the HTML parser
is something I looked for years ago and never found. Would we be able to
extend native CSS selectors, kind of like how you can do with jQuery selectors
now? It sounds really promising.

~~~
bkardell
Yes, in layers. The problem currently is that if you want to tweak something
you have to basically replicate the entire stack. That sucks - see Yehuda's
article linked elsewhere in the comments for better examples. ps, if you want
to play with jquery-like selector plugins to prollyfill a proposed feature,
check out hitchjs.com

------
szany
Alan Kay has been calling for this for a long time now.

