Inefficient third party JS library integration, e.g. plotly

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Inefficient third party JS library integration, e.g. plotly

andreas.weise@gmail.com
We are using plotly for charts quite often (plotly python in conjunction with pyspark) and it reavels a weakness regarding to third party JS library integration.

Unfortunately current plotly integration is not very efficient in terms of library integration, which leads to huge notebooks. This is because notebooks that contain plotly will have to output the full js code of plotly. (~3MB). When a Notebook contains several of that integration, the notebook becomes very slow. I think this also applies to other js libraries.

E.g. for plotly you can render charts in zeppelin the following way with pyspark (the first print is only for demoing the actual html output in cleartext):
---------------------------------------------
%pyspark
from plotly import graph_objs as go
from plotly.offline import plot

out = plot([go.Scatter(x=[1, 2, 3], y=[3, 1, 6])],include_plotlyjs=True, output_type='div')

print(out)
print('%html', out)
---------------------------------------------

An alternative would be, to load plotly.js (or any other third party library) from a CDN, e.g.
 <script src="https://cdn.plot.ly/plotly-latest.min.js"></script> (and settings include_plotlyjs in the example above to false, which would lead to the bare minimum of code for that specific chart).
But this needs to be added to the html->head, otherwise any dependent code using that library might run into 'Uncaught ReferenceError: ... is not defined' issues, due to timing.

I found that setup guide for repacking the zeppelin-web archive, to include a custom library in the index.html, but IMHO that seems to be a workaround:
https://github.com/beljun/zeppelin-plotly

Therefore I would suggest to add some zeppelin server wide configuration to allow zeppelin administrators to include additional <script> directives in the head section.

Any other recommendation / ideas to solve the timing issue?
Reply | Threaded
Open this post in threaded view
|

Re: Inefficient third party JS library integration, e.g. plotly

Jeff Zhang

Do you know how jupyter handle that ? And bokeh would load js from CDN so it doesn't have the issue you mentioned, maybe plotly could use similar approach.




[hidden email] <[hidden email]>于2018年8月14日周二 下午2:34写道:
We are using plotly for charts quite often (plotly python in conjunction with pyspark) and it reavels a weakness regarding to third party JS library integration.

Unfortunately current plotly integration is not very efficient in terms of library integration, which leads to huge notebooks. This is because notebooks that contain plotly will have to output the full js code of plotly. (~3MB). When a Notebook contains several of that integration, the notebook becomes very slow. I think this also applies to other js libraries.

E.g. for plotly you can render charts in zeppelin the following way with pyspark (the first print is only for demoing the actual html output in cleartext):
---------------------------------------------
%pyspark
from plotly import graph_objs as go
from plotly.offline import plot

out = plot([go.Scatter(x=[1, 2, 3], y=[3, 1, 6])],include_plotlyjs=True, output_type='div')

print(out)
print('%html', out)
---------------------------------------------

An alternative would be, to load plotly.js (or any other third party library) from a CDN, e.g.
 <script src="https://cdn.plot.ly/plotly-latest.min.js"></script> (and settings include_plotlyjs in the example above to false, which would lead to the bare minimum of code for that specific chart).
But this needs to be added to the html->head, otherwise any dependent code using that library might run into 'Uncaught ReferenceError: ... is not defined' issues, due to timing.

I found that setup guide for repacking the zeppelin-web archive, to include a custom library in the index.html, but IMHO that seems to be a workaround:
https://github.com/beljun/zeppelin-plotly

Therefore I would suggest to add some zeppelin server wide configuration to allow zeppelin administrators to include additional <script> directives in the head section.

Any other recommendation / ideas to solve the timing issue?
Reply | Threaded
Open this post in threaded view
|

Inefficient third party JS library integration, e.g. plotly

Partridge, Lucas (GE Aviation)

I’m pretty rusty on this as it’s several years since I tried it but I remember having a similar problem when trying to use Google Maps inside Zeppelin.  Unfortunately I can’t find the code I used but from memory, my solution was to try invoking the library, and if, the library object didn’t exist, load it. In the onload() callback (not sure I’ve remembered the method’s name right) I would then draw my map. I certainly didn’t embed the library in the notebook itself.

 

From: Jeff Zhang <[hidden email]>
Sent: 14 August 2018 08:11
To: [hidden email]
Subject: EXT: Re: Inefficient third party JS library integration, e.g. plotly

 

 

Do you know how jupyter handle that ? And bokeh would load js from CDN so it doesn't have the issue you mentioned, maybe plotly could use similar approach.

 

 

 

 

[hidden email] <[hidden email]>2018814日周二 下午2:34写道:

We are using plotly for charts quite often (plotly python in conjunction with pyspark) and it reavels a weakness regarding to third party JS library integration.

Unfortunately current plotly integration is not very efficient in terms of library integration, which leads to huge notebooks. This is because notebooks that contain plotly will have to output the full js code of plotly. (~3MB). When a Notebook contains several of that integration, the notebook becomes very slow. I think this also applies to other js libraries.

E.g. for plotly you can render charts in zeppelin the following way with pyspark (the first print is only for demoing the actual html output in cleartext):
---------------------------------------------
%pyspark
from plotly import graph_objs as go
from plotly.offline import plot

out = plot([go.Scatter(x=[1, 2, 3], y=[3, 1, 6])],include_plotlyjs=True, output_type='div')

print(out)
print('%html', out)
---------------------------------------------

An alternative would be, to load plotly.js (or any other third party library) from a CDN, e.g.
 <script src="https://cdn.plot.ly/plotly-latest.min.js"></script> (and settings include_plotlyjs in the example above to false, which would lead to the bare minimum of code for that specific chart).
But this needs to be added to the html->head, otherwise any dependent code using that library might run into 'Uncaught ReferenceError: ... is not defined' issues, due to timing.

I found that setup guide for repacking the zeppelin-web archive, to include a custom library in the index.html, but IMHO that seems to be a workaround:
https://github.com/beljun/zeppelin-plotly

Therefore I would suggest to add some zeppelin server wide configuration to allow zeppelin administrators to include additional <script> directives in the head section.

Any other recommendation / ideas to solve the timing issue?

Reply | Threaded
Open this post in threaded view
|

Re: Inefficient third party JS library integration, e.g. plotly

Jeff Zhang

Here's the code of how bokeh loading js asynchronously, hope it is useful for you.



Partridge, Lucas (GE Aviation) <[hidden email]>于2018年8月14日周二 下午4:21写道:

I’m pretty rusty on this as it’s several years since I tried it but I remember having a similar problem when trying to use Google Maps inside Zeppelin.  Unfortunately I can’t find the code I used but from memory, my solution was to try invoking the library, and if, the library object didn’t exist, load it. In the onload() callback (not sure I’ve remembered the method’s name right) I would then draw my map. I certainly didn’t embed the library in the notebook itself.

 

From: Jeff Zhang <[hidden email]>
Sent: 14 August 2018 08:11
To: [hidden email]
Subject: EXT: Re: Inefficient third party JS library integration, e.g. plotly

 

 

Do you know how jupyter handle that ? And bokeh would load js from CDN so it doesn't have the issue you mentioned, maybe plotly could use similar approach.

 

 

 

 

[hidden email] <[hidden email]>2018814日周二 下午2:34写道:

We are using plotly for charts quite often (plotly python in conjunction with pyspark) and it reavels a weakness regarding to third party JS library integration.

Unfortunately current plotly integration is not very efficient in terms of library integration, which leads to huge notebooks. This is because notebooks that contain plotly will have to output the full js code of plotly. (~3MB). When a Notebook contains several of that integration, the notebook becomes very slow. I think this also applies to other js libraries.

E.g. for plotly you can render charts in zeppelin the following way with pyspark (the first print is only for demoing the actual html output in cleartext):
---------------------------------------------
%pyspark
from plotly import graph_objs as go
from plotly.offline import plot

out = plot([go.Scatter(x=[1, 2, 3], y=[3, 1, 6])],include_plotlyjs=True, output_type='div')

print(out)
print('%html', out)
---------------------------------------------

An alternative would be, to load plotly.js (or any other third party library) from a CDN, e.g.
 <script src="https://cdn.plot.ly/plotly-latest.min.js"></script> (and settings include_plotlyjs in the example above to false, which would lead to the bare minimum of code for that specific chart).
But this needs to be added to the html->head, otherwise any dependent code using that library might run into 'Uncaught ReferenceError: ... is not defined' issues, due to timing.

I found that setup guide for repacking the zeppelin-web archive, to include a custom library in the index.html, but IMHO that seems to be a workaround:
https://github.com/beljun/zeppelin-plotly

Therefore I would suggest to add some zeppelin server wide configuration to allow zeppelin administrators to include additional <script> directives in the head section.

Any other recommendation / ideas to solve the timing issue?

Reply | Threaded
Open this post in threaded view
|

Re: Inefficient third party JS library integration, e.g. plotly

andreas.weise@gmail.com


Thanks for your answers, but as long as custom JS code resides in html->body (which is the case for any code loaded through notebooks) there is no guarenteed loading sequence when using the default HTML outputs of libs like plotly, which assume that all of the library code is already loaded. Of course you can add more custom complex JS code (promise etc.) to sort these issues per notebook, but that is not very enduser friendly.

bokeh loads all of its JS resources in the html->head, which is why things work there. And this is different to zeppelin, where everything is loaded in the body.
https://github.com/bokeh/bokeh/blob/master/bokeh/core/_templates/file.html

The point here is, that in zeppelin there is currently no feasible way to add this kind of central customization to the html->head section, neither for loading Libs from CDN nor loading JS code asynchronously (like bokeh). (without rebuilding zeppelin-web.war)

Therefore I'm again suggesting a new configuration property to allow zeppelin administrators to include any kind of special JS code (most likely referenced via an URL) to the html->head section. I'm not sure yet, if thats possible at all, because configuration is some information from the server, that needs to be loaded very early.

Or can this be achieved via helium (or an extension to helium).

Or any other idea how to solve this centrally and not on a per notebook base?

Regards
Andreas

On 2018/08/14 08:27:16, Jeff Zhang <[hidden email]> wrote:

> Here's the code of how bokeh loading js asynchronously, hope it is useful
> for you.
>
> https://github.com/bokeh/bokeh/blob/master/bokeh/core/_templates/autoload_js.js
>
>
> Partridge, Lucas (GE Aviation) <[hidden email]>于2018年8月14日周二
> 下午4:21写道:
>
> > I’m pretty rusty on this as it’s several years since I tried it but I
> > remember having a similar problem when trying to use Google Maps inside
> > Zeppelin.  Unfortunately I can’t find the code I used but from memory, my
> > solution was to try invoking the library, and if, the library object didn’t
> > exist, load it. In the onload() callback (not sure I’ve remembered the
> > method’s name right) I would then draw my map. I certainly didn’t embed the
> > library in the notebook itself.
> >
> >
> >
> > *From:* Jeff Zhang <[hidden email]>
> > *Sent:* 14 August 2018 08:11
> > *To:* [hidden email]
> > *Subject:* EXT: Re: Inefficient third party JS library integration, e.g.
> > plotly
> >
> >
> >
> >
> >
> > Do you know how jupyter handle that ? And bokeh would load js from CDN so
> > it doesn't have the issue you mentioned, maybe plotly could use similar
> > approach.
> >
> >
> >
> > https://bokeh.pydata.org/en/latest/
> >
> >
> >
> >
> >
> >
> >
> > [hidden email] <[hidden email]>于2018年8月14日周二 下午2:34写道:
> >
> > We are using plotly for charts quite often (plotly python in conjunction
> > with pyspark) and it reavels a weakness regarding to third party JS library
> > integration.
> >
> > Unfortunately current plotly integration is not very efficient in terms of
> > library integration, which leads to huge notebooks. This is because
> > notebooks that contain plotly will have to output the full js code of
> > plotly. (~3MB). When a Notebook contains several of that integration, the
> > notebook becomes very slow. I think this also applies to other js libraries.
> >
> > E.g. for plotly you can render charts in zeppelin the following way with
> > pyspark (the first print is only for demoing the actual html output in
> > cleartext):
> > ---------------------------------------------
> > %pyspark
> > from plotly import graph_objs as go
> > from plotly.offline import plot
> >
> > out = plot([go.Scatter(x=[1, 2, 3], y=[3, 1, 6])],include_plotlyjs=True,
> > output_type='div')
> >
> > print(out)
> > print('%html', out)
> > ---------------------------------------------
> >
> > An alternative would be, to load plotly.js (or any other third party
> > library) from a CDN, e.g.
> >  <script src="https://cdn.plot.ly/plotly-latest.min.js"></script> (and
> > settings include_plotlyjs in the example above to false, which would lead
> > to the bare minimum of code for that specific chart).
> > But this needs to be added to the html->head, otherwise any dependent code
> > using that library might run into 'Uncaught ReferenceError: ... is not
> > defined' issues, due to timing.
> >
> > I found that setup guide for repacking the zeppelin-web archive, to
> > include a custom library in the index.html, but IMHO that seems to be a
> > workaround:
> > https://github.com/beljun/zeppelin-plotly
> >
> > Therefore I would suggest to add some zeppelin server wide configuration
> > to allow zeppelin administrators to include additional <script> directives
> > in the head section.
> >
> > Any other recommendation / ideas to solve the timing issue?
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Inefficient third party JS library integration, e.g. plotly

andreas.weise@gmail.com
Bumping this one up again (after 2 years of silence), as its still not possible to efficiently integrate plotly for multiple paragraphs in zeppelin.

WDYT about my suggestion. I can prepare a PR for that...

> Therefore I'm again suggesting a new configuration property to allow zeppelin administrators to include any kind of special JS code (most likely referenced via an URL) to the html->head section. I'm not sure yet, if thats possible at all, because configuration is some information from the server, that needs to be loaded very early.

Best Regards
Andreas

On 2018/08/15 06:26:48, [hidden email] <[hidden email]> wrote:

>
>
> Thanks for your answers, but as long as custom JS code resides in html->body (which is the case for any code loaded through notebooks) there is no guarenteed loading sequence when using the default HTML outputs of libs like plotly, which assume that all of the library code is already loaded. Of course you can add more custom complex JS code (promise etc.) to sort these issues per notebook, but that is not very enduser friendly.
>
> bokeh loads all of its JS resources in the html->head, which is why things work there. And this is different to zeppelin, where everything is loaded in the body.
> https://github.com/bokeh/bokeh/blob/master/bokeh/core/_templates/file.html
>
> The point here is, that in zeppelin there is currently no feasible way to add this kind of central customization to the html->head section, neither for loading Libs from CDN nor loading JS code asynchronously (like bokeh). (without rebuilding zeppelin-web.war)
>
> Therefore I'm again suggesting a new configuration property to allow zeppelin administrators to include any kind of special JS code (most likely referenced via an URL) to the html->head section. I'm not sure yet, if thats possible at all, because configuration is some information from the server, that needs to be loaded very early.
>
> Or can this be achieved via helium (or an extension to helium).
>
> Or any other idea how to solve this centrally and not on a per notebook base?
>
> Regards
> Andreas
>
> On 2018/08/14 08:27:16, Jeff Zhang <[hidden email]> wrote:
> > Here's the code of how bokeh loading js asynchronously, hope it is useful
> > for you.
> >
> > https://github.com/bokeh/bokeh/blob/master/bokeh/core/_templates/autoload_js.js
> >
> >
> > Partridge, Lucas (GE Aviation) <[hidden email]>于2018年8月14日周二
> > 下午4:21写道:
> >
> > > I’m pretty rusty on this as it’s several years since I tried it but I
> > > remember having a similar problem when trying to use Google Maps inside
> > > Zeppelin.  Unfortunately I can’t find the code I used but from memory, my
> > > solution was to try invoking the library, and if, the library object didn’t
> > > exist, load it. In the onload() callback (not sure I’ve remembered the
> > > method’s name right) I would then draw my map. I certainly didn’t embed the
> > > library in the notebook itself.
> > >
> > >
> > >
> > > *From:* Jeff Zhang <[hidden email]>
> > > *Sent:* 14 August 2018 08:11
> > > *To:* [hidden email]
> > > *Subject:* EXT: Re: Inefficient third party JS library integration, e.g.
> > > plotly
> > >
> > >
> > >
> > >
> > >
> > > Do you know how jupyter handle that ? And bokeh would load js from CDN so
> > > it doesn't have the issue you mentioned, maybe plotly could use similar
> > > approach.
> > >
> > >
> > >
> > > https://bokeh.pydata.org/en/latest/
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [hidden email] <[hidden email]>于2018年8月14日周二 下午2:34写道:
> > >
> > > We are using plotly for charts quite often (plotly python in conjunction
> > > with pyspark) and it reavels a weakness regarding to third party JS library
> > > integration.
> > >
> > > Unfortunately current plotly integration is not very efficient in terms of
> > > library integration, which leads to huge notebooks. This is because
> > > notebooks that contain plotly will have to output the full js code of
> > > plotly. (~3MB). When a Notebook contains several of that integration, the
> > > notebook becomes very slow. I think this also applies to other js libraries.
> > >
> > > E.g. for plotly you can render charts in zeppelin the following way with
> > > pyspark (the first print is only for demoing the actual html output in
> > > cleartext):
> > > ---------------------------------------------
> > > %pyspark
> > > from plotly import graph_objs as go
> > > from plotly.offline import plot
> > >
> > > out = plot([go.Scatter(x=[1, 2, 3], y=[3, 1, 6])],include_plotlyjs=True,
> > > output_type='div')
> > >
> > > print(out)
> > > print('%html', out)
> > > ---------------------------------------------
> > >
> > > An alternative would be, to load plotly.js (or any other third party
> > > library) from a CDN, e.g.
> > >  <script src="https://cdn.plot.ly/plotly-latest.min.js"></script> (and
> > > settings include_plotlyjs in the example above to false, which would lead
> > > to the bare minimum of code for that specific chart).
> > > But this needs to be added to the html->head, otherwise any dependent code
> > > using that library might run into 'Uncaught ReferenceError: ... is not
> > > defined' issues, due to timing.
> > >
> > > I found that setup guide for repacking the zeppelin-web archive, to
> > > include a custom library in the index.html, but IMHO that seems to be a
> > > workaround:
> > > https://github.com/beljun/zeppelin-plotly
> > >
> > > Therefore I would suggest to add some zeppelin server wide configuration
> > > to allow zeppelin administrators to include additional <script> directives
> > > in the head section.
> > >
> > > Any other recommendation / ideas to solve the timing issue?
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Inefficient third party JS library integration, e.g. plotly

Jeff Zhang
Adding custom js via configuration make sense to me.

Andreas Weise <[hidden email]> 于2020年8月26日周三 下午8:37写道:
Bumping this one up again (after 2 years of silence), as its still not possible to efficiently integrate plotly for multiple paragraphs in zeppelin.

WDYT about my suggestion. I can prepare a PR for that...

> Therefore I'm again suggesting a new configuration property to allow zeppelin administrators to include any kind of special JS code (most likely referenced via an URL) to the html->head section. I'm not sure yet, if thats possible at all, because configuration is some information from the server, that needs to be loaded very early.

Best Regards
Andreas

On 2018/08/15 06:26:48, [hidden email] <[hidden email]> wrote:
>
>
> Thanks for your answers, but as long as custom JS code resides in html->body (which is the case for any code loaded through notebooks) there is no guarenteed loading sequence when using the default HTML outputs of libs like plotly, which assume that all of the library code is already loaded. Of course you can add more custom complex JS code (promise etc.) to sort these issues per notebook, but that is not very enduser friendly.
>
> bokeh loads all of its JS resources in the html->head, which is why things work there. And this is different to zeppelin, where everything is loaded in the body.
> https://github.com/bokeh/bokeh/blob/master/bokeh/core/_templates/file.html
>
> The point here is, that in zeppelin there is currently no feasible way to add this kind of central customization to the html->head section, neither for loading Libs from CDN nor loading JS code asynchronously (like bokeh). (without rebuilding zeppelin-web.war)
>
> Therefore I'm again suggesting a new configuration property to allow zeppelin administrators to include any kind of special JS code (most likely referenced via an URL) to the html->head section. I'm not sure yet, if thats possible at all, because configuration is some information from the server, that needs to be loaded very early.
>
> Or can this be achieved via helium (or an extension to helium).
>
> Or any other idea how to solve this centrally and not on a per notebook base?
>
> Regards
> Andreas
>
> On 2018/08/14 08:27:16, Jeff Zhang <[hidden email]> wrote:
> > Here's the code of how bokeh loading js asynchronously, hope it is useful
> > for you.
> >
> > https://github.com/bokeh/bokeh/blob/master/bokeh/core/_templates/autoload_js.js
> >
> >
> > Partridge, Lucas (GE Aviation) <[hidden email]>于2018年8月14日周二
> > 下午4:21写道:
> >
> > > I’m pretty rusty on this as it’s several years since I tried it but I
> > > remember having a similar problem when trying to use Google Maps inside
> > > Zeppelin.  Unfortunately I can’t find the code I used but from memory, my
> > > solution was to try invoking the library, and if, the library object didn’t
> > > exist, load it. In the onload() callback (not sure I’ve remembered the
> > > method’s name right) I would then draw my map. I certainly didn’t embed the
> > > library in the notebook itself.
> > >
> > >
> > >
> > > *From:* Jeff Zhang <[hidden email]>
> > > *Sent:* 14 August 2018 08:11
> > > *To:* [hidden email]
> > > *Subject:* EXT: Re: Inefficient third party JS library integration, e.g.
> > > plotly
> > >
> > >
> > >
> > >
> > >
> > > Do you know how jupyter handle that ? And bokeh would load js from CDN so
> > > it doesn't have the issue you mentioned, maybe plotly could use similar
> > > approach.
> > >
> > >
> > >
> > > https://bokeh.pydata.org/en/latest/
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [hidden email] <[hidden email]>于2018年8月14日周二 下午2:34写道:
> > >
> > > We are using plotly for charts quite often (plotly python in conjunction
> > > with pyspark) and it reavels a weakness regarding to third party JS library
> > > integration.
> > >
> > > Unfortunately current plotly integration is not very efficient in terms of
> > > library integration, which leads to huge notebooks. This is because
> > > notebooks that contain plotly will have to output the full js code of
> > > plotly. (~3MB). When a Notebook contains several of that integration, the
> > > notebook becomes very slow. I think this also applies to other js libraries.
> > >
> > > E.g. for plotly you can render charts in zeppelin the following way with
> > > pyspark (the first print is only for demoing the actual html output in
> > > cleartext):
> > > ---------------------------------------------
> > > %pyspark
> > > from plotly import graph_objs as go
> > > from plotly.offline import plot
> > >
> > > out = plot([go.Scatter(x=[1, 2, 3], y=[3, 1, 6])],include_plotlyjs=True,
> > > output_type='div')
> > >
> > > print(out)
> > > print('%html', out)
> > > ---------------------------------------------
> > >
> > > An alternative would be, to load plotly.js (or any other third party
> > > library) from a CDN, e.g.
> > >  <script src="https://cdn.plot.ly/plotly-latest.min.js"></script> (and
> > > settings include_plotlyjs in the example above to false, which would lead
> > > to the bare minimum of code for that specific chart).
> > > But this needs to be added to the html->head, otherwise any dependent code
> > > using that library might run into 'Uncaught ReferenceError: ... is not
> > > defined' issues, due to timing.
> > >
> > > I found that setup guide for repacking the zeppelin-web archive, to
> > > include a custom library in the index.html, but IMHO that seems to be a
> > > workaround:
> > > https://github.com/beljun/zeppelin-plotly
> > >
> > > Therefore I would suggest to add some zeppelin server wide configuration
> > > to allow zeppelin administrators to include additional <script> directives
> > > in the head section.
> > >
> > > Any other recommendation / ideas to solve the timing issue?
> > >
> > >
> >
>


--
Best Regards

Jeff Zhang
Reply | Threaded
Open this post in threaded view
|

Re: Inefficient third party JS library integration, e.g. plotly

andreas.weise@gmail.com
Created https://issues.apache.org/jira/browse/ZEPPELIN-5019

Expect a PR soon for that.

On 2020/08/26 15:48:23, Jeff Zhang <[hidden email]> wrote:

> Adding custom js via configuration make sense to me.
>
> Andreas Weise <[hidden email]> 于2020年8月26日周三 下午8:37写道:
>
> > Bumping this one up again (after 2 years of silence), as its still not
> > possible to efficiently integrate plotly for multiple paragraphs in
> > zeppelin.
> >
> > WDYT about my suggestion. I can prepare a PR for that...
> >
> > > Therefore I'm again suggesting a new configuration property to allow
> > zeppelin administrators to include any kind of special JS code (most likely
> > referenced via an URL) to the html->head section. I'm not sure yet, if
> > thats possible at all, because configuration is some information from the
> > server, that needs to be loaded very early.
> >
> > Best Regards
> > Andreas
> >
> > On 2018/08/15 06:26:48, [hidden email] <[hidden email]>
> > wrote:
> > >
> > >
> > > Thanks for your answers, but as long as custom JS code resides in
> > html->body (which is the case for any code loaded through notebooks) there
> > is no guarenteed loading sequence when using the default HTML outputs of
> > libs like plotly, which assume that all of the library code is already
> > loaded. Of course you can add more custom complex JS code (promise etc.) to
> > sort these issues per notebook, but that is not very enduser friendly.
> > >
> > > bokeh loads all of its JS resources in the html->head, which is why
> > things work there. And this is different to zeppelin, where everything is
> > loaded in the body.
> > >
> > https://github.com/bokeh/bokeh/blob/master/bokeh/core/_templates/file.html
> > >
> > > The point here is, that in zeppelin there is currently no feasible way
> > to add this kind of central customization to the html->head section,
> > neither for loading Libs from CDN nor loading JS code asynchronously (like
> > bokeh). (without rebuilding zeppelin-web.war)
> > >
> > > Therefore I'm again suggesting a new configuration property to allow
> > zeppelin administrators to include any kind of special JS code (most likely
> > referenced via an URL) to the html->head section. I'm not sure yet, if
> > thats possible at all, because configuration is some information from the
> > server, that needs to be loaded very early.
> > >
> > > Or can this be achieved via helium (or an extension to helium).
> > >
> > > Or any other idea how to solve this centrally and not on a per notebook
> > base?
> > >
> > > Regards
> > > Andreas
> > >
> > > On 2018/08/14 08:27:16, Jeff Zhang <[hidden email]> wrote:
> > > > Here's the code of how bokeh loading js asynchronously, hope it is
> > useful
> > > > for you.
> > > >
> > > >
> > https://github.com/bokeh/bokeh/blob/master/bokeh/core/_templates/autoload_js.js
> > > >
> > > >
> > > > Partridge, Lucas (GE Aviation) <[hidden email]>于2018年8月14日周二
> > > > 下午4:21写道:
> > > >
> > > > > I’m pretty rusty on this as it’s several years since I tried it but I
> > > > > remember having a similar problem when trying to use Google Maps
> > inside
> > > > > Zeppelin.  Unfortunately I can’t find the code I used but from
> > memory, my
> > > > > solution was to try invoking the library, and if, the library object
> > didn’t
> > > > > exist, load it. In the onload() callback (not sure I’ve remembered
> > the
> > > > > method’s name right) I would then draw my map. I certainly didn’t
> > embed the
> > > > > library in the notebook itself.
> > > > >
> > > > >
> > > > >
> > > > > *From:* Jeff Zhang <[hidden email]>
> > > > > *Sent:* 14 August 2018 08:11
> > > > > *To:* [hidden email]
> > > > > *Subject:* EXT: Re: Inefficient third party JS library integration,
> > e.g.
> > > > > plotly
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Do you know how jupyter handle that ? And bokeh would load js from
> > CDN so
> > > > > it doesn't have the issue you mentioned, maybe plotly could use
> > similar
> > > > > approach.
> > > > >
> > > > >
> > > > >
> > > > > https://bokeh.pydata.org/en/latest/
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > [hidden email] <[hidden email]>于2018年8月14日周二
> > 下午2:34写道:
> > > > >
> > > > > We are using plotly for charts quite often (plotly python in
> > conjunction
> > > > > with pyspark) and it reavels a weakness regarding to third party JS
> > library
> > > > > integration.
> > > > >
> > > > > Unfortunately current plotly integration is not very efficient in
> > terms of
> > > > > library integration, which leads to huge notebooks. This is because
> > > > > notebooks that contain plotly will have to output the full js code of
> > > > > plotly. (~3MB). When a Notebook contains several of that
> > integration, the
> > > > > notebook becomes very slow. I think this also applies to other js
> > libraries.
> > > > >
> > > > > E.g. for plotly you can render charts in zeppelin the following way
> > with
> > > > > pyspark (the first print is only for demoing the actual html output
> > in
> > > > > cleartext):
> > > > > ---------------------------------------------
> > > > > %pyspark
> > > > > from plotly import graph_objs as go
> > > > > from plotly.offline import plot
> > > > >
> > > > > out = plot([go.Scatter(x=[1, 2, 3], y=[3, 1,
> > 6])],include_plotlyjs=True,
> > > > > output_type='div')
> > > > >
> > > > > print(out)
> > > > > print('%html', out)
> > > > > ---------------------------------------------
> > > > >
> > > > > An alternative would be, to load plotly.js (or any other third party
> > > > > library) from a CDN, e.g.
> > > > >  <script src="https://cdn.plot.ly/plotly-latest.min.js"></script>
> > (and
> > > > > settings include_plotlyjs in the example above to false, which would
> > lead
> > > > > to the bare minimum of code for that specific chart).
> > > > > But this needs to be added to the html->head, otherwise any
> > dependent code
> > > > > using that library might run into 'Uncaught ReferenceError: ... is
> > not
> > > > > defined' issues, due to timing.
> > > > >
> > > > > I found that setup guide for repacking the zeppelin-web archive, to
> > > > > include a custom library in the index.html, but IMHO that seems to
> > be a
> > > > > workaround:
> > > > > https://github.com/beljun/zeppelin-plotly
> > > > >
> > > > > Therefore I would suggest to add some zeppelin server wide
> > configuration
> > > > > to allow zeppelin administrators to include additional <script>
> > directives
> > > > > in the head section.
> > > > >
> > > > > Any other recommendation / ideas to solve the timing issue?
> > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Best Regards
>
> Jeff Zhang
>