TypeScript runs on any browser or JavaScript engine
Not really, it's compiled to JS first. You can't "run" TypeScript in a JS engine.
...including IntelliSense, which offers active suggestions as code is added.
This kind of thing is readily available for JS also.
It has a namespace concept by defining a module
Not entirely sure what you mean here, but modules are fully available natively in JS.
TypeScript does not support abstract classes
I'm not a TypeScript user, but some quick googling shows TypeScript does support abstract classes (apparently since 2015?). JS doesn't support them natively (but then again it doesn't really have classes either), but it's possible to code up something that works the same.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
vartruck={start:function(){console.log("Truck in Started!");}}varbus={start:function(){console.log("Bus is Started!");}}
Start method is scoped inside it's object (context).
truck.start();// Truck in Started!bus.start();// Bus is Started!
Namespace usage protects and isolates the code from other applications.
You can use multiple functions with the same name, then distinguish them by utilizing the JavaScript namespace like in the example above.
It becomes easier to recognize the variables and functions from where they are defined.
It's not the only way to reach that. Setting private functions for example, won't clash against other private ones so they are contextualized separatelly be they with the same name or not.
The difference with the namespaces are that you mark a data structure (Object) property as the method so you always call it through the instantiation object name plus the method name.
others prefer JavaScript because it is less complex
I'm a strong proponent of JS over TS not because of TS complexity, but because of the lack of benefits at the cost of complexity. I can't recall the last time TypeScript would have prevented a bug on production, but I very much know how much longer it takes to write TS code. The usual counter to that is the IntelliSense assistance, which you've already shot down, but I would elaborate on a bit:
IDEs that derive data from static analysis of JS can provide nearly the same information (e.g. autocompletion) as from TypeScript. The small added information about type coherence can be achieved just as well through some framework features (React's proptypes), or Docblock-annotations. None of it requires TS. The overhead of writing and reading TS, however, is massive - especially for larger projects, where people seem to want TS as gospel.
The benefits of TS are almost always less than the drawbacks. When working with external data (e.g. API responses) it also gives a false sense of security, because the checks are at compile time, not runtime.
I advocate for TS on self-contained backends or on shared Fullstack applications - there, compile-time safety can be a very useful indicator - but client-side? I'll die on this hill: JS wins, every time.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
In my book that doesn't qualify as "runtime usage" but out of the box loading support.
What type of looks would you expect if you suggested to a software engineer to support an environment where C-source is compiled and linked to binary every time you need to execute the code even though the source code hasn't changed?
Technically, you are right. Still, this is what makes Deno so great. It's a runtime that on the fly uses your Typescript code without you being in the need to compile it yourself.
Typescript is a superset of JS. For an example C# code gets compiled into a inter language before then to bytecode. These two steps are necessary to ensure core features. Same goes for Typescript and JS. Since Javascript is the standard V8 can understand, Typescript gets compiled. This is why Runtimes like Bun and Deno with their build in Compile Support are great. They take the usual "watch and compile" Step away. Its just another step in the evolution of Code. If you want to use bytecode in the Browser, take a look at WebAssambly.
I can't impress this one enough. Technically it is a superset from a feature support perspective. However, people use it so they have compile-time type checking so once that becomes a requirement for you there are just things you can't do with TypeScript."
Not really, it's compiled to JS first. You can't "run" TypeScript in a JS engine.
This kind of thing is readily available for JS also.
Not entirely sure what you mean here, but modules are fully available natively in JS.
I'm not a TypeScript user, but some quick googling shows TypeScript does support abstract classes (apparently since 2015?). JS doesn't support them natively (but then again it doesn't really have classes either), but it's possible to code up something that works the same.
well it says including...
In JavaScript there are no predefined methods to use namespaces.
If they both 'include' it, how is it an advantage?
Actually main point over here was -
Although I get it what you wanna say
Thanks for fact checking!
Namespaces are a paradigm and not a "feature".
Start method is scoped inside it's object (context).
It's not the only way to reach that. Setting private functions for example, won't clash against other private ones so they are contextualized separatelly be they with the same name or not.
The difference with the namespaces are that you mark a data structure (Object) property as the method so you always call it through the instantiation object name plus the method name.
I'd also add that the intro is very reductionary:
I'm a strong proponent of JS over TS not because of TS complexity, but because of the lack of benefits at the cost of complexity. I can't recall the last time TypeScript would have prevented a bug on production, but I very much know how much longer it takes to write TS code. The usual counter to that is the IntelliSense assistance, which you've already shot down, but I would elaborate on a bit:
IDEs that derive data from static analysis of JS can provide nearly the same information (e.g. autocompletion) as from TypeScript. The small added information about type coherence can be achieved just as well through some framework features (React's proptypes), or Docblock-annotations. None of it requires TS. The overhead of writing and reading TS, however, is massive - especially for larger projects, where people seem to want TS as gospel.
The benefits of TS are almost always less than the drawbacks. When working with external data (e.g. API responses) it also gives a false sense of security, because the checks are at compile time, not runtime.
I advocate for TS on self-contained backends or on shared Fullstack applications - there, compile-time safety can be a very useful indicator - but client-side? I'll die on this hill: JS wins, every time.
Totally agree
+1
Your first point is simply not true. New Engines like deno offer a runtime for direct TypeScript usage.
Then that is a TS runtime. OP refers to browsers and JS engines, which is what I was addressing.
Deno IS a JS runtime with full TS Support. For browsers, there are certain experiments, but nothing productive these days.
In my book that doesn't qualify as "runtime usage" but out of the box loading support.
What type of looks would you expect if you suggested to a software engineer to support an environment where C-source is compiled and linked to binary every time you need to execute the code even though the source code hasn't changed?
Technically, you are right. Still, this is what makes Deno so great. It's a runtime that on the fly uses your Typescript code without you being in the need to compile it yourself.
Source code transformation shouldn't be a (production) runtime concern…
It's bad enough that JavaScript code has to make its way through Ignition, Sparkplug and Turbofan.
Typescript is a superset of JS. For an example C# code gets compiled into a inter language before then to bytecode. These two steps are necessary to ensure core features. Same goes for Typescript and JS. Since Javascript is the standard V8 can understand, Typescript gets compiled. This is why Runtimes like Bun and Deno with their build in Compile Support are great. They take the usual "watch and compile" Step away. Its just another step in the evolution of Code. If you want to use bytecode in the Browser, take a look at WebAssambly.
"TypeScript is a Subset of JavaScript
I can't impress this one enough. Technically it is a superset from a feature support perspective. However, people use it so they have compile-time type checking so once that becomes a requirement for you there are just things you can't do with TypeScript."
[The Trouble with TypeScript]
I came to that same conclusion before the article was published.
It confuses design time and runtime; yet another concession to developer convenience (by developers nonetheless).