> Back to the article. WebKit won't allow hooking in random JS engines. Allowing this slows things down because many DOM access optimizations can be achieved by assuming a specific engine. This is totally reasonable thing.
I agree, it's totally reasonable, which why I say in the article, "Removing the JavaScript layer is one thing; this was a piece of code that existed only to support Google's use of V8, and with JavaScriptCore now the sole WebKit engine, streamlining the code makes sense. Google, after all, is doing the same thing in Blink. "
It may make things harder for some out-of-tree branches, so it's probably bad news for them, which is why it also suggests that, depending on their priorities, some forks might find it better to switch to Blink.
> Apple is talking about removing a feature that no one is stepping up to maintain.
Apple is also the richest technology company in the world. I would never pretend that this means that it can simply add new WebKit developers overnight. But equally, I have a hard time accepting that there will apparently be a _long-term_ developer deficit, such that the best option is to simply cull features now, rather than retain them for a couple of months while staffing is being increased.
It's possible that features culled now will be restorable from version history in the future, but that rather depends on how many changes are made in the interim. If they're significant (integrating JSC more completely, ripping out things that Google added such as threaded HTML) then it's not clear that reinstating them from old versions will be trivial.
I acknowledge that Google had an advantage here. By making the decision to fork, Google was in a position to make sure that it had the right people in the right places to maintain the codebase. Opera's involvement in Blink is probably helpful in this regard too. But come on. If Google can maintain this range of standards track features, is it really reasonable that Apple can't at least match it?