10 Most Shocking JavaScript Features for C# Developers

Whether you’re a C# (or similar language like Java) developer eager to learn JavaScript or you’ve already been working with JS for some time, I hope you find this article interesting. I collected for you 10 JavaScript features which are/were the most shocking for C# developers who learnt JavaScript. These features of JavaScript language are the most striking differences compared to C# ecosystem. If you’re about to learn JavaScript, sooner or later you’ll also have to deal with them. Before we begin, one disclaimer: the goal of this post isn’t stating which language is better or worse. JavaScript and C# are different programming languages and their use cases are also completely different. One is better for some usages, while the other is better for others. The list is my and other readers’ subjective one and you don’t need to agree with all points. I’m myself a C# developer on my JavaScript learning journey, so I’d like to help you grasping these confusing concepts 😉

1. Dynamic Typing

Obviously, the first difference JavaScript newbie notices is that the language is dynamically-typed. It means that the types (of variables, functions, actually of almost everything) are checked at runtime, not at compile time like in C# or Java. Because of that, there’s not much difference in defining variables and assigning them data of various data types: .gist table { margin-bottom: 0; } JavaScript’s variables are not associated with any particular data type. That’s why it’s completely legit to write something like that: .gist table { margin-bottom: 0; } Because JavaScript is dynamically-typed, issues with types are detected at runtime (e.g. error is thrown as soon as you try to use a variable in a context which expects another data type), not during compilation time as it would be in C# or Java. If you have some experience with statically-typed languages, you may now feel how much confusion and troubles dynamic typing can bring. At least at the beginning.

2. Implicit types coercion

JavaScript has one more interesting feature – types coercion. Even though this term’s name sounds a bit weird 🙂, it’s quite simple: types coercion happens when a value of one type is converted to another one. It may be explicit, but harder to grasp is the implicit types coercion. It means that developer doesn’t necessarily ask for converting value of some type to another, but it still happens “silently”. To visualize it, consider the following code: .gist table { margin-bottom: 0; } Even though console.log() expects data of text type, isGreatDeveloper which holds a boolean value at the moment is implicitly converted to text. The above example was just to show you what types coercion is all about, but it gets more confusing in reality. First misleading concept is that JS has actually two equality operators: == and ===. Let’s see some code example to know the difference between them: .gist table { margin-bottom: 0; } The first == operator performs an implicit types coercion before performing the actual comparison. That’s why the text ’26’ is “silently” converted to a number 26 and the if statement is true at this point. Because of that, we should normally always use === operator to avoid such unclear situations. Existence of such (and many more) nice concepts of JavaScript leads to finding such interesting Tweets:

*shuts laptop forever*

Rebranding – becomes

Hey guys, I hope you’re doing well 🙂 Today I’d like to announce you a change that will happen on my blog in the days to come, so you’re not surprised post factum 😉  

Purpose of this blog

I’ve actually never defined why I conduct this blog and what’s the purpose of it. When I started in the beginning of 2016, I planned to launch my own technical blog to have a single place in which I collect some useful information about software development, mostly for myself. This was the main idea at that time. Then I didn’t write anything here for some time, until the Daj Się Poznać (en. Get Noticed) programming competition begun,

in which I decided to take part

[.NET Internals 09] Just-In-Time (JIT) compilation

Have you ever heard the term JIT? It’s an acronym for Just-In-Time. JIT compiler is a tool which performs the JIT compilation, which is a crucial feature of .NET applications. Let’s say a few more words on it today 🙂

What makes managed applications portable?

As we know from the previous posts published within the series, .NET Framework and CLR provide a lot of useful features for applications targeting the platform, such as automatic memory management. However, one of the main goals of managed runtimes’ invention was to make implemented applications portable. So what does it mean than an application is portable? It means that, first of all, it can be run on any kind of hardware. Ideally, it should also be software-agnostic (especially OS-agnostic). We can still observe this trend for instance by the fact that Microsoft created ans is actively developing a multi-platform NET Core. Such portability not only makes the application possible to be launched on any hardware or software platform, but also releases developers from taking care about underlying low-level structures. For instance when working with TPL, the programmer normally doesn’t need to change his/her code taking into account the underlying hardware (e.g. number or architecture of CPUs). It’s the same for memory allocation (described in the previous posts) where many close-to-metal details differ based on operating system’s architecture (32/64 bit) – CLR handles it for us. However, at some point, every application needs to be executed by the processor, which requires having a machine code  -assembly instructions understood and possible to be executed by the CPU. Depending on the OS’s or CPU’s architecture it’s sometimes necessary to use completely different CPU instructions sets in the assembly code. As you can guess, to make source code really portable it cannot be directly compiled to machine code. There’s something intermediate needed.

Intermediate Language (IL)

Because of the reasons described above, managed runtimes’ programming languages source code (like C#, F# or Java) is not directly compiled to assembly language. Instead, it’s firstly compiled to an intermediate language (IL).  CLR’s intermediate language is also referred to as MSIL (Microsoft Intermediate Language). Compilation of source code into IL is performed by the particular language’s compiler. This is the process which happens when you build your app by pressing F6 in Visual Studio or using csc.exe to compile your code. Source code -> IL compilation is done by the particular language’s compiler. For instance, C# code is compiled by Roslyn. which is a C# language’s compiler:
Visual Studio’s build – Roslyn

Viewing MSIL

In order to see the MSIL code contained in the compiled EXE/DLL files (like I showed you e.g. here and here), you can use ILSpy Visual Studio extension, which, when installed, adds a menu option in Visual Studio (Tools -> ILSpy), where you can open any compiled file and view the IL code of contained objects:
ILSpy – MSIL code
What is actually compiled into IL code? For now we can say that the most important are methods (grouped into classes, namespaces etc. of course). There are also many other things compiled (even more than you would expect by looking at your source code), but we will focus on the methods for now. OK, so we have the IL code now, but it cannot be understood by the CPU yet. How and when is it then compiled to assembly code?

Just-In-Time (JIT) compilation

Let’s start by some historical background 🙂 In the early 1960s, Japanese engineers at Toyota had to reorganize their warehouse management, because they had very high storage costs – delivery of the parts from suppliers took a lot of time, because they ordered a lot in advance. Every delivery had to be handled by someone, so they needed a lot of employees. Ordered parts were stored in the warehouses for a long time, required a lot or storage space and maintenance. In order to minimize the costs, they invented a just-in-time manufacturing (also known as Toyota Production System). Its main principle was to =&0=&

[.NET Internals 07] Unmanaged resources: finalization, fReachable queue and dispose pattern

Today we’re going to see how unmanaged resources are handled by .NET, what are finalization and fReachable queues and what’s the garbage collector’s role in it. We’ll also get to know what is a dispose pattern and see how to implement it.

Unmanaged resources and finalizers

First of all we should all get familiar with what unmanaged resources are. These ones can be files or folders on the disk, database connections, GUI elements or network resources. You can also think of them as some external elements we need to interact with in our applications through some protocol (e.g. database queries or file system manipulation methods). They’re called unmanaged not without a reason – any unmanaged resources accessed from .NET code will not be automatically cleaned by the garbage collector. That’s how they are not(un)managed. Maybe you’ve heard about

destructors in C++