DEV Community

DEV Community is a community of 722,735 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

TypeScript is slow. What can we do about it?

Aleksei Berezkin on September 28, 2020

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 ...

Read full post

R Z • Sep 29 '20 • Edited

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.

Aleksei Berezkin • Sep 29 '20 • Edited

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.

Ken Snyder • Aug 18

If you do a lot of inference it doesn't matter what beast of a machine you have. I use vscode on a iMac Pro with 14 processors and I am dealing with types that do not resolve when you hover over them for 15-60 seconds. It's intolerable. I guess I got a bit carried away with strong types and now I need to reverse course but I wish I could get a better feel for where the real pain points are coming out.

Aleksei Berezkin • Sep 2

Exactly. What is inherently slow cannot be fixed just by taking another computer, that was my point.

R Z • Sep 29 '20

On my PC TS works very fast in any environment.

Aleksei Berezkin • Sep 29 '20 • Edited

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.

The Sharp Ninja • Sep 29 '20

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.

Shaunak De • Sep 30 '20 • Edited

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.

Aleksei Berezkin • Sep 30 '20

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

Shaunak De • Sep 30 '20

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!

Ivan Jeremic • Sep 29 '20

Node is amazing.

The Sharp Ninja • Sep 29 '20

Amazingly bad.

Ivan Jeremic • Sep 29 '20

I love it :)

The Sharp Ninja • Sep 29 '20

That's some strange love. :)

Ivan Jeremic • Sep 29 '20 • Edited

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

The Sharp Ninja • Sep 30 '20

Most used does not equate to best.

Ivan Jeremic • Sep 30 '20 • Edited

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.

The Sharp Ninja • Sep 30 '20

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.

Ivan Jeremic • Sep 30 '20

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

The Sharp Ninja • Sep 30 '20

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).

Ivan Jeremic • Sep 30 '20 • Edited

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.

The Sharp Ninja • Oct 1 '20

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....

Ivan Jeremic • Oct 1 '20 • Edited

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.

The Sharp Ninja • Oct 3 '20

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.

Ivan Jeremic • Oct 3 '20 • Edited

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

The Sharp Ninja • Oct 6 '20 • Edited

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.

Eljay-Adobe • Sep 29 '20

Ruby can't be worse than PHP.

Ivan Jeremic • Sep 29 '20

Both a horrible.

Louis Low • Sep 29 '20

Horrible and dinosaur.

The Sharp Ninja • Sep 30 '20

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.

Aleksei Berezkin • Sep 29 '20

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 😢

The Sharp Ninja • Sep 29 '20

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

Denis Anisimov • Sep 29 '20

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.

Aleksei Berezkin • Sep 29 '20 • Edited

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!

JoelBonetR • Sep 29 '20

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

Aleksei Berezkin • Sep 29 '20 • Edited

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 😀

The Sharp Ninja • Sep 30 '20

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

Aleksei Berezkin • Sep 30 '20 • Edited

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.

The Sharp Ninja • Sep 30 '20

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.

Aleksei Berezkin • Sep 30 '20

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())

The Sharp Ninja • Sep 30 '20

// All types are explicit
const upper: (a: string[]) => string[] =
    (a: string[]) => a.map<string>((i: string) => i.toUpperCase())

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.

Aleksei Berezkin • Oct 1 '20 • Edited

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

The Sharp Ninja • Oct 1 '20

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.

Aleksei Berezkin • Oct 1 '20

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.

The Sharp Ninja • Oct 1 '20

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.

Aleksei Berezkin • Oct 1 '20 • Edited

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.

Tomi Adenekan • Nov 17 '20

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

Michiel Hendriks • Sep 30 '20

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?

Aleksei Berezkin • Sep 30 '20

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.

Michiel Hendriks • Sep 30 '20

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

Aleksei Berezkin • Sep 30 '20

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

Ivan Jeremic • Sep 29 '20

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.

Aleksei Berezkin • Sep 29 '20 • Edited

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.

Ivan Jeremic • Sep 29 '20 • Edited

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.

Manit-Chanthavong • Sep 29 '20

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.

Donghyeon Kim • Sep 29 '20

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

Michał Pędzik • Sep 29 '20

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

JoelBonetR • Sep 29 '20

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.

The Sharp Ninja • Sep 30 '20

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.

JoelBonetR • Sep 30 '20

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

JoelBonetR • Sep 30 '20

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

The Sharp Ninja • Sep 30 '20

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.

Michał Pędzik • Sep 29 '20

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 :)

JoelBonetR • Sep 29 '20

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 😁

The Sharp Ninja • Sep 30 '20

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.

ecyrbe • Sep 29 '20

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.

Aleksei Berezkin • Sep 29 '20 • Edited

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

ecyrbe • Sep 29 '20

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

Pranav Karawale • Oct 15 '20

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

Daniel Cunha (he/him) • Sep 29 '20

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

ender minyard • Sep 28 '20

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).

Aleksei Berezkin • Sep 28 '20

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.

stereobooster • Sep 29 '20

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

Himujjal Upadhyaya • Sep 29 '20

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.

Aleksei Berezkin • Sep 29 '20

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

Himujjal Upadhyaya • Sep 29 '20

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

Jon Randy • Sep 29 '20 • Edited

TypeScript is slow. What can we do about it?

Stop using TypeScript! 😉

[ ducks ]

Aleksei Berezkin • Sep 29 '20

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

Juan Carlos • Sep 30 '20

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

Aleksei Berezkin • Sep 30 '20

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

Juan Carlos • Sep 30 '20

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...

Aleksei Berezkin • Sep 30 '20

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.

Juan Carlos • Sep 30 '20

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

Matthew Pardini • Sep 29 '20

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

Aleksei Berezkin • Sep 29 '20

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.

Matthew Pardini • Sep 29 '20

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?

Aleksei Berezkin • Sep 30 '20

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.

Matthew Pardini • Sep 30 '20

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.

Aleksei Berezkin • Sep 30 '20

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...

Louis Low • Sep 29 '20 • Edited

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.

Aleksei Berezkin • Sep 30 '20

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.

Benny Powers 🇮🇱🇨🇦 • Sep 29 '20

Use esbuild?

Aleksei Berezkin • Sep 30 '20

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

Benny Powers 🇮🇱🇨🇦 • Sep 30 '20

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...

Nishchal Gautam • Sep 29 '20 • Edited

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

John Peters • Sep 29 '20

Does same failure happen in Visual Studio Code?

Aleksei Berezkin • Sep 29 '20

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

John Peters • Sep 29 '20

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.

Aleksei Berezkin • Sep 29 '20

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 😀

Seanmclem • Sep 29 '20

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

Aleksei Berezkin • Sep 30 '20

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