RE: Native DOM way to get nodes of arbitrary type/name

Hi Marat,

I'd like to offer some friendly advice on getting your proposal taken seriously. I hope you will take it as it is intended, in good spirits.

The first step in getting people interested in your proposal is demonstrating that you are solving a concrete problem. To do this, there are two key ingredients:

1. Showing that you are solving a real developer-facing problem, and not one of API aesthetics ("I don't like using selector strings" is aesthetics, for example);
2. Showing that there is no way to solve that real developer-facing problem currently.

This may seem like a high barrier, but features are not free in any sense. Someone has to specify them (in the extensive detail required for interop, not in the cursory detail of an email message); someone has to integrate them with the rest of the platform; someone has to apply the human-resourcing pressure to get implementers to allocate valuable developer time to writing the appropriate browser patches and developer documentation; and then there's the ongoing maintenance cost that comes with any API, e.g. its constraints on backwards-compatibility for the indefinite future of the web platform. With these costs in mind, you can see why a feature that might seem obvious to you needs a lot more convincing than you're currently doing. Expecting people to intuitively understand why your feature is worth all those costs is not fair or reasonable.

So far you have not demonstrated very good concrete use cases (recalling Glenn's definition). The best way to do this would be to find an existing web app (not server-side app) that uses existing methods, like XPath or tree walkers, and then show how much cleaner the code would be with your proposal in place. Not a contrived example, but a real, deployed web app with lots of users, that existed prior to you sending your message to the list.

If it is indeed much cleaner, then the question becomes: is the web app you've shown doing something that is common enough to add an API to the DOM for? For that, you will need multiple examples of such web apps, because if it's something that only one large web app is doing, then that web app should just write a library that allows these operations cleanly, and open-source it. Indeed, even if several are doing that, an open-source library may be the best solution for prototyping; that is how the platform gained e.g. CSS selector matching, by first prototyping it in Sizzle and only after it had gained widespread adoption and recognition, making it native.

But what about performance, you ask? Indeed, you seem to bring up this point often in your previous messages. However, I don't think this argument is very strong, for a few reasons. Native code is not generally faster than JS libraries for such tree-walking operations; the transition between the JS to C++ barrier, and back again, causes significant overhead in all current engines. As such many engines have taken to "self-hosting" parts of the platform, writing them purely in JS, without using C++ at all. This gets us back to the same performance as an open-source library.

But let's say that the C++ implementation is possibly faster; perhaps it has access to some privileged APIs. Well, you need to prove that, if you want to use performance as an argument. To do so, the best thing to do would be to submit some patches to the various open-source engines, showing how you could use these privileged APIs to create a faster version of your proposal than is possible in a JS library based on XPath or tree walker. The accompanying benchmarks would then provide a good argument, either for exposing your proposed APIs, or perhaps for exposing the privileged fast APIs that make things possible, thus enabling not only your desired operations to be written in performant JS, but also probably other operations that could benefit from such fast-path lower-level APIs.

I hope this is helpful to your goals, and that you can understand where I'm coming from. I'm very interested in getting developers like yourself involved in the standards process and in proposing new or better APIs; in my opinion the WHATWG and company could greatly benefit from help in such areas. (I do love the shape of your APIs; they are very sensible, and much better than many existing ones in the DOM!) But in this particular instance, I'm afraid you might not be tackling the problem in the right way, and so I wanted to give you some perspective to help you be more productive.

Received on Saturday, 5 October 2013 12:35:31 UTC