Replacing the MicrosoftAjax.js referenced in aspx pages in ASP.NET with Typescript

Question

The HTML/JS .aspx pages in my ASP.NET application use the MicrosoftAjax.js file like :

<script src="../../Scripts/MicrosoftAjax.js"></script>

Considering MicrosoftAjax.js is very old, I want to replace the MicrosoftAjax.js file with TypeScript (.ts) file and serve the same purpose. I am a bit not clear how complex this change would be and its impact as I am not much familiar with Typescript.

Are there any specific steps that i can follow to do this change ?

Answer 1

Well, you can download the ajaxcontrol tool kit source code.

All of the JavaScript routines are included.

thus, you could thus try and modify the toolkit source code to use TypeScript.

but, unless you willing to modify that code, look at the code, and play with the source code?

Then why bother with TypeScript. I mean, you MUST be adopting TypeScript for a reason - like say NEW software development?

I mean, why do you care if the jQuery, or jquery.UI library that SO MANY use in their projects is TypeScript or not?

Answer: You don't give one hoot - do you?

Unless you plan to active modify that JavaScript library, and make changes.

If you not planning to make changes to that code, then I see ZERO reasons to worry about that code being JavaScript, or some .net "layer" is tossed on top called TypeScript to (hopefully) make writing your JavaScript easier.

I mean, I am looking at TypeScript, since writing JavaScript tends to suck HUGE!!! Here we are with the fantastic .net framework, classes, great and fantastic type checking, strong data typing, and then we have to jump down to writing JavaScript with all of its warts, and INCREDIABLE PAIN and suffering when writing js code. It is beyond pain - it just is.

Now, don't get me wrong - we all as developers have to mess with js code. And that js gives us the abilities to write really nice interactive and responsive web applications. So amazing are the results, that we now can actually provide, and write and build applications that give EVEN BETTER user experiences then even what desktop software offers (at least in most cases - business applications). So I LOVE what client side JavaScript code can do for us - but this huge mess of JavaScript libraries - ever growing? It is killing the browser performance right now - and increasing load times - it is a mess our industry has to deal with. (and Blazer looks to be that solution).

So, I have now

 AjaxToolKit - tons of JavaScript library routines
 jQuery - a ton more of JavaScript library routines
 jQuery.UI - a ton more of JavaScript library routines
 jQuery.toast - a ton more of JavaScript library routines.
 bootstrap.js - a ton more of JavaScript library routines

And so on!!!! (probably left out a dozen more!!!!).

I mean, REALLY when is this madness going to stop!!!

Exactly how many external js libraries do you expect me to have to adopt?

But, NOTE VERY careful - library routines!!!!

That means this is code I don't maintain and modify and care about. (so who cares if that external library code is Typescript or not???)

There is NOTTHING stopping you from using TypeScript for YOUR code, but who gives one hoot about all the above external library code routines - why not just use them?

In fact, this is quite much why I can't wait to get up to speed with blazer. Blazer might be REALLY cool because I can now run my .net code client side. (how cool is that!!!) - no more JavaScript code!!!! Our savior has arrived!!!

But, what is MORE valuable in Blazor is not that you can write .net code (c# right now - hopefully they will add vb.net some day - but it don't look like that will occur).

The HUGE value is I can now dump that train wreak of having to adopt a gazillion external script libraries, and now use ONE seamless language for both server side code, and client side code. No more JavaScript, but MORE important I can then adopt pure nice clean .net code - and that code will be for both ends. And that means things like say moving a class object from server side to client side - and I don't have to muck around with JSON, or serialization , or anything - it all the same code, and thus moving data types from server to client side becomes not only near automatic, but seamless, and the same language. and it runs at compiled speed browser (client) side. Blazor has the potential to get rid of ALL THAT nonsense, including that of killing the browser side with a NEVER ending and EVER growing list of external JavaScript libraries to just build a decent working web page.

It is the galactic mess of all these libraries, and killing the browser with that truckload huge payload of external libraries that is the big mess right now.

Blazor has the potential to just toss ALL OF THAT hair ball mess out the window.

Now WHY do I mention the above? Well, if you going to consider modifying the ajax tool kit source? I would consider a migration to Blazor - and not TypeScript.

But, then again, we STILL not answered why you care?

I see ZERO advantage to change the jQuery libary code, or in this case the ajax control tool kit to using typecript UNLESS you going to actively modify the source of that external libary in the first place.

I mean, why do you give one fying hoot that jQuery, or jQuery.UI is JavaScript, or some layer on top called TypeScript is being used? (perahps bettr inteli-sense???).

So, the tool kit is open source.

I did in fact modify the ajax file up-loader.

I needed two things:

First, I wanted the time remain for a up-load (who left out that feature!!!!). But then again, that is the beauty of the ajax tool kit - it is open source. So, now my up-loader shows the time remain like this:

And the other missing feature? Well, the 3 events for the ajaxfile up-load. I wanted to be able to pass values from the up-loader to the server side events. So, I modified the events, and now I can pass a jason string - that effective allows me to pass a "class" up during the up-load process.

Now, could have I decided to spend all that extra time to make this code work as TypeScript? Gee, that would be quite a bit of messing around and extra time.

But, the fact that I already use all those external libraries (jQuery, jQuery.UI and a bunch more? I don't see the need or goal here.

We all use truckloads of those externa js libraries. Unless we plan to active MODIFY such code, then TypeScript gives ZERO value to me as a developer.

And adopting TypeScript in YOUR code does not prevent you from using and consuming that boat-load of externa js library code that you FOR SURE are using these days.

So, to answer your question?

If you want to download a copy of the ajaxtool kit, and add type script tags, and re-compile the whole tool kit on your own - and with Type Sciprt?

Sure, go ahead, but I fail to see the goal here unless you actually willing to download the source and you plan to active modify and mess around with the source code.

If you JUST going to continue to use all those external library code, then I see zero advantages to bothering with TypeScript in those external libraries - just use TypeScript FOR YOUR code development - not everyone's else JavaScript library code that you now using anyway.

I mean, do you care that jQuery, or bootstrap.js is TypeScript? Don't' think so.

But hey, the ajax tool kit is open source. You can jump right in to modify that library code, but I don't see any benefits to doing so.