Live data from Hacker News

Figma’s Journey to TypeScript

figma.com

31–40 of 257 posts

Re: Figma’s Journey to TypeScript

#31
post #15

Earlier quoted context omitted.

You probably know that Figma is a UX design software. This means it’s basically a graphics program: you draw shapes, you scroll and zoom around. It does that extremely well. It’s unbelievably snappy even on a very large canvas with many complex UI screens. Very few desktop applications run nearly as well these days. I’m convinced that this kind of optimization is an important part of their success.

I'm curious about how it all hangs together, WebAssembly and Typescript. The very first mention of WebAssembly in the article: "Some years after WebAssembly obtained widespread mobile support, we replaced many core components of our Skew engine"

I'd assume all the graphics computation happens in C++ code via WebAssembly, which is then rendered in the browser via WebGL. The Typescript part is the glue and all the non-gfx parts of the interface, like the top bar / sidebars / etc.

Since Figma is also all about multiplayer, I imagine they might have a system that takes changes to a document, packages them up in a compact binary format, and then sends that over the wire (to Figma or to other connected clients). A decent decent target for a WASM module would probably be that serialization/deserialization step.

Re: Figma’s Journey to TypeScript

#32
post #10

Earlier quoted context omitted.

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

It does smell like someone's pet project. I'm wondering what the folk at Microsoft had not figured out, that they indeed had at Figma. Typescript is open source, so why wasn't this optimisation just made as a contribution to Typescript at the time? Also, was Typescript really as claimed in its "infancy" at the time mentioned in the article? They didn't mention a particular year.

It's something Typescript doesn't want to do. Their goal is to remove the type annotations, maybe add some code for backwards compatibility, and otherwise do as little as possible to stray from the untyped JavaScript equivalent.

Re: Figma’s Journey to TypeScript

#33
post #27

Earlier quoted context omitted.

Why don't you like it? Personally, I don't like it either. Firstly - entirely irrationally - because I don't like Microsoft. I grew up with them acting incredibly hostile towards the open source community and the rest of the industry, and I find that hard to forget. I know that has nothing to do with the merits of TypeScript, but I can't say it's not there. Secondly, I don't like the complexity incurred by any compil…

I also hate microsoft. I worked with their piece of shit browser for 20 years. From ie3 onward they all sucked and lagged behind. Their OS was complete garbage and somehow they managed to penetrate like 90% of the desktop market. but beyond that typescript i find is cognitive overload for someone who considers themselves an expert at vanilla javascript. It more than doubles the development time. I rarely use the infl…

Yeah, I think that's a good point. I'm actually quite on the fence about dynamic and static typing - I like both. With a small team that knows what they're doing, I tend to go dynamic. With a larger team, it does tend to become a bit of a mess and weird workarounds to not having static typing (like some mystical 100% test coverage) start to surface.

I love the approach Python and MyPy took there: Python supports but ignores type annotations. You can add them to any part you want and check it with MyPy, but you can truly do it gradually, and you can always decide not to do it. An approach like that would fit JavaScript beautifully, I think.

Re: Figma’s Journey to TypeScript

#34

> 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?

Because things like proxies exist, I guess. Also, what's even more crazy is that destructuring {0: foo, 1: bar} can be faster in some javascript engines when destructuring an array with two or three element.

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

Re: Figma’s Journey to TypeScript

#35
post #10

Earlier quoted context omitted.

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

It does smell like someone's pet project. I'm wondering what the folk at Microsoft had not figured out, that they indeed had at Figma. Typescript is open source, so why wasn't this optimisation just made as a contribution to Typescript at the time? Also, was Typescript really as claimed in its "infancy" at the time mentioned in the article? They didn't mention a particular year.

Let's not paint pet projects black. Most things we're using today were somebody's pet projects including linux, llvm/clang, swift etc.

Re: Figma’s Journey to TypeScript

#36
post #33

Earlier quoted context omitted.

I also hate microsoft. I worked with their piece of shit browser for 20 years. From ie3 onward they all sucked and lagged behind. Their OS was complete garbage and somehow they managed to penetrate like 90% of the desktop market. but beyond that typescript i find is cognitive overload for someone who considers themselves an expert at vanilla javascript. It more than doubles the development time. I rarely use the infl…

Yeah, I think that's a good point. I'm actually quite on the fence about dynamic and static typing - I like both. With a small team that knows what they're doing, I tend to go dynamic. With a larger team, it does tend to become a bit of a mess and weird workarounds to not having static typing (like some mystical 100% test coverage) start to surface. I love the approach Python and MyPy took there: Python supports but…

> supports but ignores type annotations

That’s how TS works too though - compilation just strips the types via babel etc, with type checking a separate process. You opt in file by file by switching .js to .ts

Re: Figma’s Journey to TypeScript

#37

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

It happened in the PHP community as well, facebook being the poster child, but Yahoo also had a fair number of internal optimizations and I saw a few other companies tweak their way to get better perf/security. Then comes a point where the community catches on and has bigger momentum than the company, so it makes sense to move to the standard implementation. I'd kinda see Google's Borg -> k8s move as slightly similar…

Isn't FB/Meta still on Hack + HVVM?

Re: Figma’s Journey to TypeScript

#38
post #33

Earlier quoted context omitted.

Yeah, I think that's a good point. I'm actually quite on the fence about dynamic and static typing - I like both. With a small team that knows what they're doing, I tend to go dynamic. With a larger team, it does tend to become a bit of a mess and weird workarounds to not having static typing (like some mystical 100% test coverage) start to surface. I love the approach Python and MyPy took there: Python supports but…

> supports but ignores type annotations That’s how TS works too though - compilation just strips the types via babel etc, with type checking a separate process. You opt in file by file by switching .js to .ts

Well, the nice thing with Python types is that the _only_ difference to untyped Python is the type annotations. Last time I worked with TypeScript (two and a half years ago), it felt more like a different language _similar_ to JS. In my experience it was quite... viral. With MyPy I've genuinely seen just specific parts of a code base become typed and didn't notice any friction.

I wonder what would happen if that proposal for type comments in JS went through. Would TypeScript become just a type checker / optimizing compiler?

Google's Closure had an (IMHO) nicer approach (using doc comments for type annotations, see: https://github.com/google/closure-compiler/wiki/Types-in-the...), but I don't get the impression it'll ever catch on outside Google.

Re: Figma’s Journey to TypeScript

#39
post #6

Earlier quoted context omitted.

Often because the "standard" thing was not always the standard. Like, all those people that chose Flow now have something "non-standard."

Coffeescript used to be "standard" in Ruby on Rails community. (insert canned laughter)

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.

Re: Figma’s Journey to TypeScript

#40

Earlier quoted context omitted.

It does smell like someone's pet project. I'm wondering what the folk at Microsoft had not figured out, that they indeed had at Figma. Typescript is open source, so why wasn't this optimisation just made as a contribution to Typescript at the time? Also, was Typescript really as claimed in its "infancy" at the time mentioned in the article? They didn't mention a particular year.

Let's not paint pet projects black. Most things we're using today were somebody's pet projects including linux, llvm/clang, swift etc.

>Let's not paint pet projects black.

I don't follow. Where did I do this?

Post reply on HN