Page Specific JS for Go Web Apps

<p>I&#39;ve looked into a couple of web frameworks - Gorilla, Revel, Martini - and I don&#39;t think any of them have a way to serve your JS files based on your controller/page name. It seems horrible inefficient to dump all your JS for your entire app into one file and serve it every single time. Anybody have or know of any solutions?</p> <hr/>**评论：**<br/><br/>kardianos: <pre><p>Actually, due to how caching works if you set ETag it may be more efficient. If you actually want to serve separate JS files, you could embed them into the relevant templates.</p></pre>izuriel: <pre><p>What framework were you using where this was done? Most frameworks I&#39;ve worked with always do a single compiled file. If you handle caching correctly it&#39;s actually not a problem. </p> <p>How much JS are you even talking about? I doubt it&#39;s really as large as you think it is. </p></pre>klauspost: <pre><p>You can pass it to the templates as a parameter, at least in Revel and probably also the others.</p> <p>But do consider that approach. There usually isn&#39;t any good reason to do so. First of all, your test scenario explodes. You need to define and test a lot of pages, and you just add one more thing that can go wrong.</p> <p>You can set aggressive caching on a JS file, and if it is gzipped, it isn&#39;t that big a file anyway. Also use a code compressor to minify the code. Closure/Uglify are good depending on your needs. You can for instance use a file hash of the js file to change the included path in your pages.</p> <p>Here is an example in revel, with a &#39;hash&#39; parameter. You don&#39;t need to check it. It is just there so you can update the URL in your templates when a new js file is created. <code> GET /js/:hash/*filepath Static.Serve(&#34;public/js&#34;) </code></p></pre>stone_henge: <pre><p>http.FileServer will serve multiple files from a directory. If the files are generated on start-up, tou should be able to route to them with a simple handler that relays them e.g. via a map[string][]byte. As others have mentioned, serving a single file will probably be more efficient since it would likely result in a single request per user followed by cache hits. The worst case scenario (frequent users with caches disabled using only a small portion of the code) would be worse, though.</p></pre>calebdoxsey: <pre><p>One (or a few) file for all your JS is ideal. If you can&#39;t do that you should dump the JS directly into the page as a script tag. Implementing this with the built-in template package should be trivial.</p> <p>The reason it&#39;s more efficient is that the expense of extra http requests is far greater than the expense of a few extra kb. When properly cached, your end user will pay that cost up front on the first request, but all subsequent requests will use the same compiled JS file.</p></pre>moosingin3space: <pre><p>HTTP/2 changes this, but we have time to adapt, so I wouldn&#39;t worry too much about it for now. </p></pre>