Amazing how many JS devs I meet (or work with) that are against the very idea of Typescript.
ie languages aren't nearly quite so important as the platform.
Stuff wasn't written in js because early js was a brilliant language - it was because the platform - the web - was brilliant.
Many have written 'better' languages that compile to js - https://github.com/jashkenas/coffeescript/wiki/List-of-langu...
and while typescript is one of the better, more supported ones, isn't it just another one?
Surely in the end it just adds complexity and fragmentation of the ecosystem?
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).
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.
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.
I can see if you want to write an Excel in the web - that you might have a complex code base - but surely that's the exception - not the rule?
So back to the statement of 'modern web = ts'
Isn't that wrong - these applications aren't really web - and are the exception, not the norm?
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.
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.
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.
Hence the statement modern web = ts is wrong.
Personally I used the zoom native client and not the web one.
I spend most of my time in offline office and not the web version
You might want to reconsider that; they have a pretty bad security track record: https://www.securemac.com/news/zoom-security-flaw-puts-you-a... https://talosintelligence.com/vulnerability_reports/TALOS-20... https://talosintelligence.com/vulnerability_reports/TALOS-20... https://blog.0patch.com/2020/07/remote-code-execution-vulner...
That's like saying don't use the web version cos your out of date browser can be exploited.
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.
Are you doing server stuff with it?
You could argue here there are much better languages and platforms for that.
> 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.
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.
The "blast radius" if you will with nominal type systems is just always much larger.
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:
Dec 8
-----------
9
10 AAA
11 AAA BBB
12 AAA BBB
13 BBB
14 CCC BBB
15 CCC
16
17 DDDDDDD
18 DDDDDDD
19
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?
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.
You edit a file and reload, no munging pipeline,
TS really is different from other compile-to-js languages in this respect.
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. :/
Typescript compiler supports (some) JS DOC
https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
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 it's name.
In the end, it's still a 'splitter' to quote Monty Python.
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.
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.
(I'm joking)
My issues are not with strongly typed languages, they're specifically with TS.
I still don't know how it's possible to safely, cleanly make a library that other projects can consume comfortably with just TypeScript.
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.
Couldn't the same be said for COBOL programmes and GOTOs?
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.
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.
Largely absorbed by modern javascript? ;-)