> I hope to publish another blog post describing [speculative parsing] thoroughly, along with details on the performance improvements this feature would bring.
Isn't there any preliminary results on the perf improvements this would bring?
I understand that the % of time when the speculative parsing succeeds (instead of having to roll back to a sequential parsing) can't be know easily, since it'll be based on the testing of a large number of real-world web pages,
but I'd love to see just 2 simple examples:
* One full of `document.write`, so we can have an idea of the time lost in case of failed speculation
* One 'embarrassingly parallel' dom tree where the speculation should pay off the most.
That would give us a good idea of worst case / best case results.
It was never debugged enough to be turned on on desktop, but I think it was considered useful enough to ship on mobile in the days when mobile performance was significantly worse than it is today. In particular, on a network where request latency is high having to pause treebuilding for scripts to download can significantly increase the time until it's possible to paint anything at all on the screen.
That's not to say Servo shouldn't try it of course! Part of having a healthy multi-browser ecosystem is each browser trying lots of ideas and coming up with new solutions to problems that were encountered in other implementations.
 http://trac.webkit.org/changeset/162260/webkit (the number cited here is a joke :P)
 https://groups.google.com/a/chromium.org/forum/#!topic/loadi... (see also the design doc linked from the email)
WebKit/Blink put fewer parts of the HTML parser off the main thread, so negative results should not be taken to apply to more comprehensive approaches.
Servo is by far the technology I'm most excited about as a frontend developer. It will be a complete game changer for web performance once all the pieces are in place.
Also, after reading that old HN comment, do you think adding something like RenderEvent with values like client size already defined would make sense?
Servo feels like a great platform for experiments like this which, if successful, could move into Firefox.
The implementation of browsers is already difficult enough! It's great to see the lengths Servo is going to to be compatible, but on this one I say warn developers and deprecate this feature that no-one in 2017 should ever use.
Maybe there are other APIs that should be deprecated first but I cannot think of any.
Finally I am pretty certain you could write a document.write polyfill, I’ll have a crack at some point I think.
I definitely don't agree with this method, but there you go. Apparently ASP.NET 4.5 will even insert this pattern automatically.
Clearly. I would go further and say that we should move all parsing and rendering into the browser's "user space". That way, browser vendors can concentrate on a simple set of primitives, and improve security, robustness, and compatibility, while users get more freedom and flexibility.
though I don't know what has became of that project
There are no silver bullets for performance, only lots of lead bullets. I'm confident that parallelism via GPU and multicore is a large architectural win. But lots of making the Web fast involves a ton of little special case optimizations that just need to be implemented. That's how Stylo went: promising benchmarks and a mediocre user experience at the research stage turned into great benchmarks and a great user experience with production engineering work.