Need advice about which tool to choose?Ask the StackShare community!
TypeScript is an open source tool with 51.2K GitHub stars and 7.07K GitHub forks. Here's a link to TypeScript's open source repository on GitHub.
I am an undergraduate in computer science. (3rd Year)
Then, later, for back-end programming languages, Rust seems like your best bet. Its pros: - it's satisfying to work with (after the learning curve) - it's got potential to grow big in the next year (also with better paying jobs) - it's super versatile (you can do high-perf system stuff, graphics, ffi, as well as your classic api server) It comes with a few cons though: - it's harder to learn (expect to put in years) - the freelancing options are virtually non-existent (and I would expect them to stay limited, as rust is better for long-term software than prototypes)
And if you want to go with python as a secondary tool then i suggest you to learn a python framework (Flask,Django).
Flutter is good for everything and it is getting better as I am speaking. Flutter Web is almost ready for production and I have made 2 complex working websites already.
Well. Flutter is just a Framework (just like Django btw.) and it uses Dart as a programming language. Django is kind of solving a different problem than Dart. Dart is intened for use in Front End Applications and Django is a Framework for Back-End Web Development.
So if you want to program Flutter Apps (although i wouldn't recommend it for any serious web development yet since Flutter web isn't very mature yet) i would recommend you just lern Dart.
From a management and hiring perspective, I recommend Flutter (Dart). It provides native solutions to both mobile platform ( (Android and IOS) while having the same knowledge. Hiring managers look at this as an advantage since a developer can provide solutions for both platforms whit the same knowledge. The Flutter framework is growing and there is a lot of resources to ground your knowledge and start experimenting. Dart is also a great language that covers most E2E necessities, so again, no further need of learning one language for FE and another for BE and services. It is my belief that Dart will surpass Kotlin soon, and will leverage to Python and Java in the upcoming year.
If you are interested in Flutter, learn it on your own time, parallel to the course. No matter what order you do them, eventually you will end up learning them all anyway ;-)
We are converting AWS Lambdas from Java due to excessive cold start times. Usage: These lambdas handle XML and JSON payloads, they use s3, API Gateway, RDS, DynamoDB, and external API's. Most of our developers are only experienced in java. These three languages (Go, Node.js, and Python) were discussed, but no consensus has been reached yet.
I've worked with all three of these languages and also with Java developers converting to these languages and far and away Go is the easier one to convert to. With the improved cold-start times and the ease of conversion for a Java developer, it is a no-brainer for me.
The hardest part of the conversion though is going to be the lack of traditional Classes so you have to be mindful of that, but Go Structs and interfaces tend to make up for what is lost there.
Full Disclosure: I'm a 95% Go convert (from Python) at this point in time.
Go would provide the easiest transition for Java programmers -- its IDE/tooling is second to none (just install Goland) and the deploy/distribution story is extremely clean and lends itself to work well in lambda: single, static binaries with quick startup. No need to set up a full environment or package dependencies on your lambda AMIs, just copy a file.
So I'd agree, on the strength of AWS Lambda support and the solid performance of Go, it seems like your best choice here for Lambdas (and I'm going to need to consider that myself going forward... pardon the pun).
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 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.
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.
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.
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 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 of broad support, on tools, repos, community ... the only reason to consider flow is if you're a facebook employee
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 i love to program in Angular and used in node as well
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.
As the team grew in size, we had to formalize the way we write JS. I beleive it becomes impossible to collaborate on a large codebase without relying on static type checking. we made the switch in a month, it was painful but we never looked back.
The main drawback is when you code, you used to have the code up and running with latest changes in a second. now takes 30secs to run now, so the feedback loop is slower, however, lots of type errors and trivial mistakes are cought by the compiler now
TypeScript is a statically typed language out of the box, with that bringing all the benefits of compilation time code checking. It also has some nice structures and patterns such as union types, exhaustive check and a great and lightweight IDE – VisualStudioCode, providing more level of helpers and control over your TS code than JS. TypeScript is fully interoperable with JS and one can disable all the strictness on demand or choose proper level of it depending of the technology and business needs.
Telegram Messenger has frameworks for most known languages, which makes easier for anyone to integrate with them. I started with Golang and soon found that those frameworks are not up to date, not to mention my experience testing on Golang is also mixed due to how their testing tool works. The natural runner-up was JS, which I'm ditching in favor of TS to make a strongly typed code, proper tests and documentation for broader usage. TypeScript allows fast prototyping and can prevent problems during code phase, given that your IDE of choice has support for a language server, and build phase. Pairing it with lint tools also allows honing code before it even hits the repositories.
In 2015 as Xelex Digital was paving a new technology path, moving from ASP.NET web services and web applications, we knew that we wanted to move to a more modular decoupled base of applications centered around REST APIs.
To that end we spent several months studying API design patterns and decided to use our own adaptation of CRUD, specifically a SCRUD pattern that elevates query params to a more central role via the Search action.
Once we nailed down the API design pattern it was time to decide what language(s) our new APIs would be built upon. Our team has always been driven by the right tool for the job rather than what we know best. That said, in balancing practicality we chose to focus on 3 options that our team had deep experience with and knew the pros and cons of.
That left us with two options. We went a very unconventional route for deciding between the two. We built MVP APIs on both. The interfaces were identical and interchangeable. What we found was easily quantifiable differences.
We were able to iterate on our Node based APIs much more rapidly than we were our C# APIs. For us this was owed to the community coupled with the extremely dynamic nature of JS. There were tradeoffs we considered, latency was (acceptably) higher on requests to our Node APIs. No strong types to protect us from ourselves, but we've rarely found that to be an issue.
As such we decided to commit resources to our Node APIs and push it out as the core brain of our new system. We haven't looked back since. It has consistently met our needs, scaling with us, getting better with time as continually pour into and expand our capabilities.
- offers better maintainability and discoverability of existing code bases
- provides reasonable type safety, which frees us from writing a huge chunk of unit tests and mitigates a large set of problems that are caught in compilation
- affords a new level of expressiveness via types
Nothing is without trade offs; we are aware of, and accept that:
- fighting the compiler can be frustrating
- it adds to the already large list of skills a web developer has to learn
- it adds another piece to the already large set of tools necessary to get code from development to production
Here are our 3 main claims why TypeScript is the way to go.
Collaboration: When large coding projects have many developers there is a chance of messier coding. The number of errors increases which makes the handling difficult. With strong typing the amount of errors decreases and debugging becomes much more easier.
Productivity: TypeScript uses the latest ECMA features. Auto-completion features as well as more clear, comprehensible and readable code will boost the productivity of the developer drastically.
The project is a web gadget previously made using vanilla script and JQuery, It is a part of the "Quicktext" platform and offers an in-app live & customizable messaging widget. We made that remake with React eco-system and Typescript and we're so far happy with results. We gained tons of TS features, React scaling & re-usabilities capabilities and much more!
What do you think?
- Can be used on frontend/backend1.7K
- It's everywhere1.5K
- Lots of great frameworks1.2K
- Light weight742
- You can't get a device today that doesn't run js392
- Non-blocking i/o286
- Extended functionality to web pages55
- Relatively easy language49
- Executed on the client side46
- Relatively fast to the end user30
- Functional programming21
- Setup is easy12
- Its everywhere12
- Because I love functions11
- Like it or not, JS is part of the web standard10
- Expansive community9
- Can be used in backend, frontend and DB9
- Everyone use it8
- Easy to hire developers8
- Future Language of The Web8
- No need to use PHP8
- For the good parts8
- Can be used both as frontend and backend as well8
- Most Popular Language in the World8
- Evolution of C7
- Popularized Class-Less Architecture & Lambdas7
- Agile, packages simple to use7
- Supports lambdas and closures7
- Love-hate relationship7
- Photoshop has 3 JS runtimes built in7
- Its fun and fast6
- Can be used on frontend/backend/Mobile/create PRO Ui6
- Easy to make something6
- It let's me use Babel & Typescript6
- Client side JS uses the visitors CPU to save Server Res6
- Hard not to use6
- It's fun6
- 1.6K Can be used on frontend/backend6
- Promise relationship5
- Stockholm Syndrome5
- Function expressions are useful for callbacks5
- Scope manipulation5
- Client processing5
- What to add5
- Because it is so simple and lightweight4
- Only Programming language on browser4
- Easy to understand1
Pros of TypeScript
- Type safe104
- The best AltJS ever47
- 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
- Structural, rather than nominal, subtyping7
- Garbage collection1
Sign up to add or upvote prosMake informed product decisions
- A constant moving target, too much churn22
- Horribly inconsistent20
- No ability to monitor memory utilitization8
- Shows Zero output in case of ANY error7
- Can be ugly6
- Thinks strange results are better than errors6
- No GitHub3
Cons of TypeScript
- Code may look heavy and confusing5
Sign up to add or upvote consMake informed product decisions
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