Need advice about which tool to choose?Ask the StackShare community!
C++ vs TypeScript: What are the differences?
Differences between C++ and TypeScript
C++ and TypeScript are both powerful programming languages, but they have several key differences that set them apart.
Typing System: One of the major differences between C++ and TypeScript is their typing system. C++ is a statically-typed language, which means that variables must be declared with a specific type and this type cannot be changed. In contrast, TypeScript is a superset of JavaScript and introduces optional static typing, allowing developers to annotate variables with specific types for improved code reliability and intelligence.
Compilation and Execution: C++ is a compiled language, which means that the source code is first compiled into machine code before it can be executed. This compilation process often results in faster and more efficient code execution. On the other hand, TypeScript is a transpiled language that is converted into JavaScript, which can then be executed by a JavaScript engine. This allows developers to use TypeScript in web browsers and other runtime environments.
Memory Management: Another significant difference between C++ and TypeScript is the approach to memory management. C++ provides low-level control over memory through manual memory allocation and deallocation, which can lead to potential memory leaks and security vulnerabilities if not handled properly. In contrast, TypeScript relies on automatic garbage collection, freeing developers from managing memory explicitly.
Language Features: C++ is a general-purpose language that supports low-level programming, including direct memory manipulation and access to hardware resources. It provides features such as pointers, templates, and multiple inheritance that allow for fine-grained control over the program's behavior. On the other hand, TypeScript is designed for developing large-scale applications in JavaScript. It includes modern language features like modules, classes, and interfaces, along with advanced JavaScript features like arrow functions and async/await.
Compatibility and Ecosystem: C++ has been around for decades and has a wide range of libraries, frameworks, and tools available for various domains, including game development, system programming, and embedded systems. TypeScript, being a relatively new language, has gained popularity in the web development community and is tightly integrated with JavaScript's extensive ecosystem. It can leverage existing JavaScript libraries and frameworks, making it easy to adopt and integrate with modern web development stacks.
Performance and Execution Speed: C++ has a reputation for being a highly efficient language since it is compiled directly into machine code. This allows C++ programs to execute quickly with low-level optimizations. TypeScript, being a transpiled language, incurs a small performance overhead compared to native JavaScript but still benefits from running on JavaScript engines that have been highly optimized.
In Summary, C++ and TypeScript differ in their typing systems, compilation and execution, memory management, language features, compatibility and ecosystem, and performance. Each has its strengths and is suited to different use cases in software development.
From a StackShare community member: "We are looking to rewrite our outdated front-end with TypeScript. Right now we have a mix of CoffeeScript and vanilla JavaScript. I have read that adopting TypeScript can help enforce better code quality, and best practices. I also heard good things about Flow (JS). Which one would you recommend and why?"
I use TypeScript because:
- incredible developer tooling and community support
- actively developed and supported by Microsoft (yes, I like Microsoft) ;)
- easier to make sense of a TS codebase because the annotations provide so much more context than plain JS
- refactors become easier (VSCode has superb support for TS)
I've switched back and forth between TS and Flow and decided a year ago to abandon Flow completely in favor of TS. I don't want to bash Flow, however, my main grievances are very poor tooling (editor integration leaves much to be desired), a slower release cycle, and subpar docs and community support.
I use TypeScript because it isn't just about validating the types I'm expecting to receive though that is a huge part of it too. Flow (JS) seems to be a type system only. TypeScript also allows you to use the latest features of JavaScript while also providing the type checking. To be fair to Flow (JS), I have not used it, but likely wouldn't have due to the additional features I get from TypeScript.
We originally (in 2017) started rewriting our platform from JavaScript to Flow (JS) but found the library support for Flow was lacking. After switching gears to TypeScript we've never looked back. At this point we're finding that frontend and backend libraries are supporting TypeScript out of the box and where the support is missing that the commuity is typically got a solution in hand.
I use TypeScript because the tooling is more mature (the decision to discontinue TSLint in favor of moving all its checks to ESLint is a thoughtful and mature decision), there's a ton of examples and tutorials for it, and it just generally seems to be where the industry is headed. Flow (JS) is a fine tool, but it just hasn't seen the uptake that TS has, and as a result is lacking a lot of the nicer small things, like thorough Visual Studio Code integration, offered by TS.
We currently use TypeScript at work. Previously we used Flow (JS) but it was sometimes really difficult to make the types work the way you want. Especially non-trivial types were problematic. And the IDE support wasn't good, Flow took too much resources and sometimes remain stuck and do not show errors (I use Visual Studio Code). With TypeScript we almost do not have these problems. IDE support is superb, working with types is much easier and typing system seems more mature and powerful. There are some downsides (like partion inheritance etc.), but TS team is still pushing it forward. So for me TypeScript is clear winner.
We use Underscore because it's a reasonable library for providing all the reasonable helper functions missing from JavaScript ES5 (or that perform poorly if you use the default ES5 version).
Since we're migrating the codebase to TypeScript , we'll likely end up removing most usage of it and ultimately no longer needing it, but we've been very happy with the library.
I use TypeScript for Web Applications and for both frontend and backend because it has a lot of tooling around it and they really got the types and type safety right. Flow (JS) on the other hand lacks tooling and most of the times I scramble to find the right way of building my contracts in which TypeScript is very intuitive and natural. Additionally TypeScript is very similar to Java so your backend engineers and full stack engineers can work with it without much of context switch.
The only time I think Flow shines is (based on probably my outdated knowledge) Flow is/was the only option if you want/wanted to build a React Native application mainly because React Native transpiler at the time I was working with it would only work with flow.
I use TypeScript because it's adoption by many developers, it's supported by many companies, and it's growth. AngularJS, React, @ASP.NET Core. I started using it in .NET Core, then for a job. Later I added more Angular experience and wrote more React software. It makes your code easier to understand and read... which means it makes other people's code easier to understand and read.
I use TypeScript because I tried both on a Meteor project, and found the quantity of errors it enabled us to catch and the simplification of code it allowed was higher than Flow (JS).
I use TypeScript because it's the most mature/issue-free Javascript type-checker available, as far as I've seen.
I use TypeScript because of broad support, on tools, repos, community ... the only reason to consider flow is if you're a facebook employee
If you will start a project from scratch I recommend to use TypeScript. But, If you work with legacy projects written in JavaScript I recommend Flow (JS). Both tools have the same objective: reduce the bad code (which create illegible code, generate bugs e problems to maintenance). Flex helps you to avoid fall in bad codes, but TypeScript prevent you to c you to create bad codes. I believe cause this some JavaScript fans don't like TS, because TS block you to write some types o code. This is the fundamental difference between TS and Flow: Flow avoid problems, but no force. TS force you to prevent problems.
I recommend TypeScript. When used correctly, TypeScript can enable your application to be scalable, easy to refactor, safe, and stable. One of the biggest draws of working with any typed language is that it forces you to think about your functions' inputs and outputs. This is invaluable as it can lead to more declarative, functional style code that ultimately can be easier to reason about.
TypeScript is however not a silver bullet. Just like anything new it takes time to fully understand the concepts of types, interfaces, abstract classes, and enums. In my experience engineers who excel when using TypeScript are those who have experience working with a statically typed language.
I use TypeScript because i love to program in Angular and used in node as well
As a personal research project I wanted to add post-quantum crypto KEM (key encapsulation) algorithms and new symmetric crypto session algorithms to openssh. I found the openssh code and its channel/context management extremely complex.
Concurrently, I was learning Go. It occurred to me that Go's excellent standard library, including crypto libraries, plus its much safer memory model and string/buffer handling would be better suited to a secure remote shell solution. So I started from scratch, writing a clean-room Go-based solution, without regard for ssh compatibility. Interactive and token-based login, secure copy and tunnels.
Of course, it needs a proper security audit for side channel attacks, protocol vulnerabilities and so on -- but I was impressed by how much simpler a client-server application with crypto and complex terminal handling was in Go.
$ sloc openssh-portable
Languages Files Code Comment Blank Total CodeLns
Total 502 112982 14327 15705 143014 100.0%
C 389 105938 13349 14416 133703 93.5%
Shell 92 6118 937 1129 8184 5.7%
Make 16 468 37 131 636 0.4%
AWK 1 363 0 7 370 0.3%
C++ 3 79 4 18 101 0.1%
Conf 1 16 0 4 20 0.0%
$ sloc xs
Languages Files Code Comment Blank Total CodeLns
Total 34 3658 1231 655 5544 100.0%
Go 19 3230 1199 507 4936 89.0%
Markdown 2 181 0 76 257 4.6%
Make 7 148 4 50 202 3.6%
YAML 1 39 0 5 44 0.8%
Text 1 30 0 7 37 0.7%
Modula 1 16 0 2 18 0.3%
Shell 3 14 28 8 50 0.9%
As our codebase grew in size, we were looking for ways to improve code quality. We chose TypeScript over Flow due to its rapid industry adoption and overall tools support.
We noticed how different open-source projects were migrating from Flow to TypeScript. Most notably, it was Jest, even though Jest and Flow were both developed by Facebook. See this HN thread if you want to dive into an interesting discussion around this move.
Additionally, at the beginning of 2019, both Babel and ESLint enabled seamless TypeScript support, which allowed easy migration path in a backward-compatible way.
Initially making a decision to use Flow vs Typescript we decided to go with flow as we wanted our code to run in a way we wrote it, because when using Flow types are simply removed from the code without modifying the code itself. Sadly, the type system of Flow was in some cases very hard to understand and declare the types correctly, especially in cases when the structure is very dynamic (e.g. object keys and values are created dynamically). Another reason was bad integration with IDE and frequent crashes which made DX very poor. Therefore, we made another evaluation of Typescript and decided to move towards it. As our code base was pretty big when we decided to migrate to TS we couldn't just stop and re-write everything, that's why we started writing new modules in Typescript as well as transforming old components. To make that possible we had to configure Webpack loader to support simultaneous bundling of Flow&JS and Typescript. After around 2 months of the transformation we have around 40% of code being written in Typescript and we are more than happy with integration TS has with IDE, as well as ease of declaring types for dynamic modules and functions.
Pros of C++
- Performance203
- Control over memory allocation108
- Cross-platform99
- Fast98
- Object oriented85
- Industry standard59
- Smart pointers48
- Templates38
- Gui toolkits17
- Raii17
- Flexibility14
- Generic programming14
- Control14
- Metaprogramming12
- Hardcore10
- Full-fledged containers/collections API5
- Many large libraries5
- Simple5
- Large number of Libraries4
- Performant multi-paradigm language4
- Way too complicated3
- Close to Reality1
- Plenty of useful features1
Pros of TypeScript
- More intuitive and type safe javascript173
- Type safe105
- JavaScript superset80
- The best AltJS ever48
- Best AltJS for BackEnd27
- Powerful type system, including generics & JS features15
- Compile time errors11
- Nice and seamless hybrid of static and dynamic typing11
- Aligned with ES development for compatibility10
- Angular7
- Structural, rather than nominal, subtyping7
- Starts and ends with JavaScript5
- Garbage collection1
Sign up to add or upvote prosMake informed product decisions
Cons of C++
- Slow compilation8
- Unsafe8
- Over-complicated6
- Fragile ABI6
- No standard/mainstream dependency management5
- Templates mess with compilation units4
- Too low level for most tasks3
- Compile time features are a mess1
- Template metaprogramming is insane1
- Segfaults1
- Unreal engine1
Cons of TypeScript
- Code may look heavy and confusing5
- Hype4
Sign up to add or upvote consMake informed product decisions
What is C++?
What is TypeScript?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
Blog Posts
+5
+4
+6
+8
+32
+17+13
+15