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.
As a fan of Meteor who likes to use Typescript, I don’t really care about what the internals are written in, so long as the interfaces are properly typed. For me it would be much better investment of energy to ensure all library function interfaces in Meteor itself and for all core packages are properly typed than to rewrite the implementations in Typescript.
.
