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

111–120 of 257 posts

Re: Figma’s Journey to TypeScript

#111

Post by vanderZwan »

debugnik wrote: post #61
bryancoxwell wrote: post #34

Earlier quoted context omitted.

Quite a bit faster it looks like: https://jsbench.me/6zlvrupqmj/1

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, because the slowest Firefox is still comparable to the fastest Chrome option. Or when, for example, you're running Node on a server and know which JS engine you're using.

Re: Figma’s Journey to TypeScript

#112

Post by arcticfox »

foldr wrote: post #46
echelon wrote: post #20

Earlier quoted context omitted.

Some companies built a lot in CoffeeScript. Maintaining that won't be fun.

IIRC it compiled down to readable JS, so one reasonable option is just to delete the CoffeeScript and maintain the generated JS code.

Also it feels like LLMs were kind of born for that type of conversion.

Re: Figma’s Journey to TypeScript

#113

Post by quectophoton »

dfgdfg34545456 wrote: post #64
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…

>You’re putting yourself at a big disadvantage. Why not just appreciate the diversity of opinion and move on, rather than lecture people?

It's the Great Typing War all over again.

Some people feel more comfortable with JavaScript, Common Lisp, Lua, etc.

Some people feel more comfortable with TypeScript, Typed Racket, Luau, etc.

And that's okay.

Re: Figma’s Journey to TypeScript

#114

Post by halfmatthalfcat »

hparadiz wrote: post #83
julik wrote: post #63

Earlier quoted context omitted.

It is actually a fairly indicative story. At the start there is a brilliant individual (Evan) who sets up an entire toolchain + core of the product. They then move on (or get pushed out, or get bored), and with the team (and the product) now being much bigger, things get replatformed to a more familiar, widely used stack. The success of these steps heavily depends on how robust the eng culture is at the organisation.…

It's ironic. For the past 5 years I've been writing type strict PHP. People love to shit on PHP yet I found that when I started using strict types my code quality improved, amount of lines needed to produce a result decreased, and necessary unit tests to produce the same result also decreased. Then a few months ago I decided to write a TS project from scratch. For the record I have 18 years of JavaScript experience.…

tsx, esbuild, Bun, Deno, etc...all things that don't require you to use Webpack and just write/run TS...

Re: Figma’s Journey to TypeScript

#115

Post by blainelewis1 »

julik wrote: post #94
tossandthrow wrote: post #67

Earlier quoted context omitted.

I manage a relatively junior developer who has been using ts ignorer statements a couple of. times. I have said to him, that everytime he feel inclined to either use ts ignorer or do type coercion, he should call me first. every single time it is a reasoning flaw implementing a solution that is sub par and bug riddled. Had they just let types guide them, they would have become better developers and not had broken the…

The worst I had to deal with was converting anything browser-native into data structures that would satisfy the type checker (dealing with native references), and the whole "struct or class instance" dichotomy. Specifically - when there is a lot of DOM-native input (like drag&drop events and their targets and the targets of their targets) that have to be "repackaged" into a TS tree (ending up with properties which wo…

The ceremony is caused not by typescript but your misuse of map. You don’t need to create perserverid as an object first. Instead you could flatten fe.blocks, and then filter by b.serverId and then map to a key,value array and use Object.fromEntries to turn this into a keyed object.

Something like:

    const perServerId = Object.fromEntries(uploaderFiles.flatMap(fe => fe.blocks).filter(b => Boolean(b.serverId)).map(b => [b.serverId,b]))
And typescript infers the types correctly. But I still wouldn’t write it as one line, and I’d use lodash instead.

Re: Figma’s Journey to TypeScript

#116

Post by tossandthrow »

julik wrote: post #94
tossandthrow wrote: post #67

Earlier quoted context omitted.

I manage a relatively junior developer who has been using ts ignorer statements a couple of. times. I have said to him, that everytime he feel inclined to either use ts ignorer or do type coercion, he should call me first. every single time it is a reasoning flaw implementing a solution that is sub par and bug riddled. Had they just let types guide them, they would have become better developers and not had broken the…

The worst I had to deal with was converting anything browser-native into data structures that would satisfy the type checker (dealing with native references), and the whole "struct or class instance" dichotomy. Specifically - when there is a lot of DOM-native input (like drag&drop events and their targets and the targets of their targets) that have to be "repackaged" into a TS tree (ending up with properties which wo…

for most frameworks these typing are built. in (eg. react).

my expectation is that there are some packages/DOM typings so you don't need to write them?

regardless, your point stands: typing external dependencies is a pain.

Re: Figma’s Journey to TypeScript

#117

Post by ENGNR »

croes wrote: post #102
wolftickets wrote: post #95

Earlier quoted context omitted.

You wouldn’t really be able to tell. Figma is often just a tool for working out designs and building up a design system for your site. That later gets translated to your front end by your devs. Figma itself isn’t a styling library like tailwind, etc.

But are the designs lean or bloated. If Figma helps building lean designs it's good otherwise not. Designers tend to put too much useless parts into sites, like unnecessary transparencies and animations.

It's good with SVGs, themes, grouping elements into reusable components from your design system, and doing an art board per screen together so you can get an idea of your workflow through the app.

Not great at animations, not great at fully exploding all of the app state. Overall pretty good middle ground for designers and devs to interact.

Re: Figma’s Journey to TypeScript

#118

Post by quectophoton »

_dain_ wrote: post #81
sgt wrote: post #76

Earlier quoted context omitted.

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.

>I rarely see problems that are due to typing This is a fallacy similar to the Blub paradox: if your language has a weak[1] type system, then it isn't capable of recognizing many problems as "type error". But stronger type systems can express stronger invariants. So something that isn't a type error in one language will be a type error in another. This changes how the programmer conceives of problems. Example: missin…

Correct me if I'm wrong, but doesn't the Blub Paradox imply that languages dedicated to Code Golfing are at the pinnacle of expressiveness, and look down on everyone else's languages (for their extreme verbosity, compared to the golfing languages)?

Re: Figma’s Journey to TypeScript

#119

Post by crabmusket »

dtech wrote: post #17
crabmusket wrote: post #9

Earlier quoted context omitted.

I really wish browsers had continued to develop a "use strong" mode for JS. It sounded like there were significant challenges, but curbing some dynamism in order for more predictable optimisation sounds like a great tradeoffs for production-quality apps.

Take that to the extreme and you get WASM, or it's predecessor asm.js It's also what JITers like V8 internally do, you'll get major performance hits if you do weird dynamic things.

I think taken to the extreme "use strong" is more like putting Dart in the browser. But yes, you can sort of get the benefits of use strong with the right discipline.

Re: Figma’s Journey to TypeScript

#120

Post by cal85 »

croes wrote: post #102
wolftickets wrote: post #95

Earlier quoted context omitted.

You wouldn’t really be able to tell. Figma is often just a tool for working out designs and building up a design system for your site. That later gets translated to your front end by your devs. Figma itself isn’t a styling library like tailwind, etc.

But are the designs lean or bloated. If Figma helps building lean designs it's good otherwise not. Designers tend to put too much useless parts into sites, like unnecessary transparencies and animations.

If a designer uses ‘unnecessary’ transparencies and animations just because a design tool makes those things easy, that is not a problem with the design tool.
Post reply on HN