But again arguing on the other side, for smaller projects and when you want to get things done quickly, there is a pleasure in the speed of pure JavaScript. I remember when I started coding heavily in JS versus Java, there was this feeling of freedom and flexibility that you get when you just creating variables, calling functions, and getting things done.
There are pros/cons to it, and really depending on the project and the size of the team. It is difficult to argue against what the tech community as a whole perceives as worthy at the peak of hype, there is an inherent risk to that, to appear backward or negative, and many times one can be wrong, but there are so many people hyping TypeScript, so I think it is useful for others to voice the cons, show some constructive skepticism, in order to balance the field and help us see things for what they are.
I will never use typescript at the start of a project or any project without any semblance of success. It is a waste of time while affecting the team’s velocity and thus, hampering innovations. I’d instead use the available resources on innovation and making the project successful.
In terms of adding types, here is my hierarchy of types (both compile-time and runtime) in terms of importance:
DB Schema
Client inputs
Proptypes in React if using classes. If using hooks, then #4.
I see the biggest benefit for TS when using it with OOP, however this changes the whole way to think about software design for JS applications IMO.
Currently with Meteor I am fast and precise to write JS code mostly procedural and functional. With TS I feel subconsciously forced to go the OOP way way too much.
Also one other thing that annoys me - the code is much less readable to me. Am I the only one who perceives it that way?
I feel the same but I’m biased here as I migrated from Java years ago because I was tired of types and verbosity
Java also forces OOP which I avoid today with all my strengths. I prefer functional and declarative approaches. One example of declarative approach instead of imperative you can see in my suggestion in this PR.
TypeScript is a huge benefit IMO. In strictly-typed projects, being able to navigate code makes understanding, refactoring, and maintenance much easier, but of course there is an initial cost in learning enough TypeScript for it to be useful.
TypeScript does not force anyone to use OOP. TypeScript only provides types for things you can do in JavaScript, whether that is with functions or with objects (you choose). OOP isn’t always good. Pure-functional isn’t always good either. Both have pros and cons depending on use cases.
I despise OOP, and love typescript. I suspect most of the folks here who can’t stand typescript are trying to do OOP with it. It’s probably OOP they hate, they just don’t know it yet.
I would argue functional with objects is not OOP at all. If you aren’t having endless conversations with your team about “has a” vs “is a” and taxonomies, deep inheritance chains, and patterns like inversion of control, and dependency injection, and the gang of four, ad nauseam, you aren’t doing OOP. You are doing functional programming with objects.
I will probably never start again a project without types.
For a throw-away script, why not ? but writing code without types now feel like driving with my eyes closed.
I go faster in typescript, because my tools are able to be much more helpful. I think, and please excuse the bluntness, if typescript is slowing you down, you are using it wrong.
Computer languages have 3 environments. The syntax, static environment (what the code literally says) and the dynamic environment (what happens at runtime). The more you can tell by reading the code in the static environment, the easier everything is. JS is a “dynamic language” because it defers a lot of things to the dynamic environment (at runtime) like type marshaling, and property resolution (this). The problem with that is, you have to essentially run the program in your head to make sure all your code is right, and that’s just an error prone and slower (and more exhausting) way to code.
Think about typescript as a tool, rather than gospel. You shouldn’t have to write complex type - really ever. I almost don’t type anything, and instead simply learned to write code in a way that TS can infer almost every type. This makes things like refactoring a breeze.
I will note - I don’t do OOP. OOP is the problem 90% of the time, not typescript. OOP was a generational mistake in computer programming. Do FP (with objects) and free yourself.
Would be nice to see simple pragmatic comparison article without hype and OOP when you get time.
I’m extremely careful with anything that transpile and abstract JS. Coffee script, GWT, Dart and many attempts went to the grave and JS kept growing, I would rather have the code as close as possible to what is being executed on the browser. Once ESM modules become popular we might be able to get rid of transpiling anything and just ship the code as it.
I guess it is a matter of taste and liberalism, for small code bases I enjoy the wildness of pure JS, just “let” the variable be and call functions. Java and OOP was so formal and verbose you have to to navigate so many files, manager classes, factory, interfaces to eventually get to two lines of logic.
With that said, I am curious on how the experience of coding using react, webstorm and meteor could be enhanced with the introduction on TS.
I hear you in regards to Coffeescript. That one was just a light syntax abstraction, with some syntactic sugar. I always found it necessary to translate Coffeescript to straight JS in my head in order to understand what I was doing. That’s sort of the problem with it - it only really tried to address the syntax part of the language, which is not the weak part of JS (in fact, I like curly braces, and I’ll never understand why those Python people don’t).
Typescript is different - it adds a lot more pragmatism to the static environment, and that brings a lot of benefits. It also mostly tries to be “just javascript”. In a certain way it succeeds, but it can get a bit much, if you try to use every feature it has available (or try to do OOP with it).
A simple rule of thumb for using TS might simply be to understand that you are trying to move some of the dynamic reconciliation to the static environment. If you understand that, you can define your types in a way that keeps out of the way, and actively help you, rather than over complicate everything. I’m also not one of those purist - go ahead disable the rules that makes any an error - it’s often very helpful to use any, especially if you just don’t have to the time to find or define a complex type you don’t have any control over. Yeah, it’s not type safe - this is a tool, not a religion.
That’s well said, you convinced me to give it shot, thanks .
Here is an interesting rant about Java/OOP and what actually got me to try JS. It is really an interesting read.
And this article pretty much summarizes how I feel about typescript in general
Furthermore, I feel once ESM modules pick up, TS usage might decrease in order to ship JS straight to the browsers, I might be wrong, just sharing my opinion.
One interesting thing from the “TypeScript is a waste” article - the author rejects even modern JS syntax, such as arrow functions, which I find remarkably useful, not just because they are shorter, and make it clearer that they are returning an allocated type (a normal function does too, with hoisting to the top of the inner function scope, and other magic) but they also lock the lexical scope (this) to the author time (static) scope, and don’t resolve that at runtime. That’s incredibly useful.
I get a strong whiff of “this is different, and change is bad” from that article.
I’ll also say that, I’ve tried to switch to TS a number of times, and generally understand where the frustration comes from. There’s a hurdle to learning enough about it for it to be useful. But I can also say, that the number of times it has saved my butt in critical situations is higher than than the number of times it was a pain in the butt - and each of those times, it was just because TS was trying to tell me about an error in my code/logic. Those would have cropped up at runtime - I just might not have noticed until later (or a user might have, which is even worse). I’ve been using it now long enough that I don’t generally have issues like these any more - I understand what the type checker is trying to tell me, and it no longer gets in my way at all. It was hard earned though - that did take a while to learn.
I get your point, but given how much hype there is the JS world, I personally tend to appreciate some healthy/rational skepticism and resistance. As you pointed out earlier, those ain’t ideologies but tools and I think it benefits everyone when we have balanced discussion highlighting the pros/cons so each of us can make a better decision. Meteor as tool had it share of scrutiny and it strength and weakeness are very clear and we’ll documented.
Take a look at this article that got posted recently about building a modern website :
It feels like building an operating system not a website! I recall the days where you would just open a text file, type some html/js, throw it at the server root and off you go. Perhaps I’m getting old
P.s I also find arrow functions to be extremely readable, in fact all ES6 changes were very well designed, I’d personally encourage new comers to master those before jumping to TS, and given the native browsers support to JS it is here to stay.
At the start of Typescript, it was clearly an attempt to bring Java/C# to Javascript. They were doing Class when there weren’t available in JS, decorators, Enums…
After a few mishaps where the TS implementation was not compatible with the final JS implementation, they changed their strategy and now the TS project is never introducing a feature that is not stabilized in the JS roadmap.
The target of the project has also been redirected from classical OOP ala Java toward more idiomatic Javascript with all its pros & cons.
Most of the time TS is really JS with types. There are a few situations where it put limits on the “dynamicness” of JS but they are relatively rare, and most of the time it’s for the best.
However It has a steep learning curve if you want to use all of its power/security.
Classes solve problems that functions+objects have. After all, classes came after functional coding, as a way to represent concepts more concisely. (and functions+objects came after functions+lists)
That’s what people say. But classes also introduce entirely new problems, and the basic hierarchical structure of class inheritance (taxonomy) is kind of a problem. I still see use for OOP and some of those patterns, but things got nuts in the early to mid aughts, in the kingdom of nouns, and I think we’ve learned a lot about the limits of OOP. Basically, I think there are too many downsides to get the upsides of OOP. There’s a reason folks are looking for something different, or moving back toward more functional approaches and frameworks, with objects mixed in. I agree it’s not going anywhere, but I bet the preferred patterns are changing even in OOP circles.
.
