About XSLT-in-JS

[Kentaro Hara]

Hi

tasak@ has been working on removing XSLT code from core/ by using Blink-in-JS, but he has finished the work by making a bunch of C++-level refactoring without introducing XSLT-in-JS. Now we have no XSLT code in core/ except for core/xml/ and a very limited number of files like ProcessingInstructions. In particular, it would be worth emphasizing that we have removed all problematic XSLT code in Document and StyleEngine.

As you know, there had been a lot of discussions about a guideline and goals of Blink-in-JS [1][2]. To avoid those controversial discussions, tasak@ spent a lot of time to minimize the JS part of XSLT-in-JS. As a result, tasak@ cleaned up XSLT code at a C++ level. For example, [3] is the final CL of XSLT-in-JS where the JS part is already minimized. We considered if we should land the CL, but we concluded that it would no longer be worth landing because the CL just removes 80 lines of XSLT code from core/. After that, the genius tasak@ came up with an idea to remove the remaining 80 lines of XSLT code at a C++ level [4] and thus he finished the XSLT work without introducing XSLT-in-JS.

It was great that we've achieved our goal (remove XSLT code from core/), but it was not great that it took so long time to achieve the goal. It should have been just a two-week of engineering work if there had been no discussions about Blink-in-JS.

Now that we have a good guideline [5] about Blink-in-JS development, let's move future Blink-in-JS work forward more productively following (or improving) the guideline. Once an Intent-to-implement is approved by the community, we want to have a smoother way to support the Blink-in-JS work rather than blocking the work. That's the lesson we've learned from XSLT-in-JS :)

I'm a big fan of a productive culture of Blink ^_^;

Thanks!

[1] blink-dev@ thread: https://groups.google.com/a/chromium.org/d/topic/blink-dev/efcnimUfkRQ/discussion

[2] Slides I used at a session in BlinkOn3: https://docs.google.com/presentation/d/1-5wpqeIltM40DAZdQBhbqnzOZuFNezS4eUfx1T4YV50/edit#slide=id.g437b0e633_00

[3] The final CL for XSLT-in-JS: https://codereview.chromium.org/703193004/

[4] C++ level refactoring instead of the above XSLT-in-JS CL: https://codereview.chromium.org/730003002/

[5] blink-dev@ thread: https://groups.google.com/a/chromium.org/d/topic/blink-dev/heWdMUMMVTs/discussion

--

Kentaro Hara, Tokyo, Japan

[PhistucK]

To me, the conclusion is that Blink-in-JS was actually unnecessary for such a big feature as XSLT.

I mean, yes, it took a long time (but switching to Blink-in-JS would have taken a while as well, I assume), but you ended up with cleaner code (I think) and I believe the performance was not compromised (Blink-in-JS would have compromised the performance, as far as I understand).

(I am actually not sure Blink-in-JS is appropriate for editing as well, because of the performance issues. Editing is not going away or anything and it should be fast in order to overcome native alternatives)

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[johann...@gmail.com]

Hey,

I am a bit unsure about this discussion on text editing in JS and whether it is too slow. From the perspective of someone spending a lot of time programming a lot of editorstuff in userspace the discussion seems somewhat odd: You are aware that contenteditable currently is so broken that there is no way to make even a basic editor without interrupting all the events in userspace javascript and handling just about all of them in javascript (paragraph merging, styling a part of text, etc.), with the notable exception of input of characters that require more than one keystroke (~ + n = ñ). What part exactly are you worried about could take too long time in Blink-in_JS that is not already done in userspace JS currently?

[PhistucK]

Anything. Performance is a specific non goal of Blink-in-JS.

☆PhistucK

[Johannes Wilm]

Ok, could you be a bit more specific? 

If all of the current webbased text editors currently are running on clientside javascript (because the browser-internal implementations are largely broken), what part is it then that will be slow down if this moves into Blink-in-JS? (really an honest question, as a javascript programmer there may be issues I am not aware of). 

Right now we have to do a lot of checks and reimplement all of execCommand in javavascript, Some even draw the caret manually (as in Aloha 2.0 and Codemirror).

We were several programmers of editors talking about this at the W3C Extensible Web Summit in Berlin a few months ago talking about this. We have of course all been submitting bugs to the different browsers for years, and they have largely been ignored. The hope was that if you move this to Blink-in-JS, we can actually submit patches to fix things.

--

Johannes Wilm
http://www.johanneswilm.org
tel US: +1 (520) 399 8880
tel NO: +47 94109013
tel DE: +49 176 370 18082

[PhistucK]

No, I do not have any specific detail. That non goal is enough for me to not switch something that is not rarely used to Blink-in-JS.

I believe (if I understand correctly) that Blink-in-JS has more overhead than C++ (two context switches versus one, I think), which basically means that your JavaScript re-implementation might be faster in the end then the fixed Blink-in-JS).

Complicated editors that basically implement their own editing mechanism are out of scope here, as far as I am concerned. Basic editors that do use the various editing APIs are relevant.

Buggy implementations should be fixed, regardless of whether it is a JavaScript or a native implementation.

Your statements (editors re-implementing editing in JavaScript, bugs left open for years) make me sad (assuming they are accurate).

☆PhistucK

[johann...@gmail.com]

On Saturday, November 29, 2014 5:51:49 PM UTC+1, PhistucK wrote:

No, I do not have any specific detail. That non goal is enough for me to not switch something that is not rarely used to Blink-in-JS.

Currently, most of the things related to editing are never used, unless you go to very broken websites. Just about everything has to be overridden by javascript if you don't want the user to have a really bad experience. 

 

I believe (if I understand correctly) that Blink-in-JS has more overhead than C++ (two context switches versus one, I think), which basically means that your JavaScript re-implementation might be faster in the end then the fixed Blink-in-JS).

Ok, it would be really good if someone who does know specific details about webbased editors could say something about this. It sounds bad if builtin JS is slower than JS that has to be downloaded from a website.

 

The current state of affairs seems to be that it's unmaintainable in C++ as it's too complex and it affects too few projects for it to be an area in which any of the browser makers would want to put considerable resources into it. 

In javascript, however, you would have all of us who really need this to help you guys. 

If it is too slow in run in Blink-in-JS, it may still be preferable to entirely remove it rather than keeping the current broken implementation around.

There is actually a W3C task force set up ( w3c-editing-tf ) to create a specification for a really simple editing environment that doesn't provide anything and depends on everything being done in Javascript, simply because it appears that browsers won't be able to ever put any resources into fixing this.

Complicated editors that basically implement their own editing mechanism are out of scope here, as far as I am concerned. Basic editors that do use the various editing APIs are relevant.

Yes, could you or anyone else here name one single editor that does not have to redo most things in Javascript that is stable enough to be used in a production environment? 

Even for a simple comment form on a blog you can't do that.

TinyMCE, CKeditor, Aloha 1.0, Wikimedia editor, Gmail editor are the most basic yet still usable editors I have come across. All of them need to reimplement these functions as the C++ part has been broken for many years and no progress is being made on it.

 

More complex editors such as Codemirror, Google Docs, Aloha 2.0 don't use contenteditable for most things.

Buggy implementations should be fixed, regardless of whether it is a JavaScript or a native implementation.

Your statements (editors re-implementing editing in JavaScript, bugs left open for years) make me sad (assuming they are accurate).

Yes, in a perfect world all the browser makers would put all their resources into this. In practice though that's not what's happening, and unless there is some major paradigm shift, it won't ever happen either.

[greg...@gmail.com]

We were several programmers of editors talking about this at the W3C Extensible Web Summit in Berlin a few months ago talking about this. We have of course all been submitting bugs to the different browsers for years, and they have largely been ignored. The hope was that if you move this to Blink-in-JS, we can actually submit patches to fix things.

Have you seen this thread about contenteditable="minimal":

http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0296.html

It may be worth collaborating to create a polyfill that will eventually be implemented natively as part of the platform.

[Jochen Eisinger]

Hey,

thanks for cleaning XSLT up, and thanks for this summary

best

-jochen

[Daniel Bratell]

On Fri, 28 Nov 2014 16:15:25 +0100, PhistucK <phis...@gmail.com> wrote:

(I am actually not sure Blink-in-JS is appropriate for editing as well, because of the performance issues. Editing is not going away or anything and it should be fast in order to overcome native alternatives)

Most of the operations in document editing happens as a response to user interaction which means that you can get away with a certain amount of overhead. Considering how complicated it is to implement editing commands correctly  in C++  in face of all listeners that can interfere with every step, I wouldn't be surprised if moving to js would actually make it possible to optimize better.

Reimplementing editing in Javascript was something we discussed for Presto as well (and I'm sure others did as well because it looks like such a good choice) and I don't think performance should be the main concern.

Also, nice job by tasak on cleaning up XSLT related code!

/Daniel