Thoughts about switching from C# to Typescript
It's been a year and a half since I switched from programming in .Net (C# and #VB.net) to a completely new stack. I have been programming with #React.js, #Nodejs, #Mui, #Graphql and #Prisma.io. It is time to share some of my observations. All observations and or opinions in the following text are my own and not necessarily reflect my employers.
The primary goal of my switch was to learn a new stack. I wanted to learn a dynamic or functional language like Ruby or Elixir. I understand that with a different background I would not be immediately productive to my employer in projects with these languages. Anyway I have been programming in Typescript in stead most of the time. Which is also a pretty different stack from .Net. Previously I had shunned Javascript, because of a poor developer experience when using Javascript in the frontend. That mainly meant server side rendering and in the browser trying to do Javascript stuff.
(Side note: I stayed away from web development for years, because of my experience with .Net WebForms. As I previously mentioned here I had already learned about the #Seaside framework in #Smalltalk. Anything compared to that didn´t feel right to do, so I focused on backend development instead. Anyway, if you want to learn something new, put yourself in an uncomfortable situation. So I started doing webdevelopment in Javascript albeit TypeScript.)
So what have I learned. Well, first of all switching to Typescript has been harder than I thought. In the last 10 years or so there has been a shift towards a more functional programming style. At previous jobs existing code bases were from before 2015. They can best be described as procedural programming with classes or to be more precise procedural programming with Data Transfer Objects (DTO). This is commonly known as Object Oriented Programming. I have previously described my attitude towards that kind of programming here My first thought was that, Javascript being a functional language, that would reflect in the code bases. It turns out that is not necessarily true. In the code bases I have recently worked on we still use functions on services to transform or retrieve data. Data transfer objects (graphQl) are all over the place and considered common and good practise. Anyone familiar with the books from Yegor Bugayenko will know better.
That said I don´t know whether it is the frameworks we're using that are not functional or it is the coding style because I'm not familiar enough with functional programming to make that assessment, but I'm working on that.
Recommended by LinkedIn
So what about the frameworks. As everything was new to me I was confused by GraphQL and Prisma, but that turned out to be due to the code base that confluated everything. All types were just what you needed at that moment, no plan, no separation of concerns. I now know that wasn´t me. It was just confusing, because of all the new frameworks. We have been cleaning up that code so that was a good exercise.
Talking about Graphql. It is all about DTO's with data as JSON as the glue between systems. But I do wonder, can´t there be a more functional way doing this? Something more with decorators. I don´t know, any suggestions?
Concerning Prisma, I kind of like the syntax to retrieve data. It took a while to get used to and I still don´t fully grasp it all, but the syntax is interesting. That said it still has flaws that might be addressed in the future. At times when you think something can be retrieved simple, it actually can't and several calls to the database are needed to retrieve some form of information while the syntax suggests it is easy.
When it comes to de UI, Mui goes out of its way to make components look like templates. #Seaside abandoned templates in 2006. The thing is, while it looks like using templates, they are actually functions. As such, components resemble procedures more then true functions as meant in a functional language, or maybe I just don't know enough to make a good judgement.
Overall I like Typescript. It is an interesting mix a typed language like C# and dynamic features.
I wonder how you experience the type system of Typescript, compared to that of C#? As far as I know, in C#, just like in Java, you are using named types. The type name is what determines whether some object is compatible with the type. In contrast, in Typescript, not the name but the shape of the type determines compatibility: if a type says that it is an object with a field `length` that is a `number`, then any object that has a field `length` that is a `number` is considered compatible with that type, versus C# and Java where the class of the object explicitly has to declare the compatibility by adding somethink like `implements SomeType`. To me this one subtle difference (I think it's called 'structural typing') turns out to be HUGE and I kinda love the Typescript type system because I find it to be enormeously flexible compared to the more rigid Java type system that I came from.