Hello devRant!
Google is coming up with all useless answers so...

I have several module pages in AspX. A lot of them share the same variables that they each instantiate on load of that page like:

Var SaveText = <%=Lan.SaveText%>;

But if I put those into a javascript file to share it, instantiation fails because the <%=%>-values only work within the AspX page.

Is there really no way around this except putting it in the master page (which I really don't want to for other reasons)

This is really bad practices. Don't mix langs.

Anyway, you need to generate your js file... just replace the value server-side then send the content with mime application/javascript

@Cultist what do you mean "don't mix langs"? Isn't this exactly how you bring your C# variables over to frontend in Asp.net projects?

Mind you I'm learning as I go here, I'm just trying to find my way around this project.

Do you have any resource on the correct way to do it?

@ArcaneEye Fetch them on the frontend itself. Never have dynamic JavaScript. It's completely impossible to cache.

Can you elaborate? Do I need to set up an API and Ajax to get them or how do I go about that?

@ArcaneEye you should check how to do an API centric app.

I'm really not a fan of C# so can't say if it's idiomatic but as a general rule of thumb it's a bad idea to mix two or more languages together. Reminds me of old school php.

What you can do is transport the data to your client, basically you have your server in C#, your client in JS and a transport which is likely HTTP (REST).

The client does not need to know anything about how the data is generated.
The server does not need to know anything about how the data is consumed.

@Cultist "Don't mix langs" - ever talked to a DB in your backend? ;)

@Cultist right, so I'm asking how to do a specific thing in asp.net and you're basically saying "don't" :-p

Sadly I do not have the time on hand to restructure the whole thing to use rest api's, and considering data transfer is built into asp.net I don't have to, I'm just asking if anyone know of a way to share an aspx-codepage between multiple actual pages, but the more I look for it the less it appears to be possible. It's have been nice to cut back on the code duplication a bit, but I digress.

@PrivateGER somehow my @ got lost. Can you elaborate on your answer?

@ArcaneEye Build an API with your C# App. Restructure your frontend to use the new API routes to get data dynamically and render it. AJAX is quite outdated though.
This is the only real way to solve this problem. Anything else will earn you a slap from another dev.

@gronostaj Yes, everyday. My point still stands.

@PrivateGER this thing makes me want to kill a dev on a daily basis.

When I started out a couple months ago I thought it'd be a whole lot more C# and a whole lot less web. I was mistaken, so now I'm scrambling to try and figure this web thing out on a daily basis, and try to not lose my mind having to deal with the shit fest that is javascript. I'm wanting to do things right, but I haven't had surplus hours to take some web courses so all I know is what I see, and that's AspX dynamic values and Ajax all over the place.

I'll keep what you said in mind, but I've little hope of getting to refactor it all anytime soon, and right now I wouldn't know what to use of not Ajax calls - there are much graver things in the codebase to the point where it's a relief when things are just plain broken 'cause at least then you can rebuild it :-p

@ArcaneEye Take a look at fetch(). It's easy to learn and you'll quickly be able to use it. It's also much simpler than AJAX ;)

Btw by AJAX they mean XHR using XMLHttpRequest I guess because ajax in itself does not exist... it's just a « technique ».

Then yeah, you prolly want to favor fetch over it if you don't need to track the progress of your request.

@ArcaneEye
The other answers are correct, I'll just add this:

If it's an actual aspx (web form)... rearchitect, you're basically spraying money out of your servers onto the internet as bandwidth and cpu time prognosticating html payloads.

Web forms had no concept of handling javascript interactions. It controlled all the rendering. Want new markup? New request, new markup, and read http methods via variable sugar.

If you absolutely have to do this, the "correct" way is to wire up some form controls and use controlstate, which will serialize a ridiculous amount of data to the client and bind a form. It will then use that same serialized form representation to process the data into an object that you handle in the Page_Load event by checking if the form IsPostback in the "codebehind."

The reason you couldn't get any answers from google is you'd need to hop in the wayback machine, or target the Indian internet to find anyone still talking about it:
https://bit.ly/38pmdQ3

@SortOfTested this just makes me want to burn the whole project even more :-p

It seems to be as you describe - aspx forms, however they seem to be bastardized somehow and JavaScript is somehow running in the pages ( jQuery and a ui framework is in use)

So... While some of it seems to be asp forms, other parts are slightly more modern, we are using JavaScript to do live updates to the DOM and buttons and text fields are declared using HTML and the UI framework.

It's just that apparently the old <%=property.value%> is used as well and not knowing better I took it for standard, since my colleagues aren't cursing at that specific part quite so often.

Guess I'd best fire up pliralsight and have a closer look at what's what in the Microsoft webapp environment...

Well, like I said, the others are right.

Worst case, just drop an .ashx in the project and use that as your baseline data to transmit the values. Anything you render out to the page will inevitably be technical debt and have crosscutting concerns galore. Better to have it encapsulated at the call site in JS using fetch/xmlhttprequest.

@SortOfTested I'll take a look at that, thanks a bunch!