What's New in TypeScript 5.0? (infoworld.com) 47
InfoWorld reports that TypeScript 5.0 is smaller, faster, and simpler:
TypeScript 5.0, an update to Microsoft's strongly typed JavaScript variant, is now available as a production release, Microsoft announced March 16. With the upgrade, TypeScript has been rebuilt to use ECMAScript modules. TypeScript 5.0 also modernizes decorators for class customization.
ECMAScript modules reduce package size and boost performance. Decorators, an upcoming ECMAScript feature, allow for customizing classes and their members in a reusable way, Microsoft noted in a March 1 blog post. Decorators can be used on methods, properties, getters, setters, and auto-accessors. Classes can be decorated for subclassing and registration. While TypeScript previously supported experimental decorators, these were modeled on a much older version of the decorators proposal. TypeScript 5.0 will permit decorators to be placed before or after export and export default, a change made since the January 26 beta release of the new version.
ECMAScript modules reduce package size and boost performance. Decorators, an upcoming ECMAScript feature, allow for customizing classes and their members in a reusable way, Microsoft noted in a March 1 blog post. Decorators can be used on methods, properties, getters, setters, and auto-accessors. Classes can be decorated for subclassing and registration. While TypeScript previously supported experimental decorators, these were modeled on a much older version of the decorators proposal. TypeScript 5.0 will permit decorators to be placed before or after export and export default, a change made since the January 26 beta release of the new version.
Odd But Welcome Software (Score:4, Insightful)
I learned Typescript by doing courses about Angular. After that I started using it for middleware NodeJS projects. It only made sense and because of it my IDE (JetBrains) never gets lost. Code completion always works and is useful.
Having done a lot of Java, it always seemed odd to me that you would take a language like Javascript whose biggest strength is being weakly typed, and retrofit it with a transpiler to make it strongly typed. In other words turn it into Java.
But it all works pretty well so I don't complain.
Re:Odd But Welcome Software (Score:5, Insightful)
Javascript whose biggest strength is being weakly typed
Many major scripting languages are regretting this supposed strength.
Re: (Score:2)
Re: (Score:2, Informative)
That depends who you ask. The whole reason I switched terminology to talking about dynamic typing is precisely to be clear about my intent.
But if you think you know better than the hundreds of professionals in the industry who have debated this to death, feel free to go update Wikipedia:
https://en.wikipedia.org/wiki/... [wikipedia.org]
What you're talking about is type enforcement and there's no singular source of truth that absolutely ties strong/weak typing only to refer to type enforcement and nothing else. There's plent
Re: (Score:2)
The major regret is not knowing what the type is before run-time. The problems are the same then whether it is weakly typed or dynamically typed.
Re: (Score:2)
It is a strength. The problems start once they decide to "take themselves seriously" and become a "real" language.
Scripting languages are supposed to be simple so they can do trivial things. When they become too popular and are used for things they were never designed to handle, we end up spending 20 years trying to "fix" them, usually breaking tons of legacy code in the process. PHP is another good example. The PHP guys are trying to go the strict typing model too, and have been on a rampage deprecatin
Re: (Score:2)
The biggest problem with TypeScript is that is uses the garbage import/export syntax that has become standard in JS / NodeJS. Rather than a single project file specifying what should be included in the compilation, instead you have every single file needing file paths to every other file they depend on. It is the absolute worst, most brittle spaghetti-code way of managing types / compilation. By far, the most painful part of TypeScript is writing/refactoring/merging the 50 import statements required at the
Re: (Score:2)
> ... seemed odd to me that you would take a language like Javascript whose biggest strength is being weakly typed, and retrofit it with a transpiler to make it strongly typed ...
Because catching (type) errors at run-time is SO much "better" then catching them at compile-time. /s
Tell me you don't understand programming without saying you don't understand programming.
Fail Fast is a good engineering principle because it lets you catch errors sooner (which is cheaper) then later (which is expensive).
JavaScr
Re: (Score:3)
Tell me you don't understand programming without saying you don't understand programming.
Tell me you don't understand what I wrote without saying you don't understand what I wrote.
OOP cripples the mind... (Score:1, Flamebait)
its teaching should, therefore, be regarded as a criminal offense. Case in point:
Decorators, an upcoming ECMAScript feature
Who are the drooling morons on the standards committee? Are they just not familiar with the language at all?
Re: (Score:1)
That's complete nonsense that you can't possibly substantiate. I'm guessing that you're not familiar with C or JavaScript, quite possibly either one.
Re: (Score:1)
Re: (Score:2)
Programmers aren't engineers, neither is programming anything like engineering.
If you can't write readable and maintainable code in JavaScript, you probably shouldn't even call yourself a programmer.
Re: (Score:2)
I have friends that espouse this viewpoint - that OOP is somehow an evil thing. But the vast majority of work is done using it, and I would rather inherit and try to maintain/extend an OOP codebase than to pick up somebody's functional effort. OOP is easier, more productive, and clearer. It might not be the most elegant and technically satisfying route, but I'd rather tackle any business problem with Java or .Net rather than Clojure.
Re: (Score:1)
You have smart friends.
But the vast majority of work is done using it,
I'm sure. It is responsible for most of the needless complexity in software today.
I would rather inherit and try to maintain/extend an OOP codebase than to pick up somebody's functional effort.
This is a false dichotomy. The opposite of OOP is not functional programming. Fun fact: A surprising amount of the complexity typically layered onto OOP are just ham-fisted attempts to make up for the lack of the basic features you'd find in any functional language.
OOP is easier, more productive, and clearer.
Easier? Maybe easier to create a ton of unnecessary code. I guess OOP is great if you get paid per line, but then you're mistaking mass
Re: (Score:2)
I would suggest that "easier" and codebase size are mostly unrelated. I mean that an average team can produce correctly operating and supportable code more quickly using OOP. No need to get snarky. I've been coding for a living for 30 years, using more tools than I can remember. I've run operational teams supporting critical systems for 15 of those years. I've seen it from all sides.
Re: (Score:2)
I would suggest that "easier" and codebase size are mostly unrelated.
That's fair. Though I'm talking about 'bloat' which, as you know, is unnecessary and generally increases complexity.
I mean that an average team can produce correctly operating and supportable code more quickly using OOP.
I would disagree. I've been around a while myself. I've found that OOP does little more than bloat projects and dramatically increase both development and maintenance costs.
You should remember the hype around OOP early on. It promised to be the final solution to the software crisis, allowing us to create simple reusable modules would make writing software as simple as building with lego.
Re: (Score:2)
I think you're confusing OOP with atrocious architecture. I have seen some of the most ridiculous incomprehensible codebases that emerge from masturbationary architects who can't stop touching their junk. All kinds of ridiculous premature optimization, covering what-if scenarios that never happen. After a while, maybe the architecture can handle anything thrown at it, but at the expense of code that is so abstracted nobody can make sense of it, let alone debug it when something goes wrong.
You can create tig
Re: (Score:2)
I think you're confusing OOP with atrocious architecture.
I've been at this a very long time, and I've yet to see an example of OOP that wasn't atrocious.
but at the expense of code that is so abstracted nobody can make sense of it, let alone debug it when something goes wrong.
OOP is notorious for introducing completely pointless abstractions, and layering those on thick. It's not uncommon to run across more than one abstraction of another abstraction that is itself abstracting a different abstraction. Trying to drill down to find where something actually happens can be absolutely exhausting in the average OO codebase. There's always so damn much useless code that exists only to sat
Re: OOP cripples the mind... (Score:1)
I've hated OOP specifically because of inheritance. It feels like you have to have a deep understanding of every library -- including the standard library -- in order to avoid all kinds of pitfalls.
What all does this class inherit? And which of the functions of those classes does it override? And can they do something to fuck with my implementation? And does anything along the inheritance chain fuck with concurrency?
And oh shit, two different libraries I need for this one thing only expose their functionali
Re: (Score:2)
its teaching should, therefore, be regarded as a criminal offense. Case in point:
Decorators, an upcoming ECMAScript feature
Who are the drooling morons on the standards committee? Are they just not familiar with the language at all?
Dude, that's just an annotation, or rather an aspect. And that has more to do with AOP than with OOP. I failed to see how a) decorators/aspects are bad or b) they are a product of OOP, or c) if they were, how does that make OOP bad.
Yours is not even a normative statement. It is so interpretive and subjective.
This is not to say OOP or aspects do not have flaws. But they are tools, and just with all tools, it is the tool user, not the tool, who is responsible for its proper utilization.
Maybe I'm missing
Re: (Score:2)
Maybe I'm missing something
Decorators are pointless in a language like JavaScript because the same functionality is already present in the base language.
Re: (Score:2)
Maybe I'm missing something
Decorators are pointless in a language like JavaScript because the same functionality is already present in the base language.
But that's a different conversation from your original claim against OOP. It still doesn't answer how this is OOP's fault, or how their inclusion is the result of OOP issues (as opposed to them being a language design issues.)
Your second argument (that they are pointless in JavaScript) has merits. But your original assertion is still strange to me, and I'd much prefer to stick to that topic in an attempt to understand it.
Re: (Score:2)
The broader set of changes to the ECMA standard, starting with ES6, have been about contorting JS into a completely different language, more in line with 'classical' OO languages. This is harmful to the language as the prototypal approach is much simpler and far more powerful. Why do something that stupid? To make things feel more familiar for people who are coming from a language like Java or C#!
My comment was snarky, a corruption of a famous Dijkstra quote. What conclusion could I come to other than O
No native ChatGPT support? (Score:2)
Bummer.
Re: (Score:1)
Nah. That's an old Microsoft project. This one blue-screens your machine.
Security Risks (Score:1)
Re: (Score:2)
Have specialized security experts audited this new code?
I can't tell if you're being sarcastic or naive.
99.9% of any code is never audited. When it is, there's a pricetag per line of code attached to the project, and it usually runs on aircraft computers or some other critical application. Microsoft shit isn't in that league - not to mention, Microsoft doesn't exactly have a stellar track record in security anyway.
Re: (Score:2)
Re: (Score:3)
I remember the time when there were code reviews.
A code review doesn't make the code audited. It makes it reviewed.
Re: (Score:2)
Given they're not even using their own browser rendering engine anymore... it's hard to see how they'd get even within sniffing distance of "extinguish".
Re: (Score:1)
If you think MS is only focused on the browser market, sure, but maybe they only focus on on markets or sub-markets where they might "win" (at least in the short term). It may not be especially well thought out, but maybe something done on instinct at the corporate level. May be nothing, but old habits sometimes do die hard... ;-)
Same Pig, More Lipstick (Score:1)
Still a pig, though.
The problem (Score:2)
Sure these decorators will have some use. But at the expense of non-locality. You can already do all of these things in JS. Now they're just hiding meta-programming details.
Nothing is worse than taking a snippet of self-contained code and scattering its behavior across multiple parts of the codebase.
Are there really good legit uses? Absolutely. Will this be overused to shit, turning easily readable code into obscure series of @keywords? Oh, fuck yes, it will.
Some things don't need to be easy.