NOTE: Debate on comment section
TypeScript vs JavaScript is one of the most controversial topics in tech.
Some developers prefer TypeSc...
For further actions, you may consider blocking this person and/or reporting abuse
For me, the advantage of typescript is it's type system. As for js, you can write it without any tools and it will work. Doesn't have to be transpiled or bundled, very low learning curve, open browser console and you've got yourself a REPL.
Yup the type system in TypeScript really helps detecting errors at compile time and JavaScript isn't as complex as Typescript.
Hybrid workaround 😁
Aww... no generics or mapped types? :>
Preact compat
Interesting, but can it do the heavy lifting ts does? I.e. generating a type containing all possible property paths for a nested object, i.e. like this?
Basically the types live in a TypeScript declaration file so it's just TypeScript.
Clean separation between type space (TypeScript) and value space (JavaScript).
With that setup it is now possible to only perform static type analysis on demand. In this case it's used to arrive at "well formed JavaScript" while keeping the source under developer control.
That said you can arrive at a similar TS workflow with vite. esbuild transforms TS "blazingly fast" without doing any type checking. So you can worry about tests first, types second.
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.
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.
+1
Totally agree
well it says including...
In JavaScript there are no predefined methods to use namespaces.
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.
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!
Your first point is simply not true. New Engines like deno offer a runtime for direct TypeScript usage.
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).
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.
TypeScript decreased my anxiety but increased the time it takes to write code 😅
But it's worth it.
For me, the whole concept of TypeScript feel so much more like working productively than JS. This might change with the recent developments in ES2022 and ES2023, since many of TypeScript's loved structures (sadly not the Type System) find their way into common JS syntax.
That's only half the story, the perspective of the application developer.
"Publishing an extensible package with good TS support is hellish."
And yes, from the perspective of a package developer
If you write your package in TS it's just super easy.
So writing Redux from scratch in TS would be easy?
Perhaps try it yourself and then maintain it long term to see if you can say that with a straight face.
Even maintainers of libraries written from scratch in TS report that types significantly increase their maintenance burden.
Learning and Using TypeScript as an App Dev and a Library Maintainer
The big problem most of the time is, that most developer's dont do a complete rework of the code. They built a js to TS support. Typescript uses different Development patterns then JS. So if you try and work your types alongside with your js code, yes its super messie and hard to maintain. For example Angular and Vue did that big step with a major release and rewrote the entire framework in TS
If that were true, we could have had a much better language to begin with … like ReScript.
Unless of course your idea of better is "web development with C#".
"TypeScript began its life as an attempt to bring traditional object-oriented types to JavaScript so that the programmers at Microsoft could bring traditional object-oriented programs to the web."
[TypeScript for Functional Programmers]
If they are doing that then they are a waste of time.
Microtests cannot "verify correctness". They are there to detect unwanted change in system behaviour which is exactly what you need when you refactor.
In 2014 James O. Coplien published Why Most Unit Testing is Waste (part 2). Michael Feathers responded with one of his earlier articles The Flawed Theory Behind Unit Testing (2008).
"Unit testing does not improve quality just by catching errors at the unit level. And, integration testing does not improve quality just by catching errors at the integration level. The truth is more subtle than that. Quality is a function of thought and reflection - precise thought and reflection."
In 1996 Extreme Programming (Kent Beck et al.) used unit tests as a design/development feedback tool. This formed the basis of the Classical/Inside Out/Bottom Up/Detroit/Chicago school of unit testing in 1999. The emergence of mocking libraries gave rise to the Mockist/Outside In/Top Down/London school of unit testing in 2000 shifting the focus towards "correctness".
These days people are trying to divine the purpose of microtesting from the capabilities of the prevalent tooling alone, concluding it's about "correctness"—the original intent from 26 years ago has been all but lost.
@natescode tests do not validate implementation details, tests validare behaviour, which is just what you want to avoid changing when refactoring.
By the ctrl+f thingy seems that the testing concept is not so clear and you still thing that refactor is just "changing code".
If you added a third parameter to a function chances are that the best option really was to split it instead or if you run against the clock simply set it as optional instead and mark it to refactor in the future 🤷🏻♀️
The reason for tests is not to add "correctness" bit to add confidence in the code which is something that types alone can't provide.
Hi Nathan, I agree mostly with this, types are extra safety you add into the code at a cost of some burden in maintenance.
The issue comes with code like that
You've a sense of calm and safety because you added
:number
but we all know that contextual information about types is removed during compilation because we compile to pure JavaScript, which doesn’t know the types at runtime.This behavior does not provide any kind of safety mechanism against incorrect or invalid inputs, such as inputs from unhandled API endpoints, libs, form inputs...
TypeScript is not designed to provide input constraints that are at an advanced level of type safety.
You can add type guards, validation libraries or manual checks in critical paths, of course (so you can in JS, see (prop-types)[npmjs.com/package/prop-types] or (Joi)[npmjs.com/package/joi] as examples).
Another way to workaround that is simply to (avoid runtime errors)[softwareengineering.stackexchange....].
You can do the same with TS as well of course.
While 0 may represent a wrong result in this case
You may either design it on a way it's not important or return an arbitrary value that you can check in the caller or keep bubbling the "wrong value" if the path is not critical (i.e. does not alter business logic, doesn't have side-effects and so on).
On the tests thingy... While type check tests are considered trivial for static typed languages in some codebases, my experience (and probably yours as well) says that runtime errors/exceptions due to wrong types happen either be JS, TS, Java... so maybe they are not so trivial at the end.
Both things together (static type checks and unit tests) are a win-win in code confidence terms. If you're not ensuring types in tests (overall) maybe consider adding them through paths that are dependant on third parties or other repos just in case.
Refactor means to change the implementation details without altering the behavior.
The only way to ensure the behavior is through tests, hence you need tests in order to Refactor, otherwise you're just "changing code".
Then, if the code is tested there's few benefit on static typing, and even less if your code is documented properly (so you can know what a function/method expects as parameters and what it will return by simply hovering your cursor over it's name).
Edit: I recommend the book Refactoring Javascript by Evan Burchard, it may bring some light to this topic.
Are you kidding with
not being a full-featured programming language
What is missing?
At least this post is not a deep comparison.