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?

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.

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

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

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.

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.