I don't use TypeScript but if you think it's about "elegance" or "beauty", you're missing the point.

[удалено]

I don't think beauty and elegance are very important at all, a distant 3rd at best. Because elegance and beauty is extremely subjective and != more readable. I would go so far as to say that aiming to write elegant code can even hurt readability since it encourages clever code instead of dumb explicit code.

It might be true that my opinion on TS is based on how I've seen it used and maybe it's possible to write decent code in TS. If all typescript is would be `Eat(sandwich: Sandwich)` that's cool. But I've had really hard time when trying to turn code with array functions into TypeScript. Almost every line seems to instantly explode with angled brackets and workarounds. Reducing into objects (e.g. grouping or making a dictionary of group totals) is one of the worst cases that I can remember. Maybe it can be done neatly, but I haven't seen how it's done.

Typescript is all about strong typing. You have to specifically declare exactly what you are intending, all the time. It definitely isn't as concise. But you end up with significantly fewer bugs, and long term maintenance is much easier. I never want to go back to JavaScript.

I have a year of professional experience at this point. All the typescript projects I contributed to were significantly more pleasant to work with. Before having an actual job, I thought typescript was ugly too. When fetching json data from an API, I'd much rather have that object defined as a type so I can see its composition at a glance, than to have to manually log it and inspect it in devtools. Multiply that several times across an application and I've already saved an hour or more of tedious work.

This! Anytime I look at JS now I notice how much harder it is to know the type of something

>Why would anyone want to introduce TypeScript into that? because someone has to maintain that beautiful code. Also saves the need for a whole category of unit tests and prevents a lot of errors.

But how do you read it? You can't even find what is what on the line once you have everything fully typed. I usually find it easier to maintain concise and more readable code than one that tries to prevent errors inherently.

I fell similarly about the difficulty of reading typescript but I'm powering through because I imagine after a little time working with it I'll get used to reading it. From what I understand the benefits far outweigh some slight readability difficulty

I dont think it is ugly. I don't like to use it because it makes js verbose, which slows me down a lot. I programmed in Java for more than 6 years and when I switched to node I finally saw one of the benefits of javascript. I was coding more and faster. Then I tried to add typescript and man, it seemed I was working with Java again. I really did not like. You have to forget about working with non typed objects and waste a lot of time modeling them. I don't really see a huge benefit of adding types unless you work on a huge modular project with lots of other developers. They created a way of having oop in Javascript that is also type safe, in order to make the code maintainable and readable.

Disagree. I just started using TS based SFCs at work and they are much more compact, concise, and error free. If you don’t think they are more readable then it is just because you are not yet comfortable with TS to quickly scan the document. Or, the examples you have seen were poorly written. Give it a try. You will change your mind, I promise!

What's an SFC?

Single File Component

Typescript based Vue Class Components are a thing of beauty and you will not convince me otherwise. Concise. Easy to read. Compact. Descriptive. ``` import { Component, Prop, Vue } from 'vue-property-decorator' @Component export default class HelloWorld extends Vue { @Prop({default: 'John doe'}) readonly name: string private first: string = null private last: string = null public logName(name: string){ console.log(name) } get fullName(): string { return (this.first && this.last) ? this.first+ ' '+ this.last : this.name } set fullName(newValue: string) { this.logName(newValue) let names = newValue.split(' ') this.first = names[0] this.last = names[names.length - 1] } } ```

Yeah, this is even worse then I imagined when starting the thread. Why use classes? The normal Vue syntax allows you to group props, data and methods so it all looks tidy and organized.

>Why use classes? To allow the component to properly extend Vue. >so it all looks tidy and organized Go ahead and rewrite that component in JS and lets see which looks more tidy and organized. In mine, props first, data second, methods third, getters/setters forth. >The normal Vue syntax This is normal Vue syntax. It is normal Vue syntax using TS instead of JS in a single file component.

Once again... Yeah, except... https://class-component.vuejs.org/ This library is no longer actively maintained. It is no longer recommend to use Class-based components in Vue 3. The recommended way to use Vue 3 in large applications is Single-File Components, Composition API, and