Surprising to hear Figma had a custom language for JS. Even more surprising that it was faster than TS. And then they migrate <i>off</i> it onto slower TS!<p>Seems to happen a lot though. Company makes custom stuff early on, gets big, then migrates to something "standard".
Hey, I worked on this project! Wrote a bit more on Twitter here: <a href="https://twitter.com/andrew_k_chan/status/1786769203912925477" rel="nofollow">https://twitter.com/andrew_k_chan/status/1786769203912925477</a><p>The title of the post is misleading because we used Typescript at Figma for nearly a decade in other parts of the codebase, and there was more Typescript than Skew for almost that entire time. As the blog post explains, Skew was used in our mobile engine (and eventually for our prototyping player, mirroring feature, and maybe one or two other product surfaces I'm forgetting).
Skew wasn't just a little bit faster than TypeScript.<p>According to Evan Wallace (former Figma CTO), it was 1.5x to 2x faster due to better optimizations enabled by stricter type system.
> 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<p>This is interesting. Why doesn't JS just directly index arrays for destructuring?
They don’t really mention the ongoing developer experience impact (even if it is outweighed by the popularity of TypeScript) of losing Skew’s niceties, they just talk about the one-off transpilation of them when migrating the codebase. For example, the fact that it’s easy to end up with files that need to be imported in the right order in TypeScript, or things will break; or the fact that destructuring is slow and so should not be used (when performance is at all important). I know from using TypeScript for years that there are dozens of these gotchas (some inherited from JavaScript, some not), requiring an extensive style guide at the very least, especially if you have a lot of engineers.<p>I wonder if some engineers were sad to see Skew go.
This other blog post has some interesting details about how Figma wrote a custom TypeScript DSL + compiler to solve security problems (permissions).<p><a href="https://www.figma.com/blog/how-we-rolled-out-our-own-permissions-dsl-at-figma/" rel="nofollow">https://www.figma.com/blog/how-we-rolled-out-our-own-permiss...</a>
This pains me a bit. Every bigger company has their own inhouse tooling, language, kubernetes. Why not share.<p>If Skew was open sourced maybe it had become a better typescript.
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.<p>It's also crazy slow. We're having issues with Zod where it slows down our TypeScript language server performance significantly, so as a result we've had to introduce project references and disable project reference redirects.<p>All-in-all, there's plenty of work to be done to make TypeScript better. Especially in monorepos, and especially in making it performant.
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 commenter and yourself feel that way. You’re putting yourself at a big disadvantage.
Off topic: Does anyone know of any sites made with Figma so I can see what the UX is like?<p>As a user I don't care about DX if the resulting UX is bad.