Thanks for the responses, very interesting. On Wed, Mar 13, 2013 at 3:01 AM, Jakob Kummerow <[email protected]>wrote:
> Welcome to JavaScript! Have you considered using a language with a sane > specification? > Well, the other option is to try to write everything through the v8 API, which would be quite a bit of effort - we have 5000 non-whitespace/comment lines of JS, and ideally we don't want to rewrite it all. If we can come up with an easier-to-write DSL around the v8 API then that might be more viable, but I haven't put a lot of thought into that. A detail that doesn't really concern v8: for things like document.createElement we need DOM APIs which the separate-context solution won't actually work easily without changes to webkit afaik. It also makes the write-in-C++ solution harder for similar reasons, we'd need to make sure every DOM API we ever call is available from chromium. > Have you tried benchmarking it? If you can't measure it, it's not > important. If you can, you'll have data to help decide whether the > difference is a problem in your use case or not. > > Not really, we don't have any meaningful perf testing for extensions. I could try profiling I guess. A data point is that yesterday I found a context we were creating unnecessarily and fixed it, and it doesn't seem to have made any difference to page load speed (which is on the order of 500ms). This is promising. > Alternatively, apparently v8 has solved this problem internally by >> guaranteeing that it's running the builtin libraries - is/can this be >> exposed? >> > > Sorry, no. > You can lobby for an official way to retrieve the original unpatched > implementations to be included in ECMAScript 7. The general problem with > introducing sanity, however, is that you can't break existing code, which > basically means that all the good stuff has to be opt-in, which in turn > means that the original problem doesn't just go away, instead you'll still > have to support it until it slowly dies out, if ever. > > Getting into the world of ESFoo isn't really where I want to go with this. Strawman: if there were a 'use strict' for builtins, like 'use builtins', where for that file you get unpolluted APIs, that might solve our problems. However, I can see this breaking e.g. if I pass an array from one file to another, should it be 'instanceof Array'? I guess what I was realistically asking about is some support at the v8 API level. > Crazy idea: how about a rule for the Chrome web store that forbids > monkey-patching builtins? :-) > Not really feasible, monkey patching is an idiom that JS developers would get very upset about being taken away from them. Plus lots of libraries do it. We had a hard enough problem (and in fact failed) forbidding eval. And likewise freezing globals etc. Philosophically it's just sad if we forbid existing features of a platform because it's too hard to implement. Lastly - I am not really sure about how harmony proxies work, but it sounds like we're told after they change not before they change? If not, that would certainly be a neater solution than what we're doing for JSON (saving function references on load), but I can see it getting messy with prototypes. Cheers, Ben. -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
