I have a curious question which probably won't be possible in any immediate future. Is it possible to re-implement a layout/rendering/render tree system within native JavaScript with DOM bindings (also written in javascript)?
I'm curious as this would create a few interesting scenarios: 1. Developers could program their own CSS, or possibly be able to enhance rendering/layout to provide for new features despite if its not yet spec'd by the W3C/WHATWG. 2. Optimizations within Spidermonkey and other JIT's could reach larger portions of code to increase optimizations and performance. 2. The large javascript community would have less of a barrier to contribute code. I'm not implying that it would all be quality code, but some of the major hurdles to contributing to Mozilla or any large project is build systems. If there were a more natural way for people to be able to override various parts of layout/rendering it also creates a channel for a larger set of developers to take a look at optimizing code and increasing performance. Essentially this is crowd sourcing performance enhancements and rendering fixes. 3. Creating a standard mechanism (in C++) for accessing resources that went through a security context check could also allow most (if not all) of the standard javascript interfaces to be a written in just javascript (minus the actual resource accessor). From what I can tell this would require essentially a JS stack trace to the source for each call to this resource handler. Is this even possible in current Javascript engines? (I'd think it would be since Debugging kicks out a stack trace, however for security this would have to guarantee it would return accurate sources of the originating JS code). 4. Hypothetically, if layout/rendering/dom were all completely implemented in JS, couldn't wrappers be produced to run the layout/rendering on any context (no matter how slow)? E.g., if Mozilla produced a very nimble strong implementation of this, hypothetically it could be implemented on Chromium or IE using a Canvas object as its rendering context? I would never suggest doing this as it would most likely be intensely slow, but if Mozilla had a complete JS implementation of a layout/renderer if a developer chose to use Mozilla as their dev platform they could roll out the JS render/layout to other browsers if they needed maximum compatibility (hypothetically). 5. Could performance be improved by writing it all within ASM.js? This would give a strong use case for ASM.js in addition to promoting more adoption of it. I really believe in engaging the larger untapped communities to create something along these lines. There are too many javascript developers spending the majority of their time reinventing MVC patterns in JS when I feel they'd be much more eager to work on something that has a more concreate result such as this (even if they only get as far as writing layout unit tests or performance tests). Naturally most of this is speculative, head in the clouds, mother and apple pie type talk but i'm curious if anyone has any thoughts on it. Danke, Trevor Linton _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
