Porting a React Front End to TypeScript | Hacker News Reader

Porting a React Front End to TypeScript

executeprogram.com

72 pointsgary_bernhardt103 comments

You can get a lot of the benefits of Typescript in VSCode without leaving JavaScript behind by using JSDoc.

Typescript will pick up the JSDoc type annotations and use them to type the code. This can be a great option when typing an existing project.

Docs: https://www.typescriptlang.org/docs/handbook/type-checking-j...

Vanilla VSCode also has surprisingly good code inference for Javascript/Typescript.

Recently, Typescript was complaining about an implicit `any` even though the VSCode tooltip clearly could infer the actual type (it confusingly was showing both cases in the tooltip). I finally realized that VSCode's built-in inference worked here but Typescript didn't work at all because I forgot I was importing a .js file rather than a .ts file.

VSCode for course also downloads @types/* files in the background even in vanilla JS projects which is super helpful because you get effortless intellisense. That it does this kind of stuff out of the box is the sort of reason why I've lost my Vim/Emacs fanaticism over the years.

VS Code's JS support is actually still powered by TypeScript. I'm not 100% sure exactly what you were experiencing, but it's intentional that VS and VS Code automatically download types when powering JavaScript contexts because we try to make things "just work" for JS users.

I don't think you are saying anything in conflict with me.

VSCode tries to give you type info in contexts where Typescript wouldn't (e.g. importing Javascript files, in a completely non-TS project) so it makes sense that its inference tooltip can be more helpful. You can easily recreate this by importing a fn from a JS module and then hovering it in VSCode (also configured for Typescript): VSCode knows the fn signature but Typescript won't. Both cases show up in the tooltip (though confusingly).

At least, that's my interpretation of this sort of tooltip: https://i.imgur.com/lXS5teK.png

And to be clear, your last sentence was my exact praise for VSCode at the end of my own comment.

> intentional that VS and VS Code automatically download types

Are these coming from DefinitelyTyped?

Indirectly, sometimes. They come from npm, but the largest chunk of type packages for libraries that do not provide their own types on npm are serviced from DefinitelyTyped (via the `@types` organization and its long tail of shadow packages).

You can get a lot of this nice behaviours in Vim with coc.nvim (if you can get past the awful name). It uses VSCode's language server behind the scenes to offer similar auto-complete / tooltips.

It doesn't auto-download @types, but it does suggest them to you. It can also auto-import, rename across files, etc.

Unfortunately, I've found at my previous employer that JSDoc is incredibly limited and fails at some basic structures, has very limited generic support and will not understand "advanced" structures like type mappings.

Re-using types (structs or union types) is also a huge pain.

I’ve found this React + TypeScript cheat sheet extremely helpful while recently porting a React codebase to TypeScript. (To the point it’s one of only four bookmarks on my browsers bookmark bar.)

Perhaps others here will find it useful as well.

https://github.com/typescript-cheatsheets/react-typescript-c...

Same here, combined with a bunch of curious looks at the DefinitelyTyped repository pull requests: https://github.com/DefinitelyTyped/DefinitelyTyped/pulls

Ahh this is great, thank you!! :)

It seems that I fundamentally misunderstand the benefits of TypeScript. I found myself spending hours and hours on reading the type errors stacktraces and adding types for libraries. Writing TS code takes 2x time than simple JS... and it is extremely painful experience. In comparison to many old plain JS projects I did - it simply doesn’t make any sense, the TS solves problems which I haven’t experienced at all.

It's helped me immensely, however the projects I work on get millions of hits a day (I’m in publishing/adtech). More eyeballs means more chances for an edge case to pop up. It's been worth it alone to catch undefined errors at compile time. I'm also on a team of 5+ front end engineers, though and use other team’s internal libraries often, which is probably why it's made a difference.

If it seems more hassle then it's worth for what you're working on, the rest of your team isn't bothered, and your clients are happy you don't have to worry too much. I still throw in vanilla JS on other smaller projects every once in a while for those reasons.

Yes - there are some pain points - but my experience is that the 2x is worst case. It gets MUCH closer to 1x with experience, and I'd dare to say it will be closer to 0.75x over the long term.

As soon as a significant portion of the time spent tackling a new feature or addressing a bug becomes reading code (which you may not have written) the types pay off to at least[1] a 0.75x time-multiplier, and I'd say that's very conservative. It also makes it a hell of a lot easier and faster to collaborate on different parts of a feature that interact without exactly overlapping—"here's the interface I expect to implement, code to that, if anything changes TypeScript will tell you without our even having to talk (about that)"

[1 EDIT] at most? hahaha.

Where I've found that TypeScript is a hindrance is where I want to code fast/lazily.

E.g. if I need to add a Bar property to a Foo object, in plain JS you just do it as and when you need to without any extra hassle. This makes hacking something together really fast and low-friction which is nice.

Typescript wont let you do that though - you need to go off and define the Bar property on Foo which you might argue slows you down, or seems inappropriate if you only need Bar in certain circumstances and not every time or whatever.

Personally I find that the extra rigor that Typescript forces is way worth the extra hassle - it prevents so many subtle bugs, makes refactoring a lot easier, helps multiple people work together on the same code in a sensible way, and IDEs work so much better (in my experience at least).

Most popular libraries by the way all have the types defined already - check out https://definitelytyped.org/

I'd disagree with that - and say this scenario is where TypeScript saves me time.

I just want to add a property to an object. All I have to do is add it to the definition, and TS will show me every location I have forgotten to set the Bar property, which means I can be confident it is set, so I do not need to write extra code that tests whether Bar is set.

> TS will show me every location I have forgotten to set the Bar property

Yeah this is what I was getting at - e.g. say I have 5 functions that all return Foo object, and for just one of them I need to add in an extra Bar property then I need to make sure that all 5 functions also do the Bar property, even if only 1 needs it (or make it optional, but that might screw with the semantics of the one function that does need it). So now I have a Bar on all Foos, even though only 1 function needs it - things start to get messy.

The alternative to changing all 5 functions is just to create a separate type for just that one function that needs Bar

Either way it is "extra work" if you are used to the fast and lose javascript way of just adding it there and then and not caring about the others.

I agree though that TypeScript is way superior as you point out it would just tell you where you screwed up and I would always start with a new TS project rather than JS today, but I still think there is a place for the raw & dangerous world of untyped JS for rapid and unsafe prototyping and hacking where TS can slow you down.

If it's just one property, you could specify it's optional using a question mark instead of creating an additional type:

  type Foo = {
    Hello: string;
    Bar?: string;
  };

But if you really need separated types, the extension syntax is so short that you could define it in the function definition directly:

  type Foo = {
    Hello: string;
  };

  function hello(myparam: Foo) {}
  function world(myparam: Foo & {Bar: string}) {}

I run the type checker separately from the compiler, which is set to ignore type checking.

So in development, I am hack together things and though the type checker complains and my IDE shows plenty of red marks, it will still compile.

Once I’m don’t experimenting, I fix the type errors, and refactor.

Me too. My "dev" script compiles regardless of type check (often I do have it display warnings/errors), and the "build" script explicitly does not compile unless it passes all type checks. It works well for my workflow, sketching quickly until it shapes up, then fill in the details to edit and refine.

No: If (typeof x === 'string') {}

I personally love TypeScript, but I do have one big hang up. Janky builds in testing. Can't explain it, but sometimes the guarantees TS is supposed to provide don't compile over. Mainly while using nodemon or another auto compile. Have only ran into it a couple times, but it mainly crops up during module linking.

Also keep in mind you can use as modules via require('') and skip adding types to a js lib. Be sure to add --module commonjs or the equivalent in config.

Why I like TypeScript for myself is writing modules and api's. Mainly: inline documentation. And the pursuit of more of a deterministic outcome in your programs. Still the linking issue bothers me.

Writing statically typed code will always be slower than writing dynamically typed code.

People don't use static typing for writing code faster, they use it for code that can be READ (and understood) much faster, especially by somebody who doesn't work with that specific piece of code every day.

I think it's generally agreed that in most situations, reading code is much more common than writing code, so static typing really make sense.

> they use it for code that can be READ (and understood) much faster

You nailed it.

I agree, this is the biggest benefit of static types.

I worked at on a several hundred thousand line JS code base at a company, and people were passing objects around, and it was extremely painful to trace code and figure what the structure of the object was. I had to set a breakpoint in the browser, and inspect the object during runtime. Moreover, some fields would randomly be missing, because the field wasn't necessary for that instance of the object. It was infuriatingly maddening.

I ended up spending a lot of time adding Flow types to it, of the form:

    type Foobar = {
        someField1: string,
        someField2: number,
        someField3: Baz,
        fieldThatIsNotAlwaysThere: ?Qux
        ...
    }

The untyped state of the code base gave me an extremely hard to resist to add Flow static types wherever I could. I also added a step to the pipeline (with my manager's support) that would break the pipeline and make it impossible to merge new code, if it didn't have Flow static types (and I used flow-coverage to make sure the "any" keyword wasn't being used excessively to side step Flow type checking). I was told by some of my teammates to stop forcing types down their throat. I eventually spent so much reworking large parts of the code base, and adding static types to it that my other work suffered (and I wasn't putting as much time as I should have into it), that I was told to stop spending so much time on adding Flow static types. But it was hard to resist the temptation. When I had to implement a new feature / change a file, I would add Flow types to it, and then be drawn to adding types to the various other files that it connects to (imports from, passes data to, etc). They fired me in the end, for that (not prioritizing the things I was supposed to do well enough) and other reasons (was going through relationship issues and eventually a bad breakup, which caused associated psychological/personal/self-care issues).

I've learned my lesson. Dynamic types aren't my cup of tea, and I find dynamically typed code to be repulsive and quite nauseating.

Maybe the real lesson is you should have done your work instead of let management get pissed with you for horsing around with types the whole day?

Maybe he should have looked for a job at a shop that wasn’t a bunch of Wild West hackers writing unmaintainable code?

> some fields would randomly be missing, because the field wasn't necessary for that instance of the object

This problem can occur in statically-typed languages too, such as if you have a class to model your entity, but in this instance you only need certain fields to be hydrated. The other fields may be set to null.

This might only a problem if the half-populated instance is 'leaked' to somewhere that expects a fully hydrated instance. Thinking about it though, it's possible that null could also be used to represent a null held on the database, rather than not hydrated.

The ideal solution would I suppose be to roll your own type for this semi-hydrated data, but that's not always possible/convenient.

Example: https://github.com/microsoftgraph/msgraph-sdk-dotnet/blob/de...

Typescript makes it convenient to roll your own type-

`let draft : Partial<Foo>;` says that 'draft' is shaped like a Foo, EXCEPT all of the fields are optional.

If you try to access a field on draft that doesn't exist on Foo, it's a ts error. If you try to pass draft to a function that takes a Foo, it's a type mismatch.

"most situations" don't apply to specific situations. I write code so the computer executes it most of the time, and the times I wonder what type something is is practically never. It's simply not an isse. The real hard bugs I encounter are always logic errors no compiler would catch.

I would love to have static types in JS, but not at the expense of node.. and not just so people who are in different situations than mine are happy, because I act as if I was in their situation.

> I would love to have static types in JS, but not at the expense of node..

What do you mean by this? I use TypeScript with node all the time.

I worded that badly, I meant "at the expense of having to run node".

What's the problem of running node for your developer tools?

> Writing statically typed code will always be slower than writing dynamically typed code.

Only in the beginning / short-term when the project is new, small, and fits in your head.

IMO doesn't take much more code and complexity for it to switch over to statically-typed code being faster to write.

As an extreme example, I run an online strategy game implemented in Elm. The game only supported three melee classes but the community made really good points about how ranged classes should work.

I came back to a codebase I hadn't touched in over a year, picked a spot in the code where I knew my physics would have to be updated to handle projectiles, started implementing it, and I basically followed the compile errors until my physics system supported projectiles.

Had it been dynamically-typed, this kind of refactor/overhaul would have required me to recredentialize in much more code and either rewrite tests and/or manually test my code branches at runtime to track down errors. It would have taken much much longer.

Hey all, I work on the TypeScript team. I've been super happy to read some of the posts about the migration on Execute Program. If anyone has any feedback or questions on TS, I can also try to answer them.

Noticing the time when you posted your comment -- how big is the TypeScript team, and how many time zones does it cross?

In total there's roughly 20 people, more or less split between core compiler/language service and VS editing scenarios for JS & TS. We also work pretty closely with the VS Code team on their integration.

> Noticing the time when you posted your comment

Uh, I am just kind of a night owl. Most of our team members work out of Redmond, WA, and our distributed members are either on the East or West coast of the US.

I'm not saying I never ever run into bugs due to dynamic types such as method/variable typos, I just think it's much more rare than people make it out to be. If that sort of thing happens a lot in a project you basically have very little tests. I'm confident in saying it happens to me maybe once in a few months - and that's working in a super dynamic environment of Rails. The Null error does happen, but that happens in java as well.

But how often do you forget what properties are required for the config object that is the third argument to your function?

I'm not saying it never happens, I just really need to think hard on when it last happened. You're talking about a method that requires a certain param but doesn't raise an exception if you leave it out and then behaves in a buggy way. Again, not something happening a lot.

Everytime I construct that object I'd have to look up what the fields are, either docs (lol yeah right) or by looking at previous calls.

Bonus if my previous usage was incorrect and I didn't notice and I end up copying that same mistake again and again!

TypeScript saves me probably 15+ minutes a day of just switching back and forth looking up what parameters are needed.

It is a one time tax to make everything I do more pleasant.

btw can't you potentially write methods that receive arbitrary number of arguments in java as well? https://docs.oracle.com/javase/1.5.0/docs/guide/language/var...

You’re referring to a variadic function, which can be written in most modern languages.

The commenter you are replying to is talking about a function of fixed-arity, with a config object with required props. Which props are required? A Typed language will tell you immediately “for free”.

Tests are only as good as the person who writes them. Typescript is just another way to build confidence in your codebase. I have found it to be an invaluable tool in large projects especially on teams with various levels of experience.

Well code in general is only as good as the person who writes it. You can write static code that compiles and doesn't work at all, you still need to test it. Only in static languages testing it become way more complicated.

What are the types of tests you’d need to write in a statically-typed language that are more complicated than their dynamically-typed counterparts?

A big benefit with static typing is the ability to refactor easily. It takes time to get design and code right, in a way that captures the requirements well as well as code quality. With static typing, you get immediate feedback while you tune your code.

Most of the popular large JS projects have switched (or are switching) to TypeScript (or Flow for React, though they'd have used TypeScript today). So that supports the argument in favor of TypeScript.

I don't know the js world that well, can you provide links that show most js developers use typescript? There are arguments for both. There are still millions of python/php/js/ruby devs and codebases that use dynamic code. It could be that in javascript the gains of types are more felt than in Ruby/Python. '' + [] will raise an error in Ruby and probably python too.

> can you provide links that show most js developers use typescript?

They didn't say most developers had switched, they said most large projects have switched

Not having to go to the code and investigate what the types of am object's fields are. That alone can make TS worth it.

Heck just getting auto-complete on an object's members.

Also any sort of combinator usage or functional programming reminds me of why static typing is so useful.

A few layers of higher order functions / combinators and I don't remember if I have `value` or a `{ value: value }` container (like map vs flatMap). Or which stage of the curry I'm at. Oh right, I'm at foo(a, _, c) but thought I was at foo(a, b, _).

If you can't even remember the last time you've encountered a runtime error, you are by my definition writing trivial code or not writing much code at all.

If you need autocomplete for your object, that's a sign your objects are probably a bit too big.

Yes. I'm part of a long term support team - teams do their work and transition it to me. I support a lot of solutions at once, none of which I've built or been able to spend a significant time getting into the guts of. Having the code do a lot of the investigation for me is incredibly valuable. It helps me quickly build a mental model of the small slice of the code I'm dealing with.

Tests are a very poor and verbose duct-tapey replacement for succinct and powerful static type information.

Static types massively make it easier to understand new code. I can actually see the structure of the data that's getting passed around, with types.

Huh? tests are there to make sure your code behaves correctly, e.g it works. Don't you do that in static land?

You write tests for things that actually matter ... like you know, testing functionality.

You don't waste time writing tests that simply check if all the arguments received the right type. This is taken care of by the type checker.

Besides, the biggest benefit of types is readability.

I don't see tests as you describe in dynamic languages much. E.G this is how you would test Rails controllers https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/cont... . I don't think its that different than java world.

About 1/3 of the bugs on my current project would have been prevented just by strict null checking alone. I've seen bugs on projects with 100% test coverage that would have been caught by types. Dynamic typing was a mistake.

Are you talking about using Optional or things like that in java? That's pretty recent so you can't say that's a property of a static language. And it brings its own problems with it.

What problems does it bring with it? It's just a tool that automatically tells you where you need to deal with possible null values. It's far easier than trying to catch every possible place this can happen with loads and loads of manually written tests.

Not all static languages give you this but the trend is pretty clear with Typescript, Swift, Kotlin etc.

I can't say the use case for Optional is even well defined https://stackoverflow.com/questions/26327957/should-java-8-g... . I'm no good in java, this is just what I find on the web.

Have you actually worked in a language with good, first-class null handling? I'm not surprised that something tacked onto java very recently is awkward to use but in Swift or Typescript it's much easier than wrapping if foo.nil? calls everywhere and much more effective.

What? The use case for an optional type has been been documented for decades and iirc is sourced from type theory. See it’s usage in Haskell (Maybe type) as one aged example. Also, that stack over flow is pretty well clear on what it should be used for imo.

I don't write much JS/TS anymore but I had a weird relationship with Typescript. I work daily with Swift and sometimes Kotlin and found myself slightly disappointed about the kinds of things that Typescript would let me do, I'm not sure if this is up to the underlying limitations of compiling to JS or that the settings of the project I was on wasn't configured properly. It adds quite a bit of overhead as a dependency when you have to bring in typings and keep these updated then make everything work with tests and storybook etc. It's a huge improvement over Javascript though and it's likely unfair to compare it to those other languages.

I think the future is a strongly typed language like Kotlin/Swift to webassembly on front end, and compiled to Bytecode on back end.

I love TypeScript, but have encountered a situation where I simply could not compile my code anymore because it started causing an internal error in the compiler itself.

Fortunately, I work as a team lead, and this was on an experimental branch, so I was able to hand off bits of code relating to architectural patterns I was evaluating to my team to continue work on those.

But I simply could not proceed with my code as is, a very frustrating experience to say the least. How is this even possible?

> But I simply could not proceed with my code as is, a very frustrating experience to say the least. How is this even possible?

As a team lead, I'm sure you know...bugs happen. What sort of internal error was it causing? Something specific and spelled out, or a generic uncaught exception?

.../node_modules/typescript/lib/tsc.js:78602 throw e; ^

Error: Debug Failure. at Object.assertDefined (/media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:1690:24) at /media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:13175:89 at String.replace (<anonymous>) at formatStringFromArgs (/media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:13175:21) at Object.createFileDiagnostic (/media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:13191:20) at createDiagnosticForNodeInSourceFile (/media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:7770:19) at Object.createDiagnosticForNode (/media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:7760:16) at handleSymbolAccessibilityError (/media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:71556:50) at checkEntityNameVisibility (/media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:71929:13) at visitDeclarationSubtree (/media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:72066:29)

Regarding the previous backend related article and code sharing between backend and frontend, how does your project setup look like?

For example, does the code get compiled using a bundler like webpack? if yes how do you solve the import '../../../../../shared.ts' problem? Or do you use node modules in a monorepo? Compared to other languages I found these questions surprisingly difficult to answer and solutions often quite cumbersome, e.g. if I want to share one small file in my project I don't want to maintain a public npm module for it...

Ever heard of the "rootDirs" [1] option in tsconfig.json? You can use it to aggregate code files in the various folders as if they were in one flat folder (as far as TS is concerned) while editing. Before building with WebPack, you can copy all the code files into a temporary build folder and then run WebPack on it.

1. https://www.typescriptlang.org/docs/handbook/compiler-option...

(I wrote the article.)

We use a single git repo with no npm packages defined, other than the package.json in the root because we have to put dependencies etc. in there. The directory structure for our source code is dead simple:

  src/server
  src/client
  src/common

For example, the API endpoint definitions are common code, so you'll see stuff like this in client code that uses the API:

  import * as quizApi from "../../common/api/pages/quiz"

The ".."s are annoying, but working around them isn't worth the effort. Even when we heavily reorganize the file organization, it only ends up taking a few minutes to mechanically update these imports with a vim macro, or even with sed if it's a perfectly mechanical change.

We run two copies of tsc: one for the client and one for the server, building to build/server and build/client. That results in a weird build directory structure:

  src/server/db.js
  src/client/app.tsx
  src/common/endpoints.ts
  
  build/server/server/db.js
  build/server/common/endpoints.ts
  
  build/client/client/app.tsx
  build/client/common/endpoints.ts

If you need separate build settings for client and server, this weirdness is going to show up one way or another. However, we only introduced this build separation in the last month or so. For the first 1.5 years of the project, we got away with a single tsc process and tsconfig.json, with no build separation at all between client and server. If anyone who's newer to TS reads this, I'd encourage looking for simple solutions like that; you can get to the weirder stuff down the road if you need it (and you may never need it!)

Thanks for sharing! We actually tried the same approach but we have a couple of more micro services relying on the same shared code. This has some additional complications, e.g. managing all dependencies for all services in one package.json is a bit messy and preparing a pkg for deployment gets a bit more complicated...

Ahh, if you're taking the microservice path then you're going to have to fight all of that complexity. So far we've stuck to the constraints that I set at the beginning of the project: vanilla Heroku web dynos; exactly one Heroku worker dyno (never 0 or 2); and Postgres is the only data store (no queues etc.)

The question is, is it worth it?

I'm starting to feel behind the curve and I want to learn new stacks like Next.js, Typescript and GraphQL. Anyone else feeling this way or have already gone through that learning curve?

Typescript is really easy to learn. You can turn it on, throw your existing JS at it, and then gradually increase the strictness level as you add typing information. It's a very painless transition.

I like TypeScript quite a lot, by itself. You should definitely take a look! Whether you use it with Node, React, Angular, Vue – doesn't matter.

Whether porting existing projects to TypeScript is worth it is of course a question that cannot be answered universally. Depending on how… creative developers were when creating it, it can be incredibly mind-bending.

In my opinion, totally worth it. First, you can transition gradually, just typing one file at a time if you want. Second, the type-safety you get makes incremental refactoring so much easier and makes you more thoughtful about "interfaces" (ie function parameters, etc). It also catches tiny bugs that would otherwise blow up in production.

Yes, sometimes you'll run into weird cases where you have to wrestle the type system, but honestly, in the worst-case you can just ts-ignore those (though you probably want to minimize that).

Worth it, speaking as someone who prefers how Typescript is so flexible and does not get in your way too much.

Yes, one often overlooked benefit is the tooling that is enabled by having proper types. IDEs from jetbrain in particular are great at it.

I have transitioned my entire team (comprising people ranging from fresh-out-of-a-bootcamp to senior 20-years-in-the-web).

Next.js and GraphQL are interesting technologies, but I would say they will eventually fade. They do solve some problems, but they introduce new (hard to fix) ones.

Typescript is here to stay. The improvement it brings to the development experience cannot be understated.

It helps the inexperienced to avoid lots of (minor) bugs and providing much more useful autocompletion/inline docs than any javascript analyzer can.

For the experienced people, it is an invaluable tool when the time for largeish refactorings comes. For the first time you can "follow-the-trail-of-errors refactor" in frontend-land.

This question probably varies on who I'm asking but how long does the transpiling process take for you on a, let's say, fairly large project?

We were already using Webpack + babel. Adding transpilation there is fairly inexpensive (done by babel, without type checking).

Type checking did roughly double our build time. Even then, we do run type checking during builds because we prefer the added safety even with this extra time.

Developers run with an incremental checking watcher. It does add a significant tax, and takes a few seconds after saving in some cases (3-4). We would love that delay to go away, but it is a cost we are more than willing to bear if the alternative is not having type checking at all.

I'd personally ignore Next.js and GraphQL, but would certainly (and personally have) invested in TypeScript.

I am guessing that Next.js and GraphQL will be long-dead and obsolete "soon" (in the same way that e.g. jQuery & AngularJS were once also red-hot technologies but are now out of favor), but TypeScript really feels like it is here to stay with significant benefits. I guess this is a "learn technologies, not libraries" type thing?

I was "forced" to learn TypeScript for Angular 2 (that was the library of choice at where I worked at the time) but now also use it for my personal stuff out of choice.

Compared to pure JS it is a bit of a pain to get basic development up and running (since you need a TS -> JS compile step before you load it in the browser, unlike raw JS that you can just code and reload). For that I have created myself simple boiler-plate templates (1) that I use to bootstrap a new project so I can be up and running in a browser in 60 seconds etc (the template will do all the compilation and bundling for you using webpack)

1 - https://github.com/matt1/TsBoilerPlate

Since Babel now supports TS out of the box, it is much easier to use.

Not as safe of course, but you get 90% of the benefits.

If you've worked with a language before that uses static typing and compile time type checking (Java, C#, and C++ immediately come to mind), TypeScript will be very easy to pick up. It'll just feel like a slightly different JavaScript-friendly syntax slapped onto the same set of core concepts. Coming from a background where I had written both C# and JavaScript before, TypeScript took all of one day reading docs and messing with the toolchain to start adapting it for the React app I was working on at the time

If you haven't worked with a statically typed, compile-time type-checked language before, I think you owe it to yourself to learn one, whether or not TypeScript is the one you learn.

Next is dead-easy to learn. It takes very little and you have a solid React setup. No config required. The docs are very, very good. And they have a little tutorial.

I've used TS for 4-5 years now and I have been using Next.js/GraphQL in a work project. I would focus on TS since I don't really think Next.js/GraphQL is worth the hype and I would bet TS will outlive both by a significant margin.

GraphQL is a genuinely different kind of tool in the box, and it is at times useful in that way.

Typescript is really just a tool for people who want autocomplete in VSCode for their javascript, or who really still want to be coding in C# and unless you're just dying without those things it's a lot of overhead for not much benefit.

Typescript has made me pretty sure I don't want to be a frontend dev much longer.

Typescript has made me go looking for Elm and Purescript jobs. Not many of the latter, but I've applied for one of the former.

One critical thing for TypeScript's success that I wish for the Lua community is that it paved a roadmap for typing a huge chunk of the JS ecosystem. Porting to TypeScript can be entirely incremental, and you usually have a wealth of types coming in from dependencies. The UX here is going to be one of the best as far as ports go, as usually porting feels negative value up front

I want to start using TS for my Node service but ts-node seems janky and the compability with ndb (which I use all the time) seems bad.

Anything specific about ts-node that doesn't work or that stuck out as janky?

I keep reading people saying you should use tsc + regular Node instead which is enough to make me worried but haven't really evaluated it myself.

(I wrote the article.)

We don't use ts-node for our dev processes because it adds some annoying startup delay. We keep the TS compiler running at all times on our dev machines, and we run our server/tests/etc. from the TS compiler's build output directory. This hasn't been a big pain point for us so I wouldn't worry about it much.

Related, just in case: I definitely wouldn't use ts-node in production. If your deployed code fails to typecheck for some reason, you don't want to learn that by seeing your backend server failing to boot in production. I think you should always compile your app during your deploy process, then have production boot the compiled JS as if TS weren't involved at all.

I've never increased my productivity by using Typescript, although I really tried very hard to like it. It just keeps bugging me. It's a constant stream of interruptions that force me to please the TS compiler, compared to having a rare type issue a once in a while in plain JS.

Besides that, I've never been a Microsoft fanboy(to say the least) and it's worrying me that almost the entire JS eco system falls in the hands of that company; Github, VSCode, Typescript, NPM, etc.. Am I alone in this?

There is so much good stuff in the JS world, but we seem to adhere to a few companies and a few systems more and more. Being a 'Javascript' developer today only has very little to do with Javascript. It's about React, Redux, Hooks, ESLint, Prettier, Typescript, etc.. Oh, and don't forget to do it Agile, another joy and productivity killer. And when you don't agree with this stack you're either not so smart or still need to learn to 'understand' it.

I feel very similarly to you regarding the position that JS is moving in.

I can only surmise that things are moving in this direction to lower the barrier to entry. As more developers are working with JavaScript it's easier to subscribe to tools to manage consistency than it is to educate and rely on developers' standards to create working efficient code.

Thinking back I've worked on some massive 'Web app' projects over the last 20 years, and the biggest I worked on didn't use much in the way of frameworks or libraries, and standards were maintained by peer review and documentation.

Typescript I suppose automates a lot of this, but I don't think that makes it better.

I tend to agree with you. I've been working on the front-end side of web applications for a couple decades now. We have so many tools available to us now then ever before. It's interesting to observe how a select few end up as the go-to choices for so many projects and organizations.

At the end of the day, they are just tools and how we use them is what really matters.

Same. I have tried using it and enjoyed the IDE powers a bit more, but already knowing JS quite well, it wasn't a game changer.

Lately I have started using FastAPI in Python, which uses Pydantic to enforce type hints at runtime. This saves a lot of manual checking code (e.g. "if input_data["mykey"] == "unhappy path": raise ValidationError").

This was the same annoyance in Node.js because the types are so flimsy and manually checking is really boring. Tests are great but if you can have correctness while rapidly prototyping that would seem to be a win.

Is there a great TS lib to do runtime type reflection like Pydantic?

Self-reply: I found these two but haven't tried them.

https://github.com/pelotom/runtypes

https://github.com/ianstormtaylor/superstruct

Your comment is pretty much exactly the reason why I'm moving to Elm and PureScript as much as possible. As a specific point, function types for redux-thunk are just an absolutely miserable mess and that alone moved me to redux-saga. But personally I just want to dump the whole wretched thing. I'm glad people are waking up to this, because I felt like the odd one out disliking Typescript and preferring Javascript.

Typescript in my experience has felt like a collection of hacks more than a well thought out expansion of Javascript. Additionally, it concerns me that official solutions to some problems (e.g. iterating on an enum) require you to write around the code that the compiler will generate. That does not fill me with confidence at all.

As a personal point of contention, I really dislike that the types are useless beyond design-time. But since they don't want to go outside the EMCA spec, we'll likely not see anything like pattern matching on type or type-level destructuring anytime soon.

As it stands, some trivial things can become a nightmare very quickly. Maybe I'm just used to the ease at which ML-family languages can express some concepts.

What specific concerns did you have with the redux-thunk types?

The primary driver of Productivity isn’t how fast you type code, it’s how much time it takes that code to work correctly.

Reply on news.ycombinator.com