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

Figma’s Journey to TypeScript

figma.com

Post reply on HN
Print view View original

241–250 of 257 posts

Re: Figma’s Journey to TypeScript

#241

Post by shepherdjerred »

sgt wrote: post #76
mindfulmark wrote: post #60

It’s interesting to read comment threads of people that are dead set against Typescript. It’s a tool that has very few downsides and that improves nearly every single line of code you write. Either they’re scared to learn something new, not willing to take the time, or misunderstanding how useful it is. For anyone reading these comments and agreeing with Typescript naysayers, I would think more about why the commente…

I'm not against TypeScript, but I don't really see the massive advantage. I rarely see problems that are due to typing, and the downside is usually limited as I keep my JS on the frontend, not the backend. Regular JS/ES6 just flows better.

This is a very fair comment, and you seem open to understanding why types are useful.

"problems that are due to typing" is a very difficult thing to unpack because types can mean _so_ many things.

Static types are absolutely useless (and, really, a net negative) if you're not using them well.

Types don't help if you don't spend the time modeling with the type system. You can use the type system to your advantage to prevent invalid states from being represented _at all_.

As an example, consider a music player that keeps track of the current song and the current position in the song.

If you model this naively you might do something like: https://gist.github.com/shepherdjerred/d0f57c99bfd69cf9eada4...

In the example above you _are_ using types. It might not be obvious that some of these issues can be solved with stronger types, that is, you might say that "You rarely see problems that are due to typing".

Here's an example where the type system can give you a lot more safety: https://gist.github.com/shepherdjerred/0976bc9d86f0a19a75757...

You'll notice that this kind of safety is pretty limited. If you're going to write a music app, you'll probably need API calls, local storage, URL routes, etc.

TypeScript's typechecking ends at the "boundaries" of the type system, e.g. it cannot automatically typecheck your fetch or localStorage calls return the correct types. If you're casting, you're bypassing the type systems and making it worthless. Runtime type checking libraries like Zod [0] can take care of this for you and are able to typecheck at the boundaries of your app so that the type system can work _extremely_ well.

[0]: https://zod.dev/ note: I mentioned Zod because I like it. There are _many_ similar libraries.

Re: Figma’s Journey to TypeScript

#242

Post by pquki4 »

yurishimo wrote: post #134
arnorhs wrote: post #51

Earlier quoted context omitted.

That is an impressive misrepresentation of history. PHP and its community were dying by the time FB used it. People here on HN kept talking php down. In 2014 FB made their own flavour of php with a bunch of perf features, called hack. Eventually a lot of the perf features hack made its way into php. FB is still on its own flavour. Php community is still dying.

You’re crazy if you think PHP is dying. Development on the language is steadily pushing forward with big QoL improvements coming to 8.4 later this year. The popular frameworks are still growing steadily and WordPress is starting to slowly shift off some of its stranglehold on old versions now that most webhosts don’t even offer old versions. That said, even Wordpress will work out of the box with old versions (they j…

Dude, go to TIOBE, stackoverflow survey, Google Trends or basically any ranking/metric that compares programming language popularity and user base, and without any question php is getting less and less usage over the last few years, often even ignored. Fewer and fewer job postings mention PHP at all. These are my first hand observations, if you don't believe it, you are welcome to look it up right now.

Re: Figma’s Journey to TypeScript

#243

Post by pquki4 »

some_furry wrote: post #58
arnorhs wrote: post #51

Earlier quoted context omitted.

That is an impressive misrepresentation of history. PHP and its community were dying by the time FB used it. People here on HN kept talking php down. In 2014 FB made their own flavour of php with a bunch of perf features, called hack. Eventually a lot of the perf features hack made its way into php. FB is still on its own flavour. Php community is still dying.

> PHP and its community were dying by the time FB used it. > Php community is still dying. https://www.tiobe.com/tiobe-index/php/ https://w3techs.com/technologies/overview/programming_langua... Yeah I dunno about that one.

The w3techs number is often quoted, but it has never been validated by anybody else, and its methodology is very questionable if not flat out wrong.

Re: Figma’s Journey to TypeScript

#244

Post by some_furry »

pquki4 wrote: post #243
some_furry wrote: post #58

Earlier quoted context omitted.

> PHP and its community were dying by the time FB used it. > Php community is still dying. https://www.tiobe.com/tiobe-index/php/ https://w3techs.com/technologies/overview/programming_langua... Yeah I dunno about that one.

The w3techs number is often quoted, but it has never been validated by anybody else, and its methodology is very questionable if not flat out wrong.

I'm not one to make perfect the enemy of good. If it's the best we have, it's what I will cite until better is provided.

Re: Figma’s Journey to TypeScript

#245

Post by vouwfietsman »

eddd-ddde wrote: post #208
vouwfietsman wrote: post #195

Earlier quoted context omitted.

> Duck typing can lead to a false sense of security when you /think/ you have Foo when in reality you have Bar with the same shape. This is literally always your problem with javascript, its only sometimes your problem with typescript. It's a weird argument. > Also Typescript sucks at keeping track of type changes in a single scope. Isn't this considered a very bad practice? Also rust does not allow this, it only all…

For the first one: It's not an issue in JavaScript because there isn't some compiler telling me yeah that's fine, I have to confirm myself. For the second one: I know it is shadowing, what I mean is I find commonly that I'd like to have it in Typescript as well. In JavaScript is not necessary since I can just use the same variable. For the third one: If I have some string variable that needs to be created from either…

1: You are similarly able to confirm yourself when you ducktype in TS, regardless: once you've ducktyped once in TS you are then at least helped by the compiler. Again, this is really not a good argument at all.

2: This is a programming practice I never see and would seriously question if its necessary ever, let alone "commonly". I think you may have picked up bad practices from writing in dynamic languages. Please see this for a few example arguments against this practice: https://softwareengineering.stackexchange.com/questions/1873...

3: You are now debating that Rust has better typing than TS, which makes sense because Rust is made from the ground up to have extremely well done static type checking, whereas typescript has to comply with dynamic typing originating from JS. It follows trivially that Rust has the better design because it has more freedom to do what it wants. JS < TS < Rust

Re: Figma’s Journey to TypeScript

#246

Post by _hl_ »

quectophoton wrote: post #108
mindfulmark wrote: post #60

It’s interesting to read comment threads of people that are dead set against Typescript. It’s a tool that has very few downsides and that improves nearly every single line of code you write. Either they’re scared to learn something new, not willing to take the time, or misunderstanding how useful it is. For anyone reading these comments and agreeing with Typescript naysayers, I would think more about why the commente…

> It’s a tool that has very few downsides and that improves nearly every single line of code you write. Sometimes I just don't feel like dealing with those very few downsides though, but I can accept it's mostly personal preference. At my age, sometimes I just don't want to deal with: 1. Yet another configuration file (tsconfig.json in this case). When something breaks, having one more place to look at is not somethi…

Don’t let perfection be the enemy of the good

Re: Figma’s Journey to TypeScript

#247

Post by julik »

Aeolun wrote: post #129
CuriouslyC wrote: post #107

Earlier quoted context omitted.

Remix. Vite done right, mostly pre-configured out of the box.

If you want to spend a minute or two waiting before your server is back up after making any kind of change, Remix sounds about right. My project is relatively tiny too. I’ve never regretted a choice more than Remix.

A minute or two? A sizeable Rails web app I am working on takes maybe 5 seconds to start...

Re: Figma’s Journey to TypeScript

#248

Post by vbezhenar »

vanderZwan wrote: post #111
debugnik wrote: post #61

Earlier quoted context omitted.

91.86% slower on my Android phone with Firefox, so it definitely depends on which JS engine.

Yeah, absolutely. With the linked benchmark I just got the following results on desktop Linux: - 17M ops/s ± 1.65% for array destructuring in Chrome - 169M ops/s ± 0.78% for object destructuring in Chrome - 545M ops/s ± 3.68% for array destructuring in Firefox - 81M ops/s ± 0.8% for object destructuring in Firefox So per the principle of "optimize for the bottleneck", one could choose to use object destructuring, bec…

77M ops/s ± 0.31%; 1.3B ops/s ± 0.17% for Safari. Difference is huge

800M ops/s ± 0.5%; 837M ops/s ± 0.32% for Chrome on the same computer.

Re: Figma’s Journey to TypeScript

#249

Post by _dain_ »

mistercow wrote: post #184
mirekrusin wrote: post #39

Earlier quoted context omitted.

Coffeescript had astonishing success, so many constructs made it to ecma standard. Coffeescript is still better than js with many ideas - everything is an expression, comprehensions, existential operator, extended switch statement, chained comparisons overall terse, readable syntax. Some things are terrible ie. type annotations through clunky comments.

I think the absolutely fatal mistake CoffeeScript made was implicit variable declarations, and how that worked with variable shadowing. Once it became clear that it was downright dangerous not to hack explicit variable declarations in using IIFEs, the entire language became a clunky mess. I have a ton of respect for the language and all of the stuff it cross-pollinated into JS, but it’s an interesting object lesson i…

>implicit variable declarations, and how that worked with variable shadowing.

Coffeescript was before my time so I never used it, can you give an example of the problems this caused?

Re: Figma’s Journey to TypeScript

#250

Post by mistercow »

_dain_ wrote: post #249
mistercow wrote: post #184

Earlier quoted context omitted.

I think the absolutely fatal mistake CoffeeScript made was implicit variable declarations, and how that worked with variable shadowing. Once it became clear that it was downright dangerous not to hack explicit variable declarations in using IIFEs, the entire language became a clunky mess. I have a ton of respect for the language and all of the stuff it cross-pollinated into JS, but it’s an interesting object lesson i…

>implicit variable declarations, and how that worked with variable shadowing. Coffeescript was before my time so I never used it, can you give an example of the problems this caused?

Basically, if you want to declare a local variable, you just assign it where you want it declared. It gets scoped automatically to whatever block it’s first assigned in. But if a variable with the same name was already declared earlier (for example in the parent block), then the language doesn’t provide a way to say “this is a new declaration”.

So what can happen is that you have some large block of code where, for example, near the top, you’ve said “x = 1”. Then, maybe a few hundred lines down you have a loop, and inside the loop you say “x = getWidget()”. You think you’re declaring a new variable, but actually you’re reusing a variable from the outer scope. There’s no way to know if you’re accidentally doing this except to search the entire enclosing scope.

It’s even worse in the other direction. You have a small block way down in a function where you’ve said “x = getWidget()” and this is all fine and correct. But you need to add something to the top of the function, and you add “x = 0”. You’ve now retroactively changed the scope of some random variable you weren’t even thinking about.

Edit: Actually my memory’s a little rusty, but I think they actually removed any kind of block scoping entirely by version 1, but everything I said above still applies to nested functions, which you tend to use liberally in CS.

Post reply on HN