PSA: Deprecate Blink-in-JS

[Kentaro Hara]

Hi

We introduced Blink-in-JS 2+ years ago to enable Blink developers to implement high-level web features on top of web-exposed JS APIs. However, there were lots of concerns about performance, backdoor JS APIs etc since then. And we have concluded that Blink-in-JS would not be a good architecture to realize the layered web platform.

Now we've started the Onion Soup project and are working on a service layer, which is a much nicer architecture to enable the layered web platform in C++. To replace Blink-in-JS with the service layer, we've decided to rewrite features currently implemented in Blink-in-JS (i.e., <marquee> and XML tree viewer) into C++.

This does not mean that we will resurrect the old <marquee> implementation that was terribly messing up the layout engine. We're just planning to translate the Blink-in-JS code to C++ using web-exposed APIs of web animations (CL by adithyas@).

If you have any question/concern, please let me know. Thanks!

--

Kentaro Hara, Tokyo, Japan

[Jochen Eisinger]

Thank you for seeing this project through, Kentaro! I think that's a reasonable plan forward.

[Harald Alvestrand]

Does this mean the end of the drive to be able to use JS to implement Web-facing features?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[PhistucK]

V8 extras were also introduced for this purpose, I think. Are those discouraged?

☆PhistucK

[Kentaro Hara]

Does this mean the end of the drive to be able to use JS to implement Web-facing features?

No, the idea of Onion Soup's service layer is to implement high-level features using web-exposed APIs in C++ (not in JS).

To implement features in JS, we need to switch contexts between user script's context and Blink-in-JS's context. This is heavy and one of the reasons we couldn't use Blink-in-JS widely :/

[PhistucK]

So you mean "yes", right? :) It is the end of the drive.

☆PhistucK

[Jochen Eisinger]

V8 extras are still a thing. Domenic wanted to come up with a JS-only bindings that we could then use to create a code generator. I don't think we should add hand-written bindings, neither C++ nor JS.

On Tue, Dec 6, 2016 at 9:31 AM PhistucK <phis...@gmail.com> wrote:

So you mean "yes", right? :) It is the end of the drive.

☆PhistucK

On Tue, Dec 6, 2016 at 10:29 AM, Kentaro Hara <har...@chromium.org> wrote:

Does this mean the end of the drive to be able to use JS to implement Web-facing features?

No, the idea of Onion Soup's service layer is to implement high-level features using web-exposed APIs in C++ (not in JS).

To implement features in JS, we need to switch contexts between user script's context and Blink-in-JS's context. This is heavy and one of the reasons we couldn't use Blink-in-JS widely :/

On Tue, Dec 6, 2016 at 5:26 PM, Harald Alvestrand <h...@google.com> wrote:

Does this mean the end of the drive to be able to use JS to implement Web-facing features?

On Tue, Dec 6, 2016 at 9:02 AM, Jochen Eisinger <joc...@chromium.org> wrote:

Thank you for seeing this project through, Kentaro! I think that's a reasonable plan forward.

On Tue, Dec 6, 2016 at 8:58 AM Kentaro Hara <har...@chromium.org> wrote:

Hi

We introduced Blink-in-JS 2+ years ago to enable Blink developers to implement high-level web features on top of web-exposed JS APIs. However, there were lots of concerns about performance, backdoor JS APIs etc since then. And we have concluded that Blink-in-JS would not be a good architecture to realize the layered web platform.

Now we've started the Onion Soup project and are working on a service layer, which is a much nicer architecture to enable the layered web platform in C++. To replace Blink-in-JS with the service layer, we've decided to rewrite features currently implemented in Blink-in-JS (i.e., <marquee> and XML tree viewer) into C++.

This does not mean that we will resurrect the old <marquee> implementation that was terribly messing up the layout engine. We're just planning to translate the Blink-in-JS code to C++ using web-exposed APIs of web animations (CL by adithyas@).

If you have any question/concern, please let me know. Thanks!

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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

[Kentaro Hara]

On Tue, Dec 6, 2016 at 5:30 PM, PhistucK <phis...@gmail.com> wrote:

So you mean "yes", right? :) It is the end of the drive.

Sorry, yes, I meant yes :)

[Kentaro Hara]

Update:

adithyas@ has moved <marquee> and XMLTreeViewer out of Blink-in-JS and removed all the infrastructure of Blink-in-JS from the code base.

[Chen Zhixiang]

I'm somewhat disappeared about hearing this.

IMO, Blink-In-JS is just like Mozilla Firefox's partial JS-like code, it may be hurting performance, but code in js may be more steady then code in C++?

Also, if JS hurts perf, maybe we can use a restricted subset, like v8's %callRuntime syntax, instead of a general ES6/7 JS syntax.

[PhistucK]

On Fri, Dec 16, 2016 at 3:28 PM, Chen Zhixiang <cten...@gmail.com> wrote:

but code in js may be more steady then code in C++?

I am not following, what is more "steady" (stable, you mean?) about JavaScript?​

☆PhistucK