We Keep Coding

Does C# code contained in Javascript still need to be compiled?

We have a web application built with C# and ASP.NET. I have to reference a few .NET session variables in my JavaScript code, so I use the following line to do so:
var layoutID = '<%=Server.UrlEncode(string.Format("{0}", Session["layout_id"]))%>';
This works just fine. The web application is built and published to our web server. If I want to make a change, a .NET change would require me to compile the changes and publish it to the web server again. If it's a JavaScript change, I can simply edit the js in the .ASPX page and the fix is immediately picked up...no compiling needed.
My question - what if I make a change to this inline C# code contained in JavaScript? Say, for example, I meant to access Session["layoutid"] without the underscore. Could I just edit the .ASPX page on the web server, or will this require compiling just as if it were in a .CS file? I'm guessing since it's C#, I will still need to compile for the change to be picked up. And yes I could just try it and see for myself, but I was hoping someone could give a little insight into what goes on behind the scenes with this inline c# code. And while we're on the topic, is the technique I'm using to access .NET sessions variables in JavaScript the most efficient way to do it?
Bonus question - what is this technique called? I tried searching for an answer but I wasn't sure what to search for other than "in-line c# code JavaScript".
Thanks!

No, changes to ASPX/CSHTML files don't require re-compilation.
Note: whether it is good idea to jump on production server and change random code bypassing source control/testing is question to discuss and answer by your team.

Include html files in an html file on a local file system?

I have a help system that is completely offline, no server, using file://.
I have one main page, with hundreds of line of html that represent many sections of the help system. I would like to stick each section in a html file and just include it. Unfortunately it seems like this is only possible with some nifty server side include techniques, with HTML5 (which I do not want to assume my users have), or with a nasty javascript hack where you copy your html file into js files with document.write calls for every line as written about here: Ways to include html in html.
What about something like handlebars.js or mustache.js? Can I use templating?

Since you don't want to use server-side includes, I would suggest using a static site generator (SSG).
If you are not familiar with SSG's, they allow you generate HTML pages from templates & includes (often Handlebars templates) and HTML, Markdown, JSON, or YAML, content using a CLI.
If you want to get started with an SSG, there are plenty of options, from Ruby based Jekyll, or Node.js based Assemble. In my opinion, Assemble is the best option and I would highly recommend it.

Are external javascript libraries hidden?

So I realize that anyone can view the javascript in-line with HTML running in their browser, so if I use an external js library on my server will its contents be completely hidden?
Another question is are there any cases where it's better to use in-line javascript, like with jQuery or something, or is there really no down side to just using a js library for all of it?

No, there is no way that your javascript will ever be "hidden". Anything that can be run in a browser can be trivially saved and inspected. The best you can do is use an obfuscator.
The downside to using an external file is that it's another request. The upside is that it can be cached independently. For best performance, code that will be used from more than one page should be stored in its own file, and code that is page-specific is better off being stored within the page that uses it.

JavaScript operates on the Browser level, that means that the browser at some point read your JS (external or internal same s.). You can easily conclude from this that if at some point the JS is now registered by the browser, and it's accessible by anyone with a bit more knowledge in web stuff. you'll not be able to hide your JS trickery.
Pus inside your JS a Copyright notice and pray.
Never send sensitive data through the yellow wire.
If you have some extra sensitive strings, encode and compare them on server side - sending them like MD5 or in some SHA model to the server.

Javascript, with the exception of something like node, operates client-side so you can't really use an "external js library" on your server, whatever that means.
Best practices dictate that you should almost always reference your javascript using <script> tags and link to your javascript file using the src attribute.

Alfresco debugger cannot open js including an import tag

I'm implementing a custom document-details action in Share on community 4.0.a.
This action is using repository webscript that acts as an HTTP POST handler.
So I went to /alfresco/service/api/javascript/debugger to enable the js debugger tool.
But when I try to open a js file manually like aspects.post.json.js it launches a syntax error.
it does it with any js that starts with:
<import resource="classpath:/alfresco/xxx/xxx.js">
Is there anything I should be aware of to use this debugger with such files?

The "import tag" is not valid javascript. Thats why javascript syntax aware editors complain. As Florian mentions, it is resolved before the "whole" javascript is fed to the interpreter (rhino).
Nevertheless, would be nice if Alfresco would replace this tag with valid javascript to make tools happy - maybe with something similiar to the require function node.js provides.

I have opened an improvement request (or rather contribution) in the Alfresco JIRA which addresses this issue by providing a clean import API in JavaScript. In case you want to play around with it, you can grab the patch files as attachments at https://issues.alfresco.com/jira/browse/ALF-13631
With this, your example
<import resource="classpath:/alfresco/xxx/xxx.js">
becomes
importScript("legacy", "classpath:/alfresco/xxx/xxx.js", true); //Repository tier
importScript("classpath:/alfresco/xxx/xxx.js", true); //Share tier

I have never tried it but I am pretty sure that the debugger can't handle the statements. The debugger comes from the Rhino javascript engine and the import tags are an extension from Alfresco. They are resolved before the script is actually run in the Javascript engine.

If possible, try to separate the actual javascript code into different .js files as described here: Alfresco Web Scripts using Javascript – Part 1.
The first challenge when structuring your Web script code is how
Alfresco imports additional Javascript files. Alfresco expects
xml-style tags at the top of the main Web
script file. This will break javascript validation, automatic code
indentation and other important editor features.
This can be solved by placing all Javascript code in separate files,
leaving only the import declarations in the main Web script .js file.
Of course, this only works if you got full control over the webscript files..

best practice for dealing with common "structural" elements of pages?

Very basic question: I am coding a web app that has a handful of pages. These pages have the usual shared elements: eg, the site's header/masthead and a side-bar are present on all pages. The HTML is static (not dynamically generated, its "ajaxy-ness" is done client-side).
What is the best way of importing/"including" those common elements into my pages? The solution I am using is to have the HTML files contain empty place-holders
<div id="header"></div>
<div id="leftSideBar"></div>
(...)
and then do in jquery's $(document).ready():
$.get("header.html", function(html) { $("#header").html(html); });
// ....
Is this the best way to do this? I'm new to web development. : )
I guess I could also dig up a "macro-like" code-generation tool that I would run on the HTML files to replace, eg, "#header" with the contents of header.html. That way loading a page would require a single request for a single HTML file, which sounds better.
What is the smart way to achieve this? I am sure this problem has been solved a thousand times.
EDIT: The server-side is coded in Python+cherrypy. (I am assuming it is reasonable to try to keep away from dynamically generating HTML when doing "web 2.0-ish" web apps. Please correct me if I am wrong. As I said, I am very new to this environment.)
Thank you for your insights,
lara

If you want to include files, please consider using some backend language such as PHP or ASP. Javascript is not really meant to do this even if this would work.
<?php include 'other_file.php'; ?>
Using javascript to do this will lead, I think, to a poor SEO and the loading of the page might look weird for the end user. If you really don't want to use a backend language, some IDE have a way to handle templates, you could look into that.
Concerning frameworks, most of them have a way to handle templates. ASP.NET has the master page system, Ruby on Rails has layouts.
Here's an example using Rails :
<html>
...
<div id="content"> <%= yield %> </div>
...
</html>
Here all the content of a subpage will go into the "yield". Here's a link to learn more about that.
Some frameworks can handle multiple place holders.

To some extent, it depends on what you're using on the server side to render the pages. If your using server side scripts to generate the page you should be able to use a web framework (eg. Django or RubyOnRails) or even just a basic templating engine such as Genshi. Basic include functionality may even be built into the language you're using (ie. PHP)
If it's just static HTML you may want to look into setting up some form of server side includes such as Apache SSI or NGINX SSI. You'll need to pick the one that works with whichever server you're using, and you'll need enough access to install and configure the plugin or module.
Alternatively, you might want to look at using a script to generate your pages (edit, generate and deploy). A simple approach using cat / sed / awk / make (additional useful reference - Sed & Awk) may be all you need, or you might want to use a templating engine and a language such as Python or Perl.

I'd have the includes handled server-side, and this will mean fewer requests from the client, and may also have other benefits (easier to debug js, etc).
Having the server process includes really isn't going to put a major strain on it.