11 ms·

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 h

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.

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.