Earlier quoted context omitted.
web-sys[1] generates the binding code using the same IDL files that browsers use to generate their JS bindings to the C++ doing the actual work. [1] https://github.com/rustwasm/wasm-bindgen/tree/main/crates/we...
You still need to run JavaScript functions to manipulate the DOM. "without ever touching JS/TS" seems misleading as that implies "no JavaScript code is executed".
TypeScript 5.0
321–330 of 332 posts
Re: TypeScript 5.0
#322Earlier quoted context omitted.
> there is currently no sensible way to type a non empty array in Typescript If we remove the "sensible" requirement: type NonEmptyArray = [any, ...any[]]
Or better: type NonEmptyArray = [unknown, ...unknown[]]; const nea: NonEmptyArray = []; // ^^^ Type '[]' is not assignable to type 'NonEmptyArray'. // Source has 0 element(s) but target requires 1.
Re: TypeScript 5.0
#323Earlier quoted context omitted.
One of my most regretted decisions was evaluating Flow vs Typescript and going with Flow. Years later I had the opportunity to use Typescript and it was so nice comparatively. I've enjoyed it ever since. Of course, that was with years of development in its belt so maybe the experience wouldn't have been as nice if I went with it originally.
It’s hard to imagine if you weren’t in the React community at the time, but I feel like most people were pushing Flow at the time and choosing TS was quite controversial. I think it was the combination of Flow being from Facebook, and the “no build step/its just JS with annotations” thing which people made a big deal out of, but I never saw as a big differentiator. I had a hard time convincing a couple of places I wo…
I put quite some time into evaluating Flow vs Typescript around 2016, and preferred Flow mostly because its type checking was more correct, and its bugs more straightforward. Typescript would happily compile all sorts of incorrect code even with its strictest configs, it was insane.
I eventually found my happy place with Scala.js.
Re: TypeScript 5.0
#324Probably an unpopular opinion, but my favorite thing about typescript is what it's done for the jsdoc community. A bunch of stuff had to be built to support good tooling in vscode for types with JavaScript, and that was leveraged for jsdoc also. I don't use typescript, but I benefit from it in multiple ways, js doc and the occasional .d.ts file have made my life better.
The only other argument being “no compile step” which is a non-argument in the age of modern bundlers.
Re: TypeScript 5.0
#325Earlier quoted context omitted.
Pattern matching was recently added to C#. I can't say quite how well it's been embedded into the language. I always hear great things about F#, ADTs, pattern matching, nice type system and it integrates nicely into the rest of the .NET ecosystem.
F# is great. Simple, small, straightforward, great interop with .NET
They had me at features, lost me at manual compilation ordering.
Re: TypeScript 5.0
#326Earlier quoted context omitted.
Or better: type NonEmptyArray = [unknown, ...unknown[]]; const nea: NonEmptyArray = []; // ^^^ Type '[]' is not assignable to type 'NonEmptyArray'. // Source has 0 element(s) but target requires 1.
Can you map over this and preserve the NonEmptyArray type?
type NonEmptyArray = [T, ...T[]];Re: TypeScript 5.0
#327Re: TypeScript 5.0
#328Earlier quoted context omitted.
Does Swift has pattern matching and equivalent of Option/Result enums? I tried it casually but the documentation didn't feel great and things felt like they assumed familiarity with Apple's ecosystem.
Patterns: https://docs.swift.org/swift-book/documentation/the-swift-pr... Optionals: https://docs.swift.org/swift-book/documentation/the-swift-pr... Result: https://developer.apple.com/documentation/swift/result
Re: TypeScript 5.0
#329Earlier quoted context omitted.
Good take if you ask me. When I want to flesh out an ontology, I find that TypeScript's type syntax more natural than anything else. Generally I find it to do an amazing job of bridging between a very expressive and flexible type system and a language that at runtime knows nothing about your types. Want structural/duck typing? No problem; that's the default. Define new interfaces that old classes happen to implement…
Addendum to my nominal types: For the 'fake' nominal types (you can't put a symbol on a number!) I like to make those fields optional, which makes the type less of a lie. "If this number did have a [unit symbol] property, the value would be 'USD'". That will still prevent accidental USD CAD conversion, but allows converting to/from regular numbers without explicit casting. A pile of thoughts on the subject from back…
Re: TypeScript 5.0
#330Earlier quoted context omitted.
Does Swift has pattern matching and equivalent of Option/Result enums? I tried it casually but the documentation didn't feel great and things felt like they assumed familiarity with Apple's ecosystem.
Patterns: https://docs.swift.org/swift-book/documentation/the-swift-pr... Optionals: https://docs.swift.org/swift-book/documentation/the-swift-pr... Result: https://developer.apple.com/documentation/swift/result