> 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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
