Is TypeScript actually worth It?

• d2-playground

  23 62 6.5 JavaScript

  An online runner to play, learn, and create with D2, the modern diagram scripting language that turns text to diagrams.

  

if you're talking about the playground, I did the initial version in a weekend or so (https://github.com/terrastruct/d2-playground), which includes building a WASM version of D2 (written in Go), putting a text editor, some UI stuff like dropdowns/menu, hooking it up together, layouts and responsiveness whatnot.

If you're talking about D2 language itself, ~2 devs over 3/4 of a year.

• proposal-type-annotations

  101 4,086 4.7 JavaScript

  ECMAScript proposal for type syntax that is erased - Stage 1

  

My biggest fear with TS is people forgeting why TS exist in the first place and stop trying to solve the problem TS solves because it's already solved. It's not solved, TS is by far the best option, but its far from being ideal. Deno coming out of the box with TypeScript support and the JavaScript Type Annotations Proposal [1] gives me faith that we will grow past TS.

[1] https://github.com/tc39/proposal-type-annotations

• SurveyJS

  surveyjs.io sponsored

  Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

  

• ts-proto

  8 1,913 9.0 TypeScript

  An idiomatic protobuf generator for TypeScript

Re libraries incompatible with certain typescript versions - e.g. protobufjs fix - it’s been my experience that you want to try and only use compilers specific to each library and compile libraries separately. It’s unfortunate but the JS community often tries to run all JS for a project through the same single compiler tool chain, using one global version of the compiler instead of relying on and effectively linking the JS output for each library. Unless you routinely rewrite third-party libraries to match your toolchain’s expectations, you’re going to have a hard time doing that.

For a library that generates code, that’s a special case, as the code it generates must target a particular language version. You have three choices: 1. Upstream a fix as you propose; 2. Side-by-side install both TS 4.6 and TS 4.7 using workspaces or sub-projects and have some of your code compile with 4.6 and then link the results or 3. Find a replacement that is updated to 4.7. For example, https://github.com/stephenh/ts-proto has 4.7 support listed in its readme.

• DefinitelyTyped

  158 47,090 10.0 TypeScript

  The repository for high quality TypeScript type definitions.

  

That shouldn't happen https://github.com/DefinitelyTyped/DefinitelyTyped#i-want-to...

• TDungeon

  6 1,155 10.0 TypeScript

  TDungeon is a small adventure game that runs in the Typescript type system

I did not write the blog post, it was just a simple infer/extends non-trivial example explained in depth, commonly used in packages like express and so forth. TDungeon [1], a game running on the TypeScript type system, really showcases how powerful the type system truly is.

Why not C#? Probably because Anders Hejlsberg [2], lead architect of C# and core developer of TypeScript, wanted something different.

[1] https://github.com/cassiozen/TDungeon

[2] https://en.wikipedia.org/wiki/Anders_Hejlsberg

• flyweight

  9 489 7.2 JavaScript

  An ORM for SQLite

I wrote https://github.com/thebinarysearchtree/flyweight in JavaScript, not TypeScript. It generates TypeScript declaration files as it types SQL, which helps with intellisense support in VSCode. That is the only reason I use TypeScript.

I don't like TypeScript though, and would never write anything in it. I have a long history with C# and I came to conclusions about this topic a long time ago. I just prefer writing JavaScript, it is more fun and more productive.

Flyweight is quite a complex library. It parses arbitrarily complex SQL. This is more complex than most of the things people work on and claim they need static typing. It isn't millions of lines of code, but often those codebases aren't complex, they are just many independent components that in themselves are not that complex.

The amount of time I spend having to update the TypeScript aspect of my library is really quite annoying. Also, with regards to your point about libraries not including type information - this is also true for the actual native APIs in the browser and so on as well. For example, TypeScript doesn't recognise the "indices" property of regular expression matches.

• rescript-compiler

  94 6,453 9.5 OCaml

  The compiler for ReScript.

  

I find ReScript (https://rescript-lang.org/) fundamentally better than TypeScript. It has easy FFI and a sound typesystem. With Rescript you wont have any runtime errors, like you can with typescript. But compared to vanilla javascript typescript is a big improvement.

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

• proposals

  54 17,811 8.2

  Tracking ECMAScript Proposals

  

• React

  1,690 221,535 9.8 JavaScript

  The library for web and native user interfaces.

  

The TS type system is incredibly powerful, and I wish I could apply to other languages out there. The biggest annoyances with it come from the fact that it isn't its own language; you get runtime errors due to incorrect or out-of-date types (often maintained by people other than the library authors). Also, "any" and "unknown" types tend to sneak in via default generic arguments, vague external module typedefs, etc. These types can spread through your codebase, preventing the type checker from doing its job, and the "strict" mode doesn't do much about it!

Generally speaking, I have to be extremely careful with working on a JS/TS project. I use the strictest modes possible and enable as much linting as possible. I also use the type-coverage module and fail the build if the `any` type gets applied anywhere.

As another general complaint, NPM doesn't do enough to incentivize its users to release quality software. JS/TS has always been very trend-based and social, and even just running a few simple lints and prominently displaying a score on NPM would probably really help the community improve its standards.

Take pub.dev (Dart), for example. Here's a module page: https://pub.dev/packages/firebase_core. The score is displayed prominently, and if you click on it you get a full breakdown of how it was calculated: static analysis, up-to-date dependencies, and documentation (although the coverage is not 100% for this module, so I think it's wrong to assign full points). When you upload to pub.dev, you want a score of 100! It doesn't guarantee that the module is fantastic software, but at least the basics have been taken care of.

In my opinion, the most important piece missing from the score on pub.dev is test coverage. Take for example a page from Metacpan (Perl packages). Here's a module I've released: https://metacpan.org/pod/Algorithm::AM. On the left you see displayed the automated test results, including the test coverage, which has been submitted by volunteers who downloaded and tested the code on a variety of platforms and Perl versions. There's also link to a "kwalitee" page, which is similar to the pub.dev score (though this could be much improved by having an actual score and displaying it prominently on the main module page).

Now an NPM module: https://www.npmjs.com/package/react. What info do we have about the quality of the package? Essentially just the activity from the community (open PR's and issues, downloads). We have no idea how well it's tested, what kind of static checks have been performed, whether your editor will be able to display documentation or typing when you mouse over a method from the library, etc. (TypeScript is mainstream enough now that it should be fine for NPM to provide a bit of special handling for it.) Most 3rd party libraries are from individual authors and probably have very little activity. When deciding whether or not to use them, right now you need to dive through the code to check if the basics are taken care of. Having some of this automated would save a lot of time.

• protobuf.js

  1 15 4.8 JavaScript

  Protocol Buffers for JavaScript. Finally. (by apollographql)

  

> Can I just open an issue in the TypeScript repo for this sort of thing if I have a concrete suggestion?

My former colleague Arthur has already answered this one - but yes! If you have a concrete suggestion, that's fair game and we can brainstorm on the issue to think of something. We might not come up with something general enough to implement, but it's often a good seed to plant.

> which in turn broke a type used from ProtobufJS.

I am curious to hear what sort of issue you ran into. Was this the Apollo fork (https://github.com/apollographql/protobuf.js), or the original?

Suggest a related project