loading...
Cover image for The Trouble with TypeScript

The Trouble with TypeScript

ryansolid profile image Ryan Carniato ・10 min read

Hi my name is Ryan, and this is my first post on dev.to. I regularly write for medium.com but I wanted to give dev.to a try. I'm a big enthusiast of reactive libraries and front-end JavaScript performance. I'm the author of Solid.js one of the top-performing libraries on JS Frameworks Benchmark. But today I want to write about something else.

I've been using TypeScript now for about a year. Hardly enough time to come to a conclusion about it, but I've wanted to write this article for months. Pushing it off each time hoping that it would finally click. I also decided that I might not be the best judge as being a library writer I was sort of thrust right over the deep end. So I wanted to give people of different experience levels and programming backgrounds I trusted an unbiased chance at it. So not only did I convert all my open-source libraries to TypeScript, but 6 months later I asked the developers at the startup I work at if they would like to use TypeScript on a rewrite of our core application. They had a varied interest in learning it, but they were all open to it. Now that several more months have passed, I finally feel that I'm at a point I can say something. So let's dig in.

TypeScript is an Art, Not a Science

I've been programming for about 25 years now. I've used dozens of typed languages over the years. But TypeScript was a first in that it was trying to put types on top of a dynamic language. This in itself seems like it would be an incredible feat. But then again dynamically typed languages did so a few decades ago. At one point getting rid of the types was actually seen as progress.

When you start with simple examples it all seems familiar enough. You add a few annotations and marvel at how it won't let you assign a string to a number. You make sure your functions have clear parameters and return types and you start feeling like you are getting it. And then you hit a place where you need to pass in different objects. Your first thought is loosening up the definition but then you see an example with generics and realize TypeScript uses generics way more liberally than you are used to with C++ or Java. Even cooler, their type can often be inferred which means you don't even need to annotate and everything magically works.

That is until you add a few extra levels on to, and you start coming across the inconsistencies, or the places where types can't be inferred. The other day I was helping my lead dev work through some typings on factory function that produces hooks that return CSS in JS generated classes that are a result of the style definition passed into the factory and props passed into the hook. He had something very basic and couldn't quite figure out why his types weren't working. So I sat down and started using generics to assign multiple values and creating wrappers to project types for return values. Someone how after a couple of tries I got it working for the most part. I admit I felt pretty good about myself, but the developer looked bewildered. You see he thought he was finally getting TypeScript and he had no idea what I had just done. So I spent the next half an hour explaining it. In the end, he got it, but he still didn't feel any better about it as he would have never thought about it that way. And truthfully I was in the same boat months earlier.

You've heard the saying that programming is art? Developers choose how to model their problems and have their own stylistic approach. Everyone's code is different. I remember when I was a young developer I'd try to find the most clever way to solve a problem and feel so proud before a senior developer tore a hole in it and asked why I just didn't do the simplest thing. Over time my code got more directed and less frivolous. TypeScript has so many tools to do seemingly similar things since JavaScript has so much potential, that you might easily take a tact that can't get you 100% of the way there. It's very difficult to know what the right way is unless you've experienced it. But since it is impossible to safely type all things in JavaScript you don't even know if what you are trying to do is possible or if you are just thinking about the issue wrong.

This leads to a very strange scenario that the more complex the issue even when you go for help, communicating the intent of the code is as important as the function. When talking about possible solutions it isn't unlike people looking at modern art trying to critique the intent and the emotion of a toilet paper roll nailed to a wall. You can spend hours perfecting an elegant solution to your types without shipping any new workable code. It makes you feel really good and clever when you get it right. It is metaprogramming to the highest degree. It gets even more awkward when you are trying to use a 3rd party library who is more concerned about spending several months getting it right than getting something out that works (while in meanwhile the current types are effectively broken).

As I alluded to previously, programming itself has these characteristics, but it's super strange when your tools do too. That level of uncertainty, that need to solve a puzzle with your tools completely on the side of the programming problem you are solving is the kind of thing that I can see developers liking given their personality as problem solvers, but when it comes down to things like efficiency and productivity it is excess. Every time I use TypeScript and I realize that I remember being that young and unexperienced programmer just doing a lot of unnecessary stuff.

TypeScript focuses on Ceremony

I often wonder how many people who rave about TypeScript have ever really used JavaScript. I used CoffeeScript for 5 years almost exclusively and only returned to ES6 for the last couple of years. I wouldn't recommend people move over to CoffeeScript today except perhaps to appreciate some of its qualities briefly. CoffeeScript in some ways is the absolute opposite of TypeScript exemplifying the other characteristics of JavaScript. Forget types. You don't even declare variables for the most part. If you read the way these people talk about JavaScript I can only imagine what they'd think of CoffeeScript.

Would it surprise you that CoffeeScript increased productivity over JavaScript for our team? This was a different time and I'm not sure it would do as much now. But let me paint the picture. Writing CoffeeScript is a lot like writing pseudocode. So after you plan out how you are going to approach your programming task, you tend to just throw stuff up. Need a new variable just start using it. Getting an idea up was incredibly fast. The syntax being terse was nice as something that would be 80 lines in JavaScript would be about 30 lines in CoffeeScript. Sure you'd run it realize it didn't quite work since you missed a null check. And you'd add a ? (null coalescing operator). Then you realize your logic was wrong in the 2nd loop. So you need to do a refactor.

What I've witnessed with TypeScript is that 30 line CoffeeScript file is now 150 lines. I can't see the whole thing in my IDE window anymore without scrolling. At about the same time the CoffeeScript developer is starting the refactor the TypeScript developer has just reconciled all the types and is about to run their code for the first time. Type annotation doesn't take much time unless you need to look up Types you don't know (seriously for the browser MDN is such a lifesaver here), but the tendency here is to ensure everything matches that it all works out the first time you run it. Sure the TypeScript developer never has that run where the browser spits out Cannot read 'name' of undefined but by the time they are realizing their logic is wrong in the 2nd loop our first developer is already testing the refactor.

Many JavaScript developers are very used to just throwing stuff against a wall and see if it sticks sort of development. They rapidly test ideas without the code being perfect. This just wasn't a luxury afforded compiled languages. If you are going to wait a couple of minutes you better make sure your code works before you hit build. To me, it isn't that different from the difference between waterfall and agile methodologies. We know that some larger companies can still have some issues being as agile and I feel the argument for TypeScript is sort of similar. Now don't get me wrong. The CoffeeScript probably produced more bugs, but trying something can often reveal when your assumptions are wrong quicker. Waste less time perfecting something you aren't going to use anyway.

TypeScript is Noisy

As in it has a higher noise to signal ratio. Less of the code you are looking at is functional. I've already talked about more code being required but this goes beyond initial development. I know this is perhaps more opinion based but when Dan Abramov (React Core Team) recently tweeted that when he looks at someone else's code the Types actually get in the way of him seeing the code, I realized I wasn't alone. Type information can be noise when you are just trying to see the flow. Truthfully this is less of an issue compared to the last as it doesn't change how you approach coding. But it is something. We can filter out the annotations pretty readily but simply function declarations going from one line to 5 lines starts you on a path where you are always looking at less.

TypeScript is a Subset of JavaScript

I can't impress this one enough. Technically is a superset from a feature support perspective. However, people use it so they have compile-time type checking so once that becomes a requirement for you there are just things you can't do with TypeScript. I hit this right away when writing Solid.js. It uses JSX in a completely different way than React, it has a lot of functional patterns like currying, and functions that support paths and dynamic arguments. Not to mention at its core it is incredibly tuned for performance so I was unwilling to change what the underlying JavaScript compiled to. I kid you not with 3 weeks I ran into over a dozen unsolved TypeScript issues with open tickets and reported 2 more myself. I have received a lot of help from the TypeScript community and have no ill will towards the people working on it and supporting it. But when for the solutions that are solvable the best options are: change your API or add another function call to get the compiler to work the way you want, I was understandably very uncooperative.

Ultimately I settled on not having custom bindings with $ prefixes in the JSX attributes, using JSX namespaces, and introducing intrinsic elements with special characters (all things supported by the JSX spec). I introduced another syntax against my better judgement to avoid paths. I just think is vital to understand that there are a ton of patterns you'd do with JavaScript that cannot be made type-safe and many more that would require an expert to determine if it is.

Obviously, as a lower-level library writer, I hit these right away, but I've even seen these affect application developers. They've had to change the way they would approach an interopt layer since it wasn't as TypeScript friendly. Similarly hitting weird TypeScript only idiosyncrasies when using 3rd party libraries. Pretend you haven't sold your soul to TypeScript and read this guide for Material UI. Why would I ever sign up for this?

Conclusion

If you treat TypeScript as a language in its own right, with albeit a smaller feature set than JavaScript, you will do just fine. If you treat TypeScript as JavaScript with types you will be disappointed. The thing is despite how terrible of an experience I or those around with me have had we are sticking with it. As a library writer it makes a lot of sense since there are many people that want it. It hasn't meant any compromise thus far that I wasn't willing to make so I'm committed to supporting it. I know somewhere in my head by doing so I'm limiting my creativity. Some of my more interesting ideas don't work with TypeScript so taking this position might compromise my motivation to look into them. But Solid.js, as it is today, is already very impressive.

On my team, it was split. The backend developers did not have a hard time with TypeScript and their solution scaled with their knowledge as they've found better ways to structure their project. However, on the frontend, it has been nearly a disaster. TypeScript has basically dictated other technology choices. Where we've been like use TypeScript or use this library. So far we've sided with TypeScript because of the promise of what it brings. In hindsight, I would have never introduced it there but I feel like we are starting to get over the hump so the time invested is worth seeing it through. It's just ironic that many of the advertised benefits I believe are actually detrimental.

TypeScript doesn't improve productivity or readability. It doesn't particularly improve on modern JavaScript feature set. If anything it restricts what you can do. But it isn't all negative. It pushes developers to document code. It sets a contract when dealing with 3rd party APIs. However, the biggest win I think is it makes developers more comfortable. It inspires developer confidence which is something we can all get behind even if the language itself might be the worst mess of compromise I've witnessed in my 25 years of programming.

TypeScript might not be the language we need, but it is the language we deserve for now.

Discussion

pic
Editor guide
Collapse
juliang profile image
Julian Garamendy

This was not my experience with TypeScript at all.

I consider type annotations a way to increase the expressiveness of my code.

TS makes my refactorings easier since I know I haven't finished until the types check.

It also allows me to write fewer tests.

I tried JS without types for a small project and I got constantly stuck on silly type errors that would have been made obvious in my IDE even before saving the file.

I never felt TS slowed me down.

Collapse
ryansolid profile image
Ryan Carniato Author

From what I've read that is a lot of people's experience. Of course, I write code that has errors but they are usually easy to classify and fix. There is that 2% that aren't logical or that aren't obvious at a glance I feel TypeScript might catch. But this waiting until I'm done to run through things definitely feels slower. After a while, it actually feels that even those 2% are classifiable without heavy debugging by learning what the symptoms look like.

I've refactored large projects across multiple modules without types many times. It looks a lot like aggressively changing everything and then everything is broken. And then you work piece by piece to get things working again. I know that terrifies some people (including my developers) but my mentors did similar things, and I have found that while you can introduce bugs the process is much faster since you aren't getting hung up on those details early on. Even removing TS from the equation, I've found less experienced developer's timidness in refactor being a gigantic slowdown. And there are tests for the rest. Tests have value regardless and I feel that TS should not be a reason to write less tests since runtime is the only truth.

And that's the thing I don't think using TypeScript feels slow. I think that the process/ceremony it pushes you towards can be slower than just doing things and trying as you go. It may not be in all cases but I don't believe it's so cut and dry to be like "improves" productivity.

Collapse
juliang profile image
Julian Garamendy

I realise I've never worked on a large JS project (only TS). So perhaps I don't really have real-life examples to compare.

I agree the ability to refactor is more related to test coverage (of use cases) than to having types or not.

I just never felt slowed down by TypeScript, and I did when I worked on (even small) projects using only JS because I need to load the "types" or object-structures in my head instead of letting my IDE and type checker do it for me.

I never had to ask myself:

What's the shape of the object this function is expecting?

because in TS you can't get it wrong. My IDE will highlight it in red as I make a mistake.

I only add type annotations where strictly needed, I let type-inference do the work for me.
I don't spend much time writing types.

I'm not sure what's the process/ceremony you mentioned.

Cheers!

Collapse
trusktr profile image
Joe Pea

After the "hump" you'll find yourself more productive I think. It's just like with Vim: after using it for a while you are faster than with regular editors at text manipulation. Every day I use text fields like the one I'm typing in right now, and can tell the difference in speed. There's some Chrome extensions like Wasavi that I maybe should try. But anyways, I've done some fairly huge refactors of code bases with TypeScript (in VS Code in particular with all the refactoring tools), and I can't imagine doing the same in plain JavaScript, let alone the refactors sometimes working first try! It's wonderful.

Collapse
ryansolid profile image
Ryan Carniato Author

Yeah that's what I've been hoping for. I'm expecting the other shoe to drop for months now. And it sort of does. Like I feel fairly competent now with TypeScript. It's just the more I learn the more I'm impressed with how difficult the challenge that exists here. And while it's admirable and the community has been so helpful. There is always just the next thing.

I lived in the CoffeeScript world for a long time with no tooling after coming from C# where everything was autocompleted. It was less of a system shock than I expected. I've lived through both and they have their tradeoffs. The weird part for me is how TS is not C#. That strange ambiguity and incompleteness when approaching certain problems that are possible only because TS is JS.

Collapse
trusktr profile image
Joe Pea

Yeah, it is interesting how TypeScript is releasing some new type features -- that basically don't exist in any other typed language -- due to the efforts in making it possible to express JavaScript paradigms with types.

Collapse
trusktr profile image
Joe Pea

I'm really enjoying AssemblyScript too!

Collapse
jwp profile image
John Peters

Joe, kind of funny really. Webassembly must throw Javascript purists crazy. Their infrastructure is crumbling daily. Typescript from the top, Wasm from underneath. I'm not a fan of Razor, but it's ahead on challenge.

Thread Thread
ryansolid profile image
Ryan Carniato Author

Perhaps. As mentioned I'm into benchmarking. And WASM just isn't faster for DOM operations. Solid's higher level abstraction still is faster than the fastest WASM vanilla optimized hand crafted routines in JS Frameworks Benchmark. When you add a higher level abstraction on WASM it gets slower still. I'm sure it will get there some day but I think the direction of using compilation like Solid or Svelte doesn't make anyone in the wider JS community feel threatened by WASM. It's another tool. I think its more interesting when JavaScript haters don't realize that the more they accept things like TypeScript and WASM they are just playing further into the same infrastructure that legitamizes JavaScript. At some point there will be something better and it probably won't look like anything that is there right now. And it won't be because of some Type vs UnTyped mentality will be about capability and expressitivity. That's why JavaScript is still here. In those terms it is incredible. I think things can be better. JS is far from perfect but it sort of accidentally hit this sweet spot that I don't think is immediately appreciatable.

Thread Thread
jwp profile image
John Peters

Today, I like Javascript. But in 1990-2005, I couldn't stand it. I was forced into it due to its ubiquitous utilization. If one works the Web. Javascript is paramount.

Thread Thread
trusktr profile image
Joe Pea

Yeah, until WebAssembly Interface Types are out and Wasm has direct access to DOM references, it will be hard to make Wasm faster than plain JS for DOM operations. But once Interface Types are out, and Wasm can work with DOM references directly rather than needing to do it via a JavaScript bridge, we might see optimized Wasm become faster.

When the day arrives that Wasm can access DOM directly, tools like Blazor (Wasm-based DOM manipulation in .NET), RSX (JSX-like expressions for manipulating DOM from within Rust compiled to Wasm), gccx (JSX for C++), and others, will be in a great position to take advantage of it and allow developers to truly select their favorite language for working with DOM and have great performance at the same time.

AssemblyScript is TypeScript syntax, which already supports JSX, so that's going to be neat once all the existing TypeScript DOM-typed APIs work directly in Wasm.

It is currently not possible for Wasm to win against JavaScript in DOM performance, but I believe that will change.

Collapse
mateiadrielrafael profile image
Matei Adriel

I tried assemblyScript a few weeks ago and it has lots of problems, it feels like a prototype and until it gets out of beta I dont think I'll give it another try

Thread Thread
trusktr profile image
Joe Pea

What problems did you have? The main problem I can think is that it works with only a subset of the features of TS/JS, but if we stick with those features then it works well. I've been porting Three.js to AssemblyScript over at github.com/infamous/glas and so far it's been pleasing to see the ported tests pass in AssemblyScript. THe most notable changes were, so far, that we needed to modify any APIs that used object literals to instead use strictly-typed objects generated from classes. This is actually improving the type safety of the code. :)

Thread Thread
mateiadrielrafael profile image
Matei Adriel

I cant remember exactly the problems I had, but basically I was just porting an entity component system when I started getting random crycptic erros for no reason (and yes, I only used the supported features)

Collapse
jwp profile image
John Peters

And then you hit a place where you need to pass in different objects. Your first thought is loosening up the definition but then you see an example with generics and realize TypeScript uses generics way more liberally than you are used to with C++ or Java. Even cooler, their type can often be inferred which means you don't even need to annotate and everything magically works.

That is until you add a few extra levels on to, and you start coming across the inconsistencies, or the places where types can't be inferred. The other day I was helping my lead dev work through some typings on factory function that produces hooks that return CSS in JS generated classes that are a result of the style definition passed into the factory and props passed into the hook. He had something very basic and couldn't quite figure out why his types weren't working. So I sat down and started using generics to assign multiple values and creating wrappers to project types for return values. Someone how after a couple of tries I got it working for the most part. I admit I felt pretty good about myself, but the developer looked bewildered. You see he thought he was finally getting TypeScript and he had no idea what I had just done. So I spent the next half an hour explaining it. In the end, he got it, but he still didn't feel any better about it as he would have never thought about it that way. And truthfully I was in the same boat months earlier.

This is more about lack of knowledge than the goodness of Typescript.

Besides, Typescript does not preclude anything that can be done in Javascript. If it can be done in Javascript it can be done in Typescript.

Javascript's cohersion makes for programmers who are clueless to the pitfalls of type cohersion. So much so, they don't see any value to static typing at all. Including pre compile time errors they call noise.

Choosing generics over spread operators or 'any' types, or optional properties is a design decision, not a language fault. Introducing generics to newbies is costly because they will never 'just get it'. Especially when the mentor writes articles about his dislike of Typescript.

Collapse
markerikson profile image
Mark Erikson

If it can be done in Javascript it can be done in Typescript.

I'd have to disagree with this statement.

There's a lot of very dynamic JS behavior that is difficult or effectively impossible to describe in TS. Try looking at the React-Redux type definitions as an example.

TS definitely pushes you to alter how your APIs are defined in order to get more easily typeable code. In some ways, this is actually a good thing, but just saying "you can do any JS in TS" is too much of a hand-wave-y statement.

Collapse
jwp profile image
John Peters

Yes those definitions are very complex; too complex, and most likely an indication of a bad design.

I've looked into redux before and rejected the concept of separation of state concerns to other components.

The MVVM pattern kept state in the view model and there were no state issues in past 20 years. State concerns do not need to be farmed out.

Thread Thread
markerikson profile image
Mark Erikson

My point had nothing to do with whether Redux is a tool you should use or not.

I'm simply saying that connect is a highly dynamic JS API that was designed before TS became popular. It accepts multiple arguments, all of which are optional, the first two arguments have multiple possible overload forms, and the result is a React "higher order component" that passes those derived props to your own component. It's a very JS-centric API. Thus, trying to define typedefs for that dynamic behavior becomes harder.

In contrast, our new React-Redux hooks API is two functions:

const dispatch = useDispatch();

const todo = useSelector( (state: RootState) => state.todos[props.id]);

We didn't specifically design them that way just to work better with TypeScript, but the ability to type them easily was a factor in our consideration.

So, as I said: there is some JS behavior that is extremely hard or impossible to type correctly in TS. Therefore, TS usage pushes you to design APIs that are easier to type.

Thread Thread
jwp profile image
John Peters

I have seen C# apis, where one endpoint served many different things. All were later ripped out as the 'SRP' Principal was a better pattern.

I'm simply saying that connect is a highly dynamic JS API that was designed before TS became popular

I was only noticing the 'less than optimal' design of allowing an interface to accept dynamic parms. Of course it's only an opinion.

Collapse
jwp profile image
John Peters

The only difference in a strong type and weak type is a definition file.

The worst case is to create a type of 'any' if needed; however the Typescript definition project has 95% coverage. Not a problem for me, really.

I have yet to be stopped from using any Javascript npm package. So not sure how valid this argument is...

Collapse
jwp profile image
John Peters

Excellent article on your experience with generics in Typescript. I concur that's some ugly stuff.

Collapse
yuanhao profile image
YuanHao Chiang

TypeScript is Noisy

As in it has a higher noise to signal ratio. Less of the code you are looking at is functional.

+1 there. I've tried to give Typescript its deserved chance, everytime I feel that maybe I'm just not used to it but the feeling doesn't fade away. Reading docs in Typescript takes a lot of mental energy too.

Great article! A lot of insight and this answers a lot of the questions I had. I imagine you've learned a lot from it by working on Solid (just learned about it on this post, looks solid -- pun intended --).

Collapse
jwp profile image
John Peters

I felt the same way about Javascript. So much so I rejected it totally for 10 years.

Collapse
ryansolid profile image
Ryan Carniato Author

I started with QBasic and C, then got a little taste of JS in the mid to late 90s and was not impressed. Then went to University and worked professionally with "real" programming languages for about 10 years. But then through myself into JS the last 10 (5 of those being CoffeeScript). And something about it just clicked. It was so freeing. I still like C# a lot and you could use TypeScript that way. But knowing that I could be programming JavaScript is really irksome since TypeScript isn't like WASM getting me closer to the hardware. Instead it just makes doing certain things really uncomfortable. Things that I don't want to give up because I know I can. I'd rather program in C# over TypeScript any day.

Thread Thread
jwp profile image
John Peters

Typescript to me is just metadata for pre compile type checking saftey. It makes APIs a relic,as auto-completion just works. I get to choose when to use typing and when to ignore it. I like Typescript.

Collapse
markerikson profile image
Mark Erikson

I wrote an extended post recently on my experience learning and using TypeScript as both an app developer and a Redux library maintainer.

Summarizing, I'm totally on board with using TypeScript as an app dev, which also means I want the libraries I use to be well-typed. As a lib maintainer, dealing with type definitions can be painful, but necessary.

Ultimately, the key for using TS in an app is to be pragmatic about type usage, and be willing to accept an 80% solution rather than obsessing over 100% "perfect" type coverage.

Collapse
evanplaice profile image
Evan Plaice

As another lib dev I prefer not to use TS

Instead, I JSDoc comment/type all public APIs and generate the typings as a pre-publish step. It provides all the benefits of TS (ie Intellisense + inline docs + type checking) w/ none of the downsides.

IMO, typing private/internal API surfaces is a waste of time. Tests should cover logic and a good linter should cover the rest.

The main reason I use this approach is it drastically lowers the barrier-of-entry for users/contributors.

TS really does add a ton of cognitive overhead. There's no one true/correct way to type code. This leaves room for ambiguity, which leads to friction diring review. In short, who the hell wants to waste time arguing over the 'correct' way to define types?

This is less of an issue on an internal team b/c everybody should be familiar with each other's individual styles.

On OSS projects where cohesion is generally low-to-non-existent, anything that introduces friction is a no-go.

Collapse
ryansolid profile image
Ryan Carniato Author

Thanks for linking your article. That's been almost exactly my experience right down to the details of dealing with PRs and the fanaticism with typing. I think it is too easy to equate TypeScript with 100% perfect types and perhaps that is what I have the bigger issue with. I just was trying to push the boundaries with my library especially in the area of JSX and TypeScript really felt like a limitation to creativity. Which has been hard simply because it's taken creativity to prove that a precompiled Reactive library can use JSX with so many recognizable naysayers like Rich Harris, and Evan You.

I do get why better typeable APIs generally are better and I've seen the same move to simple APIs after. But definitely painful when trying to push boundaries.

In any case great article and I've distributed it to my team.

Collapse
albertomontalesi profile image
AlbertoM

I've been a developer for roughly 2 years, all spent using JavaScript and TypeScript. For a large project I would never go back to JavaScript, i think types make my life much easier. Admittedly we still use any in our codebase but that's also what I like about TS. Since you can just write normal JS, you are not forced to type everything, if you feel like it would take longer to apply proper types than the actual benefit you would get from doing so, you can still write plain JS or use any.

Overall I've had a great experience with TS, i had to learn it during the first few months as Junior dev and to be honest it's very easy to pick up.

Collapse
ryansolid profile image
Ryan Carniato Author

All our codebases are strict mode. But I see value for explicit any. But on the other hand I wish any just worked. It's been hard because casting to any sometimes just doesn't work too. I understand why but try to teach developers that. There isn't just an escape hatch. I think though for junior devs this is an easier pickup because they sort of don't realize what they are missing in terms of how you can approach problems with JavaScript.

Collapse
jwp profile image
John Peters

Typescript is great and will always outshine Javascript. It adopts Javascript and makes it dead simple for OOP folks who were around before Javascript was invented. It's the language for everybody, a bridge to sanity.

Collapse
luismasg profile image
Luis Ma SzGtz

This is the most simplistic statement.
"I like Typescript because I like my confort zone"
"make it dead simple for OOP folks" ... and the discussion is dead. you should have opened with that and admit it's what you know, it's your confort zone.
when all you have is a hammer everything looks like a nail.

And yet here you are doing JS to pay your rent.
Instead of staying in your old position doing cute little LINQ expression thingies.
let me guess , you also despise CSS?, UX?, DX? animated transitions?

And as for OOP being around for ages, you shot yourself in the foot there.
you're defending a pattern built in the dark ages refusing to consider that "hey , maybe we know a bit more than 60 years ago"

All i'm hearing is "I struggle with js and feel more confortable with typescript. it makes me feel all warm and fuzzy and java-y"

yes, typescript is easier for the oop folk that jumped ship and came over to js. we get that. it's a fact.
trying to convince the world the it's better then js is just being obnoxious.

Collapse
jwp profile image
John Peters

Your injecting odd thoughts into everything I have discussed. I don't agree with anything you've implied. It's falsey. BTW it is better for one reason alone, intellisense always works!

Collapse
steveblue profile image
Steve Belovarich

🤨 I will have to agree if a project doesn’t start with TypeScript, migrating to TS can be problematic, we are all engineers and by definition that means we should be finding technological solutions to problems. Being an engineer doesn’t necessarily mean “I do what I want”.

I have run into instances where I had to refactor code to make it conform to TS compiler, but never found a use case where the refactor made the code less performant.

Perhaps instead of calling out all the issues you found with TypeScript, be more proactive and help fix those issues. That is what open source is all about, collaboration.

There is no controversy here. No “trouble”.

Collapse
ryansolid profile image
Ryan Carniato Author

I try to be heavily involved in Open Source and I have reported and joined discussions on issues. Refactoring for TS is unacceptable for Solid at this point as it is in contention for being the fastest Client UI rendering library period. So very sensitive to even smallest code changes. But that's a library.

I figured refactoring would be hard so that's why at the startup we have only started TypeScript on greenfield projects and that is the additional experience I am speaking to.

Collapse
steveblue profile image
Steve Belovarich

I would like to see some concrete examples of how adopting TS would slow down rendering in Solid. Without performance metrics this is just hyperbole.

Thread Thread
ryansolid profile image
Ryan Carniato Author

Solid is all TypeScript and it works well so I feel I worded that wrong. I meant that I was unwilling to change the runtime output to better support types. Especially around JSX there have been some questionable suggestions. Most of the friction has been around declarative path based API which is there to enforce better patterns as reactivity can get out of control. Internally TypeScript still lets me use object factories where they are faster than classes. And define class interfaces without using class properties which babel can handle less than ideally. And I have benchmarks for those sort of things. Coming from the perspective of someone who benchmarks excessively it wasn't about TypeScript being slow. It's about finding the optimal JS code and then in a few places forcing TS to behave. It takes considerable effort when changes are made in certain places to test these things. So I didn't like TS changing output. But making it work without on the performance side wasn't too bad. API is a whole other thing.

Thread Thread
steveblue profile image
Steve Belovarich

If you are concerned about performance then you should take a look at Closure Compiler which will change output, but is tried and true solution for optimizing JS better than any other tool.

Thread Thread
ryansolid profile image
Ryan Carniato Author

Thanks. A few of the other top tier competitors use it or used it at one point. I admittedly haven't tried it with Solid yet but it's probably worth a shot.

Collapse
juanfrank77 profile image
Juan F Gonzalez

I agree with the feeling. I started using TS because of an Angular 7 project and all it's promised features seem good but then it comes with these things where you feel you're fighting against the language or the linter is yelling at you in all these details.
The signal to noise ratio is also something that threw off pretty much all my team, it's like some lines of code for a function that get cluttered with all these decorators and things.
For me, it invoked some feelings of Deja-vu in that I sometimes felt I was reading something similar to Java or C# and got little shivers every time. Indeed I pretty much think of it as JavaScript with types and other added features but now in the project, I'm working on I'm using React PropTypes and so far so good I haven't had anything that I consider an issue. So yeah I'm one of those people that TS is not for them.
Great article, cheers!

Collapse
jwp profile image
John Peters

When I first learned Javascript the S/N ratio was also high plus it was very cryptic. The Javascrpt learning curve is about the same as React or Angular.

Today, I love both Typescript and Javascript. All have matured a lot in 25 years.

Collapse
juanfrank77 profile image
Juan F Gonzalez

It could be argued that someone coming from a backend language would find JavaScript 'noisy' and 'weird'. Several friends have told me that.

Also, the learning curve is different not only because React uses js and Angular uses ts by default, but because you can do very little with React without any extra stuff. In Angular, the minimum expression is still a boilerplate modules, routes and a styling approach.

Thread Thread
jwp profile image
John Peters

Yes, so many learning curves and so little time. I spent 10 years in Java, 15 in C#, 7 in Javascript and 4 in Typescript. I spoke them all fluently but was an expert of none.

Collapse
the_spyke profile image
Anton Alexandrenok

TypeScript isn't a super set for sure. Private fields are still in beta, etc.

I'd like to see something different and designed around JS/Babel instead of C#. Flow feels abandoned and reusing types is difficult.

Collapse
jwp profile image
John Peters

How is reusing types difficult?

Collapse
the_spyke profile image
Anton Alexandrenok

Because of how types are stored in a single git repo.

Thread Thread
jwp profile image
John Peters

How is this difficult?

export lastname:string = 'default value'

Thread Thread
the_spyke profile image
Anton Alexandrenok

My comment was about how typings ecosystem works. A git repository in Flow vs. npm packages in TS.

Collapse
jwp profile image
John Peters

This leads to a very strange scenario that the more complex the issue even when you go for help, communicating the intent of the code is as important as the function. When talking about possible solutions it isn't unlike people looking at modern art trying to critique the intent and the emotion of a toilet paper roll nailed to a wall. You can spend hours perfecting an elegant solution to your types without shipping any new workable code. It makes you feel really good and clever when you get it right. It is metaprogramming to the highest degree. It gets even more awkward when you are trying to use a 3rd party library who is more concerned about spending several months getting it right than getting something out that works (while in meanwhile the current types are effectively broken).

This makes little sense to me except in the context of generics. It's the same thing as saying Picassos 'Guernica' is noisy, chaotic, ugly (all true) until you discover the history behind it. Only then is its genius seen.

Collapse
ryansolid profile image
Ryan Carniato Author

Exactly. The artistic comparison is exactly what I'm getting at. Its strange for my tools to be like Picasso. I'm not particular stoked when code is that way.

Collapse
jwp profile image
John Peters

I spent 15 years in C#. When LINQ and Generics came out, I didn't at first see the value, why? Because I was alredy doing it without them.

Once I dug in, I couldn't live without either. But, I did have to rewire my thoughts and go through a painful learning curve.

Only then, did I start noticing code duplication based on type only. Generics extended my insight and forever changed my coding style.

Today, I have not yet had the need to use Generics in Typescript, but when I do, it'll be a no brainer.

Generics aren't for beginners nor is it for typeless programmers.

Collapse
rhymes profile image
rhymes

Thanks for describing my gut feeling about TS with actual real world that goes further than toys.

I really see the point in using it as a library developer, less so as an app developer. As all things JS there's a lot of hype around it but there's also value in it. I just don't like the push towards it "just because".

TypeScript has basically dictated other technology choices

Yeah, this is a issue that I see in TS but also in Python with mypy. Theoretically you can adopt types in dynamic languages gradually but eventually everything is "omg this perfectly fine library that we used to love until 5 minutes ago doesn't have a types interface file, let's rewrite it or burden the library developers with the task of learning everything about this new ecosystem we don't fully understand either so they can build a soon to be unmaintained type file so we can finally autocomplete in Visual Studio Code and be cool" 👀

Collapse
jwp profile image
John Peters

What 'dictation' do you refer?

Collapse
qm3ster profile image
Mihail Malo

I'm concurrently building a backed service in TypeScript and clientside in Svelte.
I didn't bother including TS in the clientside for the non-component files.
I find it extremely helpful, doubly so with RxJS (on the backend), where it has surprisingly good inference.
That is despite the fact that are bugs/rough edges in the typedefs though, for example when you use multicast as one of the adapters in pipe.
It obviously is a subset of JS, and that is partially the point.
You mention type inference (where you mention generics), but I must say it is actually very poor at the moment.

const arr = []
arr.push('🥔')

Oh wow, that's an Array<never>? Good to know.

Collapse
jwp profile image
John Peters

TypeScript uses generics way more liberally than you are used to with C++ or Java.

This statement has no proof or value. C#, the king of generics, has it front and center as a main enhancement to compliment LINQ.

Too bad Java lagged the curve by 7 years and poorly implemented generics.

Even cooler, their type can often be inferred which means you don't even need to annotate and everything magically works.

Oh, you mean cohersion is cool?

Collapse
jwp profile image
John Peters

That is until you add a few extra levels on to, and you start coming across the inconsistencies, or the places where types can't be inferred.

What inconsistencies?

Types can never be inferred where there's no definition. But how difficult is it to define 'any'? Pretty simple to do.

Collapse
seanmclem profile image
Seanmclem

With minimal effort and minimal extra code -you can use typescript to drastically improve readability and maintainability of your projects. Some of the problems you pointed out can be bypassed with a one-off any

Collapse
jwp profile image
John Peters

This is the 2020 Tech Statement of the Year.

Even Eric Elliot can't refute that point, but he tries in his Medium articles.

Eric wrote books on the greatness of Javascript before Typescript came out. He regularly casts shadows on Typescript and doesn't acknowledge that Typescript was 2 years ahead of Javascript recently. He prefers linters over built in type safety.

Collapse
jwp profile image
John Peters

change your API or add another function call to get the compiler to work the way you want, I was understandably very uncooperative.

This statement makes little sense to me. Please explain.

Collapse
ryansolid profile image
Ryan Carniato Author

I linked an example in the Material UI docs but I also hit this a couple times in Solid with JSX type casting. Like look at createStyles in this documentation TypeScript with Material UI. This function call is necessary to make TypeScript work nicely even though it is essentially a no-op and pure runtime overhead.

Collapse
jwp profile image
John Peters

I like your work on solid.js, the concept is great! I just did the same thing on a work project using only Json to create the component.

Collapse
jwp profile image
John Peters

However, on the frontend, it has been nearly a disaster.

This quantifies 1) lack of interest 2) lack of leadership 3) lack of skill and 3) new tech rejection from the Javascript world of chaos.

Collapse
ryansolid profile image
Ryan Carniato Author

Likely a lot of those things. Difficulty with 3rd party libraries with the same set of issues as well. We found we had to fix types on 3rd party libraries a number of times and did our part submitting PRs. This article is mostly a response to the universal praise TS receives. I don't think all the issues are with TS itself.

Collapse
jeromedeleon profile image
Jerome De Leon

I really need this right now. Thanks!

Collapse
jwp profile image
John Peters

What I've witnessed with TypeScript is that 30 line CoffeeScript file is now 150 lines.

Who cares about Coffeescript? It's dead. Why bring in coffeescript comparisons?

Collapse
ryansolid profile image
Ryan Carniato Author

CoffeeScript exemplifies some of the benefits of JavaScript that tend to be lost from the TypeScript perspective. I'm not recommending using CoffeeScript right now. Simply that JavaScript has some of those characteristics and they aren't as distinctly bad as one might believe.

Collapse
ronca85 profile image
Info Comment marked as low quality/non-constructive by the community. View code of conduct
ronca85

Maybe you don't realize this but all the mumbo jumbo code you come up with in the states ends up like literal garbage in the 3rd world where people maintain these awful legacy projects and have to learn all the fancy methodologies and "best" practices a few years down the line for peanuts. And you guys are most likely completely oblivious that you are doing this. You keep going in circles, keep reinventing the wheel, make package, make library, go to conference, make a speech, ask for donation, repeat and never stop creating new garbage piles that you wrap up nicely and ship out and then go tap yourselves on the back for being a good boy and doing a great job, oh yes. Programming is EASY. People are DIFFICULT. How many languages do you need get a piece of data from one machine to another?

In general, I was looking into ts, came across this article, tried reading it but a lot of sentences make no sense. As if no one proofread any of it. But the conclusion is this is just another thing to learn once the americans move on to something new that isn't new at all.

Collapse
ryansolid profile image
Ryan Carniato Author

That's interesting. I am actually not an American and just moved to the US a couple of months ago. But I hadn't heard that take before. So I have to admit, I have had no appreciation for that scenario. Generally, you think you are making things better every time you discover a new way to improve performance, improve tooling, or find an easier abstraction. Then again I've spent most of my professional career working on small teams developing a single product over the course of several years. In that scenario after maintaining something for a decade you tend to think a lot about the limitations of the original system, and how you'd do it differently next time.

And a lot of this article was reflecting on the team making this switch when we finally retired the old system (May 2011-Dec 2020). Ironically it was this same experience that lead me to writing my own UI library, initially hoping to improve development at the company. I guess it's just a matter of perspective. I saw the experience as an opportunity. Ironically as much as I still dislike TypeScript, it was unanimous that it was the way to go. That's with myself from Canada, a lead front end dev from Spain, a junior front end dev from Japan, a backend dev from Korea, a senior backend dev from France, a devops engineer from Bulgaria, and a QA lead from the UK.

But I haven't had the distinct pleasure of maintaining someone else's code for years. Everyone was excited to work on our project. So I probably can't appreciate the scenario where you are basically being forced to learn the latest greatest thing long after it is considered so. I definitely had to slog through decade old open source projects, but when it came time to finally lay that beast to rest we got to choose what we used. And TypeScript one of them.