loading...

TypeScript is slow. What can we do about it?

alekseiberezkin profile image Aleksei Berezkin ・4 min read

Before the takeoff

I was working on my project when noticed my laptop fan is spinning like before the takeoff. I checked htop and found out there's a node process spawned by WebStorm, and this process' CPU consumption skyrockets to 100% each time I edit a TS file. It took 10–20s for the process to finish its work and to release the CPU.

I started googling and encountered quite a few issues about TypeScript and crazy fan spinning submitted both to TypeScript and WebStorm. Unfortunately they where barely helpful so I decided to make a small research.

Profiling the language service

I asked for a suggestion on JetBrains community forum and was kindly instructed to take V8 profile. It showed me that there is some heavy 20-seconds computation triggered by getSemanticDiagnostics:

FlameGraph

getSemanticDiagnostics is a TS language service method which analyzes a file for errors like “x is not assignable to type y”, “type x does not have property y” etc. It seems okay that WebStorm invokes it on each edit, but what is it doing that long? Is there a busy waiting or an endless loop? To understand it I decided to get my hands really dirty.

Debugging the language service

I attached to the node process and paused it several times. There was very very long stack:

Debugger stack

On the first sight it seems like it's too hard to find out what's going on; but actually there are things revealing general picture.

First, there's a loop iterating over all statements in the file:

forEach

Next, down the stack, there's a type inference request for a specific place in my file which is visible through arg:

Infer types

Apparently this request is executed for every single part of the file. Next, it lands onto the long recursive chain of checkTypeRelatedTo(), isRelatedTo(), recursiveTypeRelatedTo() etc. which, as seen, performs the real CPU-intensive work of inferring types.

isRelatedTo calls

But why is type inference that heavy?

Indeed, a lot of languages can infer types, is there something special about TS? Well, I see two things:

  • TS type system is exceptionally rich and powerful, way more powerful than that of Java or Scala. This also means that the size of a code that infers types is huge.
  • Unlike many other languages, TS is written on a slow scripting language — JavaScript. Now, don't get me wrong, I love JS and appreciate its value for web, but... It wasn't intended to build so complex and computational-demanding things like TypeScript! Which I also love 😢

So the problem is clear now

  1. On each edit, WebStorm calls TS Server's getSemanticsDiagnostics method
  2. The method analyzes the whole edited file, running types inference where needed
  3. That type inference is very, very expensive, and furthermore seems it's not linear of the file size

Or, putting it in one short conclusion:

TypeScript is slow by nature. Its performance degrades with the file size, and the relation is likely non-linear.

But what can we do?

Just keep files small. How exactly small depends on your computer, and what fan noise you can tolerate 😀 I personally try to stick to these limitations:

  • No more than ~400 lines
  • No more than ~20 imports

Perspectives

TS codebase grows with each release bringing us new cool features. But this also means one day even short files will burn out our CPUs! What can the TS team do about it? I'm not a sci-fi writer to predict the future, but I'll try 🤓

So, TS team can:

  1. Migrate TS to some compiled language. Too late perhaps, but who knows 😉
  2. Make TS language service able to partially analyze a file. This requires very deep integration between the service and an editor, which may possibly bring other hard problems.
  3. Utilize WebAssembly. It's not stable in node for the moment, but this will happen one day. The language service may be split to API and computational parts, and latter may be compiled to WASM.
  4. Develop or adopt a tool compiling JS (TS) to some lower-level representation like LLVM or even to the native code!

I believe TS team adopts (3) or (4). Furthermore, I suppose it's partially possible even now! However, that's not the way for the webdev majority, and the TS team needs to implement some tooling to simplify the process. Yet, of course, editors need to support an optimization path which TS team chooses.

Staying tuned

Whatever the technology is, it has limitations, and TypeScript is no exception. And we must admit, there's certainly a room for improvements! So, staying tuned for news!

Thanks for finishing this reading. If you find it interesting, please consider leaving some feedback or following me on DEV.to or Twitter. I'm new here and I'd be glad to know if this kind of stuff is helpful. Thanks.

Discussion

pic
Editor guide
Collapse
sharpninja profile image
The Sharp Ninja

This article cracks me up! As long as the tools for TypeScript are written in TypeScript, and TypeScript continues to compile to a web browser scripting language (which WASM is as well, BTW), it's going to be slow. It's that same chuckle/disgust I feel when someone tells me their Node app doesn't perform well under load and they truly cannot fathom that it's because they have quite literally chosen the second-worst platform (the worst being Ruby) from a cost-performance perspective.

Collapse
shaunakde profile image
Shaunak De

My thoughts precisely. For more time then care to admit I spent working on close to a million line C++ codebase in Visual Studio. Compile times were coffee break times, but I never felt IntelliSense lagged in any way. I work in golang now. While compile times have dramatically gone down (I also work on a much smaller codebase now) - the tooling never seems to live up to my memory of Visual Studio 6. The cold hard truth of computers is that interpreted languages will (as of 2020) be slower then compiled ones - even for clever developer tooling.

Having said all this - I never want to write a website using TreeFrog ever again.

Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

Is Golang interpreted? I haven't yet tried, but Wikipedia suggests it's compiled...

Thread Thread
shaunakde profile image
Shaunak De

No, it's compiled. But its biggest party trick is that it compiles really quickly. A small example: stackoverflow.com/questions/297663...

Thanks for writing this blog post. I really enjoyed learning about Typescript. Front end development is opaque to me, and I like atleast knowing what's new!

Collapse
ivanjeremic profile image
Ivan Jeremic

Node is amazing.

Collapse
sharpninja profile image
The Sharp Ninja

Amazingly bad.

Thread Thread
ivanjeremic profile image
Ivan Jeremic

I love it :)

Thread Thread
sharpninja profile image
The Sharp Ninja

That's some strange love. :)

Thread Thread
ivanjeremic profile image
Ivan Jeremic

I love to write apps with the most used and most flexible language in the world:)

Thread Thread
sharpninja profile image
The Sharp Ninja

Most used does not equate to best.

Thread Thread
ivanjeremic profile image
Ivan Jeremic

Yeah we know it but the reality is if you want to start using C++ for everything good luck. Also I have no idea why the negativity against wasm you know that the internet (browser) is a place where where amazing software runs not everything can be in app stores or local software. Being in the browser gives you the advantage that you can sit on any device and start working where you left on the other device, SaaS software like monday.com, hootsuite, Figma, or things like CodeSanbox, imagine them being only locally available they would be useless. What I want to say the future is cloud for the most part and the user facing Apps and UI will not be 100 % nativ but the speed will be almost there so end users will never be able to tell.

Thread Thread
sharpninja profile image
The Sharp Ninja

My problem with web is not the concept, but the implementation. At almost every major inflection point along the way the worst possible technical solution presented was the one chosen.

Thread Thread
ivanjeremic profile image
Ivan Jeremic

For me the browser of today feels better than 5 years ago and it keeps improving since I know that browsers exist, What you want is a perfect world how we ship apps and in what language they are written but other then streaming the apps to the user so people use apps on play button like a Netflix video or like a Google Stadia game I can't think of an other solution this way whole operating systems could be streamed to the users and everyone walks around with devices able to open this, and again most likely it will be browser on this devices that are used for this as you can see with Google Stadia so I don't know what the future is but it is for sure not only Native/Local apps

Thread Thread
sharpninja profile image
The Sharp Ninja

Most of the reason that browsers today feel better than 5 years ago is because today's computers have more memory and most phones have a LOT more memory than back then. The fundamentals of how the web works hasn't changed, and today's JavaScript framework du jour will be out of style in five years for another framework that uses even more memory and CPU because both will be even more readily available then.

So how do we fix it? First, we have to educate EVERYBODY on how the web actually works and the costs involved in propping up terrible platforms and frameworks out of the desire to hire the cheapest developers possible (ie. inexperienced and/or naïve). Here's a great case-study that explains how raygun.io improved performance by 2000% by migrating from Node to ASP.Net Core. Businesses need to know this stuff because being able to reduce your server count by 60% has a very big cash-flow and profit impact on your business. This is very, very real and very, very important for the long term health of your company.

And any web-centric view of the world is blind to the fact that apps are far more popular on mobile:

Recent research shows that 90% of their mobile time is spent in apps, and only 10% browsing the rest of the internet. In the ecommerce space, the contrast is even more glaring: mobile app users spend an average 201.8 minutes per month shopping, compared to 10.9 minutes/month for website users.

Additionally, apps generate more conversions, on average 4.1x more than mobile web browsers.

Why is this? User's prefer real apps because they are more immersive, perform better, and can be used offline (depending on purpose of the app).

Thread Thread
ivanjeremic profile image
Ivan Jeremic

We all know these statistics, and listening to them it sounds like the web is dead and there are no jobs and nobody uses it, which is totally not true and it is the opposite, I think there will always be both.

Thread Thread
sharpninja profile image
The Sharp Ninja

You know the stats and ignore them for what purpose? My goal is to educate business owners and executives of the absolute wastefulness of scripting languages for application code on both the client and server. Think about how much electricity is wasted by every unicorn running on node or Ruby....

Thread Thread
ivanjeremic profile image
Ivan Jeremic

C# is in my opinion also a scripting language, and I already told you that this is a myth there a tons of SaaS products running in the browser successful and millions of people use them, I know loosing clients to web devs must hurt but instead of fighting about languages just do your thing and write software how you think it is best. Also my focus is on desktop I don't think you will ever walk into an office and see people have no PCs and only work on smartphones.

Thread Thread
sharpninja profile image
The Sharp Ninja

C# has allowed for native AOT compilation from day 1. Over the years that has gotten better and better, too, with .Net 5.0 even advocating AOT and single-file distribution that requires zero dependencies.

And though your focus may be on desktops, Android already has an active market share that is double that of Windows, then throw iOS in on top of that. And especially on Desktop you can create far more immersive and creative apps with native than with web technologies. The CPU power of desktops tends to mask the deficiencies of JavaScript as long as users don't go nut with browser tabs, but that is rarely the case and users wind up hating web apps and don't understand that it's because they've been given this tool that is fundamentally flawed and it is forced on them out of the laziness of people who would rather pass on the cost and expense of hardware to customers than incur the cost and expense to deliver a quality product.

Thread Thread
ivanjeremic profile image
Ivan Jeremic

I will just say Discord. It grows like crazy and it is likely to become one day number one.

Thread Thread
sharpninja profile image
The Sharp Ninja

Discord is an interesting case. As a website, their service works fine, but their Electron client is a horrible resource hog. In the attachment you can see it launch a separate process for each server you have joined. It does nothing but chat and very poor streaming. It does have a friendly UI, but that is easily replicated with a native app such as Quarrel which start up in a fraction of the time and use less RAM.

Comparison of Discord vs Quarrel

Collapse
eljayadobe profile image
Eljay-Adobe

Ruby can't be worse than PHP.

Collapse
ivanjeremic profile image
Ivan Jeremic

Both a horrible.

Collapse
loouislow profile image
Loouis Low

Horrible and dinosaur.

Collapse
sharpninja profile image
The Sharp Ninja

Performance-wise Ruby is about as bad as it gets. Newer versions of PHP are actually pretty performant, but the security is still the worst.

Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

Not only tools for TS are written on TS, the TS itself is written on TS! What you described, I'd call it a “prototype trap”. It's so fast and nice to quickly hack MVP on JS or Python, but it's very painful afterwards if the prototype evolves to the product as is. However writing everything on C++ from the very beginning may increase the initial cost of a product. Sooo... It's hard, and there's no simple answer 😢

Collapse
sharpninja profile image
The Sharp Ninja

C# is nearly as performant as C++ and Rust overall and offers a far more productive development lifecycle than C++.

Collapse
futureistaken profile image
R Z

Webstorm itself is very slow.
I never saw any problems with TS using VScode. Everything works very very fast, including TS.

Before giving any recommendations about what TS team must do, throw away your laptop out of the window and buy a good PC. The second option, get rid of the webstorm.

I did the exact things that have been described above and I am happy.

Don't forget that people need high-performance PCs not only for gaming, but also for working with modern technologies.

Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

Thanks for your suggestions! But I'd better keep that MacBook Pro with me 😀 In VS Code the effect is less noticeable, yes, but only to some degree. With enough memory tsserver consumes much more CPU than the editor. Yet, tsserver performance is the same regardless of the editor.

Collapse
futureistaken profile image
R Z

On my PC TS works very fast in any environment.

Thread Thread
alekseiberezkin profile image
Aleksei Berezkin Author

Sure, having a big and powerful computer is better than having a small and limited laptop. Personally I don't like laptop keyboards (and especially Apple touchbar), I don't like small screens, I don't like fan noise, I don't like carrying it with me. But unfortunately I have to. Using laptop is always a compromise. It's not the best equipment I can imagine, it's just the most adequate for me.

Collapse
dbanisimov profile image
Denis Anisimov

Sure, TS is not blazing fast and you've pointed out the main reasons for that, mainly having a very powerful type system. It worth noting that TS analyzes not only the source files in the project, but also all of the dependencies, so the source size doesn't matter as much as the overall tree size. Most of the huge performance problems I've seen were due to some 3rd-party library trying to create very complex types, which library maintainers and TS maintainers usually take very seriously and eventually fix or improve type inference performance. It's always a good idea to keep TS version up-to-date as the team ships perf improvements in every release. (dangerous tip: you can boost TS performance by using an option --skipLibCheck)

I'm personally a bit skeptical about options 3 and 4. Native code is not a silver bullet, and a scripted interpreted language doesn't imply bad performance. IMO the way forward is for node to implement more advanced JIT optimizations and for TS to focus on higher-level optimizations, like caching and improving the IR and algorithms.

Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

Thanks for an insightful comment. That's true that not only file size matters; I've noticed that the number of imports matters. This is similar to what you write about the overall tree size.

I agree that optimizations I speculate may not be the focus of the TS team; that's why I wrote it's a sci-fi 🙂 However, V8 optimizations are also not a silver bullet; V8 is already heavily optimized.

About TS optimizations — yes, agreed. There are some issues in the TS repo like “let's memoize something”, and the code I saw looks like there is not that much cached. But, you know it, caching is hard: keeping editor and TS Server in sync is very hard problem.

Anyway, looking forward for news, I believe something interesting happens soon!

Collapse
joelbonetr profile image
JoelBonetR

Can you, please share your laptop specs for adding context?
I developed with TS using a shitty i5 8250u and 16Gb RAM, also tried with a R5 3500u with 8Gb RAM and it was fine, next week I'll try with my new office laptop which is an i7 1065G7 with 16Gb RAM and I'll see if there's any visible improvement

Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

It's good but usual MacBook Pro with i7 and 16 GB RAM. Most of the time it's fine; interesting things begin when the file size approaches 1,000 lines and heavily uses type inference. Funny is that not specifying types and letting a compiler figure them out is somethings we like TS for 😀

Collapse
sharpninja profile image
The Sharp Ninja

Not specifying types is an anti-pattern and the root of your problem.

Thread Thread
alekseiberezkin profile image
Aleksei Berezkin Author

Could you please elaborate a bit on this? Because I actually heard the opposite.

The Effective TypeScript by Dan Vanderkam discusses this in details:

Chapter 3. Type Inference

Item 19. Avoid Cluttering Your Code With Inferrable Types

(...) in TypeScript many annotations are unnecessary. Declaring types for all your variables is counterproductive and is considered poor style.
(...)
Ideal TypeScript code includes type annotations for function/method signatures but not for the local variables created in their bodies.

Things to remember

  • Avoid writing type annotations when TypeScript can infer the same type (...)

I agree that this may be the place where the beautiful theory meets the harsh reality. But anyway, type inference is something every language is sort of proud of, and one of their promotion points. And keeping away from this feature looks like artificially limiting your expressiveness.

Thread Thread
sharpninja profile image
The Sharp Ninja

I hate terseness for the sake of terseness. Yes, many languages can infer type at compile time, but as you can see from your own experience is that there's a huge cognitive load on the toolset to do so. Now, think about a human reading your code and having to apply the same type of cognitive load to infer types so they can effectively maintain your code.

Thread Thread
alekseiberezkin profile image
Aleksei Berezkin Author

I think that may be a matter of measure. And taste to some extent. Best practices have some exceptions; or these are the part of a best practice. However, I doubt you like an example without a single inferred type.

// 3 types inferred: upper, i, output of map
const upper = (a: string[]) => a.map(i => i.toUpperCase())

// 3 types inferred: a, i, map output
// This is recommended in Effective Typescript
const upper: (a: string[]) => string[] =
    a => a.map(i => i.toUpperCase())

// All types are explicit
const upper: (a: string[]) => string[] =
    (a: string[]) => a.map<string>((i: string) => i.toUpperCase())
Thread Thread
sharpninja profile image
The Sharp Ninja
// All types are explicit
const upper: (a: string[]) => string[] =
    (a: string[]) => a.map<string>((i: string) => i.toUpperCase())

or

Func<IEnumerable<string>, string[]> Upper = 
    a => a.Select(i => i.ToUpper());

With C# the compiler only needs one type specification and then the IDE simply knows the variable's type because it cannot change and thus doesn't have to be inferred at each usage. The single strongly typed Func<> declaration has all the types defined for the lambda.

Thread Thread
alekseiberezkin profile image
Aleksei Berezkin Author

I don't get your point. You don't like type inference in TS but like it in C#?

Thread Thread
sharpninja profile image
The Sharp Ninja

It's not inference in C#. The types are known at declaration and cannot change. The issue that the original article is about is a side-effect of TypeScript constantly trying to enforce types when none actually exist. Strong typing in TS is an illusion, and the only way to prop up that illusion is for the language server to constantly calculate the object graph's types so it can notify of illegal assignments.

Thread Thread
alekseiberezkin profile image
Aleksei Berezkin Author

Knowing types from a context is not a type inference? Whut? 😲 Then what is type inference, if not this? How does editor “know” that i in your C# example is a string? Compiler (or editor plugin, the same) infers its type for you. To achieve this, it constantly monitors all changes (just like TS server), and restarts the process whenever something is changed (just like TS server). Otherwise how this would work do you think? All languages work the same. For TS there are certain things which make it slow, and this can be improved — that was my point.

Thread Thread
sharpninja profile image
The Sharp Ninja

There is no need to check a type unless it's declaration changes or it is being referenced as a different type than its declaration. In all other cases there's nothing to infer, the IDE already has the correct type for the object. With TypeScript you can disable strict typing for object that are implicitly typed as Any and thus create a situation where the IDE cannot know the type and must ask the language server to infer the type, which will probably come back as Any.

Thread Thread
alekseiberezkin profile image
Aleksei Berezkin Author

any works the opposite way 😀 any tells TS and IDE to stop inferring or checking a type of a var. Thus, if your code is full of anys, compilation will be the fastest. In my example there's not a single any, all types are strict.

Collapse
codejym profile image
Code-Jym

i5 is sh**ty? Try working with Intel celeron and 4 gigs RAM. 😂

Collapse
prinzsabishi profile image
Michał Pędzik

Interesting article! I would love to see TS being written on some compiled language.

Collapse
joelbonetr profile image
JoelBonetR

Doesn't Web Assembly are meant to be the performant front-end executable?
I mean, you can write on Rust, Kotlin and many others and compile it into web assembly if you are going to the better performance.

Collapse
sharpninja profile image
The Sharp Ninja

WASM still is a scripting language that is running in the JavaScript engine of the browser. The advantage of WASM is being precompiled to tokens (in a binary format) that eliminates a lot of parsing that is required with JavaScript.

Thread Thread
joelbonetr profile image
JoelBonetR

And what's the advantages of that workaround while on production?
I alrrady minify, obfuscate and so my JS when transpiled.

Thread Thread
sharpninja profile image
The Sharp Ninja

Even transpiled JS in its rawest form has to be read, parsed and tokenized before being executed. WASM has all of these steps completed ahead of time.

joelbonetr profile image
JoelBonetR

Damn I just realized that I didn't catch the WASM concept as Web Assembly 😂😂😂 thank it was some other new tool that transpilates into js

Collapse
prinzsabishi profile image
Michał Pędzik

Probably, you are right with this. I am beginner so I don't know which is good and which is bad in the topic of performance. I am just curious! That's it :)

Thread Thread
joelbonetr profile image
JoelBonetR

Haha no problem, there are many languages and tools around, it's a community issue to use the fancy tool instead of the correct one for the job.
When you're about to release let's say a landing page you must not use any JavaScript Framework such react, angular, preact, svelte... with or without TS which is only a JS superset. Nor will you use a java or C# environment because it's a waste of resources, you need to choose plain HTML, CSS (sass or scss on dev time) and the minimum JavaScript possible due to performance and specific use case / target (which on a Landing page it's SEO and speed).
By the other hand you can use angular, preact, react, svelte... On a private web app to provide a service to your customers (having or not a node back end, this is not important here) due to user experience and easy to develop and scalability for example. There are many use cases and few better options to reach the desired target easier or on a better way regarding to the future 😁

Thread Thread
sharpninja profile image
The Sharp Ninja

due to user experience and easy to develop and scalability for example.

You got one of three right. User experience suffers with web technologies compared to native apps which are much faster, safer and more reliable. JavaScript is one of the least scalable platforms ever created and Node gets crushed under lots of users as it has to start a new process for every simultaneous request. But it is easy to develop for web (as long as you have a consistent set of requirements and platforms to work on and stuff...).

There are many use cases and few better options to reach the desired target easier or on a better way regarding to the future

Utter nonsense.

Collapse
elmuerte profile image
Michiel Hendriks

Isn't the real problem TS's language server? Why does it need to visit so many files every time. Can't it just keep around the "compiled" results? It doesn't need to rebuild the whole AST for the file you are editing... right? Or is this a limitation of the language server protocol design?

Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

These are very good questions! The server could have cached something but this, I suppose, would only trade problems: if there's caching, chances are the editor and the server may get out of sync. Invalidating caches is always a hard problem.

Collapse
elmuerte profile image
Michiel Hendriks

Sure, but the IDE should obviously communicate changed regions. This how IDEs work internally with languages they support as first class citizens.

Thread Thread
alekseiberezkin profile image
Aleksei Berezkin Author

I'm not sure TS supports this. Do you have some insights?

Collapse
ecyrbe profile image
ecyrbe

You can use the typescript compiler deno has started to use that is written in Rust:
github.com/swc-project/swc

Build typescript faster. Now you need to replace ts server with swc but that's another project that is not created yet.

Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

Interesting! How quickly does it pick up new features of TypeScript? There's not much in the docs.

Collapse
ecyrbe profile image
ecyrbe

Yes, their documentation doesn't directly point to features, but in fact they are listed in comparison with Babel here:
swc.rs/docs/comparison-babel

Collapse
ivanjeremic profile image
Ivan Jeremic

I would claim that it is useless and unproductive more time is spent on finding types and fixing types than developing, good eslint setting and good editor are better that TS in my opinion, TypeScript and Types developed a hype similar to Apple products almost a Type fanbase who type everything everywhere and all he thinks is types types types, if you are one of there who use TypeScript to detect missing imports or underline unused variables and functions then you don't need TypeScript, this is also possible without it.

Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

I hear this quite often about TS. However, IMO there's no controversy: if you feel you don't need types, you actually don't need them. Lucky you! Your editor is fast, and npm scripts are short. You are happy developer who've never worked in large old enterprises in its worst sense. Having types in such projects is usually the only good thing about them.

Collapse
ivanjeremic profile image
Ivan Jeremic

I'm not against types but it gets crazy if types are more code then my actual code, I'm for to only type what is really needed like what gets returned that's it.

Thread Thread
manitchanthavong profile image
Manit-Chanthavong

TypeScript pulled me back into Node.JS development. . Without TypeScript I would have ditched node and moved onto a different platform altogether.

IMO, developing with node, typescript, vscode is a whole lot faster and more enjoyable than asp.net core, c#, and vs. However, for large Node apps, there are some serious development patterns you have to be aware of to make your app successful.

Thread Thread
0916dhkim profile image
Donghyeon Kim

Same here. I would never have come back to nodejs if there wasn't TS.

Collapse
stereobooster profile image
stereobooster

I disagree with some points in article, but... big kudos to author who responses with grace to all bad takes in comments

Collapse
himujjal profile image
Himujjal Upadhyaya

I therefore started ekscript.com
Because I thought Typescript was now mature enough to have a standalone compiler/interpreter.

Your post is absolutely correct. I therefore had to ditch VS Code or JetStorm IDEs in favour of Nvim-QT. I don't face the problems you do though. Everything is snappy.

Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

Thanks for sharing a link! Is this the repo? github.com/ekscript/ekscript There's no code 😕

Collapse
himujjal profile image
Himujjal Upadhyaya

It is. There's no code. Just the concept put out. I started it. I hope i pull this off in future though. not giving any hopes though. just that typescript is an awesome language

Collapse
zyzmoz profile image
Daniel Cunha (he/him)

I'd say that your post title should be "Programming Best Practices"...
Webstorm and typescript might overload your computer resources for a number of reasons. If you take account of what your IDE/Editor, bundler, compiler, lint, and others do, you'll see that larger files are way expensive to perform actions (compile, syntax checks, etc) than smaller ones...
Still, you shared valuable content! Thanks :)

PS.: I've been using a MacBook Pro 2013(i5/ 8gb RAM/ SSD) to work with numerous projects of different complexities and sizes. Therefore, it works fine with 4 VSCode instances, servers, RMDBS, Browsers, Spotify and more

Collapse
obnoxiousnerd profile image
Pranav Karawale

I see some options for this TS issue(fingers crossed for this to be finished):

  • Wait for swc to implement type checking
  • Compile tsc using nectarjs (I tried but got lot of errors)
  • Bear with ye good ol' tsc
Collapse
ender_minyard profile image
ender minyard

JavaScript has performance limitations. We can see this with slow SPAs. Now, with TypeScript, we're seeing the limits of JS as well.

If I were using TS, I would always target WASM, then do a plain JS fallback for browsers that don't support WASM (module/no-module pattern).

Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

Yep, WASM is promising, and its support in node is coming. I'm talking about node because I'm discussing the development process here which is usually supported by TS server running on node. But anyway, a lot of applications, as expected, may benefit from full WASM support.

Collapse
juancarlospaco profile image
Juan Carlos

"TypeScript way more powerful than Java or Scala." Citation Needed!.

Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

TypeScript type system is 😀 That's not a citation, that's my own impression

Collapse
juancarlospaco profile image
Juan Carlos

Types on TypeScript are kind of limited compared to other programming languages, to name a few things missing:

  • Subrange types
  • JSON types
  • Regex types
  • int8/16/32/64 types
  • Char types
  • Option types
  • Dependent types
  • Custom Operator Overloading by Type on any Type
  • Types with Side Effects Tracking
  • Types with enforced run-time bounds checking
  • Probably more I dont remember...
Thread Thread
alekseiberezkin profile image
Aleksei Berezkin Author

I'm not sure it's correct to expect from TS some “custom” primitives or anything in runtime 😀 TS doesn't have a runtime, and cannot add anything to JS primitives. These are parts of the TS type system which, combined together, form the TS uniqueness: unions and intersections, ambient types, augmented types, mapped types, conditional types (T extends U ? X : Y), inference by request (T extends Array<infer E> ? E : never), types assertions, types widening and narrowing. Now they added yet more: template literal types.

Thread Thread
juancarlospaco profile image
Juan Carlos

Other languages just have it builtin since long time ago for frontend too.
I said run-time not runtime.

Collapse
matthewpardini profile image
Matthew Pardini

I think webstorm is your problem here. What version of typescript were you on?

Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

The latest stable version (4.0.3). As I already answered somewhere, with VS Code the effect is less visible. But tsserver was consuming exactly the same CPU (100% for ~15 seconds) in both cases.

Collapse
matthewpardini profile image
Matthew Pardini

Well if you read the GitHub issues on this, it does appear that there have been a few concurrent issues since sometime in version 3.3.x. VsCode handles it better by clearing cache automatically for you. Sure typescript could be faster, but why not use a better suited IDE for the job?

Thread Thread
alekseiberezkin profile image
Aleksei Berezkin Author

Again, tsserver process performed literally exactly the same for both editors. WS heaviness is the different topic, perhaps a subject for another post 😄 That's why I'm not going into these details here.

Thread Thread
matthewpardini profile image
Matthew Pardini

There are GitHub issue comments from 2019 saying that in vscode tsserver does not do that if you follow certain steps. And in a later version of vscode made those steps automated. If you’re saying it is still doing that on the latest version, you ought to file a new bug. The ide isn’t irrelevant.

Thread Thread
alekseiberezkin profile image
Aleksei Berezkin Author

You are right. I found an open issue which was lacking an example file and attached my file on which issues reproduces. Thanks for convincing me. github.com/microsoft/TypeScript/is...

Collapse
loouislow profile image
Loouis Low

WebStorm is a resource eater. The IDE also makes my expensive DELL workstation PC noisy after few hours of use. I had to use WebStorm because I still have few weeks left before the license expired. And it is expensive too.

Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

WS is definitely CPU-demanding, however, it's the price to pay for its cleverness. But anyway, I'm discussing here only tsserver performance which was the same regardless of an editor.

Collapse
bennypowers profile image
Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

Is it possible to integrate WS or VSCode with this tool? Briefly looked into a documentation, haven't found anything about it.

Collapse
bennypowers profile image
Benny Powers 🇮🇱🇨🇦

esbuild won't do any typechecking, just transform to javascript

I prefer to do it with @web/dev-server for a buildless development workflow

modern-web.dev/docs/dev-server/ove...

Collapse
cyberhck profile image
Nishchal Gautam

Try a i7 ssd computer with Linux on it and see if you notice any difference at all (you should).

Collapse
jonrandy profile image
Jon Randy

TypeScript is slow. What can we do about it?

Stop using TypeScript! 😉

[ ducks ]

Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

It's because of the nature of the JavaScript web. Stop using web? 😅

Collapse
jwp profile image
John Peters

Does same failure happen in Visual Studio Code?

Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

Yes. However, because VSCode eats less CPU itself, the overall effect is less noticeable.

Collapse
jwp profile image
John Peters

Your analysis of this issue is over the top good! Was wondering if breaking the work down into separate composable parts would help. For example in TS I'm just know breaking into using more function libraries to replace any code that doesn't really follow my own strict separation of concerns. Even if I spot for example 15+ lines of code in a component, that has for example 20 other functions in it. I split them off into one file named for the concern which contains one or more functions of only that filename's concern.

What I found in doing this is that when in development mode (using webpack development server) none of those functions get recompiled because, well, because they didn't change. This makes for ultra fast reloads in the browser.

But there's a small price to pay for this, in that some changes never get picked up (probably mostly my fault) until I do a new build. Why this happens is unknown to me but I don't think the hot reload logic is bullet proof. TS function files work better than Class files because the functions are first class citizens just like a class. They are better because if we allow a class to contain all the functions, creating an instance loads all the functions! When using the function method the loading is only for the imported function.

Also in regards to the language service differences between WebStorm and Visual Studio Code, this indicates that WebStorm is doing something different that may be adding to the problem.

Thread Thread
alekseiberezkin profile image
Aleksei Berezkin Author

Separation of concerns is always a good thing, regardless of the language. For TS the most performant dev environment is a lot of small files.

I also used to encounter wepback stuck, not sure what's that. This happens sometimes for Babel and JS as well.

Regarding WS vs VSCode tsserver usage — yes, they are doing it slightly differently. However, the result CPU load is the same. Again, I'm talking about tsserver in isolation. Additional load from WS is a subject for completely different post 😀

Collapse
seanmclem profile image
Seanmclem

use less code-formatting extensions. That's what slows down vs-code

Collapse
alekseiberezkin profile image
Aleksei Berezkin Author

I'm using only standard plugins. Is there anything you advise to turn off?