scripts: js minify about templ HOT 10 CLOSED

I'm playing around with the use of tdewolff's JS parser to enable a new type of <script> parsing.

It would open up the door to this sort of thing in templ, and maybe supersede script and CSS templates over the longer term:

templ Component(y any) {
  <script>
    var x = {{ y }};
    alert(y);
  </script>
  <div>Hello</div>
  <a href="google.com" onclick="if {{ y }}.data { alert('no'); }">Click</a>
}

So yes, tdewolff's minifier might work nicely.

from templ.

That is also something that I'm looking at @stephenafamo - I put an example of what that could look like at #498 (comment)

The example demonstrates the concept of being able to have just the HTML rendered, which would massively simplify the use of HTML and other LSPs.

from templ.

Currently the only way to achieve this would be to ditch templ scripts and create your own JS files that are minified and referenced by your templates.

I think that the code in templ scripts should be small so may not really benefit from minification, which I believe is ideal for projects with large JS assets which are usually inflated by dependencies.

from templ.

It's not recommended to pass go values to scripts anymore?
The alternative then is to have an API endpoint and a fetch call in the js?
Aren't we losing a very useful feature?

Edit: never mind, please ignore my comment. I didn't read the full documentation https://templ.guide/syntax-and-usage/script-templates#passing-server-side-data-to-scripts

from templ.

If this is to be considered, I think esbuild may be a better tool to rely on.

from templ.

You could use your favorite javascript minifier in a build step, and point your <script> tags to the foo.min.js file instead of foo.js.

from templ.

Following the templ guide, in my example, every custom templ component (if needed) has its own script part.
So the js is only rendered if its really needed, not a general js file is provided.

Is this a design issue (from my own) I havent considered?

from templ.

It would also be great if templ's LSP can perhaps also proxy to another LSP for JS (similar to how Go code is checked with gopls)

from templ.

I think the same applies to css. Being able to run the component level css through postcss at generate time opens up a whole ecosystem of plugins without templ having to be aware.

So maybe a hook/middleware in the generate logic that calls out to plugins, allowing custom logic?

Alternatively, a vite plugin that triggers templ generate so that vite handles the esbuild, postcss and bundling. I think that may even help the LSP.

I'm going to dig around under the hood today and see what that would take.

from templ.

Due to the recommendation to move away from script templates I think we can close this.

The decision is due to scenarios exactly like this, we cannot support all of the workflows that people like to process js and css, so making the interop with the outputs of said processes should be the priority.

from templ.