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

171–180 of 257 posts

Re: Figma’s Journey to TypeScript

#171

Post by WuxiFingerHold »

CuriouslyC wrote: post #107
incrudible wrote: post #104

Earlier quoted context omitted.

Or just go straight to esbuild. I've found vite just makes things more complicated and slower. Particularly, the "smart reloading" breaks in subtle ways and turning every source file into a request doesn't scale well. This can probably be configured away somehow, but again, that just makes things more complicated.

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

Vue, Nuxt or Svelte are even better. No need to waste time and energy with React and it's peculiarities. However, if you want or must React, then Remix, hands down.

Re: Figma’s Journey to TypeScript

#172

Post by Jasper_ »

bryancoxwell wrote: post #23

> To complete an operation like `const [a, b] = function_that_returns_an_array()`, JavaScript constructs an iterator that iterates through the array instead of directly indexing from the array This is interesting. Why doesn't JS just directly index arrays for destructuring?

Any object can become iterable by adding Symbol.iterator, and destructuring should work for them. You can even patch Symbol.iterator on arrays itself, and the VM has to cope:

    > Array.prototype[Symbol.iterator] = function*() { yield 1; yield 2; yield 3; }
    > [...[4, 5, 6]]
    [1, 2, 3]
The terrible performance of the iterator protocol was discussed and ignored at the time, by saying that escape analysis would solve it [0]. Nearly 10 years later, and escape analysis has still not solved it. It's extremely GC-hungry and still sucks. It's just a bad spec, designed by people who are not performance-conscious.

It might make sense for engines to specialize destructuring assignment and splicing of Arrays to remove their iterator protocol overhead (if the user hasn't patched Symbol.iterator) but that's a whole other can of worms.

[0] https://esdiscuss.org/topic/performance-of-iterator-next-as-...

Re: Figma’s Journey to TypeScript

#173

Post by reasonableklout »

dvrp wrote: post #10
resonious wrote: post #2

Surprising to hear Figma had a custom language for JS. Even more surprising that it was faster than TS. And then they migrate off it onto slower TS! Seems to happen a lot though. Company makes custom stuff early on, gets big, then migrates to something "standard".

Why? Because Evan Wallace is gone. That’s my wild guess.

We actually recognized that Skew had become a liability years ago, and Evan worked on a proof-of-concept to remove Skew around ~2020. But as described in the article, benchmarks showed that performance would have been severely impacted (mobile Safari was an especially big problem). The rewrite only became possible once mobile WASM was performant enough for us to move the hot parts of our code to it and we had enough engineering resources to do it safely.

Re: Figma’s Journey to TypeScript

#174

Post by camdenreslink »

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

I agree that config and tooling are the hardest part of getting Typescript working. Everybody is saying use a framework, but if your use case deviates from the frameworks it can get pretty difficult. My use case that was very tricky to config was.

- SSR rendering of react in an express app (both typescript).

-Trying to get VSCode visual debugger to work for both the client and server code paths.

- Getting the various test libraries to work correctly (I still can’t get the NYC code coverage library to work).

- Mix of ESM, CommonJS, misconfigured npm packages that don’t expose their types correctly.

I ultimately used Vite, and got things working 90% the way I wanted and called it good enough.

Re: Figma’s Journey to TypeScript

#175

Post by Buttons840 »

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

And even after all the work configuring webpack, did you have readable stacktraces when an error happens?

Re: Figma’s Journey to TypeScript

#176

Post by eddd-ddde »

tossandthrow wrote: post #67
julik wrote: post #62

Earlier quoted context omitted.

As anything - "it depends"™. I did not notice "every single line of code" getting better at all. Yes, it makes things easier on a large team where people do not have time to do codebase discovery - or where people are moved to be highly interchangeable, on big codebases. Yes, static verification can help those teams and those codebases. But it also introduces a lot of extra work "just to appease the type system". It…

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…

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.

Also Typescript sucks at keeping track of type changes in a single scope. While in Rust I can assign string to foo and then update it with int, I can't in Typescript. This leads to worse types or worse code for the same operation. Combined with typescript's lack of statements as values, conditionally initializing a value is pretty obtuse.

Those are the issues that come to mind right now.

Re: Figma’s Journey to TypeScript

#177

Post by dimgl »

WuxiFingerHold wrote: post #157
dimgl wrote: post #131

I like TypeScript and we have a full-stack system on TypeScript but it's not perfect. Configuring TypeScript for monorepos is a nightmare. Having to make sense of it with internal packages under a pnpm monorepo requires lots of manual tsconfig.json work to make all of the paths work with each other. And our production toolchain was basically unmaintainable until the excellent tsx package became available. It's also c…

Zod is known to be slow. Typebox for example is much faster - not saying you should switch, but that it's not a Typescript issue or something that needs to be addressed by Typescript. Your monorepo issues sound like you didn't use the same config in all the packages? If that's the case, enforcing the same config and coding standards would be the first thing I would fix. Again, not a Typescript issue. Or did you use t…

We already do all of this, thanks.

We’re considering Typebox but it’s a big lift and the author of Typebox, while responsive in GitHub, doesn’t seem interested in improving interoperability and documentation regarding usage with tRPC.

Re: Figma’s Journey to TypeScript

#178

Post by dimgl »

jeswin wrote: post #145
dimgl wrote: post #131

I like TypeScript and we have a full-stack system on TypeScript but it's not perfect. Configuring TypeScript for monorepos is a nightmare. Having to make sense of it with internal packages under a pnpm monorepo requires lots of manual tsconfig.json work to make all of the paths work with each other. And our production toolchain was basically unmaintainable until the excellent tsx package became available. It's also c…

> I like TypeScript and we have a full-stack system on TypeScript but it's not perfect. Configuring TypeScript for monorepos is a nightmare. It isn't TypeScript that needs to support your particular set of tooling and library choices, but the other way round. We have a mid-sized monorepo (multiple apps, many services) which is mostly typescript. It works alright with a boring npm workspaces based configuration.

Zod is recommended by most modern type safe packages. Also this is not the first time we’ve run into TS performance issues. MUI also suffers from poor TS performance.

I agree with your assessment re: library choices in theory but it suck to run into these DX problems that you wouldn’t normally run into with other languages, like Go for example.

Re: Figma’s Journey to TypeScript

#179

Post by sureIy »

brainzap wrote: post #87

This pains me a bit. Every bigger company has their own inhouse tooling, language, kubernetes. Why not share. If Skew was open sourced maybe it had become a better typescript.

I’m not a fan of this take and it usually comes from lack of OSS experience.

Just because something is open source, it doesn’t mean you get free contributions. Every non-trivial PR must be followed by lengthy reviews, discussions and possibly rewrites.

Re: Figma’s Journey to TypeScript

#180

Post by dimgl »

sod wrote: post #143
dimgl wrote: post #131

I like TypeScript and we have a full-stack system on TypeScript but it's not perfect. Configuring TypeScript for monorepos is a nightmare. Having to make sense of it with internal packages under a pnpm monorepo requires lots of manual tsconfig.json work to make all of the paths work with each other. And our production toolchain was basically unmaintainable until the excellent tsx package became available. It's also c…

Saying typescript is slow because zod is slow is like saying c++ is slow, because javascript is slow. Not to say that typescript is quick in any way (how could it be, as something written in javascript). But letting typescript execute code to infer types in a large scale application seems like a self inflicted issue.

But TypeScript IS slow. It just so happens that the issue is currently with Zod but JavaScript in general has always been less performant than other lower level languages. This is why JavaScript tooling is all built in other languages.
Post reply on HN