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

221–230 of 257 posts

Re: Figma’s Journey to TypeScript

#221

Post by tossandthrow »

eddd-ddde wrote: post #176
tossandthrow wrote: post #67

Earlier quoted context omitted.

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…

Duck typing can lead to a false sense of security when you /think/ you have Foo when in reality you have Bar with the same shape. Also Typescript sucks at keeping track of type changes in a single scope. While in Rust I can assign string to foo and then update it with int, I can't in Typescript. This leads to worse types or worse code for the same operation. Combined with typescript's lack of statements as values, co…

I am curious on any example where changing type in scope is more performant or more readable.

it is not really an argument against typescript that Javascript is so bad that you need to spent time tracking your changes.

Re: Figma’s Journey to TypeScript

#222

Post by Dylan16807 »

nolist_policy wrote: post #187
hparadiz wrote: post #83

Earlier quoted context omitted.

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

You don't have to transpile anything, you can just put your TS types in JavaScript comments. Or am I missing something?

You can, but it's ugly and time-consuming. And makes it harder to parse what's actually a comment.

Re: Figma’s Journey to TypeScript

#223

Post by erhaetherth »

gedy wrote: post #159
8n4vidtmkvmk wrote: post #21

Earlier quoted context omitted.

Photopea is great and replaced my need for PS. I only do light weed editing though

> light weed editing Sounds like getting stoned and making a meme or something

Haha. Auto-correct. I think I meant light "work" editing maybe??

Re: Figma’s Journey to TypeScript

#224

Post by Dylan16807 »

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.

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

Re: Figma’s Journey to TypeScript

#225

Post by 0xblinq »

CuriouslyC wrote: post #106
hparadiz wrote: post #83

Earlier quoted context omitted.

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

This is the reason that JS frameworks are a thing. Next is buggy and overbuilt, but Remix is pretty much plug and play, I strongly recommend checking it out.

+1

I’ve been using remix for the last 6 months and I’m super happy with it.

Re: Figma’s Journey to TypeScript

#226

Post by 0xblinq »

biinjo wrote: post #189
CuriouslyC wrote: post #106

Earlier quoted context omitted.

This is the reason that JS frameworks are a thing. Next is buggy and overbuilt, but Remix is pretty much plug and play, I strongly recommend checking it out.

Im surprised that Remix doesn’t get much love in the community. Or is it because Vercel and their influencer team is yelling so loud about Next that we can’t hear the Remix people?

It’s going to take some time but it’s going to take over.

Next really fucked up with the app router, and people are realizing everything is just a trap to get more customers on vercel.

Re: Figma’s Journey to TypeScript

#227

Post by dilyevsky »

vbezhenar wrote: post #215
summerlight wrote: post #211

Earlier quoted context omitted.

k8s is not allowed to use in the most projects utilizing the internal stack, at least yet. In fact, it hasn't reached to the feature parity level necessary to replace any big projects running on Borg.

If other companies can run big projects on Kubernetes, so can Google.

Im sorry but this statement is pretty funny to anyone who has seen google’s internal infra. Where are those companies who run like 10-20k machine kubernetes clusters?

Re: Figma’s Journey to TypeScript

#228

Post by tacker2000 »

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.

What nonsense! Just because you dont use it or (as is apparent) dont know anything about it doesnt mean it’s “dying”.

Re: Figma’s Journey to TypeScript

#229

Post by mirekrusin »

devbent wrote: post #206
mirekrusin wrote: post #39

Earlier quoted context omitted.

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.

> existential operator, JavaScript has had this for a bit now and it is really nice. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Existential operator can be used as optional chaining operator but also in trailing position ie:

    if window?
      env = 'browser'
      ...
is equivalent to:

    if (typeof window !== "undefined" && window !== null) {
      env = 'browser'
      ...
    }
But yes, nullish coalescing and optional chaining that came from existential operator are good.

Re: Figma’s Journey to TypeScript

#230

Post by mirekrusin »

mistercow wrote: post #184
mirekrusin wrote: post #39

Earlier quoted context omitted.

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.

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

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.

Post reply on HN