171–180 of 212 posts
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.
Earlier quoted context omitted.
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.
The only difference is that you’ll be warned when you write inconsistent (buggy) code. And that your IDE will autocomplete with only compatible values.
There is absolutely no way typescript slows down development, you’re just totally free to ignore any or all of it. But it will help you more than you imagine.
tbf, the only valid reason not to use ts today is if your code targets directly the browser without any build step and is referenced as is by your html.
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(…
If you want "native" JS output, use the tsconfig option... "target": "esnext
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'
So... You have two declarations, one of which is a real array that's allocated at runtime. Is that really better than an enum? Not to mention, there's a slight mental overhead to parsing this. When I see this code, I might wonder if there's a reason for this to be an array. I might wonder if the order is intentional. An enum has a more clear intent. My only complaint is that enums are not string-by-default, so we end…
Enums are fine, just don't forget to use Object.freeze(enumName) afterwards!! Apart from that, because Typescript has powerful union types, not using enum is perfectly fine as well, for example instead of: enum Relation { Less = -1, Equal, Greater } Object.freeze(Relation); you could do instead: const Less = -1; type Less = -1; const Equal = 0; type Equal = 0; const Greater = 1; type Greater = 1; type Relation = Less…
It's true the down-levelled code that uses WeakMaps is slower. The decision to downlevel is in the hands of the user and is controlled by the tsconfig "target" option.
The only environment that needs downlevelled #private fields is IE11.
Earlier quoted context omitted.
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…
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…
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:
The Flutter team specifically seemed to indicate that they are already used to operating in non DOM environments where they have to support accessibility across Android, iOS, MacOS, Linux and Windows that doing it on web actually isn’t that big a deal as it first seems.
They already have all of the code in place that builds a full tree (like the DOM) which does a complete mapping between every element (widgets in Flutter lingo) on the canvas to their respective bits of accessibility info. They then just take that tree and hook it up to the respective accessibility APIs that each platform exposes.
At no point have they indicated that this looked like it was going to be a serious roadblock or challenge for them. I believe them and they have a history of this approach working elsewhere.
There is just too much money riding on this investment for them not to get accessibility 100% correct in a web native way.
From there if you are able to expose everything through accessibility APIs then you presumably also have everything you need as a search engine or an adblocker to actively read and modify that canvas. At this point the entire argument that it’s just an opaque set of pixels seems to vanish for me.
This is also AFAIK already a solved problem for them in other products where they are using canvas based rendering such as Google Earth and Google Docs.
I don’t have the details beyond that right now sorry but that passes the sniff test for me at least.
The author of the article surely knows the significant difference between JS private fields and TS private fields: TS private fields can be easily circumvented, whereas JS private fields cannot. See TS playground link[1]
I think this is a significant enough point that people should not be taught that TS's private is just a different way of doing the same thing. I've always said that TS is basically a fancy linter, and sometimes that's exactly what you want.
TS's private keyword communicates programmer intent, but lets you do what you like when you really have to. Just like the rest of TS.
[1]: https://www.typescriptlang.org/play?#code/MYGwhgzhAECC0G8BQ1...
Earlier quoted context omitted.
> Enums IMO have no advantage over union types with string literals, e.g. `type Status = 'fulfilled' | 'pending' | 'failed'`. Well I would say having to not repeat and update your code everywhere when you change or add a possible value is a pretty big advantage.
My IDE does this just fine (WebStorm, btw)
For people that don’t see the problem and are happily using these features, here’s an explanation of the second problem with these sorts of features, additional to the “it’s not just JavaScript with types which is what the label said” reason which is the focus of the article. The real trouble occurs when TypeScript implements something because that looks like the way things are heading, but then they don’t head that…
I recently listened to an interview with Igor, Angular’s inventor. In it he talked about how Angular 2 pushed decorators in to TS. And to this day, Angular is the only major JS thing that I can think of that uses decorators. Creating that ng-abomination was not enough. No. Google also had to poison a perfectly fine language.