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

191–200 of 212 posts

Re: TypeScript Features to Avoid

#191

Post by G3rn0ti »

I think this whole discussion of whether union types are better than enums sheds light on the issues I have with type script in general: It’s basically a JS extension (like coffee script btw — remember that?) that is supposed to make your life easier as a developer but instead introduces a huge amount of unnecessary complexity giving you even more head aches.

I’ve yet to see typical front end code that really benefits from strong typing or even just the use of enums. I tend to accept language limitations and focus on designing my programs around those instead of wasting my energy on fighting on niche language extensions…

Re: TypeScript Features to Avoid

#192

Post by rezonant »

mhoad wrote: post #176
rezonant wrote: post #158

Earlier quoted context omitted.

There are a few big problems with using Canvas for UI on the web. First and foremost is accessibility- there is no way for your app to convey the information screen readers are able to get from analyzing the DOM along with the ARIA metadata that you (should) put into your markup. Furthermore, users who have trouble using a mouse can use the keyboard on the web, and it usually works very well since the browser handles…

This was my first reaction also and I think it’s understandable but having looked at proposed solutions to it as well it actually doesn’t seem like such a big deal. I apologise if I get some minor details wrong here as I am doing this on a phone and recalling this from memory because I don’t have the time to grab the sources right now. However… the short version of the plan to solve this that I seem to recall to this…

> respective accessibility APIs that each platform exposes.

That's the problem, there isnt an accessibility API for the web, is there?

EDIT: At least not one that works without DOM

Re: TypeScript Features to Avoid

#194

Post by Vinnl »

wk_end wrote: post #119
Vinnl wrote: post #81

This basically comes down to: avoid TypeScript features that clash with TypeScript's design goals. Specifically, the one to: > Avoid adding expression-level syntax. https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi... And that makes sense to me. IMHO it's best to consider TypeScript as a tool that aims to help you write JavaScript by catching common errors; it's more like a linter than a separate language…

> it's more like a linter than a separate language I wish people wouldn't think like this; it's very possible to write perfectly acceptable JavaScript that's fundamentally terrible TypeScript. By "fundamentally terrible", I mean unnecessarily untypeable, or unnecessarily difficult to type. If you're just writing your usual JavaScript without thinking about the types just figuring you'll "lint" it later with tsc to ca…

That's pretty much what I mean. A good linter will influence how you write code; e.g. over time, you'll have internalised to initialise a variable before using it, to name a dumb example. TypeScript is similar: yes, you'll write "regular" JavaScript, but no longer "without thinking about the types". TS very much influences how you write JS, and it makes you better for it.

Re: TypeScript Features to Avoid

#195

Post by Vinnl »

donatj wrote: post #95
Vinnl wrote: post #78

Earlier quoted context omitted.

> imho represent a misunderstanding of what Typescript is going for. It's pretty what TypeScript's going for though: > Avoid adding expression-level syntax. https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

I’m curious what they mean by “expression-level syntax” specifically, because they certainly added a lot of syntax that isn’t ECMA and aren’t just Babel, backporting future ECMA features.

As long as it's stage 3 EcmaScript, I (and the TS team, AFAIK) wouldn't count that as TS syntax - that's actual ES for all intents and purposes.

Other than that it's mostly syntax that affects how your code runs - i.e. if you were to remove all syntax that TS adds, the code should still run without further modifications in any interpreter that understands ES. (And features like enums don't satisfy this condition, hence why they don't match TS's design goals.)

Re: TypeScript Features to Avoid

#196

Post by erikpukinskis »

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…

This is actually the reason I prefer string unions.

Lets say I have a function that converts sizes to pixels:

     const sizeToPx(size: ‘small’ | ‘med’ | ‘large’): number
If I have a Button component that can only be small or medium that’s no problem:

    type ButtonProps = { size: ‘small’ | ‘medium’ }
    const Button = styled.button(({ size }: ButtonProps) => ({
      height: sizeToPx(size)
I can’t do that with an enum.

You’re correct there’s a risk of a type collision. But I have never experienced anything like that. Seems pretty unlikely.

Re: TypeScript Features to Avoid

#197

Post by mhoad »

rezonant wrote: post #192
mhoad wrote: post #176

Earlier quoted context omitted.

This was my first reaction also and I think it’s understandable but having looked at proposed solutions to it as well it actually doesn’t seem like such a big deal. I apologise if I get some minor details wrong here as I am doing this on a phone and recalling this from memory because I don’t have the time to grab the sources right now. However… the short version of the plan to solve this that I seem to recall to this…

> respective accessibility APIs that each platform exposes. That's the problem, there isnt an accessibility API for the web, is there? EDIT: At least not one that works without DOM

Hence my timeline of a few years, right now browsers have coupled accessibility with the DOM but that is going to change.

Re: TypeScript Features to Avoid

#198

Post by fifticon »

I cannot agree regarding enums. I want enums exactly as they are. In particular, I insist on decoupling their names and their values. I want to rename/update their names, without affecting their representing value. I want them to work with both integers and strings (as they do). Their raw values may appear in external data, for reasons that are none of your business, and thus must be preserved, maintained and under control. The enum as it exists was created by people who know what they are talking about when they talk about enums. People are free to go in their corner and play with their union types and crayons, but they should not confuse them with enums. There is nothing wrong with union types, apart from them being union types but not enums. The language with the best enums is java - enums in java are so great, that I often regret the hoops I have to jump through with enums in C# (you might well say, enums in java are overengineered).

Re: TypeScript Features to Avoid

#199

Post by yoz-y »

breatheoften wrote: post #84

Is anyone still using the class keyword in javascript or typescript? private field syntax doesn't matter in the first place if you don't use class {} anywhere ... I feel like most of the typescript code i've been in recently looked like it needed 0 more class declarations.

Is anyone... yes, of course.

React, Lit, angular, all use classes to define elements (yes you can use functions for a subset of components, but not all)

Re: TypeScript Features to Avoid

#200

Post by Zababa »

mhoad wrote: post #143
Zababa wrote: post #139

Earlier quoted context omitted.

> 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…

If you’re going to be working in a multi language code base I am with you. Handing people garbage looking generated or compiled code and saying work with this is going to require a solid set of well defined interfaces at a minimum and maybe like you said even giving up all of that and having to make one thing look like the other. All of what I said was under the assumption that you don’t need to think about JavaScrip…

Good points about JS being a target and that currently evolving. Lots of people these days code without any knowledge of assembly, maybe one day JS will be like that too. On the other hand, if your risk profile is more conservative (like many companies), you may want to let early adopters try out this "JS-less" world before investing in it. Since TS has a huge focus on large projects, and thus large companies, being conservative here makes sense.

For Dart, I wouldn't be so enthusiastic when describing it. The VM, hot reload, and all of that are impressive, but I'm not impressed by the language itself. The language seems to be an incremental improvement on 2005 Java and 2005 JavaScript, which are themselves not great. For example, it lacks data classes (records) and sealed classes. It took a long time to get nullability, the type checker (and system) are not impressive (things can easily fail at runtime).

Post reply on HN