Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript Features to Avoid

executeprogram.com

Post reply on HN
Print view View original

131–140 of 212 posts

Re: TypeScript Features to Avoid

#131

Post by ironmagma »

seniorsassycat wrote: post #116

Lots of comments seen to have missed that the article isn't recommending against private fields, only the private keyword. Typescript and JavaScript have a newer brand # to make fields private. The native feature will have runtime benefits while the private keyword creates fields that's are public at runtime. I still use the private keyword because constructor shorthand doesn't support brands. constructor (private fi…

> We'd like to maintain feature parity with JavaScript unless there's a compelling reason not to.

And ladies and gentlemen, the generated code...

var __classPrivateFieldGet = (this && this.__classPrivateFieldGet) || function (receiver, state, kind, f) { if (kind === "a" && !f) throw new TypeError("Private accessor was defined without a getter"); if (typeof state === "function" ? receiver !== state || !f : !state.has(receiver)) throw new TypeError("Cannot read private member from an object whose class did not declare it"); return kind === "m" ? f : kind === "a" ? f.call(receiver) : f ? f.value : state.get(receiver); };

Nothing about this says "native JavaScript" to me. Who cares that a private field is technically public at runtime?

Re: TypeScript Features to Avoid

#132

Post by rezonant »

smoyer wrote: post #62

The arguments against the four language features in this article all boil down to it not being Javascript. If I wanted to write in Javascript, I'd use files with a .js extension. If you've picked Typescript, I don't think you should worry about whether your code is also valid Javascript "if you remove all the type information" (who's going to do that anyway.) Unless you're a solo developer, what's more important it t…

While I agree with the general sentiment, there's a bit of pedantry for you here: Typescript itself removes all the type information when you compile, it's not about the developer doing that themselves outside the context of the compiler. But that is a moot point with regard to the suitability of the features as the article itself suggests-- TS doesn't break your enums during compilation, a suitable JS representation is emitted.

Occasionally I think I might want to use enums in a place but then find that other solutions like const collection objects or plain constants works fine enough for the purpose at hand. I don't think it's a problem if folks use enums though, it's really not a big deal.

Re: TypeScript Features to Avoid

#133

Post by rezonant »

mhoad wrote: post #126
smoyer wrote: post #62

The arguments against the four language features in this article all boil down to it not being Javascript. If I wanted to write in Javascript, I'd use files with a .js extension. If you've picked Typescript, I don't think you should worry about whether your code is also valid Javascript "if you remove all the type information" (who's going to do that anyway.) Unless you're a solo developer, what's more important it t…

I continue to maintain that despite all the nice features from ES6 onwards working in straight JavaScript is psycho shit. It’s the NFTs of development. I’m genuinely looking forward to the day where we have other viable options for the DOM. I see TypeScript at best as a temporary band aid because you’re still stuck in the god awful NPM ecosystem at the end of the day.

I disagree with almost all of this, but I will say have you checked out Deno? It is in fact Typescript without the NPM ecosystem (amongst many other interesting aspects)

Re: TypeScript Features to Avoid

#134

Post by rezonant »

eyelidlessness wrote: post #110

The reason enums are useful—and the private keyword until recently with JS adding private fields—are that they’re nominal types. You can have… enum HTTPMethod { POST = 'post', // ... } enum FenceMaterial { POST = 'post', // ... } … and you can be sure 'post' is not ambiguous. Private fields have the same benefit, which is particularly useful for treating abstract classes as nominal interfaces. But yes, if your target…

Namespaces are most useful for external typings, and in some cases are the only way to correctly model them, sadly

Re: TypeScript Features to Avoid

#135

Post by jbbe »

cobertos wrote: post #64
kesslern wrote: post #61

Earlier quoted context omitted.

One advantage of enums is that you can iterate over all possible values of an enum, but not a union type.

You can if you derive the union from a const array using indexed types. const MyTypeValues = ['a', 'b'] as const; type MyType = typeof MyTypeValues[number]; MyType is now a type 'a' | 'b'

I often use that approach but (especially when you're importing from a seperate package) the compiler will sometimes view MyType as just an alias for string and won't catch typos.

Am I missing something in how to use this?

Re: TypeScript Features to Avoid

#136

Post by mhoad »

rezonant wrote: post #133
mhoad wrote: post #126

Earlier quoted context omitted.

I continue to maintain that despite all the nice features from ES6 onwards working in straight JavaScript is psycho shit. It’s the NFTs of development. I’m genuinely looking forward to the day where we have other viable options for the DOM. I see TypeScript at best as a temporary band aid because you’re still stuck in the god awful NPM ecosystem at the end of the day.

I disagree with almost all of this, but I will say have you checked out Deno? It is in fact Typescript without the NPM ecosystem (amongst many other interesting aspects)

Honestly, I’m more waiting for WASM garbage collection to officially land as a standard.

It won’t get me DOM level access but I can at least move a lot of my code there. I’m also quietly hopeful that canvas based rendering can make some huge improvements in the next few years so it doesn’t feel like Flash 2.0 but I’m ready to at least start thinking about letting go of the DOM as the thing I have to care about.

Until then I’m having a good time with Lit (lit.dev) for building web apps that need to be super snappy and “web feeling” which is still basically every customer facing thing.

But in a dream scenario I would way rather be writing apps in Flutter which was at least built from the ground up for building complex user interfaces in a sensible way, but that whole ecosystem is still in some very early days on the web and isn’t a good choice right now for most things, hoping that changes in a few years as they also seem to be targeting the WASM + Canvas path and the web as a platform isn’t there on that yet and neither are they.

Re: TypeScript Features to Avoid

#137

Post by sgt »

kwinten wrote: post #113
sgt wrote: post #111

We evaluated TS for a recent project but ended up with JS (and VueJS 3). I have a feeling it would have taken much longer to develop using TS, but lacking experience in TypeScript it's hard to say. I find JS pretty neat for exploratory programming.

I can assure you that doing it in TS would not have been any slower and you would have gained all the benefits that static type checking brings with it. VueJS 3 in particular is much better suited to use TS than its predecessor (without any additional plugins).

Can probably add types later, and consider it once we get the project underway. I am not saying you are wrong, but I have heard TypeScript developers complain about the turnaround in development being slower.

Re: TypeScript Features to Avoid

#138

Post by Recursing »

jbbe wrote: post #135
cobertos wrote: post #64

Earlier quoted context omitted.

You can if you derive the union from a const array using indexed types. const MyTypeValues = ['a', 'b'] as const; type MyType = typeof MyTypeValues[number]; MyType is now a type 'a' | 'b'

I often use that approach but (especially when you're importing from a seperate package) the compiler will sometimes view MyType as just an alias for string and won't catch typos. Am I missing something in how to use this?

`as const` is the important bit there, see this playground link https://www.typescriptlang.org/play?#code/MYewdgzgLgBKlQIICd...

Re: TypeScript Features to Avoid

#139

Post by Zababa »

mhoad wrote: post #128
donatj wrote: post #92

Earlier quoted context omitted.

That seems very readable , especially in comparison to something like Dart or Elm’s output, both of which can output thousands of lines from something as simple as your example. From the language goals > 4. Emit clean, idiomatic, recognizable JavaScript code. https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

I don’t really see the value proposition of having a compilation step that also prioritises readability when you have source maps. I love Dart personally and I mostly see it’s compile to nonsense looking code as a feature not a bug because it’s an ACTUAL compilation step worked on by ex Chrome team members who understand V8 internals not just code splitting and running terser over it and calling it a day. Want to get…

> I don’t really see the value proposition of having a compilation step that also prioritises readability when you have source maps.

It's to increase adoption. Some people still remember migrating to coffeescript and away from it. It's in line with tsc accepting regular JS files, the degrees of strictness, things like that. Typescript is optimized to be adopted by the maximum number of people, which in turn increases its usefulness, the feedback they can get, their influence on JS. People are going to write bindings for popular libraries, even migrate them.

Some other people (like at my job) have some people use typescript, and others the generated code. It makes debugging and reasoning about code easier.

As for Dart, I'm not really convinced. The language seems to have the same philosophy as Go (incremental improvement over old technologies), and while for Go it works because Go is relatively "low level" (lower than Dart), for Dart it's just weird.

Re: TypeScript Features to Avoid

#140

Post by goodoldneon »

ameliaquining wrote: post #54
leodriesch wrote: post #25

Despite the large amount of criticism in the comments here I think that the point the article makes here is pretty valid. The described features are not what TypeScript itself wants to be, and I think if it wasn't for backwards compatibility the team would remove some of them. IIRC namespaces as well as the `import = ` syntax come from a time where ESM wasn't a thing yet but a module system was very much needed. So n…

Numeric enums are a lot more useful than string enums, in my view.

Just don't use numeric enums with implicit values. If you add a member anywhere but the end of the enum, it'll change existing members' values
Post reply on HN