Senior Software Engineer at Google working on Google Meet 👨💻 Helping developers be more awesome 🔥 author, speaker & nerd 🧙🏼♂️ into JavaScript, TypeScript, Vim & pixelart ❤️
Hi Jon! Thanks for your comment! :D hehe Did you know that the whole point of the JavaScriptmancy series was to teach C# developers that vanilla JavaScript was pretty awesome (when you actually got to learn it)? xDD
I remember that when TypeScript came out (I think it was around 2014 for the 1.0 release) I was quite sceptical about the whole thing. I went from C# to JavaScript and even though I loved C#, I really enjoyed the freedom from types in JavaScript. Particularly when doing object composition patterns that required a lot of boilerplate in C#. So I was worried that TypeScript would be just C#-ifying your JavaScript :D.
Anyhow, I think that the project has improved a lot since the early beginnings and I celebrate their success and the new ideas and great developer experience they've brought to JavaScript.
One cool thing about web development is that it is the meeting place for a lot of different communities of developers that wouldn't interact (so much) otherwise and, as such, it becomes a great place for cross pollination and sharing ideas and things that have worked great for these particular communities. One of those examples was CoffeeScript, and another one is TypeScript.
I see TypeScript as, "yo! We've been using static typing to provide great compile time checks and awesome developer productivity for years. Perhaps we can bring that same experience to the web". This developer experience naturally feels more comfortable to developers with strongly typed backgrounds since they get to use a lot of the things they're accustomed to.
A great thing for the rest of the JavaScript developer community is that TypeScript is very respectful of the nature of JavaScript. A good example of this is that TypeScript has structural typing (that is duck typing) as opposed to a nominal type system like Java or C#. The types of things are defined by their structure rather than by a name.
In regards to more complex tooling, I think that for most projects there's not gonna be a big difference in tooling since either you're gonna have TypeScript or Babel. Since types disappear after transpilation and you're left with JavaScript, I'm not sure there's a big runtime overhead. The polyfilling generated by TypeScript is negligible and varies based on the target you set in your compiler configuration.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Jon! Thanks for your comment! :D hehe Did you know that the whole point of the JavaScriptmancy series was to teach C# developers that vanilla JavaScript was pretty awesome (when you actually got to learn it)? xDD
I remember that when TypeScript came out (I think it was around 2014 for the 1.0 release) I was quite sceptical about the whole thing. I went from C# to JavaScript and even though I loved C#, I really enjoyed the freedom from types in JavaScript. Particularly when doing object composition patterns that required a lot of boilerplate in C#. So I was worried that TypeScript would be just C#-ifying your JavaScript :D.
Anyhow, I think that the project has improved a lot since the early beginnings and I celebrate their success and the new ideas and great developer experience they've brought to JavaScript.
One cool thing about web development is that it is the meeting place for a lot of different communities of developers that wouldn't interact (so much) otherwise and, as such, it becomes a great place for cross pollination and sharing ideas and things that have worked great for these particular communities. One of those examples was CoffeeScript, and another one is TypeScript.
I see TypeScript as, "yo! We've been using static typing to provide great compile time checks and awesome developer productivity for years. Perhaps we can bring that same experience to the web". This developer experience naturally feels more comfortable to developers with strongly typed backgrounds since they get to use a lot of the things they're accustomed to.
A great thing for the rest of the JavaScript developer community is that TypeScript is very respectful of the nature of JavaScript. A good example of this is that TypeScript has structural typing (that is duck typing) as opposed to a nominal type system like Java or C#. The types of things are defined by their structure rather than by a name.
In regards to more complex tooling, I think that for most projects there's not gonna be a big difference in tooling since either you're gonna have TypeScript or Babel. Since types disappear after transpilation and you're left with JavaScript, I'm not sure there's a big runtime overhead. The polyfilling generated by TypeScript is negligible and varies based on the target you set in your compiler configuration.