DEV Community

TypeScript vs JavaScript🤔

Archit Sharma on August 04, 2022

NOTE: Debate on comment section TypeScript vs JavaScript is one of the most controversial topics in tech. Some developers prefer TypeSc...

Read full post

Volodymyr Yepishev • Aug 4 '22

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.

Archit Sharma • Aug 4 '22

Yup the type system in TypeScript really helps detecting errors at compile time and JavaScript isn't as complex as Typescript.

JoelBonetR 🥇 • Aug 5 '22

Hybrid workaround 😁

Volodymyr Yepishev • Aug 5 '22

Aww... no generics or mapped types? :>

peerreynders • Aug 5 '22 • Edited

/**
 * Factory for the core structure of a suite
 * @template {object} [U = Record<string,never>]
 * @param {import('./internal').State<U>} state
 * @returns {import('./internal').Context<U>}
 */
function context(state) {
  return {
    tests: [],
    before: [],
    after: [],
    bEach: [],
    aEach: [],
    only: [],
    skipped: 0,
    state,
  };
}

Preact compat

Volodymyr Yepishev • Aug 5 '22

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?

peerreynders • Aug 5 '22

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.

Jon Randy 🎖️ • Aug 4 '22 • Edited

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.

FJones • Aug 4 '22

I'd also add that the intro is very reductionary:

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.

JoelBonetR 🥇 • Aug 5 '22

Jon Randy 🎖️ • Aug 5 '22

Totally agree

Archit Sharma • Aug 4 '22

This kind of thing is readily available for JS also.

well it says including...

Not entirely sure what you mean here, but modules are fully available natively in JS.

In JavaScript there are no predefined methods to use namespaces.

JoelBonetR 🥇 • Aug 5 '22 • Edited

Namespaces are a paradigm and not a "feature".

var truck= {
  start: function () {
    console.log("Truck in Started!");
  }
}

var bus = {
  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.

Jon Randy 🎖️ • Aug 4 '22

If they both 'include' it, how is it an advantage?

Archit Sharma • Aug 4 '22

Actually main point over here was -

Excellent tools support

Although I get it what you wanna say
Thanks for fact checking!

Jonas Pfalzgraf • Aug 5 '22 • Edited

Your first point is simply not true. New Engines like deno offer a runtime for direct TypeScript usage.

peerreynders • Aug 5 '22

The JavaScript engine is still V8 — so it "runs" JavaScript
For performance reasons TS is only transformed, not type checked, when it is initially loaded.

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?

Jonas Pfalzgraf • Aug 5 '22

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.

peerreynders • Aug 5 '22 • Edited

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.

Jonas Pfalzgraf • Aug 5 '22

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.

peerreynders • Aug 5 '22 • Edited

Typescript is a superset of JS.

"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.

They take the usual "watch and compile" Step away. Its just another step in the evolution of Code.

It confuses design time and runtime; yet another concession to developer convenience (by developers nonetheless).

If you want to use bytecode in the Browser, take a look at WebAssembly.

zack

@zack_overflow

Rambling about why WASM web frontend frameworks can't be faster than vanilla JS frontend frameworks (at least right now):

16:34 PM - 27 Jul 2022

Jon Randy 🎖️ • Aug 5 '22

Then that is a TS runtime. OP refers to browsers and JS engines, which is what I was addressing.

Jonas Pfalzgraf • Aug 5 '22

Deno IS a JS runtime with full TS Support. For browsers, there are certain experiments, but nothing productive these days.

Andrew Baisden • Aug 8 '22

TypeScript decreased my anxiety but increased the time it takes to write code 😅

But it's worth it.

Jonas Pfalzgraf • Aug 5 '22

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.

peerreynders • Aug 5 '22

the whole concept of TypeScript feel so much more like working productively than JS

That's only half the story, the perspective of the application developer.

"Publishing an extensible package with good TS support is hellish."

Theo - ping.gg

@t3dotgg

One last addendum because it's important:

The Typescript experience I shill here is NOT the library builder and maintainer experience. Publishing an extensible package with good TS support is hellish.

Those maintainers are a huge part of why TS is great, we owe them.

03:07 AM - 08 Apr 2022

Jonas Pfalzgraf • Aug 5 '22

And yes, from the perspective of a package developer

Jonas Pfalzgraf • Aug 5 '22

If you write your package in TS it's just super easy.

peerreynders • Aug 5 '22

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

Jonas Pfalzgraf • Aug 5 '22

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

peerreynders • Aug 5 '22

Typescript uses different Development patterns then JS.

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]

peerreynders • Aug 5 '22

Tests validate implementation.

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).

Michael Feathers

@mfeathers

‘Why Most Unit Testing is a Waste’ by @jcoplien. My answer: not if seen this way: michaelfeathers.typepad.com/michae...

15:35 PM - 06 Mar 2014

"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.

JoelBonetR 🥇 • Aug 5 '22

@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.

JoelBonetR 🥇 • Aug 6 '22

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

  function add(a:number,b:number):number {
     return a + b 
 }

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....].

const add = (...args) => args.reduce((p, c) => (Number.parseFloat(p) || 0) + (Number.parseFloat(c) || 0));

add(true, 3) // 3
add(false, 3) // 3
add('hey', 3) // 3
add('hey', true) // 0

You can do the same with TS as well of course.
While 0 may represent a wrong result in this case

add(1, -1) // 0
add('hey', true) // 0

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.

JoelBonetR 🥇 • Aug 5 '22 • Edited

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.

decker • Aug 5 '22

Are you kidding with

not being a full-featured programming language

What is missing?

At least this post is not a deep comparison.