As a web-focused software engineer, I can safely say TypeScript is the best thing that happened to my work in the last decade.
Aside from the known direct benefits of safety and self-documentation, I've found over time that having a pleasant, smooth coding experience and producing elegant code required me to think differently. I work on a project with very complicated and overloaded business logic, but nowadays my code looks very... "algebraic"? state machines within state machines, exhaustive switches everywhere...
Maintaining and modifying such code has been a joy compared to the old ways. Most of the work is just adding a new member to some union or an attribute to a type, following the red trail fixing errors and voilà.
The real genius of it is that it's really not a "type" system at all: it's a contract system. The nearest thing like it was Eiffel. The new "satisfies" feature in 4.9 makes this even more clear. Honestly there's so much space to cover here, I think it's just going to keep getting better and better.
It's such a powerful complement to the "no rules" JS when you layer it on top. You really get to have your cake and eat it, too. I feel like there's another huge step to take in "layering" invariant checking on top of TS for QA/test systems... Imagine like "in all 500 of my tests, make sure this variable is an integer greater than 10 at all times no matter what". I'm waiting for this to show up
I’m curious what you’re distinguishing here. To me a type system and a contract system are identical concepts with different descriptions.
It seems like you might be highlighting the structural typing aspects of TypeScript’s type system versus nominal or concrete types in many others, but that’s been clear for most TS usage for since well before `satisfies` so I’m not sure if my interpretation is right.
I agree, there's doesn't seem to be any reason why you can't use types to express something like contracts. I think the general name for these kinds of types is 'refinement types':
"a refinement type is a type endowed with a predicate which is assumed to hold for any element of the refined type. Refinement types can express preconditions when used as function arguments or postconditions when used as return types"
There's even some literature linking contracts and types directly:
"Traditional static type systems are effective for verifying basic interface specifications. Dynamically-checked contracts support more precise specifications, but these are not checked until run time, resulting in incomplete detection of defects. ... This paper explores the key ideas and implications of hybrid type checking, in the context of the λ-calculus extended with contract types, i.e., with dependent function types and with arbitrary refinements of base types."
Traditional design by contract checks the contracts at runtime. They can be understood as a form of dynamic typing with quite complicated types, which may be equivalent to refinement types
But you can check contracts at compile time too. It's quite the same thing as static typing with something like refinement types. That's because, while with contracts we can add preconditions like "the size of this array passed as parameter must be a prime number", with refinement types we can define the type of arrays whose size is a prime number, and then have this type as the function argument. (likewise, postconditions can be modeled by the return type of the function)
Now, this Rust library isn't generally understood as creating another type system on top of Rust, but we could do the legwork to develop a type theory that models how it works, and show the equivalence.
Or, another example, Liquid Haskell: https://ucsd-progsys.github.io/liquidhaskell/ it implements a variant of refinement types called liquid types, which is essentially design by contract checked at compile type. In this case, the type theory is already developed. I expect Liquid Haskell to be roughly comparable to Rust's contracts checked by MIRAI.
Now, what we could perhaps say is that refinement types are so powerful that they don't feel like regular types! And, while that's true, there are type systems even more powerful: dependent types used in languages like Coq, Lean and F* to prove mathematical theorems (your type is a theorem, and your code, if it typechecks, is a proof of that theorem).
Dependent types were leveraged to create a verified TLS implementation that mathematically proves the absence of large class of bugs, miTLS https://www.mitls.org/ (they discovered a number of vulnerabilities in TLS implementations and proved that their implementation isn't vulnerable), and HACL* https://github.com/hacl-star/hacl-star a verified crypto implementation used by Firefox and Wireguard. They are part of Project Everest https://project-everest.github.io/ which aims to develop provably secure communications software.
I came to TypeScript from Clojure/ClojureScript, which in turn I came to from untyped JavaScript. At this point I’d say both Clojure and TypeScript had equally the greatest impact for me. Clojure helped me understand how to reason about managing state over time in a way I carry to everything I’ve worked on since. TypeScript helped me understand how to reason about interfaces between operations and guarantees about state over time, which again will be with me anywhere I go… in projects I maintain now which haven’t yet migrated from JS to TS, and if I ever get motivated to return to lisps for business or pleasure.
I've spent the last two years working with TypeScript solely. Coming from ~20 years with PHP and using Kotlin and Dart for some years as well, I feel that I'm doing something wrong.
I absolutely loathe working with TypeScript. The community is the most fragmented I've ever experienced, the silly amount of package managers, builders... TypeScript just doesn't fit with me.
You're describing issues with the underlying JS ecosystem. TS builds on that, and while it can paper over the language deficiencies, the libraries and frameworks are down to the larger community with its culture of constant churn.
Yeah — TypeScript is great in a vacuum, and if you’re working on an established project that’s got all the tooling configured perfectly it can be a pleasure… but if you’re starting from the ground up, it can be a god awful nightmare.
I think typescript is great but the heavy, heavy dependency on starter kits that come with a dozen build dependencies configured to within an inch of their life is a testimony to how much of TypeScript is voodoo.
Every dependency you add to a project requires new incantations and prayers and probably some sort of sacrifice.
Typescript itself is fine. But yes, if you are using 3rd party libraries and frameworks with typescript, you might wonder if it's too late to change career and become a monk.
It’s my impression GP doesn’t have a clear picture of where TypeScript ends and the rest of the tooling ecosystem begins. Which is totally understandable, especially given how pervasive TypeScript is and how it nearly totally overlaps with the rest. I think you and I have similar perspectives on the details, but you could be kinder expressing them.
I assumed repox prefers bluntness, due to their writing style. I was careful with the words and tone that I chose. Checking comment history, repox wrote that they are a Dane (which I didn't know). My experience of friends from other nearby countries is that their style of interaction can be seen as rude by many people. In particular my stereotype is that Americans often prefer a more gentle approach.
I think you are assuming I am not being respectful. However I believe that a blunt reply is definitely showing respect to them in this situation. I do need to be careful not to make comments that are personal attacks (or that could be mistaken for), which I certainly was not trying to do.
(To quote you: "you’re making the claim, you defend it. Otherwise the assumption is just, like, your opinion man." ;)
Hopefully repox can reply, although they don't often comment, so I would guess they are unlikely to check replies. Anyways, definitely off topic!
Hey, I mistake appropriateness of being blunt too. I’m autistic, so. I’m kind of impressed you dug through my recent comment history, even if the quote feels misplaced. Anyway feel free to be blunt with me, if you recognize me around.
But I’ll also be blunt when I notice a critique is probably misplaced.
To explain: I quickly scanned some of their recent comments to see if my assumptions could be wrong. When I noticed they were Danish, I then wondered if you were American, so I used hn.algolia.com to scan your comments for “American” as a keyword. You said you were, but at that point I luckily noticed the comment of yours that I quoted, which I just couldn’t resist cheekily passing back to you, because it fitted the discussion on comment quality at a meta level</smirk>.
I often write personal notes like this after the topic has dropped from the front page. If there are a lot of people still reading the comment threads, I try harder to not be a distraction to others and I try to keep on topic.
I really do appreciate your effort to keep my comment quality high - if we all do that for many comments (especially through voting) then the whole community benefits. I don’t realise when I get tone wrong. In this case I have been very slightly downvoted on both comments which is not usual for me - so your comment was an extra help.
The developer experience must be evaluated holistically, because languages don't exist in a vacuum. The JS tooling, libraries and community absolutely impacts on how it feels like to be a Typescript developer.
The Kotlin situation isn't comparable because there is an established community that uses Kotlin in the backend, without using Android.
But perhaps you could compare with Swift: while Swift may technically run on non-Apple systems, that's not the experience of most developers. So it's totally valid to avoid Swift because you don't want to deal with Apple and Xcode.
> Please correctly blame the ecosystem that you dislike, instead of thoughtlessly using a language as a label for an ecosystem.
While I understand your point, I can't help but feel like the two are connected.
I _do_ have some beefs with the language itself, though. The export syntax concept is awful, the overly flexible type system to which I still haven't seen the point with and of course the whole thing needs to be transpiled to actually run.
Minor annoyances, sure. Easily to blame my abilities and capabilities as the reason for not understanding and enjoying TypeScript. But the ecosystem really hits the nail and by working with TypeScript on a daily basis, I'm forced to interact with it.
The developer community is so fragmented to anything else I’ve experienced. Granted, I don’t know every language and their respective communities, but the whole NodeJS/TypeScript community seems to have no common direction whether it comes to dependency managers, coding styles, transpilers, bundlers or much about any other “best practice” paradigms. And this also something that is pestering packages and the maintainers. I don’t experience this vast amount of fragmentation in PHP, Python, Kotlin or Dart. Whenever you reach out to the community, you’re rarely met with more opinions than you have fingers and toes; sure - not all agree on everything, but there’s more often than not, a sense of consensus on what a common approach to any given problem could be. While I of course could just have been very unlucky for the past two years, the community is the main (but not the only) reason I will not work with anything related to TypeScript or NodeJS ever again.
> I can't help but feel like the two are connected. I _do_ have some beefs with the language itself, though. The export syntax concept is awful, the overly flexible type system to which I still haven't seen the point with and of course the whole thing needs to be transpiled to actually run.
They are connected, but almost exclusively in the JS -> TS direction: typescript imports are javascript imports, the type system is messy because javascript is messy (whether complete compatibility with javascript was a good goal is another question...), etc.
> But the whole NodeJS/TypeScript community seems to have no common direction whether it comes to dependency managers, coding styles, transpilers, bundlers or much about any other “best practice” paradigms.
If it’s just the tooling that makes you dislike it, the tooling is just as frustrating if you write plain JS. If you don’t have specific gripes with the TypeScript syntax and type system as such, I’d suggest trying just using it without any additional tooling (typescript as a dev dependency, tsc as the only build step) in a project amenable to that. The biggest downside is slower iteration when tsc itself is slow. But you don’t actually need all of the tooling complexity if that’s what you don’t like.
I tried to port a vanilla js browser game to typescript and I found it introduced a lot of complexity to the project. It sucked me into the npm ecosystem and forced me to rewrite every file to use js modules import/export syntax and a bundler like webpack to resolve all the modules business for browsers when none of those were needed before.
Of course I could set TS modules to none but then I lose access to typing of any third party libraries I'm using like PixiJS.
And my CI pipelines are like 10x slower now because I need npm to install and compile and bundle stuff which is really slow compared to my previous CI pipeline which simply concatenated the js files together with `cat`.
Does this sound right or an I missing something? What I want:
To be able to just type annotate my existing JS without needing modules, but also have TS be able to pull in type information of 3rd party libraries by pointing it to the appropriate .d.ts file. I suppose that's having your cake and eating it too in this case.
If I understand correctly, before moving to TS / npm, you would concatenate your library files and your own code, and in your own code reference libraries using some kind of global variable à la `$.` for jquery?
If that's the case, you could add the libraries .d.ts to your project and augment the global.Window interface with types pulled from those definitions. You would then be able to call `window.something` and have the correct type and should work after cat'ing everything together.
Which bundler are you using? If you don't need any of the advanced webpack / rollup stuff, have you tried a fast one like esbuild?
Yes, that's exactly right. I just include pixi.min.js which exposes the "PIXI" global variable.
> If that's the case, you could add the libraries .d.ts to your project and augment the global.Window interface
Do you know where I can find an example of this? I've been able to do "npm install pixi.js", which gives me access to the .d.ts file but I'm not sure how to then map those types to the global PIXI object exposed by pixi.min.js without turning everything into a module and doing an "import PIXI" from node_modules of some flavor or another.
> Which bundler are you using? If you don't need any of the advanced webpack / rollup stuff, have you tried a fast one like esbuild?
My bundler is literally "cat *.js > bundle.js" which works well. I have not tried esbuild, though I've read good things about it. I'm sort of gunshy about learning new js tooling like this though ever since I learned grunt and then gulp once upon a time....
Thank you very much for posting this! I just tested this and it does exactly what I wanted - to get full type checking including 3rd party libs without having to convert all my existing files to be modules. I owe you a beverage of choice-
I write a fair amount of Typescript, but it's frustrating to see it used so ubiquitously, when in a lot of cases it's just not necessary.
A strongly typed language definitely has a place in web UI development though. But my hope is to see it replaced by a WASM based language, or better still, a choice of WASM based languages.
If you look at how Python is used in 3D graphics (or similar DSLs in the more esoteric 3D apps), they've been using the scripting system in the likes of Maya and Blender to create inordinately complicated systems for decades.
Like 3D graphics, a lot of UI code is visual, ephemeral, complex. The development process for such features, benefits from from the speed of iteration and flexibility that dynamically typed code can provide.
Granted, a checkout, or a clinical case management form (for example) will definitely benefit from the kind of precision a strong type system will encourage.
Beyond that, we should think more about the how and why, because type wrangling can slow down delivery, experimentation, and cannot guarantee the prevention of bugs.
Gmail and Google Maps for example, at least when those projects started out, had no TypeScript in their UI code.
Google Maps, even in it's earliest iteration, far outstrips the complexity of most TypeScript applications in the wild today. And also has a greater requirement for precision than many of the applications that we can call to mind, outside of Finance, Transport, Construction, or Medicine.
People seem to talk as though certain applications were impossible to build without without TypeScript, but that is simply not true.
So TLDR, answering the root of your question, TS is not at all necessary. But it can be helpful. Yet we're in a position now where it's almost intractable, and I don't think that's an ideal situation.
It's very case-by-case if a rewrite makes sense or not. For a greenfield project you'll have a whole different experience and it's more of a no-brainer, moreso the less you depend on un(der)typed frameworks.
Typescript as a language isn't too bad but the ecosystem is an absolute dumpster fire. NPM is terribly fragmented, costs a fortune in effort to maintain dependencies, security updates etc... Every Typescript/JS project I work on is full of a dangerous amount of third party dependencies - it can be hundreds if not thousands in a single repo - many of them fragile in their own special way. Language packages management is hard - but it seems especially hard with TS/JS.
Typescript as a language is better than "isn't too bad", it's great! I love the syntax for unions and how normal things like "if" will narrow types.
But I agree that it's a shame that the JS ecosystem is such a mess. Granted, dealing with it is essentially Typescript's purpose, but I would love for it to be a full fledged language on its own, divorced from JS. How cool would it be if you could write normal backend apps in it and compile them to native code?
I use Deno a bit and pretend, but it's not quite the same.
I agree, I wish there was more incentive for developers (especially on the front end side!) to not install every package under the sun and instead be a little less "fancy" or aim for satisfying the 90% rather than the 100%.
That’s not a Typescript problem, that’s a modern JavaScript stack problem.
let Typescript have it’s win here… I want to hate it because I loath Microsoft so deeply, but it really has changed everything in the web world, I wouldn’t hire a front-end dev who couldn’t work in it now.
It's mashing things better by making lib authors like about their API.
jQuery typing showed what a shitty api it actually was. You had no idea what you'd get back f on a call, one element, an array, what type of element.
It made it impossible to build reliable software and why everyone hates jQuery now.
So many early projects had "magic" APIs to save you a few characters or lines of code, only to become a maintenance nightmares because without the docs (or TRYING to analyze source) you had no idea what it did or how.
TypeScript is the best thing to happen to web dev, and it keeps getting better. My only gripe is that sometimes in a codebase that is heavy on inferred types I need to restart the TS server occasionally. Nonetheless, unless there is a specific requirement that TS isn't the right choice for, it's the language I reach to for everything.
There are a lot of other great languages, but none of them run in the browser. Once you know that your frontend is in TS, there are a lot of advantages to writing the BE in it also. Like I said, there are exceptions, but it has become my default.
Great post/looking back at the core decisions/bets that worked out really well (from the post):
* "Impose no runtime overhead on emitted programs."
* "Align with current and future ECMAScript proposals."
* "Preserve runtime behavior of all JavaScript code."
* "Avoid adding expression-level syntax."
* "Use a consistent, fully erasable, structural type system."
I also really liked the callout of their approach to "innovating in the type system around conventions and patterns found 'in the wild' of the JavaScript ecosystem."
This "you can still write the JS-style APIs you want, just safely" is a stark contrast to the Dart/ActionScript/others options mentioned in the HN thread, which said "you have to give up the JS-style APIs you have, and instead write 'basically Java'".
It's also amazing how TS 1.x itself was "basically Java" (in terms of a type system, albeit except being structural), but so many of the TS 2.x type systems innovations (mapped types, conditional types, etc) look as if they were designed in the language from day 1.
One other point, the post calls out they didn't add extra syntax to JS, only types; in this regard, I think TypeScript frankly got lucky by how much JavaScript itself has evolved in the last 10 years. Like if JS had been going through a "10 years of sterility" period like Java did from ~2005-2015, then TS itself would have been greatly hindered and probably would have had to jump to syntax-level changes, like the Scalas and Koltins and other Java.nexts had to do.
So, kudos to JS itself for also evolving extremely well from its ~2010 everything-is-a-callback early days, and letting TS stand on its shoulders.
In most programming languages JS style APIs (i.e. give me anything and I will try to interpret it somehow in an undocumented or poorly documented way) are antipatterns. TS is often bringing sanity to libraries that switch from JS to TS.
I think TS team is doing really great job. I would not call it standing on the shoulders of predecessor, more like trying to build something stable on the swamp. JS definitely does not have a positive influence on TS.
TS is not a great programming language, but it is really great accomplishment considering that it supports and extends JS in a such good way.
Oh, I like this. A pure syntactic sugar over a language that otherwise preserves semantics is neat. Nice work on documenting what was kept/changed/removed too. Really easy to see at a glance what the project is all about.
Love that there's an online playground, LSP, and VSCode extension along with it.
Very cool! For years I've wanted to fork LiveScript and integrate it with the TS checker somehow (and remove `on/off/yes/no`, good call), sort of an F# to TypeScript's C#
Generally a huge positive. With tools like swc, there's really fast compilation & typechecking now. With --watch, the DX is pretty good but yeah sometes has to be restarted anyways.
A couple not so greats:
Typescript has added a lot fo confusion & chaos to the ESM transition. A lot of typescript code is in ESM style, byt if you pull the package, it outputs cjs or what not. TypeScript 4.8- very recent- is the first to actually have a semi-viable Node.js + ESM story going; being a respectably modern package hasnt even really been possible with typescript until just recently. Not fully typescript's issue, but writing a package.json that fully helps consumers is quite difficult, and there's a lot more to grol.woth typescript in the mix. There's such a long long tail of typescript packages that are going to be the long long hold up for getting to ESM cleanly. It's not that hard to change, but awareness is just low, and friction is high while we are still so stuck-in-the-middle. Typescript makes writing code easy, but outputting a good respectable usable library has been impossible & is still not easy. Woe.
I really hope EcmaScript does get type annotations, which could eliminate so much of the need to compile & let typed code just run untyped, elide so many of these difficult transpilation challenges.
Another major issue for typescript is that it is stil so compile-time focused, that type metadata isnt kept intact. It's wild to have such a vast typing system, but to just throw it all out at compile time. To be fair, object metadata in js has been tied to annotations, which has been long long delayed, a huge struggle for the language, so there's not clear targets for how to output type information, but there have been some goes, some works to add runtime type information to typescript & there's so little follow up, so little engagement. All TypeScript feels like such a sharply more limited less useful less ambitious project than what it should be doing, than what a real language+runtime would be. It feels like typescript lives in the shadow of a much more clear & visible greatness.
Hrrmmm. I've been using the newer Jest testing library releases & they are supposedly powered by SWC. I definitely see some typechecking errors, & assumed this was also swc. But I see little evident in the swc project they've made headway here.
Im not sure what Im experiencing in jest. It's definitely not the same level of typechecking. But there's definitely something there & it's definitely much faster start time. Thanks for writing; Im curious too.
When you can write a busy beaver machine in the type system, LOC ceases to be a good indicator or how long something should take to typecheck, imo. If you're frustrated with your build, you should use the trace tools on the TS wiki[1] to track down what types are slow to check, so you can attribute the slowness to the appropriate library authors/yourself and decide for yourself if the speed/correctness tradeoff they've made is right for you.
Personally, I find that I don't really need full type checking on every build. For most small changes, the errors shown in vscode are sufficient while editing, and then full type checking can be run occasionally when needed (and in CI of course).
Your IDE can be doing type checks on whatever file(s) you're working on, you can use esbuild or swc to compile to javascript to make sure it runs correctly, and you can periodically use tsc to fully compile and typecheck your entire codebase to catch anything that you somehow missed in the IDE.
> "Align with current and future ECMAScript proposals."
But they admitted namespaces, enums, and interfaces into the language (the latter becoming more and more confusing as type aliases got more expressive),
> "Avoid adding expression-level syntax."
Is "as", "is", or "satisfies" expression-level?
> "Use a consistent, fully erasable, structural type system."
And decorators. But this was very early on and they won’t ever do it again unless there’s a drastic change on principle and probably a reorg of global proportion. They categorically reject anything with runtime implications now, and to the point of decorators are actively working to align them with the standard as it’s approaching stability.
> and interfaces into the language (the latter becoming more and more confusing as type aliases got more expressive) […] Is "as", "is", or "satisfies" expression-level?
No. All of this is completely separate from the runtime and on a standards course to be treated effectively as comments.
> But the enums!
I’m one of the minority who actually likes TS enums, but I strongly suspect they’ll be deprecated, alongside namespaces, as soon as there’s general consensus around types as comments. The TypeScript team considers these mistakes and would very much like to be able to drop them. I’d welcome that too even though I quite like enums.
The fact is TS has considerable backwards compatibility expectations, and aligning their mistakes with their goals is great on principle but something which would require thousands upon thousands of hours of labor for people to accommodate.
I’m not affiliated with the team in any way but I’m almost totally certain they’d welcome a contribution that gets them closer to their stated principles where historical designs are entrenched, without breaking workflows for thousands of people and interrupting releases for millions.
Flow feels almost like the Betamax to Typescript's VHS - Flow is better technically in many ways (in addition to the things you mention, I miss being able to spread the properties of one type into another, rather than having to inherit from an interface), but in practice, in terms of engineering cost, it's so much more expensive that it's hard to justify using it.
Flow's team have made it clear [0] that they don't care about usage outside internal Facebook projects, so since Facebook (from what I hear) uses few external JS dependencies, support for library types is terrible - there's no practical way for library developers to ship Flow types with their library. The third-party flow-typed repository helps somewhat, but relatively few libraries are covered there, so in practice you'll need to write your own typedefs for most libraries you want covered.
When I worked in a Flow codebase, I enjoyed writing Flow types for things, but it was only ever fun in a sudoku-puzzle-solving, Zachtronics-game kind of way. The tools provided were technically enough to express whatever you wanted, but it always took some lateral thinking. TS certainly allows for the same kind of type astronautery, but as a non-library app developer you never have to resort to that; you can always fall back to something slightly less strict that covers you from most real-world problems without the all-or-nothing strictness Flow mandates. In the end I was the last holdout on the team advocating for not migrating to TS. The migration went well and the team was more productive for it.
It's fun to think about an alternate universe where Facebook gave Flow the investment and community support it deserved, and today it's part of a beautiful React/Flux/Jest/Flow/Reason ecosystem (eventually leading to a complete takeover of the browser frontend by Ocaml). For real work, though, Typescript gets the job done.
They messed up with contributions to flow-typed where they were not accepting partially done typings, ie. not having some kind of incubator. People would push stuff, others would fix it. In community run projects you need to focus on low friction, not perfectionism. That killed typing coverage while ts was growing like crazy. Typing coverage worked like magnet for ts vs flow decisions. So it killed flow in effect.
In practice I’m very happy with structural types. It provides all the safety I could wish for and slots in well with the underlying language and broader ecosystem.
Though I do miss an easy way to create something like a type Email of string, as it conforms to a set of rules. But that’s a small price to pay.
You can't use `instanceof` ie. for your error types, actually every time you use class that extends something - it'll not be typed correctly. Basically nothing OO/class/inheritance related is typed correctly. Flow does it correctly.
I've always been a big proponent of TypeScript, but does anyone else feel like the type system has gotten a bit too flexible? I recently had to fix some errors when upgrading packages on an old project, and it was not at all clear what was wrong by just reading the compiler output. For some errors, there were like 5-10 lines of confusing info/context, it felt like trying to understand the errors reported in template-heavy C++.
Honest question: why did TypeScript succeed while ActionScript 3.0, another ECMAScript-superset language with typing and OOP (and predates TS by a few years), is all but a distant memory? Is it more than just Adobe being a terrible steward of its tech?
With that said, TS is definitely a blessing; I recently had the privilege of migrating to it after having written a hobby project in plain JS, and the difference in usability between the two is night and day. But I can't help but feel that I've seen this all before years ago in AS3.
> Honest question: why did TypeScript succeed while ActionScript 3.0, another ECMAScript-superset language with typing and OOP (and predates TS by a few years), is all but a distant memory? Is it more than just Adobe being a terrible steward of its tech?
Microsoft and Yahoo voted against ES4 adoption at the ECMA committee, cause Microsoft had, what was it called again? Silverlight, Their flash alternative to promote so they weren't interested in improving Javascript in anyway. Due to Microsoft stupidity, carelessness for standards, the web lost a decade of improvements.
Adding insult to injury in that absurd era, Microsoft had its own AS3 implementation called JScript.net before C# became more popular.
I'm surprised nobody ever wrote a book about this saga, it's completely absurd and petty but there are plenty of stories to tell.
As a former Flash/Air/Flex dev way back in the day I agree, AS3 was a great language that JavaScript still hasn't fully caught up with in some ways but it was only really viable to author ActionScript within Adobe's endorsed editors and their Eclipse fork abomination. Being confined to the Flash runtime also made life difficult as a general purpose programming language. It was a rough development experience and no amount of language superiority would ever fix that.
Wasn't fate of ActionScript strongly tied to Flash? As much as some open source community try, they can't beat the full force of the investment done and talent assembled by Microsoft.
IMO the flash runtimes leaked memory and that made them bad for long-running applications.
I remember writing a long-running digital display app and the memory would balloon to the point where we would use a product (mdx/mdm?) to restart the flash player periodically.
I'm aware of how they were related... AS3 was based on ES4 ideas, and, as the major implementation of ES4, AS3 influenced the evolving direction of ES4. But ES4 was never really finished to the point where everyone who needed to actually agreed on it.
I think MS, who had a browser monopoly at the time, was never going to agree to something that made Adobe Flash more important. It seems crazy now, but at the time it seemed like a real possibility that browsers could end up mere shells for the real internet runtime, Flash Player.
The way TS stuck such an expressive type system in top of such a dynamic and somewhat clumsy language is nothing short of witchcraft. And as a dev it all feels so effortless.
TypeScript has lots of great features and a few bizarrely bad ones. It’s great in spite of itself.
The main misfeature is their dogmatic refusal to rewrite import paths (citing the “Preserve runtime behavior of all JavaScript code” principle mentioned in this article). Here’s a good summary of the problems this causes: https://github.com/microsoft/TypeScript/issues/42151
I’m curious, how many people are using TSC only for type-checking, and a different system (eg esbuild or ts-node) to actually compile/bundle/execute their code?
I think TypeScript would be even stronger if they focused fully on type-checking, and relaxed some of those dogmatic restrictions (and the many, many confusing config options) imposed by the JS code generator.
They're beginning to yield on file suffixes, and even have module resolution tracked on the 4.9 iteration plan. I agree it’d be better for them to focus on type checking but gratefully that’s what they seem to be moving towards with their types as comments proposal.
Someone please point me to a project using TypeScript that isn't an over-engineered steaming pile of excrement. Please. Enlighten me. I've yet to see one where the code is even somewhat mentally parsable. Abstractions galore, needless separations of concern, indecipherable build scripts that take forever to run, insane JS output and more. It's basically a write-only language extension where only the people actively working on a project can actually understand any of it.
Look at this thread. So many comments about how great the language is, but with the caveat about how horrible the ecosystem is. Think about that for a second and maybe you'll get it.
What is it about strongly typed languages that attracts developers enamored with their own cleverness? I'd rather work with Java. And I loathe Java.
Reading this thread gave me my first encounter with `satisfies`. While I love the concept, the syntax really bothers me. I'm used to seeing the type right after the variable name when it's being defined, not looking after the assignment for it. The placement after assignment almost seems to imply that if you `let x = 1 satisfies number` with an implicit "any" you could reassign x and have it satisfy something else further on in the code, which would be an unbelievably terrible antipattern. (I'm assuming you can't do that?)
To me it seems more logical to use something like a double-colon or some other syntactic sugar to imply `satisfies` when you declare a variable... and possibly a <Satisfies Classname> or just <Classname*> prepend for casting.
I overall like TypeScript. But one thing I have encountered in every TypeScript codebase I've worked on are types with a crazy amount of optional properties like this:
I'm sure there is some value to having this than not having it at all, but I find it hilarious the amount of times I'm writing TypeScript that I can't even trust the types given to me. Of course this isn't a fault of TS itself, but I think what TS has inadvertently done is give programmer yet another outlet to express their bad habits.
Sounds like a shitty function. Count your lucky stars it's at least statically typed! TS unfortunately can't solve people not understanding the benefits of a type system as it pertains to foundational design - they have to learn that on their own.
I switched this year to working at a company who uses typescript for backend systems after working as a python dev for 3 years.
It’s not that I hate it, it’s just that TS/JS does not give you anything in terms of built-ins. This testing suite is so fragmented, it’s this ugly thing that I dread working with.
Anyone have advice for repos I can use that have rich testing frameworks? Or books? I’d love to learn to love TS, but it’s not there yet.
am I the only one who hates typescript?... development time is extended because you need to create all the types / interfaces for every variable and function. And you blow up the already complex / almost unreadable code with type definitions.
Some of the definitions can be very complex, a dev needs time to decrypt what other dev wrote and what I can finally use as a parameter in a function. Sometimes even if you put the correct parameters, it still doesn't work, and you need to fiddle around with webpack or other config files or spend hours on google to find a possible solution for a "simple" thing.
I just want to create code and solution... I used to work on a project with typescript only, and it was a huge pita, especially because the ts was very complex. Never again typescript projects for me.
I don't "hate" TS. I understand how useful it can be. But I don't enjoy working with TS code - especially in large codebases which have been touched by many developers, each with their own understanding of how to use TS. When it comes to the world of professional web development it's up to me to adapt to the project's coding requirements, not the other way around.
TypeScript has always worried me a little because of MicroSofts old “EEE” policy but damn its just so nice to use. Building a complex JavaScript project without it feels wrong now.
Given the number of codebases littered with 'any', and the fact that TS is known to produce app bundles that perform slower than handwritten JS code, I'm in two minds about celebrating those ten years... But it is strange to think it's been ten years.
Do you have examples of slower code generated by typescript? TS is a superset of JS so it changing anything that has a large performance impact seems odd, but maybe I’m missing something here. The types aren’t even available at runtime, what’s the biggest slow down you’ve seen?
This claims that TypeScript is an order of magnitude slower than JavaScript, which is obvious nonsense if you know how TypeScript works, unless they counted transpiling in execution time.
> TS is known to produce app bundles that perform slower than handwritten JS code
Wrong. TS doesn’t bundle files. TS doesn’t produce code unless you target an earlier ES version than what you write, in which case there’s no way around it: native for-of loops and await/async will always be faster regardless of what you use to transpile it.
I think you’re confusing the tool with something else.
Const enums get completely erased by the compiler, and modules are a native js feature.
Non-const enums and namespaces are probably the only aspects of typescript that actually have any significance at runtime, but they get compiled into simple objects. The compiler output is very close to what you'd write by hand. Take a look at this compiler output here [1].
Unless you're constantly recreating enums and namespaces inside of a loop (which you'd never do in real life code), I can't imagine there'd be any performance penalty.
It can (depending on which features you're using), but the comment that started this thread claimed that the produced code was much slower than handwritten js. I was just pointing out that the examples you gave (enums and namespaces), don't change the performance of your code.
Aside from the known direct benefits of safety and self-documentation, I've found over time that having a pleasant, smooth coding experience and producing elegant code required me to think differently. I work on a project with very complicated and overloaded business logic, but nowadays my code looks very... "algebraic"? state machines within state machines, exhaustive switches everywhere...
Maintaining and modifying such code has been a joy compared to the old ways. Most of the work is just adding a new member to some union or an attribute to a type, following the red trail fixing errors and voilà.