Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Figma’s Journey to TypeScript

figma.com

Post reply on HN
Print view View original

81–90 of 257 posts

Re: Figma’s Journey to TypeScript

#81

Post by _dain_ »

sgt wrote: post #76
mindfulmark wrote: post #60

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

I'm not against TypeScript, but I don't really see the massive advantage. I rarely see problems that are due to typing, and the downside is usually limited as I keep my JS on the frontend, not the backend. Regular JS/ES6 just flows better.

>I rarely see problems that are due to typing

This is a fallacy similar to the Blub paradox: if your language has a weak[1] type system, then it isn't capable of recognizing many problems as "type error". But stronger type systems can express stronger invariants. So something that isn't a type error in one language will be a type error in another. This changes how the programmer conceives of problems.

Example: missing a case in a switch statement isn't a "type error" in C or Java, but it is a "type error" in languages like Rust or ML, because they have sum types with exhaustiveness checking. Other examples: array bounds checks can be eliminated with dependent types; lifecycle bugs like use-after-free and double-free can be eliminated with substructural types.

[1] "weak" in an informal sense of "not very expressive"

Re: Figma’s Journey to TypeScript

#82

Post by hajile »

dtech wrote: post #17
crabmusket wrote: post #9

Earlier quoted context omitted.

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.

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.

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.

Re: Figma’s Journey to TypeScript

#83

Post by hparadiz »

julik wrote: post #63
resonious wrote: post #2

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

It is actually a fairly indicative story. At the start there is a brilliant individual (Evan) who sets up an entire toolchain + core of the product. They then move on (or get pushed out, or get bored), and with the team (and the product) now being much bigger, things get replatformed to a more familiar, widely used stack. The success of these steps heavily depends on how robust the eng culture is at the organisation.…

It's ironic. For the past 5 years I've been writing type strict PHP. People love to shit on PHP yet I found that when I started using strict types my code quality improved, amount of lines needed to produce a result decreased, and necessary unit tests to produce the same result also decreased.

Then a few months ago I decided to write a TS project from scratch. For the record I have 18 years of JavaScript experience. 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.

Re: Figma’s Journey to TypeScript

#84

Post by mikeocool »

arnorhs wrote: post #51
makeitdouble wrote: post #7

Earlier quoted context omitted.

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…

That is an impressive misrepresentation of history. PHP and its community were dying by the time FB used it. People here on HN kept talking php down. In 2014 FB made their own flavour of php with a bunch of perf features, called hack. Eventually a lot of the perf features hack made its way into php. FB is still on its own flavour. Php community is still dying.

Perhaps I’m misreading your comment, but PHP was definitely not dying in 2004. Nor was anyone talking it down on HN, as HN didn’t exist.

Re: Figma’s Journey to TypeScript

#86

Post by hparadiz »

59nadir wrote: post #53
arnorhs wrote: post #51

Earlier quoted context omitted.

That is an impressive misrepresentation of history. PHP and its community were dying by the time FB used it. People here on HN kept talking php down. In 2014 FB made their own flavour of php with a bunch of perf features, called hack. Eventually a lot of the perf features hack made its way into php. FB is still on its own flavour. Php community is still dying.

Meh, as far as I can see PHP has a ton of very active development around web services and frameworks, which is its core value proposition. PHP as a language should probably slow down in general but the people who use it don't seem to be really dying out or slowing down as much as the bubble leads us to believe.

People hate php for no reason. They talk about performance or whatever while building rest crud apps. Literally any language can handle that easily and your bottleneck is usually the database. I've scaled startups on PHP to hundreds of thousands of users running on a few cheap ec2 instances. But no one wants to build new php projects instead focusing on Go, Python, or Ruby. I honestly don't get it. PHP devs earn less. The syntax is super easy to pick up. Don't you want cheaper labor?

I've started to learn the ecosystems of the other languages. It's all the same shit. Really.

Re: Figma’s Journey to TypeScript

#89

Post by tomduncalf »

_dain_ wrote: post #81
sgt wrote: post #76

Earlier quoted context omitted.

I'm not against TypeScript, but I don't really see the massive advantage. I rarely see problems that are due to typing, and the downside is usually limited as I keep my JS on the frontend, not the backend. Regular JS/ES6 just flows better.

>I rarely see problems that are due to typing This is a fallacy similar to the Blub paradox: if your language has a weak[1] type system, then it isn't capable of recognizing many problems as "type error". But stronger type systems can express stronger invariants. So something that isn't a type error in one language will be a type error in another. This changes how the programmer conceives of problems. Example: missin…

Yeah or even simple typos, or mixing up the order of arguments, are things that are hard to catch in regular JS (except at runtime) but trivial in TS.

I suspect a lot of people might have had bad experiences with codebases which overuse complex types or trying to type things like Redux which is messy. When I use TS for personal stuff I’ll typically be a bit loose about things like any in places where I don’t care (for now) and I feel it doesn’t add much overhead, but I have been using it for a long time so it’s become second nature.

Re: Figma’s Journey to TypeScript

#90

Post by cranberryturkey »

fhd2 wrote: post #33
cranberryturkey wrote: post #30

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…

They say TS is optional but I've ran into issues using 3rd party libraries that require it when calling their methods.

I just never really used typing. I started with perl and then did php and ruby for awhile before focusing on javascript. So I never knew what I was missing.

I'm just much much faster in vanilla js than I am with typesh

Post reply on HN