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 ...
We're a place where coders share, stay up-to-date and grow their careers.
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.
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.
Is Golang interpreted? I haven't yet tried, but Wikipedia suggests it's compiled...
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!
Node is amazing.
Amazingly bad.
I love it :)
That's some strange love. :)
I love to write apps with the most used and most flexible language in the world:)
Most used does not equate to best.
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.
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.
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
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:
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).
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.
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....
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.
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.
I will just say Discord. It grows like crazy and it is likely to become one day number one.
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.
Ruby can't be worse than PHP.
Both a horrible.
Horrible and dinosaur.
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.
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 😢
C# is nearly as performant as C++ and Rust overall and offers a far more productive development lifecycle than C++.
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.
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.On my PC TS works very fast in any environment.
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.
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.
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!
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
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 😀
Not specifying types is an anti-pattern and the root of your problem.
Could you please elaborate a bit on this? Because I actually heard the opposite.
The Effective TypeScript by Dan Vanderkam discusses this in details:
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.
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.
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.
or
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.
I don't get your point. You don't like type inference in TS but like it in C#?
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.
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.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.
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 ofany
s, compilation will be the fastest. In my example there's not a singleany
, all types are strict.i5 is sh**ty? Try working with Intel celeron and 4 gigs RAM. 😂
Interesting article! I would love to see TS being written on some compiled language.
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.
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.
And what's the advantages of that workaround while on production?
I alrrady minify, obfuscate and so my JS when transpiled.
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.
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
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 :)
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 😁
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...).
Utter nonsense.
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?
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.
Sure, but the IDE should obviously communicate changed regions. This how IDEs work internally with languages they support as first class citizens.
I'm not sure TS supports this. Do you have some insights?
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.
Interesting! How quickly does it pick up new features of TypeScript? There's not much in the docs.
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
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.
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.
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.
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.
Same here. I would never have come back to nodejs if there wasn't TS.
I disagree with some points in article, but... big kudos to author who responses with grace to all bad takes in comments
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.
Thanks for sharing a link! Is this the repo? github.com/ekscript/ekscript There's no code 😕
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
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
I see some options for this TS issue(fingers crossed for this to be finished):
tsc
using nectarjs (I tried but got lot of errors)tsc
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).
Yep, WASM is promising, and its support in
node
is coming. I'm talking aboutnode
because I'm discussing the development process here which is usually supported by TS server running onnode
. But anyway, a lot of applications, as expected, may benefit from full WASM support."TypeScript way more powerful than Java or Scala." Citation Needed!.
TypeScript type system is 😀 That's not a citation, that's my own impression
Types on TypeScript are kind of limited compared to other programming languages, to name a few things missing:
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.Other languages just have it builtin since long time ago for frontend too.
I said run-time not runtime.
I think webstorm is your problem here. What version of typescript were you on?
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.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?
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.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.
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...
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.
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.Use esbuild?
Is it possible to integrate WS or VSCode with this tool? Briefly looked into a documentation, haven't found anything about it.
esbuild won't do any typechecking, just transform to javascript
I prefer to do it with
@web/dev-server
for a buildless development workflowmodern-web.dev/docs/dev-server/ove...
Try a i7 ssd computer with Linux on it and see if you notice any difference at all (you should).
Stop using TypeScript! 😉
[ ducks ]
It's because of the nature of the
JavaScriptweb. Stop using web? 😅Does same failure happen in Visual Studio Code?
Yes. However, because VSCode eats less CPU itself, the overall effect is less noticeable.
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.
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 abouttsserver
in isolation. Additional load from WS is a subject for completely different post 😀use less code-formatting extensions. That's what slows down vs-code
I'm using only standard plugins. Is there anything you advise to turn off?