Discuss alternative <script> lazy-loading technique in docs

[taoeffect]

While working on my "modern web development guide", which mentions Vue.js a good amount, I wanted to explain the various ways that third-party javascript libraries can be used by designers.

Designers are often used to having a vendor folder to plop in libraries like jQuery, which are then included using the traditional way (via a <script> tag in the HTML).

I'm writing an FAQ on lazy-loading and wanted to explore this route to see if it would work over the less intuitive lazy-loading that webpack/browserify do via require. The question I'm trying to answer is just what are all the primary techniques to reduce the size of the app.js bundle.

During my experiments, I found out a few things:

1. Including <script> tags in the HTML that gets swapped in by vue-router does nothing

This applies to both .vue and .ejs files. Adding this doesn't load jQuery when the view is swapped in:

<script src="/vendor/jquery.js" async></script>

I'm curious, why does that not work? I think this traditional (expected) way of doing things would be a welcome convenience for designers.

2. It's possible to lazy-load 3rd party libraries using <script> and vue-router

You just have to do it in a round-about way within a .vue file using the component's ready method. Example:

<script>
export default {
  ready() {
    if ( ! window.jQuery ) {
      var s = document.createElement("script")
      s.type = "text/javascript"
      s.src = "/simple/vendor/jquery.js"
      s.async = true
      this.$el.appendChild(s)
    }
  },
  methods: {
    submit: function () {
      var $ = window.jQuery
      // do something with $...
    }
  },

That actually works. 😄

Could the Lazy-loading documentation cover this technique (maybe also pros/cons)?

3. Libraries don't get unloaded when the view is swapped out

Another observation that I noticed is that once a third-party library gets loaded in a single-page app, it never gets unloaded. So if an app has a bunch of libraries, and the user visits "all the pages", then they'll be using up a good amount of memory since none of the global JS that gets attached to window ever gets unloaded. I was also wondering what "the right" way to do this is (and maybe the docs could also cover it?).

Curious to hear your thoughts!

[yyx990803]

This does work, but I think it's serving a different purpose from the "lazy loading" discussed specifically in the context of vue-router and with a module system.

Things like jQuery dependencies are easy to lazy load like this because they are a well-defined piece of code that never changes. Nor does it have any module relationship to the rest of your code. But what webpack lazy loading achieves is you can write your code in small modules, and let the build tool determine the splitting and bundling of chunks for you, and most importantly, it is about lazy loading a Vue component.

So while I think your technique is useful in certain contexts, it probably doesn't fit vue-router's docs in this case.

[taoeffect]

@yyx990803 Do you know why simply adding a <script> tag to the <template> doesn't work?

[yyx990803]

Vue filters out <script> tags when parsing the templates.

[taoeffect]

@yyx990803 ... Is there a reason for that? Would be neat if they could be used to reduce the app.js bundle size as per above.

[taoeffect]

I just had an idea, maybe it's possible to create a Vue component to do the above. It could even be a built-in component to Vue.js that would be pretty useful.

An ideal <script> component would take additional parameters that specified what globals get defined and whether or not to "unload" them when it gets swapped out.

For example, this would only load the script if jQuery hasn't already been loaded:

<script src="vendor/jquery.min.js" v-if="! window.jQuery"></script>

And something along these lines could unload jQuery when it gets swapped out:

<script src="vendor/jquery.min.js" v-if="! window.jQuery" v-unload="window.jQuery"></script>

In the meantime I'll look into implementing this myself under a script2 tag or something, but do you think this is something that could be added to Vue.js itself? (Should I open an issue for it somewhere?)

[yyx990803]

I think it's an anti pattern to include <script> in component templates, as code dependency logic should be handled in JS, not templates. So I don't think this will be added to core, but feel free to implement <script2>!

[taoeffect]

OK, I do not see how this is an anti-pattern. It is standard HTML, and it's been how HTML development has been done since it started. I don't want to force designers to relearn "how to include jQuery using this weird new trick" if there's no good reason for it. In this case, I do not see a good reason for changing the standard behavior and using require in the JS section of a .vue file. That is weird, non-standard behavior that also bloats a global app.js file that gets included on every "page".

[yyx990803]

@taoeffect you are free to think that way, but I maintain my opinion.

[taoeffect]

@yyx990803 It's very likely the case that I'm just not groking some part of your viewpoint.

Could you help me understand then, what you would consider to be the best + simplest way to "lazy load" a third-party "vendor" lib like jQuery in the situation shown above?

[taoeffect]

Also, I am running into bit of trouble coming up with a good/convincing explanation for why Vue.js prevents .ejs files from containing <script> tags. I get that you have whatever (not very clear to me, see question in comment above) reasons for wanting to keep <script> out of the <template> area, but this doesn't make as much sense when .ejs files are being used in a project that uses vue-router as there is no dedicated <script> section there to add them in.

I thought Vue.js was supposed to be a flexible framework, but it seems I've stumbled upon an area of inflexibility here. :-\

[taoeffect]

Also, what's weird is that the <script> tag is passed through to the page currently (for both .vue and .ejs files), but for whatever reason it doesn't get "loaded" by the page the way it does when the document.createElement technique is used: