[webkit-dev] webkit editing rewrite?
ggaren at apple.com
Wed Aug 4 15:07:19 PDT 2010
> we won't get better APIs if we don't try and the current
> APIs suck hard.
Better APIs don't require a rewrite in a new language.
As I just said, a rewrite in a new language seems to be a distraction from better APIs.
>>> -Ensures that editing code never crashes (outside of JSC/V8 bugs)
> These crashes are much less likely to be exploitable security issues.
> That's one (major) plus.
>> - 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.
> I'm not sure that's clearly true.
Could you elaborate?
Are you unconcerned about all the debugging tools we would lose?
> For those systems,
> having better plumbing and being able to operate on more
> deterministic, low-level APIs for editing would be a serious plus.
>> 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.
> The bindings are already opaque. How is this really worse?
More glue is more con.
Also, we've never used glue to implement core DOM operations before. We've only used JS to wrap the DOM before.
>>> 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.
More information about the webkit-dev