16 ms·

Figma’s Journey to TypeScript

261 points by soheilpro 2y ago

resonious 2y ago
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".
- paulddraper 2y ago
  Often because the "standard" thing was not always the standard. Like, all those people that chose Flow now have something "non-standard."
  - raincole 2y ago
    Coffeescript used to be "standard" in Ruby on Rails community. (insert canned laughter)
    - gmac 2y ago
      Why the laughter? CoffeeScript was great. TypeScript is even greater. All IMHO and YMMV, of course.
      - echelon 2y ago
        Some companies built a lot in CoffeeScript. Maintaining that won't be fun.
        foldr 2y ago
        IIRC it compiled down to readable JS, so one reasonable option is just to delete the CoffeeScript and maintain the generated JS code.
        arcticfox 2y ago
        Also it feels like LLMs were kind of born for that type of conversion.
    - mirekrusin 2y ago
      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.
      - mistercow 2y ago
        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 in how a seemingly tiny design choice can turn out to be disastrous.
        mirekrusin 2y ago
        Yes, that was stupid. Also not embracing flow/ts when they had a chance still riding on atom/rails. I guess when exploring uncharted territory it's a bit of a dice roll - you can't keep winning all the time. Otherwise great contrib to advance frontier.
        _dain_ 2y ago
        >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?
        mistercow 2y ago
        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.
    - mejutoco 2y ago
      And prototypejs before jquery!
- tstrimple 2y ago
  Faster than TS for a narrow use-set is a fairly low bar. But as you scale it's a bar you have to measure against the available talent from the market. You've got to weigh the cost of a developer who can pick up a completely new framework sight unseen versus the weight of a developer who has documented experience in a platform or technology you're already using. If you go full custom development you can get incredible performance out of literally any language and framework out there. But as your project needs to handle more and more scenarios, the number of developers needed to maintain it reaches a point where you're better off with Off The Shelf software despite it being slower and not specifically suited to your needs. If you can maintain your Unicorn hiring criteria long term, maybe fully custom stacks are maintainable. For most organizations, they need to move to something that the average hire can maintain going forward. That means big name boring software vendors for the most part.
- makeitdouble 2y ago
  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, though they're the one inviting the community around the standard they built themselves.
  - the_duke 2y ago
    Isn't FB/Meta still on Hack + HVVM?
    - makeitdouble 2y ago
      They are. At this point it's a completely different language with its own stack, as far as I know that will be a core component for the forseable future. Now they also have modern PHP and some other languages alongside with hack from what I understand.
      - rafark 2y ago
        It’s not completely different, it’s still mostly the same language with some big additions. If you read their dev blog, you’ll see they fixed a bug that was also present in php a few months ago.
      - phyrex 2y ago
        I don’t think there’s any vanilla php in use at meta
        makeitdouble 2y ago
        Don't know if it's vanilla, but there seems to be some: https://medium.com/@aarthimanikandan2006/does-facebook-still-use-php-unveiling-the-technology-behind-the-social-media-giant-6a0f0a7cb833 https://medium.com/@aarthimanikandan2006/does-facebook-still...
- dvrp 2y ago
  Why? Because Evan Wallace is gone. That’s my wild guess.
  - leononame 2y ago
    One of the first points in the article was that wasm became widespread enough that they could migrate them performance critical parts to C++ and the rest to typescript. The necessity for skew simply wasn't there anymore
  - dfgdfg34545456 2y ago
    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.
    - wewxjfq 2y ago
      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.
    - mirekrusin 2y ago
      Let's not paint pet projects black. Most things we're using today were somebody's pet projects including linux, llvm/clang, swift etc.
      - dfgdfg34545456 2y ago
        >Let's not paint pet projects black. I don't follow. Where did I do this?
        Drakim 2y ago
        > It does smell like someone's pet project. "Smell" has negative connotations in English. If you say that "this code smells" it means it's bad, and likewise it's very easy to read your "It does smell like" as you meaning it's a bad thing.
- onion2k 2y ago
  Weird and quirky things like custom languages are bad for your resume if you're just a user (e.g a dev who uses it) rather than the implementor. That means ambitious people will consider it to be a reason to leave. It also makes hiring harder and onboarding takes longer. You also have a big transformation project to do if you ever drop your custom language. Sometimes it's worth it if the speed boost is huge, or if you can write safer code, or if you actually want to gatekeep hiring to people who like learning new languages.
- jpgvm 2y ago
  If you read carefully they migrated all the perf sensitive parts to C++/WASM. At that point only glue was left and their custom language didn't have a reason to exist anymore.
- julik 2y ago
  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. I suspect (no evidence though!) that Evan and other founders have set up an excellent eng culture at Figma and even if they make a mistake at some point, there is sufficient resilience in place to correct. All power to them!
  - hparadiz 2y ago
    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. What I found was that the biggest barrier to entry was configuring webpack to be "just right". Other devs on my team with similar level of experience would have their eyes glaze over when webpack came up and get annoyed. For good reason. It took me several days to get it to work right. The fact that the tsconfig has 20 options that can effect the transpiler and not have good docs is a problem. The fact that there needs to be two tsconfigs in a react native project that compiles down to web as a secondary build target is another problem. The fact that you need a very experienced dev to spend days configuring webpack is another problem. Finding information about the right configuration is like the blind leading the blind. Most search results on the topic are riddled with half truths and non sense. Many devs rely on a preexisting webpack config and if they do anything to mess it up they are many times completely unable to fix it. Typescript is fine. I guess. The code produced is nicer. But having to rely on webpack is an issue. I actually like TS but I wish I didn't need to transpile anything or have to bang my head against a webpack config for days. It's by far the biggest barrier to entry because while you're banging your head against it you're not writing code. And for none technical stake holders when you have nothing visual to show at stand ups that can create friction and make the engineers seem like they aren't doing anything. So far at multiple companies I've had to configure webpack for extremely complex JavaScript based single page apps which took me literally months of messing around with it until it worked just right. And until it does work "just right" the non technical folks think you're wasting time.
- Justsignedup 2y ago
  They likely realized that maintaining their own language is very risky and going full on standardized means they can take advantage of massive progress in the entire ts ecosystem. Custom is great right up to when the lead eng leaves.
metadata 2y ago
Skew wasn't just a little bit faster than TypeScript. According to Evan Wallace (former Figma CTO), it was 1.5x to 2x faster due to better optimizations enabled by stricter type system.
- crabmusket 2y ago
  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.
  - dtech 2y ago
    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.
    - hajile 2y ago
      If you want complete type erasure, then a system that ensures monomorphism is critical to good JS performance. If you can leave the type system in place, then you could move toward an ML-style type system and see massive improvements within strictly-typed parts of the code as you'd only need type guards and inline caches at the boundaries of the strictly-typed code.
    - crabmusket 2y ago
      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.
    - Dylan16807 2y ago
      > Take that to the extreme and you get WASM, or it's predecessor asm.js Only if your code was pure number crunching. Normal code can't just go through some belt tightening to become WASM/asm.js code. Compiling it down that way is very different from making the control flow more understandable to the optimizer.
porsager 2y ago
Ah yes.. Switch to Typescript and give up all your advances to get a brand new set of crutches.
- wiseowise 2y ago
  Can you elaborate what you consider "crutches" in this case?
  - porsager 2y ago
    They had a custom language giving them full flexibility to achieve making a product in the browser that put them ahead of everyone else, and instead of embracing that, they throw it out to be able to hire of the shelve developers to code in a language that doesn't let them move freely. Typescript is like crutches in the sense that it might support you in not falling, but you only really need them if you're crippled in some way.
    - IshKebab 2y ago
      What are you talking about? Typescript is a fantastic improvement on JavaScript. Skew doesn't look fundamentally better enough that it would be worth the downsides. Lack of IDE support alone is probably enough to cancel out a productivity gains from a better language.
    - whywhywhywhy 2y ago
      > They had a custom language giving them full flexibility to achieve making a product in the browser that put them ahead of everyone else From the article it sounds like it was only used for the prototyping system so a single code base could run in the iOS client and the Web client. I believe the main UI of Figma and what makes it so performant and magical to use is C++ https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
- frou_dh 2y ago
  They should have brought you in as a consultant so that they would have arrived at the correct decision. Alas, they are now doomed to be wrong forever.
dfgdfg34545456 2y ago
For people like me who know little about Figma, what motivates their use of WebAssembly?
- jumploops 2y ago
  They started with the goal of photoshop in the browser.
  - 8n4vidtmkvmk 2y ago
    Photopea is great and replaced my need for PS. I only do light weed editing though
    - gedy 2y ago
      > light weed editing Sounds like getting stoned and making a meme or something
      - erhaetherth 2y ago
        Haha. Auto-correct. I think I meant light "work" editing maybe??
- codeflo 2y ago
  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.
  - dfgdfg34545456 2y ago
    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"
cranberryturkey 2y ago
[flagged]
- fhd2 2y ago
  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 compile-to-JS language. For Figma I bet it's worth it, I bet they did their homework. But the amount of tiny projects I've seen that are an unreasonable maintenance burden because of all the packages and toolchains they use, it'd be funny if it wasn't sad. I might still use TypeScript, but for me it's more of a "give me a reason to use it" than a "give me a reason not to use it" kind of situation.
  - cranberryturkey 2y ago
    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 inflections because 50% of the time it points to "any" so its utterly useless...and these kids who claim "but you won't get an undefined error!" is just well fix your fucking undefined error when you see it...is my response. WHy do I need to 3x my dev time and hurt my brain in the process so some jackass doesn't have to worry about an undefined variable. I also think the reason MS released TS is because they were unable to find good devs who knew JS. ALl that typeshit in other languages (most enterprise crap like java and .net/c#) could now all be converted to ts devs without having to rehire. TS is for offshore teams imo. That being said I will say on a team of 50+ devs on the same codebase I would vote for typescript becuase you will get a shit load of js spaghetti otherwise from these people who can't be bothered to understand js.
    - 2y ago
bryancoxwell 2y ago
> 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?
- vanderZwan 2y ago
  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.
  - bryancoxwell 2y ago
    Quite a bit faster it looks like: https://jsbench.me/6zlvrupqmj/1 https://jsbench.me/6zlvrupqmj/1
    - debugnik 2y ago
      91.86% slower on my Android phone with Firefox, so it definitely depends on which JS engine.
      - vanderZwan 2y ago
        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.
        vbezhenar 2y ago
mindfulmark 2y ago
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.
- julik 2y ago
  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 rarely improves performance (if ever). Because TS has no runtime inference/validation, working with larger libraries or the browser can be a chore because half of your code are type signatures or casts. So - not necessarily a naysayer, but I do believe that TS is oversold and with smaller teams/projects it might be slowing you down as opposed to helping.
  - tossandthrow 2y ago
    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 application. I am curious though. can you provide a snippet where types would be a disprovement?
    - julik 2y ago
      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 would be a JS-version of void*). An example of what I call "ceremony" would be interface BlockIndex { [key: string]: UploaderBlock; } const perServerId = {} as BlockIndex; uploaderFiles.map((fe) => fe.blocks.map((b) => b.serverId && (perServerId[b.serverId] = b))); While somewhat useful, this is in internal code which never gets used directly, and there are 4 lines of ceremony for 1 line of actual code.
jd0x 2y ago
[flagged]
croes 2y ago
Off topic: Does anyone know of any sites made with Figma so I can see what the UX is like? As a user I don't care about DX if the resulting UX is bad.
- whywhywhywhy 2y ago
  It’s just a system for animating the transitions between flat designs and adding scroll areas so you can preview an estimation of a design on mobile and web. Doesn’t even support more advanced prototyping things like inputs and dynamic changes. Not a site builder
- wolftickets 2y ago
  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.
  - croes 2y ago
    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.
    - gryn 2y ago
      that's like asking if a pen or keyboard lead to bloat. depends on who's using them.
      - croes 2y ago
        More like if AI leads to spam or if guns kill people. The latter one is harder if you only have a knife instead of an assault rifle.
        alpinisme 2y ago
brainzap 2y ago
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.
- poiru 2y ago
  Skew is open source, but no longer maintained: https://github.com/evanw/skew https://github.com/evanw/skew
- sureIy 2y ago
  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.
Nishant6572 2y ago
[flagged]
tambourine_man 2y ago
>… TypeScript, the industry standard language for the web This breaks my heart.
- salomonk_mur 2y ago
  Why? It's the truth.
  - airstrike 2y ago
    things can both be true and heartbreaking
  - tambourine_man 2y ago
    The frontend language for the web is JavaScript. People who don’t like JavaScript but, for whatever reason, still want to write frontend apps have chosen to invent a new language that transpiles to it. To call that effort a standard is heartbreaking to me.
dimgl 2y ago
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 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. All-in-all, there's plenty of work to be done to make TypeScript better. Especially in monorepos, and especially in making it performant.
- kirbyfan64sos 2y ago
  Do note that Zod is a bit of an outlier in how slow it can make type checking, e.g. https://dev.to/nicklucas/typescript-runtime-validators-and-dx-a-type-checking-performance-analysis-of-zodsuperstructyuptypebox-5416 https://dev.to/nicklucas/typescript-runtime-validators-and-d... one of the tests hits nearly 300ms, but no other library even touches 100ms.
- sod 2y ago
  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.
  - anamexis 2y ago
    What do you mean by that? I don't think Zod is doing anything special as far as the TS type system goes, although its types are necessarily complex to make its "magic" work. But it's not executing code to infer the types
  - dimgl 2y ago
    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.
reasonableklout 2y ago
Hey, I worked on this project! Wrote a bit more on Twitter here: https://twitter.com/andrew_k_chan/status/1786769203912925477 https://twitter.com/andrew_k_chan/status/1786769203912925477 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).
gregors 2y ago
>>> Modern JavaScript features like async/await and a more flexible type system So Skew only had callbacks?
- elwell 2y ago
  Maybe `Promise`s?
freeqaz 2y ago
This other blog post has some interesting details about how Figma wrote a custom TypeScript DSL + compiler to solve security problems (permissions). https://www.figma.com/blog/how-we-rolled-out-our-own-permissions-dsl-at-figma/ https://www.figma.com/blog/how-we-rolled-out-our-own-permiss...
sghiassy 2y ago
Lesson to learn: don’t build custom languages
dgreensp 2y ago
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. I wonder if some engineers were sad to see Skew go.
- reasonableklout 2y ago
  It was certainly important for us to make sure developers were happy with the result. That's why our rollout included stuff like a phase where developers continued writing Skew but their changes automatically checked-in generated TS. This way, devs could see what it would look like in PR review and report issues. As for performance and runtime correctness, you're right that there are some gotchas with TS. We caught issues like the array destructuring one with instrumentation and strict monitoring. I was definitely sad to see some features of Skew go. For example, operator overloading and integer types. But the move was ultimately a decision the whole team made, and I agree with them that it was the right one.

261 points by soheilpro 2y ago

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

paulddraper 2y ago
Often because the "standard" thing was not always the standard. Like, all those people that chose Flow now have something "non-standard."
- raincole 2y ago
  Coffeescript used to be "standard" in Ruby on Rails community. (insert canned laughter)
  - gmac 2y ago
    Why the laughter? CoffeeScript was great. TypeScript is even greater. All IMHO and YMMV, of course.
    - echelon 2y ago
      Some companies built a lot in CoffeeScript. Maintaining that won't be fun.
      - foldr 2y ago
        IIRC it compiled down to readable JS, so one reasonable option is just to delete the CoffeeScript and maintain the generated JS code.
        arcticfox 2y ago
        Also it feels like LLMs were kind of born for that type of conversion.
  - mirekrusin 2y ago
    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.
    - mistercow 2y ago
      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 in how a seemingly tiny design choice can turn out to be disastrous.
      - mirekrusin 2y ago
        Yes, that was stupid. Also not embracing flow/ts when they had a chance still riding on atom/rails. I guess when exploring uncharted territory it's a bit of a dice roll - you can't keep winning all the time. Otherwise great contrib to advance frontier.
      - _dain_ 2y ago
        >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?
        mistercow 2y ago
        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.
  - mejutoco 2y ago
    And prototypejs before jquery!
tstrimple 2y ago
Faster than TS for a narrow use-set is a fairly low bar. But as you scale it's a bar you have to measure against the available talent from the market. You've got to weigh the cost of a developer who can pick up a completely new framework sight unseen versus the weight of a developer who has documented experience in a platform or technology you're already using. If you go full custom development you can get incredible performance out of literally any language and framework out there. But as your project needs to handle more and more scenarios, the number of developers needed to maintain it reaches a point where you're better off with Off The Shelf software despite it being slower and not specifically suited to your needs. If you can maintain your Unicorn hiring criteria long term, maybe fully custom stacks are maintainable. For most organizations, they need to move to something that the average hire can maintain going forward. That means big name boring software vendors for the most part.
makeitdouble 2y ago
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, though they're the one inviting the community around the standard they built themselves.
- the_duke 2y ago
  Isn't FB/Meta still on Hack + HVVM?
  - makeitdouble 2y ago
    They are. At this point it's a completely different language with its own stack, as far as I know that will be a core component for the forseable future. Now they also have modern PHP and some other languages alongside with hack from what I understand.
    - rafark 2y ago
      It’s not completely different, it’s still mostly the same language with some big additions. If you read their dev blog, you’ll see they fixed a bug that was also present in php a few months ago.
    - phyrex 2y ago
      I don’t think there’s any vanilla php in use at meta
      - makeitdouble 2y ago
        Don't know if it's vanilla, but there seems to be some: https://medium.com/@aarthimanikandan2006/does-facebook-still-use-php-unveiling-the-technology-behind-the-social-media-giant-6a0f0a7cb833 https://medium.com/@aarthimanikandan2006/does-facebook-still...
dvrp 2y ago
Why? Because Evan Wallace is gone. That’s my wild guess.
- leononame 2y ago
  One of the first points in the article was that wasm became widespread enough that they could migrate them performance critical parts to C++ and the rest to typescript. The necessity for skew simply wasn't there anymore
- dfgdfg34545456 2y ago
  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.
  - wewxjfq 2y ago
    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.
  - mirekrusin 2y ago
    Let's not paint pet projects black. Most things we're using today were somebody's pet projects including linux, llvm/clang, swift etc.
    - dfgdfg34545456 2y ago
      >Let's not paint pet projects black. I don't follow. Where did I do this?
      - Drakim 2y ago
        > It does smell like someone's pet project. "Smell" has negative connotations in English. If you say that "this code smells" it means it's bad, and likewise it's very easy to read your "It does smell like" as you meaning it's a bad thing.
onion2k 2y ago
Weird and quirky things like custom languages are bad for your resume if you're just a user (e.g a dev who uses it) rather than the implementor. That means ambitious people will consider it to be a reason to leave. It also makes hiring harder and onboarding takes longer. You also have a big transformation project to do if you ever drop your custom language. Sometimes it's worth it if the speed boost is huge, or if you can write safer code, or if you actually want to gatekeep hiring to people who like learning new languages.
jpgvm 2y ago
If you read carefully they migrated all the perf sensitive parts to C++/WASM. At that point only glue was left and their custom language didn't have a reason to exist anymore.
julik 2y ago
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. I suspect (no evidence though!) that Evan and other founders have set up an excellent eng culture at Figma and even if they make a mistake at some point, there is sufficient resilience in place to correct. All power to them!
- hparadiz 2y ago
  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. What I found was that the biggest barrier to entry was configuring webpack to be "just right". Other devs on my team with similar level of experience would have their eyes glaze over when webpack came up and get annoyed. For good reason. It took me several days to get it to work right. The fact that the tsconfig has 20 options that can effect the transpiler and not have good docs is a problem. The fact that there needs to be two tsconfigs in a react native project that compiles down to web as a secondary build target is another problem. The fact that you need a very experienced dev to spend days configuring webpack is another problem. Finding information about the right configuration is like the blind leading the blind. Most search results on the topic are riddled with half truths and non sense. Many devs rely on a preexisting webpack config and if they do anything to mess it up they are many times completely unable to fix it. Typescript is fine. I guess. The code produced is nicer. But having to rely on webpack is an issue. I actually like TS but I wish I didn't need to transpile anything or have to bang my head against a webpack config for days. It's by far the biggest barrier to entry because while you're banging your head against it you're not writing code. And for none technical stake holders when you have nothing visual to show at stand ups that can create friction and make the engineers seem like they aren't doing anything. So far at multiple companies I've had to configure webpack for extremely complex JavaScript based single page apps which took me literally months of messing around with it until it worked just right. And until it does work "just right" the non technical folks think you're wasting time.
Justsignedup 2y ago
They likely realized that maintaining their own language is very risky and going full on standardized means they can take advantage of massive progress in the entire ts ecosystem. Custom is great right up to when the lead eng leaves.

metadata 2y ago

Skew wasn't just a little bit faster than TypeScript. According to Evan Wallace (former Figma CTO), it was 1.5x to 2x faster due to better optimizations enabled by stricter type system.

crabmusket 2y ago
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.
- dtech 2y ago
  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.
  - hajile 2y ago
    If you want complete type erasure, then a system that ensures monomorphism is critical to good JS performance. If you can leave the type system in place, then you could move toward an ML-style type system and see massive improvements within strictly-typed parts of the code as you'd only need type guards and inline caches at the boundaries of the strictly-typed code.
  - crabmusket 2y ago
    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.
  - Dylan16807 2y ago
    > Take that to the extreme and you get WASM, or it's predecessor asm.js Only if your code was pure number crunching. Normal code can't just go through some belt tightening to become WASM/asm.js code. Compiling it down that way is very different from making the control flow more understandable to the optimizer.

porsager 2y ago

Ah yes.. Switch to Typescript and give up all your advances to get a brand new set of crutches.

wiseowise 2y ago
Can you elaborate what you consider "crutches" in this case?
- porsager 2y ago
  They had a custom language giving them full flexibility to achieve making a product in the browser that put them ahead of everyone else, and instead of embracing that, they throw it out to be able to hire of the shelve developers to code in a language that doesn't let them move freely. Typescript is like crutches in the sense that it might support you in not falling, but you only really need them if you're crippled in some way.
  - IshKebab 2y ago
    What are you talking about? Typescript is a fantastic improvement on JavaScript. Skew doesn't look fundamentally better enough that it would be worth the downsides. Lack of IDE support alone is probably enough to cancel out a productivity gains from a better language.
  - whywhywhywhy 2y ago
    > They had a custom language giving them full flexibility to achieve making a product in the browser that put them ahead of everyone else From the article it sounds like it was only used for the prototyping system so a single code base could run in the iOS client and the Web client. I believe the main UI of Figma and what makes it so performant and magical to use is C++ https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
frou_dh 2y ago
They should have brought you in as a consultant so that they would have arrived at the correct decision. Alas, they are now doomed to be wrong forever.

dfgdfg34545456 2y ago

For people like me who know little about Figma, what motivates their use of WebAssembly?

jumploops 2y ago
They started with the goal of photoshop in the browser.
- 8n4vidtmkvmk 2y ago
  Photopea is great and replaced my need for PS. I only do light weed editing though
  - gedy 2y ago
    > light weed editing Sounds like getting stoned and making a meme or something
    - erhaetherth 2y ago
      Haha. Auto-correct. I think I meant light "work" editing maybe??
codeflo 2y ago
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.
- dfgdfg34545456 2y ago
  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"

cranberryturkey 2y ago

[flagged]

fhd2 2y ago
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 compile-to-JS language. For Figma I bet it's worth it, I bet they did their homework. But the amount of tiny projects I've seen that are an unreasonable maintenance burden because of all the packages and toolchains they use, it'd be funny if it wasn't sad. I might still use TypeScript, but for me it's more of a "give me a reason to use it" than a "give me a reason not to use it" kind of situation.
- cranberryturkey 2y ago
  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 inflections because 50% of the time it points to "any" so its utterly useless...and these kids who claim "but you won't get an undefined error!" is just well fix your fucking undefined error when you see it...is my response. WHy do I need to 3x my dev time and hurt my brain in the process so some jackass doesn't have to worry about an undefined variable. I also think the reason MS released TS is because they were unable to find good devs who knew JS. ALl that typeshit in other languages (most enterprise crap like java and .net/c#) could now all be converted to ts devs without having to rehire. TS is for offshore teams imo. That being said I will say on a team of 50+ devs on the same codebase I would vote for typescript becuase you will get a shit load of js spaghetti otherwise from these people who can't be bothered to understand js.
  - 2y ago

bryancoxwell 2y ago

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

vanderZwan 2y ago
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.
- bryancoxwell 2y ago
  Quite a bit faster it looks like: https://jsbench.me/6zlvrupqmj/1 https://jsbench.me/6zlvrupqmj/1
  - debugnik 2y ago
    91.86% slower on my Android phone with Firefox, so it definitely depends on which JS engine.
    - vanderZwan 2y ago
      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.
      - vbezhenar 2y ago

mindfulmark 2y ago

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.

julik 2y ago
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 rarely improves performance (if ever). Because TS has no runtime inference/validation, working with larger libraries or the browser can be a chore because half of your code are type signatures or casts. So - not necessarily a naysayer, but I do believe that TS is oversold and with smaller teams/projects it might be slowing you down as opposed to helping.
- tossandthrow 2y ago
  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 application. I am curious though. can you provide a snippet where types would be a disprovement?
  - julik 2y ago
    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 would be a JS-version of void*). An example of what I call "ceremony" would be interface BlockIndex { [key: string]: UploaderBlock; } const perServerId = {} as BlockIndex; uploaderFiles.map((fe) => fe.blocks.map((b) => b.serverId && (perServerId[b.serverId] = b))); While somewhat useful, this is in internal code which never gets used directly, and there are 4 lines of ceremony for 1 line of actual code.

jd0x 2y ago

[flagged]

croes 2y ago

Off topic: Does anyone know of any sites made with Figma so I can see what the UX is like? As a user I don't care about DX if the resulting UX is bad.

whywhywhywhy 2y ago
It’s just a system for animating the transitions between flat designs and adding scroll areas so you can preview an estimation of a design on mobile and web. Doesn’t even support more advanced prototyping things like inputs and dynamic changes. Not a site builder
wolftickets 2y ago
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.
- croes 2y ago
  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.
  - gryn 2y ago
    that's like asking if a pen or keyboard lead to bloat. depends on who's using them.
    - croes 2y ago
      More like if AI leads to spam or if guns kill people. The latter one is harder if you only have a knife instead of an assault rifle.
      - alpinisme 2y ago

brainzap 2y ago

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.

poiru 2y ago
Skew is open source, but no longer maintained: https://github.com/evanw/skew https://github.com/evanw/skew
sureIy 2y ago
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.

Nishant6572 2y ago

[flagged]

tambourine_man 2y ago

>… TypeScript, the industry standard language for the web This breaks my heart.

salomonk_mur 2y ago
Why? It's the truth.
- airstrike 2y ago
  things can both be true and heartbreaking
- tambourine_man 2y ago
  The frontend language for the web is JavaScript. People who don’t like JavaScript but, for whatever reason, still want to write frontend apps have chosen to invent a new language that transpiles to it. To call that effort a standard is heartbreaking to me.

dimgl 2y ago

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 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. All-in-all, there's plenty of work to be done to make TypeScript better. Especially in monorepos, and especially in making it performant.

kirbyfan64sos 2y ago
Do note that Zod is a bit of an outlier in how slow it can make type checking, e.g. https://dev.to/nicklucas/typescript-runtime-validators-and-dx-a-type-checking-performance-analysis-of-zodsuperstructyuptypebox-5416 https://dev.to/nicklucas/typescript-runtime-validators-and-d... one of the tests hits nearly 300ms, but no other library even touches 100ms.
sod 2y ago
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.
- anamexis 2y ago
  What do you mean by that? I don't think Zod is doing anything special as far as the TS type system goes, although its types are necessarily complex to make its "magic" work. But it's not executing code to infer the types
- dimgl 2y ago
  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.

reasonableklout 2y ago

Hey, I worked on this project! Wrote a bit more on Twitter here: https://twitter.com/andrew_k_chan/status/1786769203912925477 https://twitter.com/andrew_k_chan/status/1786769203912925477 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).

gregors 2y ago

>>> Modern JavaScript features like async/await and a more flexible type system So Skew only had callbacks?

elwell 2y ago
Maybe `Promise`s?

freeqaz 2y ago

This other blog post has some interesting details about how Figma wrote a custom TypeScript DSL + compiler to solve security problems (permissions). https://www.figma.com/blog/how-we-rolled-out-our-own-permissions-dsl-at-figma/ https://www.figma.com/blog/how-we-rolled-out-our-own-permiss...

sghiassy 2y ago

Lesson to learn: don’t build custom languages

dgreensp 2y ago

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. I wonder if some engineers were sad to see Skew go.

reasonableklout 2y ago
It was certainly important for us to make sure developers were happy with the result. That's why our rollout included stuff like a phase where developers continued writing Skew but their changes automatically checked-in generated TS. This way, devs could see what it would look like in PR review and report issues. As for performance and runtime correctness, you're right that there are some gotchas with TS. We caught issues like the array destructuring one with instrumentation and strict monitoring. I was definitely sad to see some features of Skew go. For example, operator overloading and integer types. But the move was ultimately a decision the whole team made, and I agree with them that it was the right one.