You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@zeppelin.apache.org by an...@gmail.com,
an...@gmail.com on 2018/08/14 06:34:47 UTC
Inefficient third party JS library integration, e.g. plotly
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?
Re: Inefficient third party JS library integration, e.g. plotly
Posted by Andreas Weise <an...@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 <zj...@gmail.com> wrote:
> Adding custom js via configuration make sense to me.
>
> Andreas Weise <an...@gmail.com> 于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, andreas.weise@gmail.com <an...@gmail.com>
> > 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 <zj...@gmail.com> 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) <Lu...@ge.com>于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 <zj...@gmail.com>
> > > > > *Sent:* 14 August 2018 08:11
> > > > > *To:* users@zeppelin.apache.org
> > > > > *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/
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > andreas.weise@gmail.com <an...@gmail.com>于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
>
Re: Inefficient third party JS library integration, e.g. plotly
Posted by Jeff Zhang <zj...@gmail.com>.
Adding custom js via configuration make sense to me.
Andreas Weise <an...@gmail.com> 于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, andreas.weise@gmail.com <an...@gmail.com>
> 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 <zj...@gmail.com> 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) <Lu...@ge.com>于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 <zj...@gmail.com>
> > > > *Sent:* 14 August 2018 08:11
> > > > *To:* users@zeppelin.apache.org
> > > > *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/
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > andreas.weise@gmail.com <an...@gmail.com>于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
Re: Inefficient third party JS library integration, e.g. plotly
Posted by Andreas Weise <an...@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, andreas.weise@gmail.com <an...@gmail.com> 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 <zj...@gmail.com> 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) <Lu...@ge.com>于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 <zj...@gmail.com>
> > > *Sent:* 14 August 2018 08:11
> > > *To:* users@zeppelin.apache.org
> > > *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/
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > andreas.weise@gmail.com <an...@gmail.com>于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?
> > >
> > >
> >
>
Re: Inefficient third party JS library integration, e.g. plotly
Posted by an...@gmail.com,
an...@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 <zj...@gmail.com> 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) <Lu...@ge.com>于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 <zj...@gmail.com>
> > *Sent:* 14 August 2018 08:11
> > *To:* users@zeppelin.apache.org
> > *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/
> >
> >
> >
> >
> >
> >
> >
> > andreas.weise@gmail.com <an...@gmail.com>于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?
> >
> >
>
Re: Inefficient third party JS library integration, e.g. plotly
Posted by Jeff Zhang <zj...@gmail.com>.
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) <Lu...@ge.com>于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 <zj...@gmail.com>
> *Sent:* 14 August 2018 08:11
> *To:* users@zeppelin.apache.org
> *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/
>
>
>
>
>
>
>
> andreas.weise@gmail.com <an...@gmail.com>于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?
>
>
Inefficient third party JS library integration, e.g. plotly
Posted by "Partridge, Lucas (GE Aviation)" <Lu...@ge.com>.
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 <zj...@gmail.com>
Sent: 14 August 2018 08:11
To: users@zeppelin.apache.org
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/
andreas.weise@gmail.com<ma...@gmail.com> <an...@gmail.com>>于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?
Re: Inefficient third party JS library integration, e.g. plotly
Posted by Jeff Zhang <zj...@gmail.com>.
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/
andreas.weise@gmail.com <an...@gmail.com>于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?
>