[RFC Early Feedback] Wrapping up default <script> behavior

[FredKSchott]

In previous discussions, we have worked to finalize <style> and <script> behavior in Astro components. I had first proposed opt-in magic via a special @component attribute, but the feedback was largely negative on this idea and users were more in favor of how we currently do scoped, processed, and optimized styles by default.

Armed with better feedback, I still want us to address the inconsistency between <style> and <script> default behavior as a part of v1.0. Currently, <style> has opt-out processing, but <script> does not. This is still confusing and unintuitive, and many questions & support threads that I see are impacted by this.

Proposal (draft)

I would like to propose the following as an RFC, and would love your early feedback:

tldr: Change <script> to use current <script hoist> behavior, and add <script is:inline> to use current <script> behavior.

1. Make current hoist behavior the default <script> behavior. This aligns it with <style> behavior that users love and encourages our "optimized by default" / "pit of success" mentality.
2. Add the ability to opt-out of processing, optimization, and import resolution via is:inline. This can be useful for scripts that must exist inlined into the page, like Google Analytics.
3. If any script tag has an attribute (ex: src=, type="module", async) or client-directive (define:vars) then emit a warning that is:inline is needed. This is because a bundled script is added to some other JS file, so the script element itself will not exist in the final build.

Pros:

1. Aligns script with style behavior.
2. Keep supporting all current use-cases.
3. Enables more powerful component scripts by default. For example, importing npm packages and vite-powered import resolution, similar to <style> @import behavior.
4. Encourages our "optimized by default" / "pit of success" mentality. Easier to do the right thing.

More details on behavior specifics found here in this accepted RFC: https://github.com/withastro/rfcs/blob/style-script-rfc/active-rfcs/0000-style-script-behavior.md#script

Open Questions:

1. Should we just go ahead and add is:inline support for <style> here as well? The same reasoning applies to styles as well, and currently there is no way to add a <style> element directly to the page, inlined with the template.

[tony-sull]

This is definitely one that I'll need to revisit a couple times to think through all the implications, but I really like the approach in general 👍

Treating styles and scripts similarly to when they are/aren't compiled, bundled, and optimized makes a lot of sense to me

I also like the idea of optimizing by default with an escape hatch when needed. Very curious how more people feel about that one though, I'm sure there are others that would expect or prefer optimization to be opt-in only

[FredKSchott]

Thanks for the feedback. I'm basing some of this confidence off the fact that the feedback on #12 was overwhelmingly "please don't take away my default scoped styles, it would make it too easy to do the wrong thing". I think the same thinking would apply to scripts if users had experience with this as the default.

My hope is that this wouldn't be too difficult to implement, since there's no new features added other than changes to defaults. In that case, a prototype could help gather feedback as well.

[okikio]

A key use case that this proposal doesn't cover is how to handle polyfills and legacy code, where should the polyfill code be placed to function properly, how to bundle legacy code using legacy configs, etc...

[matthewp]

I like the alignment with style overall. Some things to think about here though, as I think scripts a little more complex:

• Worried about breaking embed usage. What happens if you grab the embed for a CodePen?
  • Should hoisting bundle external scripts like these? Currently it does not.
• Naming needs some work if we go this route, "inline" is confusing for external scripts.
• I believe define:vars cannot be bundled on scripts. Would using that automatically make it is:inline or do you need to add that attribute as well?

[FredKSchott]

• Worried about breaking embed usage. What happens if you grab the embed for a CodePen?
• Should hoisting bundle external scripts like these? Currently it does not.
• I believe define:vars cannot be bundled on scripts. Would using that automatically make it is:inline or do you need to add that attribute as well?

I think that all 3 of these points fall under this line of the proposal: "If any script tag has an attribute (ex: type="module", async) emit a warning that is:inline is needed, because a default script tag will be bundled." Basically, only <script> with zero attributes or directives supports the new default-on hoist/bundled behavior. I can rewrite this line to more clearly highlight src and define:vars.

• Naming needs some work if we go this route, "inline" is confusing for external scripts.

Open to others! I think that this still works in that the script element itself is inline, but I agree that it's also easy to misunderstand.

[jonathantneal]

Change <script> to use current <script hoist> behavior, and add <script is:inline> to use current <script> behavior.

Does this mean every <script> becomes <script type="module">? I need to revisit this a couple times, but I kinda don’t want Astro using HTML and then reversing how HTML works.

And I’d much rather <style> work like <script>, and the alignment go the other way.

[tony-sull]

Ran into a very relevant use case today, for what it's worth!

Use case
I'm working on migrating a client site from 11ty to Astro and have a couple instances where the 11ty site is using 11ty and alpine.js. The first use of Alpine that I've migrated over so far is using an Alpine controller to intialize a Siema.js carousel with Google Business reviews

The 11ty project has a shared index.js script that gets loaded in the client with a few NPM imports and also declares a handful of Alpine controllers used on the site

In Astro
I wanted to skip Alpine for at least this particular scenario, it was just a quick and dirty way to hook up the Siema carousel after the page loads. Here's where I landed with Astro, not sure if it's the best solution but it gets the job done 🪄

Nothing revolutionary here, but I thought it was pretty interesting figuring out how a pretty clean way of doing this. Now I just need to write my own carousel web component so none of this is needed at all 😄

/** in src/components/blocks/ReviewsBlock.astro */

<section>
  <div id='reviews'>
    // builds the HTML for each review card
  </div>
</section>

<script type="module" hoist>
  import Siema from "siema"

  const reviewsElem = document.getElementById("reviews");

  // initialize the Siema scroller
  const siema = new Siema({
    selector: "#reviews",
    loop: true,
    perPage: {
      640: 2,
      1024: 3,
    },
    duration: 300,
  });

  // auto-scroll every 5 seconds
  let timer = setInterval(() => siema.next(), 5000);

  // disable scroll while hovering
  reviewsElem.addEventListener("mouseenter", function () {
    clearInterval(timer);
  });

  // enable scrolling again
  reviewsElem.addEventListener("mouseleave", function () {
    timer = setInterval(() => siema.next(), 5000);
  });
</script>