Hardly just another one, and hardly fragmenting. It’s absorbed the vast majority of effort previously dedicated to Flow (the fragment in its own target space), and has continually gained in the JS community proper. It’s not just (or intended to be) a “compile to JS” language, it’s (almost) just annotated JS where the annotations provide additional tooling value.
The resistance in the JS community isn’t to “yet another language”, it’s to the perceived complexity of TS strictness/appeasing the compiler. I’m saying this not based on polling so obviously take it with a grain of salt, but I routinely search Twitter, GitHub and rando blogs for TS content and that sentiment represents nearly 100% of the anti-TS content I encounter.
And largely I find that in React-focused communities. Which having spent the last several years using TS on Node in production, and the last couple months working on a web project in React, it’s not remotely surprising. React and many libraries built on it have ridiculously complex types. That’s not because of TS but interacting with and satisfying those types at compile time is extremely frustrating even to me as a seasoned TS dev who has built libraries that take advantage of many advanced features in the type system (I just don’t expose that complexity to the API consumer).
Front end library type definitions are a nightmare because they are usually retrofitted onto code that uses JavaScript idioms that take heavy advantage of metaprogramming and it's dynamic nature. It's also compounded (in my opinion) by developers that insist on making everything inferable instead of just putting a few generic parameters here and there and saving an enormous amount of complexities. Native typescript libraries are generally extremely easy to work with, however.
I think many JS developers are also somewhat blind to the breadth of types of sites that are written, and so don't understand how valuable a type system can be on the web.
Most websites are what I'd call "broad and shallow". For any individual action the corresponding code path is small. Most code in these sites is easy to write and easy to debug in vanilla JS. Typescript adds boilerplate and compiler times for type safety the development team was doing fine without.
However there are some sites, usually very complex SPAs, that are necessarily "deep". Even small user actions absolutely must cause >10k lines of code to run. Type systems are often very valuable for the development of such sites.
It's my experience that some developers who've only ever worked on "broad and shallow" sites fail to appreciate what a time saver a type system can be for the right "deep" website.
In before someone comments: "But chances are you are not the person who needs something as complicated as TS therefore it's useless." and "If your code is more than a thousand lines then you're doing it wrong, all code should be <1000 lines that you throw out immediately and replace with new code".
Because applications on the web are increasingly that -- full applications.
I create scientific models and simulations for use in schools. Whether it's simulating a hurricane, or continental drift, electronics, or molecular interactions, the simulations themselves need to run on the browser, and all the UI that provides the users with all the affordances to interact with the model needs to also be written in JS/TS.
I think your questions are just revealing a failure of imagination/experience for what kinds of applications run on the web these days.
> it's no longer the web is it - just a way to deliver traditional applications
This statement is meaningless to me. What makes it "no longer the web?"
"The web" now includes fully-fledged applications. It's fine to make a distinction between things that are full applications and things that are close to blogs, if you like, but it doesn't change the fact that many people develop full applications for the web.
And I think this is clearly a lot more common you are recognizing.
The fact you ask this question gets at my point I think.
For several years I've been writing a large computer algebra system(CAS) that runs on a webpage. Every time the user puts some input into a text box the CAS runs. Depending on the input it may run as many as ~40k lines of code. There are no coherent lines upon which to split the CAS as far as anyone developing it can tell.
The CAS must run on the browser both to deliver on real time performance requirements and to keep server costs manageable (certain inputs will get even high end CPUs humming).
If breaking this SPA up is possible, it's not apparent even to engineers with >10 years of experience developing highly complex applications.
Other similarly complex applications run on the web, even if it's unusual.
The trick is to not break it up. Adding more lose ends will just make the ball of twine more complicated. What you can break out though is independent code that is the same for many apps, that code can be made into a module and reused across apps. Pure mathematical functions can be turned into a library.
But what could probably help keep your sanity for a CAS is to add a test case for every change to make sure the same input produce the same output in the future. As well as performance tests to avoid performance regressions.
> Surely in the end it just adds complexity and fragmentation of the ecosystem?
Lol. I switched to TS from pure JS a couple years ago and could never imagine going back. I am so much more productive in TS than JS:
1. Typeahead is crucial, and even when just working on my own projects it makes me much faster.
2. Refactoring is a scary nightmare in pure JS, but so much easier with TS.
3. I have yet to see any sizable, multi-person pure JS project not become an incomprehensible nightmare after a couple years. TS makes large codebases much easier to maintain.
There are other reasons.
If anything, the consolidation onto TS from previous competing type systems for JS (e.g. I think Flow is dead for all intents and purposes, and I've seen a number of projects migrate onto TS from Flow) results in less fragmentation.
Yes, in my current tech stack our entire backend is in Node with TypeScript, and the front end is React with TypeScript.
> You could argue here there are much better languages and platforms for that.
You could, but I think you'd be wrong. I come from a background of using Java on the backend for over a decade, then some time with various backend languages including Python and Ruby. This is the first time in my career when everything (front end and back end) are essentially on the same stack, and there are huge, gigantic productivity improvements to that. Most of it stems from it being easy for developers to switch between front end and back end code. E.g. it's very easy for front end developers to dig in and debug something that's not right on the back end, and usually to fix it themselves. Same thing goes for backend devs investigating how APIs are used by the front end. In all my previous jobs it was relatively rare (certainly not never but not that common) for devs to cross that divide, mainly because setting up the environment in a totally different stack was time consuming and annoying, and mentally context switching into a different language was difficult, if all you wanted to do was dig in on one particular endpoint, for example.
But even discounting that, I am much more productive in TS than I ever was with Java, primarily because the structural typing of TS makes thing much easier to refactor compared to the nominal typing of Java. Sure, there are some cases (mainly WRT scalability) where Java may be a better choice, but the idea that TS/Node is not an awesome choice for the server is outdated IMO.
>primarily because the structural typing of TS makes thing much easier to refactor compared to the nominal typing of Java.
That's interesting. This year I switched from server-side Java to server-side TS and I find that refactoring is incredibly painful when compared to Java. I think any productivity gains in the greenfield portion of a TS project are quickly offset by the pain of refactoring and debugging during maintenance. It's really disappointing, as I quite like TS.
I'm curious, could you give an example where refactoring is more difficult? I find TS much more easy to refactor because since the structural typing basically just says, for example, "This method argument needs to have these properties of these types", if I find out "Uh oh, this method actually needs one more piece of data", in Java I'd have to change the definition of the type that was passed in which could have lots more unintended side-effects, while in TS I can essentially "localize" my changes just to wherever I call that method.
The "blast radius" if you will with nominal type systems is just always much larger.
have you worked with GUIs much? complex interactive UIs take a surprising amount of code, doubly so if what you're doing isn't covered well by your platform/toolkit's native inputs.
i'm working on a webapp with a scheduling thing and even drawing a nice-but-not-interactive day schedule is a bunch of work. consider a day view that lays out overlapping events next to each other:
like, even laying out those boxes takes a bunch of code. and then you need interactivity, the actual "app" part - you want drag-n-drop that snaps to columns and switches you to another day if you drag it to the side, and selections, and menus, and hovery-popupy things, and undo, and so on... it adds up quickly
But you can split it with with web components and es6 modules to be sane without resorting to a pre-processor so you code won't run directly on the platform.
Have you seen the size of frontend codebases? Even modest SPAs reach into the tens of thousands of lines. Or the size of large Express.js driven backends? A huge portion of the web is driven by JS/TS.
>> Even modest SPAs reach into the tens of thousands of lines.
I still don't get how we got from fifty lines of code for a form with simple client side validation to a React/Vue/Angular/Next version that needs 100 different modules and a thousand lines of code to replicate. Why do people see this as a huge advancement in front-end development?
Because people are writing applications, not forms. As software engineering has gotten easier, customers have demanded more complicated applications.
Modest SPAs do have a lot of code. So does a C++ Win32 application that calls into some central datastore. The complexity is not a byproduct of languages or libraries, but rather the customer's complicated needs.
Those libraries are providing a lot more than just simple validation though. Bunch of advanced validation rules, masking, etc. I'm sure if you dive into any of those modules you'd be able to see why. Not saying there isn't dependency bloat but it's not like people are creating these for the sake of it.
As a daily user of IntelliJ IDEA—which, IME, has the best autocomplete and code suggestions of any IDE for dynamically typed languages—there is a world of a difference between the quality of suggestions for a codebase using TypeScript and one written in vanilla JS. Without concrete types, the IDE often has to guess the possible type(s) that a value can have, whereas with TS, there is (generally) no such ambiguity.
I don't really experience this issue and I use Web storm which is basically the same thing. I find that the dynamic type hinting plus the combination of using JS Doc formatted comments rarely leaves me with any ambiguity when writing vanilla JavaScript.
Unlike other languages, typescript adds zero runtime overhead, and the APIs that one writes in TS are trivially consumable from JS. Consuming JS from TS is also made as easy as possible, including the option to set types aside entirely for some parts of your code using the "any" type, which means "don't type check this, just trust me that it works".
TS really is different from other compile-to-js languages in this respect.
It adds overhead on initial write, saves massive overhead every day after that.
There is JS code I deal with once a month where the manipulation of types is so complex I probably burn ~30 minutes every time I have to touch it. If that was was transformed into TS (which is going to happen eventually) that'd be 30 minutes saved per month, on this one particular flow of data.
I've done refactorings that were only possible because TS existed.
A lot of JS unit tests consist of "ensure these fields exist on this object after it has been called by these functions."
Typescript removes the need for those tests.
And it removes the need to update those tests every time the code changes (just change the declarations appropriately!). And it removes the need to run those tests on every commit.
That said, the overall code/compile/run time savings is possibly not in TS's favor due to how slow the compiler is. :/
So you can use the compiler as a static analysis tool without buying into the language itself completely, which I do and just stick type definitions to comments when needed.
> Though the attempts at close compatibility mean it's not properly type safe despite its name.
Every type checked language I've used, from Haskell to Java to Idris to C++ to Rust has ways to override the type checker (and either do the type checking at runtime, or, as C++ is often want to do, just YOLO it). It's not just the language but the codebase and the norms it and its dependencies use.
Some TypeScript codebases, the types are usually accurate, but not enough to rely on them, so you still need to do runtime checks in many places. In others, if something says (string|null) then you know with confidence that it is either a string or the null value, nothing more and nothing less.
Pretty annoyed with Typescript too. Mostly because of its popularity.
Before Typescript most compile-to-js languages existed in their own world. You might have not liked them. But you'd never have to deal with them.
Typescript has become so popular that many top javascript libraries use it too. Whatever you think of it, sooner or later you'll be working with Typescript code.
It's terrible. The amazing issues that TS can introduce to a codebase are terrifying, and TS has breaking releases on a regular cadence. As someone who has to do maintenance on a legacy TS platform it was miserable and literally involved flipping through TS versions to find one that worked.
My issues are not with strongly typed languages, they're specifically with TS.
What issues does TS introduce into a codebase that weren't already there? This sounds kinda like arguing that if we write fewer tests we'll have fewer bugs.
In our case: 1) slow and long transpilation times, 2) although not that common these days but missing typings used to cause some head scratch 3) overly permissive/overly restrictive type definitions 4) wrongly configured sourcemaps 5) unreadable type definitions/declarations... The list is long but these are off the top of my head
Getting a configuration together that consumes all your dependencies and generates code without crapping a ton of meaningless warnings about duplicate type definitions in its own type mappings for runtime types is non-trivial and requires setting more than a few non-default compiler options, none of which are named anything that means anything.
I still don't know how it's possible to safely, cleanly make a library that other projects can consume comfortably with just TypeScript.
I've been thinking a lot about why this is, and I think one reason is because TS adds mental overhead to the language, while simultaneously removing other mental overhead.
However, for JS programmers, worrying about types is habitual. Offloading that task to a robot is great, but it doesn't mean the habit will just disappear. Thus to them, TS seems to mainly add overhead.
Yeah I guess I'd generalize it as programming having two kinds of learning. First is memorization of syntax and semantics of the language. Second is a kind of shadow learning, or "street smarts" for survival in the language; which parts of town to avoid and which paths avoid dark alleys, etc. These habits are hard to quantify, and beginner programmers especially tend to apply the "street smarts" from their first language to every future language, which creates problems.
I've spent enough time converting nearly illegible coffee script back to JS that I didn't want to do it again. I believe TS has its has benefits, I just don't care.
In that JavaScript only needs to adopt a few of its features for the benefits of welding yet another compiles-to-JS toolchain on to projects to dwindle in comparison to writing ES8+.
The difference between CoffeeScript and TypeScript was that CoffeeScript offered syntax that people preferred, whereas TypeScript provides write-time checking of errors. It is more similar to ESLint in that regard, and is better understood as a linter than as a separate language like CoffeeScript.
Even if TS's type annotations would be added to the language (like it practically almost has been, through Babel supporting it), you'd still want to run a tool as you write it to actually check that those annotations are adhered to, rather than having your code crash on the user when they are not. TypeScript is that tool.
Python already does type annotations, and I have no use for Mypy other than using it for type checking in my editors via LSP. I don't import it or use it as a dependency at all in projects.
I feel like JavaScript adopting type annotations in a similar manner will make TypeScript look the same as Mypy in many regards: nice to have, but not necessary most of the time because the parent language ships with most of its features.
