[webkit-dev] webkit editing rewrite?

[Geoffrey Garen]

> Some of us had a somewhat crazy idea to rewrite much of the editing code (e.g. document.execCommand) in JavaScript. 
> 
> Pros:

> -Ensures that the APIs we expose to the web are at least good enough for our own editing code

I don't think this necessarily follows. Not everything exposed to the internal editing implementation would necessarily be exposed to the web. If we required that everything exposed to the internal editing implementation be exposed to the web, that would substantially slow development, since every new API would need to be vetted and possibly standardized. So this is either not true or a substantial con.

> -Ensures that editing code never crashes (outside of JSC/V8 bugs)

JavaScript can still crash -- you just get an unhandled exception instead of a segfault. It's not clear to me why that would be better. I can think of reasons why it would be worse:

- Can't use standard OS tools like CrashReporter to detect problem areas.
- Harder to debug, since you need to use the Web Inspector, which:
	- doesn't have all the features of modern C++ debuggers, like watchpoints and breakpoint commands
	- creates a circular dependency
- Sometimes, instead of an unhandled exception, you'll just get incorrect behavior that's very hard to track down.

A similar set of cons pertains to performance issues.

> -Gives a clean slate for starting the editing code anew

This is an argument for a rewrite, not an argument for JavaScript. A rewrite can happen in any language.

A rewrite is not self-evidently a good thing.

> -Moves code out of WebCore

Changing the language doesn't move the code out of WebCore.

Moving code out of WebCore is not self-evidently a good thing.

> -If other browser vendors choose to expose the same APIs, then we can share the editing library and make the world better for web developers

That's a big if. Do you have any evidence that other vendors are interested? Are there vendors specifically interested in adopting WebKit's editing library, but not WebKit as a whole? That would surprise me.

> Cons:
> -Potentially slower since DOM calls are now JS-->C++
> -Potential for regressions due to holes in the layout test coverage
> -Not statically typed

I notice that you don't mention the added complexity of gluing two languages together for core DOM operations. I think that's probably the main con.

> I'm not too concerned about the perf hit. It should be no more than a constant-factor and, historically, the editing perf problems have been order-of-magnitude issues.

You're not considering the hurt that the editing JavaScript code could put on website code. If the editing memory footprint is large, the GC hit on other websites could be substantial.

JavaScript's scoping rules also have a nasty tendency to introduce accidental memory references that keep large object graphs alive, exacerbating this problem.

For security reasons, we might need to instantiate a new copy of the editing code for every webpage. That could be a substantial memory use regression.

> As for the functionality regressions, I think they're inevitable. We'd hit most of the same issues trying to refactor the existing C++ code on top of better APIs.

I agree that a rewrite inevitably introduces a large number of bugs, regardless of whether it happens in C++ or JavaScript.

However, I don't agree that refactoring inevitably introduces just as many bugs as rewriting. I would submit that the entire history of the WebKit project demonstrates the value of refactoring over rewriting.

Geoff