Nice comparisons here. I too realized after using Typescript for a while that it is nothing more than a metadata generator allowing IDEs to do nice things with the metadata. All the metadata being stripped off at compile time shows us plain ole JavaScript.
But even JavaScript on its own can't detect a null parm being sent in and won't without AOP. The traditional place to validate for last 50 years is in entry to the function. Shoot, Marshall Dillon did it.
But even AOP once thought impossible may have new life with the new decorator standards appearing. A recent article here showed how that works. Which is cool but will present debugging challenges to those unaware.
JavaScript is OK but nothing super over the top. I've never told my own Mother about it. Its major attribute is it's ubiquitous adoption. As it matures; we are seeing Typescript like adaptions, like the class, arrow functions, constructors and now decorators.
The JavaScript of today is nothing like it was and that's a good sign of a thriving language.
Maybe soon it will overtake Typescript's innovation like Rust overtook C++. The only problem is MSFT knows languages extremely well. I don't see them letting up on Typescript innovation. To do so, would leave them nowhere close to JavaScript. They have no language entry in the JavaScript world without Typescript.
Hey, is that your shed on fire over there in your background?
I've been quite intrigued by decorators. The only thing holding them back, at the moment, is the fact that they're still "experimental". And as you point out, even when they're adopted, they also present some new challenges. Nevertheless, I think it's my C# experience that makes me so fond of them. IMHO, they're both incredibly useful and they create rather "clean" code (as opposed to, say, doing it manually by literally wrapping a function/method in another function/method).
I'm also encouraged by the rapid pace of JS's development. In fact, I wrote a whole article about that earlier (dev.to/bytebodger/why-javascript-i...).
I imagine that, as time goes on, TS will continue to evolve. But I also think that some of TS's features will also end up being absorbed into JS. I'm not implying that they'll eventually become the same thing. But jQuery is, IMHO, a useful example.
Nowadays, there's much about the jQuery model of querying DOM elements that you can do without ever loading up jQuery. I can imagine a similar path for TS features in core JS.
Thanks again for the feedback. I'm gonna go check on that shed now...
When I first came to JS from C# I used (what is now) github.com/mihaifm/linq . In the end I felt that map/filter/reduce was enough and slowly it dropped out of my daily practices.
At the beginning TS was a way of being able to code with fancy new features for sure. Then JS got better as Adam has pointed out in other articles. I guess I've been burned by following the Microsoft "hype" - we built a lot of stuff in XAML and SilverLight and were left hanging. I find myself distrusting anything that is powered by an advertising machine and that is significantly perpetuated by it.
AOP would be fantastic though. I'd dearly love to be using metadata in frameworks.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Mr. Davis,
Nice comparisons here. I too realized after using Typescript for a while that it is nothing more than a metadata generator allowing IDEs to do nice things with the metadata. All the metadata being stripped off at compile time shows us plain ole JavaScript.
But even JavaScript on its own can't detect a null parm being sent in and won't without AOP. The traditional place to validate for last 50 years is in entry to the function. Shoot, Marshall Dillon did it.
But even AOP once thought impossible may have new life with the new decorator standards appearing. A recent article here showed how that works. Which is cool but will present debugging challenges to those unaware.
JavaScript is OK but nothing super over the top. I've never told my own Mother about it. Its major attribute is it's ubiquitous adoption. As it matures; we are seeing Typescript like adaptions, like the class, arrow functions, constructors and now decorators.
The JavaScript of today is nothing like it was and that's a good sign of a thriving language.
Maybe soon it will overtake Typescript's innovation like Rust overtook C++. The only problem is MSFT knows languages extremely well. I don't see them letting up on Typescript innovation. To do so, would leave them nowhere close to JavaScript. They have no language entry in the JavaScript world without Typescript.
Hey, is that your shed on fire over there in your background?
Great points!
I've been quite intrigued by decorators. The only thing holding them back, at the moment, is the fact that they're still "experimental". And as you point out, even when they're adopted, they also present some new challenges. Nevertheless, I think it's my C# experience that makes me so fond of them. IMHO, they're both incredibly useful and they create rather "clean" code (as opposed to, say, doing it manually by literally wrapping a function/method in another function/method).
I'm also encouraged by the rapid pace of JS's development. In fact, I wrote a whole article about that earlier (dev.to/bytebodger/why-javascript-i...).
I imagine that, as time goes on, TS will continue to evolve. But I also think that some of TS's features will also end up being absorbed into JS. I'm not implying that they'll eventually become the same thing. But jQuery is, IMHO, a useful example.
Nowadays, there's much about the jQuery model of querying DOM elements that you can do without ever loading up jQuery. I can imagine a similar path for TS features in core JS.
Thanks again for the feedback. I'm gonna go check on that shed now...
I love your articles and great sense of humor! Have a good day my friend.
Yes, just think of JavaScript adopting type annotations. That could kill Typescript. Who knows maybe Typescript will introduce LINQ.
When I first came to JS from C# I used (what is now) github.com/mihaifm/linq . In the end I felt that map/filter/reduce was enough and slowly it dropped out of my daily practices.
me too, I just loved linq so much, it was the best thing since chewing gum!
At the beginning TS was a way of being able to code with fancy new features for sure. Then JS got better as Adam has pointed out in other articles. I guess I've been burned by following the Microsoft "hype" - we built a lot of stuff in XAML and SilverLight and were left hanging. I find myself distrusting anything that is powered by an advertising machine and that is significantly perpetuated by it.
AOP would be fantastic though. I'd dearly love to be using metadata in frameworks.