We are starting up a new web project. I have worked with typed languages my whole career so I am not really fond of JavaScript. We are mostly C# guys so Typescript feels very familiar. What do people think of TypeScript? Is it a good alternative to JavaScript? Our first tests look really good but I wonder if there are any downfalls.
The front end world is a land of sand castles. If you put in the work and care to make yours wonderful then I'm sure there is a sense of pride and accomplishment at what can be done with the tools.
However, the tide will come in and it feels like it comes in daily to threaten to wash away all of your work. You do not control the tide.
-----------------
By the above I mean that you will need to fully own the application life cycle management and realize that for as great as Typescript is virtually _none_ of the examples you see will be based in it and there will always be some level of disconnect between what you are doing and what most everyone else is doing.
I think Typescript is a great fit _if_:
a) You ship a part of the project that _only_ has to interface with your TS code post compilation/transpiling. For example a little proxy shim responsible for server round trips or the business logic that the front end devs will call.
b) You are using Angular.
Otherwise use whatever the core framework you adopt is using. Usually just ES6 + Babel + a nice linter + tests.
Hope that helps. I'm a C# dev and I've tried and failed to use TypeScript for years. Mainly because the buy in is usually for React/Vue/etc and the JS front end land is squirrely enough without my having to mentally translate every example I see into TS. I've come to terms with doing one mental switch during my day between logical tiers (front end, middleware, backend). I try to limit the additional context switching I have to do once in those spaces.
Our mobile team was working on creating an app a while ago. We are all C# coders so the obvious solution seemed Xamarin because you can use C# plus you get multi platform. First they dumped Forms and went with a native UI. Then there were a ton of bugs (don't know the details) in Xamarin that caused them to switch to Java on Android. The iOS version will probably be written in Swift. Noone is talking about Xamarin anymore.
> Then there were a ton of bugs (don't know the details) in Xamarin that caused them to switch to Java on Android.
Interesting. Those are the type of day-to-day details that I'm curious about when I see cross platform solutions like Xamarin, Kotlin Native, or React Native.
I disagree. TypeScript is JavaScript plus type annotations. A team can move from JavaScript to TypeScript and see easy wins with little friction (barring my personal pet peeve, the difficulty of applying types to idiomatic React). I think you are including more about your specific situation in your analysis than is easy to parse out, like your role within a larger organization and the number of different technologies you are working with.
That is very fair. However you are disagreeing with something I stated was my very humble opinion. I didn't mean for it to be an analysis. More of a story shared at a pub as to why I don't fish off a particular pier anymore.
I've used it to moderate success on an 8 month React project. I originally started the project in ES6 and then migrated it over to Typescript. It generally works well with React, aside from a major pain point which is that it makes it difficult to compose with higher order components.
If you are working in your own bubble with few outside dependancies it works very well. I have been learning WebGL lately, and have found it extremely useful in that regard. Things get hairy dealing with external libraries with often flakey type definitions.
I would still use Typescript on new projects where I can. I have come to accept that I will often just need to use "any" in place of a proper type. There is the temptation to spend a lot of time creating complex types with generics but I've found it to be a can of worms. I'm always looking for new ways leverage the type system, and feel like I often hit dead ends.
Generally I think using Typescript to be an improvement over plain ES6. It catches a lot of bugs, and allows me to refactor with more confidence, but it is very far from ideal.
I’ve very happily used it for a Node/Express server and API project. I very much like have a typed system for that side. I much preferred having a type system for working with database models (for example in MongoDB it was a pleasure). I also liked the structure it imposed in that end.
A good build system and tests can but don’t have to be overly tricky to set up and support improves all of the time.
I’ve tried to get good projects going with React but unfortunately many packages haven’t been typed (though it’s getting better).
I definitely prefer it for any work with data. I don’t know if you’d consider it a benefit that you can break out of the type system if you need to do so.
I generally find JavaScript unpleasant and would do a lot to avoid working with it: not only do I find it difficult to work without types, but I feel that JavaScript bring its own special kind of mess to everything. I have never managed to bring myself to work with it or learn much about it because of that.
I ended up having to work on a front-end project a couple of years ago and a bit of exploring brought up TypeScript. I found working with it refreshing and enjoyable. Besides a good type system, it brings with it new (to me) features of JavaScript that really help (async/await, arrow notations, substantial syntactic sugar), and more productivity that I'd have expected.
So, I find it a good alternative to JavaScript. I thought that the interface with JavaScript was icky at time, but the investment in time learning it was well worth it.
Personally, I find TypeScript to be a joy. I am a team of one right now, but at the last company I worked for, we migrated the codebase to TypeScript, and it was a fair amount of work to migrate the existing code (especially since we had partially migrated to Flow), but worth it, IMO, to have the additional type information, especially given that it was a large shared codebase.
I've never seen such a powerful type system that's so easy to use. While the advanced stuff can be quite complex (as a consequence of its power), the experience of working with the compiler is made pleasant by good IDE support, fast type-checking, and readable syntax. Also, the level of type safety you want to go for is totally up to you.
The one frustrating thing can be using frameworks and libraries that don't have good type definition files. React and TypeScript are actually a slightly awkward fit, because React's component classes and idiomatic HOCs are quite difficult to type correctly, even though TypeScript has built-in React support. In my own code, I've ditched React's component classes for this reason.
I think they should stop to pack more and more type-featzres in each release. I know you do not need them all, but still if you use typescript you should be aware of all features, which become more overwhelming with each new release. I think many features should be made optional / unlockable like babel does that in their .babelrc
18 comments
[ 2.8 ms ] story [ 44.6 ms ] threadThe front end world is a land of sand castles. If you put in the work and care to make yours wonderful then I'm sure there is a sense of pride and accomplishment at what can be done with the tools.
However, the tide will come in and it feels like it comes in daily to threaten to wash away all of your work. You do not control the tide.
-----------------
By the above I mean that you will need to fully own the application life cycle management and realize that for as great as Typescript is virtually _none_ of the examples you see will be based in it and there will always be some level of disconnect between what you are doing and what most everyone else is doing.
I think Typescript is a great fit _if_:
a) You ship a part of the project that _only_ has to interface with your TS code post compilation/transpiling. For example a little proxy shim responsible for server round trips or the business logic that the front end devs will call.
b) You are using Angular.
Otherwise use whatever the core framework you adopt is using. Usually just ES6 + Babel + a nice linter + tests.
Hope that helps. I'm a C# dev and I've tried and failed to use TypeScript for years. Mainly because the buy in is usually for React/Vue/etc and the JS front end land is squirrely enough without my having to mentally translate every example I see into TS. I've come to terms with doing one mental switch during my day between logical tiers (front end, middleware, backend). I try to limit the additional context switching I have to do once in those spaces.
Hope that helps.
Interesting. Those are the type of day-to-day details that I'm curious about when I see cross platform solutions like Xamarin, Kotlin Native, or React Native.
If you are working in your own bubble with few outside dependancies it works very well. I have been learning WebGL lately, and have found it extremely useful in that regard. Things get hairy dealing with external libraries with often flakey type definitions.
I would still use Typescript on new projects where I can. I have come to accept that I will often just need to use "any" in place of a proper type. There is the temptation to spend a lot of time creating complex types with generics but I've found it to be a can of worms. I'm always looking for new ways leverage the type system, and feel like I often hit dead ends.
Generally I think using Typescript to be an improvement over plain ES6. It catches a lot of bugs, and allows me to refactor with more confidence, but it is very far from ideal.
A good build system and tests can but don’t have to be overly tricky to set up and support improves all of the time.
I’ve tried to get good projects going with React but unfortunately many packages haven’t been typed (though it’s getting better).
I definitely prefer it for any work with data. I don’t know if you’d consider it a benefit that you can break out of the type system if you need to do so.
I generally find JavaScript unpleasant and would do a lot to avoid working with it: not only do I find it difficult to work without types, but I feel that JavaScript bring its own special kind of mess to everything. I have never managed to bring myself to work with it or learn much about it because of that.
I ended up having to work on a front-end project a couple of years ago and a bit of exploring brought up TypeScript. I found working with it refreshing and enjoyable. Besides a good type system, it brings with it new (to me) features of JavaScript that really help (async/await, arrow notations, substantial syntactic sugar), and more productivity that I'd have expected.
So, I find it a good alternative to JavaScript. I thought that the interface with JavaScript was icky at time, but the investment in time learning it was well worth it.
I've never seen such a powerful type system that's so easy to use. While the advanced stuff can be quite complex (as a consequence of its power), the experience of working with the compiler is made pleasant by good IDE support, fast type-checking, and readable syntax. Also, the level of type safety you want to go for is totally up to you.
The one frustrating thing can be using frameworks and libraries that don't have good type definition files. React and TypeScript are actually a slightly awkward fit, because React's component classes and idiomatic HOCs are quite difficult to type correctly, even though TypeScript has built-in React support. In my own code, I've ditched React's component classes for this reason.