[webkit-dev] webkit editing rewrite?

[Geoffrey Garen]

> 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)
>> 
>> 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:
> 
> These crashes are much less likely to be exploitable security issues.
> That's one (major) plus.

Have security issues in editing code been a big attack vector? Bigger than other vectors that we're not considering rewriting in JavaScript?

>> - 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?

How would SpinTracer integrate with JavaScript editing? How about Shark?

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.

Once again, this is a pro to better editing abstractions, not a pro to a rewrite, nor a pro to JavaScript.

>> 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.
>> 
>> 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.
> 
> Luckily Ojan et. al. happen to be very good at JavaScript ;-)

Are they correspondingly bad at C++? If so, that might be an argument for using JavaScript instead of C++, but a better solution would probably be to find engineers who are good at C++.

Geoff