I'll give you one guess what the F stands for...

This is a sensible C# inspired take on JavaScript's crappier nearly unusable stock objects.

The number of times I have had a head slapping moment using JS has formed a little crater in my forehead. For a language that we are all forced to use for web development, it's quite lacking. It has gotten better over the years, but there are still some things to this day that are just embarrassing. So I thought it would be fun to replicate C# objects using JS to see how far I could take irony of developing in JS to use C# objects in JS ultimately. If you haven't figured it out already this is mostly a joke. So if you are getting upset don't; I am just poking fun at the Stockholm syndrome of programming languages.

Below is a list of what I have implemented so far. I am only planning on adding things as needed.

I am organizing the TypeScript classes and modules as logically as I can to follow C# namespacing. Therefore, everything will start in the System folder like it has done for many years in mscorlib.dll.

JavaScript's Date object is one of the most ubiquitously hated objects to use because there are some very unwelcomed biases that the creator(s) introduced. Unlike C#'s pristine example of what a DateTime library should be. I have written a wrapper around the nonsensical Date object to make it mirror the dot net System.DateTime struct.

• JS Date
• C# DateTime

There are so many problems with JS Date it gets its own ReadMe.

JavaScript's woefully lacking Date object does not support reasonable date math. Therefore, there is no exact JS equivalent TimeSpan object unlike the wonderous joy it is to use C#'s System.TimeSpan struct. The closest thing that JS has is the getTime() function which returns the total number of milliseconds since 01/01/1970 UTC which is a designated epoch.

• JS Date.getTime()
• C# TimeSpan

Everything in JS inherits from Object.prototype, just like everything in C# extends System.Object. The concepts are the same, but unfortunately there was no easy way to encapsulate this object without making life miserable. Therefore, I opted for making an interface instead to help provide guidance on getting closer to a C# object.

• JS object
• C# object

Here is a list of key differences between the two object constructs:

This interface accepts a generic of type T so that the equals function knows what it is trying to equate to. This diverges from what C# does, but this exercise is never going to be perfectly replicate C#. It's just going to better than what JS has to offer today. Therefore, there isn't a benefit to implementing an equals method that takes object.prototype or any type as an argument for compare.

https://learn.microsoft.com/en-us/dotnet/api/system.iequatable-1

There is no equivalent in JS for this. I just wanted to follow the same pattern provided in C# where you would implement this interface to get additional benefits from collections and other objects that need the Equals(T) method.

There is overlap between this interface and IObject{T} and that's on purpose.

https://learn.microsoft.com/en-us/dotnet/api/system.icomparable-1

There is no equivalent in JS for this. It is required for sorting objects.

https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.iequalitycomparer-1

There is no equivalent in JS for this. I implemented it so I could use it with my Dictionary<TKey, TValue> implementation.

https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.keyvaluepair-2

You could argue that there are equivalents for this in JS, but not really. This is used in conjunction with my Dictionary<TKey, TValue> implementation.

This is an amalgamation of System.Array and List<T> to combat the inconsistencies of the thing called an Array in JS. You know this thing []. The Arrays in JS are confused because they don't know if they want to be arrays or stacks.

The one glaring problem that became terribly clear to me while working on this humanitarian effort is that JS Arrays are mutable. I don't know why that never dawned on me before. Something always really bugged me about JS Arrays, but I have finally nailed it.

JS Arrays, really shouldn't be called Arrays - it's a poorly managed array that wants to be a stack sometimes at best.

• JS Array
• C# Array
• C# List{T}

There are so many problems with JS Arrays it gets its own ReadMe.

JS Maps are actually not that bad, but they still kind of suck for one reason. JS Maps, JS as a whole really, has zero clue how to index custom objects. If you are using anything other than a primitive for a key, your Map is absolutely useless. JS Maps will let you add duplicate keys, because again it has zero clue how to do comparisons. This is what I would refer to as an incomplete feature. I can't call it a bug because JS has no concept of hashing.

• JS Map
• C# Dictionary{TKey, TValue}

There are several problems with JS Maps, so it too gets its own ReadMe.

Since hashing isn't a thing in JS I had to come up with some ways to do it. And when I say come up with ways to do it I mean rip off C# as best as I can. Shockingly I was able to implement equivalent hashing algorithms for both System.DateTime and System.string. I honestly didn't think it could be done, but alas here we are and we are better for it :D.

This is a complicated subject, so it gets its own ReadMe.

What does the F stand for in BFG 9000? If you can't answer that question, you are making me feel old and that's rude.

Lastly I just want to shout myself out for doing this for the world. It couldn't have been done without my selfless efforts.

We can do better than JavaScript. Please, think of the children.

~ YOU'RE WELCOME ~

Pascal I did it!