[HN Gopher] Ten Years of TypeScript
___________________________________________________________________
Ten Years of TypeScript
Author : kbhomes
Score : 118 points
Date : 2022-10-01 19:02 UTC (3 hours ago)
(HTM) web link (devblogs.microsoft.com)
(TXT) w3m dump (devblogs.microsoft.com)
| repox wrote:
| I've spent the last two years working with TypeScript solely.
| Coming from ~20 years with PHP and using Kotlin and Dart for some
| years as well, I feel that I'm doing something wrong.
|
| I absolutely loathe working with TypeScript. The community is the
| most fragmented I've ever experienced, the silly amount of
| package managers, builders... TypeScript just doesn't fit with
| me.
| int_19h wrote:
| You're describing issues with the underlying JS ecosystem. TS
| builds on that, and while it can paper over the language
| deficiencies, the libraries and frameworks are down to the
| larger community with its culture of constant churn.
| rroot wrote:
| Typescript itself is fine. But yes, if you are using 3rd party
| libraries and frameworks with typescript, you might wonder if
| it's too late to change career and become a monk.
| mirekrusin wrote:
| We need:
|
| - exact object type
|
| - match expression
|
| flow is still better at:
|
| - OO - nominal typing for classes, conforming to liskov
| substitution principles
|
| - first class opaque types
|
| - first class exact object types
|
| - better flow based inference
|
| - comment types - no extra dsl, full access to the language, so
| simple, so powerfull for the times you don't want transpilation
| phase
|
| - [edit] spread types map to spread in runtime
| wwwigham wrote:
| Pattern matching is actually being discussed in tc39 for JS as
| a whole (where TS reps are some of the champions, ofc):
| https://github.com/tc39/proposal-pattern-matching
|
| The specifics of the proposal will likely shift a bit since
| it's still stage 1 (2?).
| nxrabl wrote:
| Flow feels almost like the Betamax to Typescript's VHS - Flow
| is better technically in many ways (in addition to the things
| you mention, I miss being able to spread the properties of one
| type into another, rather than having to inherit from an
| interface), but in practice, in terms of engineering cost, it's
| so much more expensive that it's hard to justify using it.
|
| Flow's team have made it clear [0] that they don't care about
| usage outside internal Facebook projects, so since Facebook
| (from what I hear) uses few external JS dependencies, support
| for library types is terrible - there's no practical way for
| library developers to ship Flow types with their library. The
| third-party flow-typed repository helps somewhat, but
| relatively few libraries are covered there, so in practice
| you'll need to write your own typedefs for most libraries you
| want covered.
|
| When I worked in a Flow codebase, I enjoyed writing Flow types
| for things, but it was only ever fun in a sudoku-puzzle-
| solving, Zachtronics-game kind of way. The tools provided were
| technically enough to express whatever you wanted, but it
| always took some lateral thinking. TS certainly allows for the
| same kind of type astronautery, but as a non-library app
| developer you never have to resort to that; you can always fall
| back to something slightly less strict that covers you from
| most real-world problems without the all-or-nothing strictness
| Flow mandates. In the end I was the last holdout on the team
| advocating for not migrating to TS. The migration went well and
| the team was more productive for it.
|
| It's fun to think about an alternate universe where Facebook
| gave Flow the investment and community support it deserved, and
| today it's part of a beautiful React/Flux/Jest/Flow/Reason
| ecosystem (eventually leading to a complete takeover of the
| browser frontend by Ocaml). For real work, though, Typescript
| gets the job done.
|
| [0] https://medium.com/flow-type/clarity-on-flows-direction-
| and-...
| mirekrusin wrote:
| They messed up with contributions to flow-typed where they
| were not accepting partially done typings, ie. not having
| some kind of incubator. People would push stuff, others would
| fix it. In community run projects you need to focus on low
| friction, not perfectionism. That killed typing coverage
| while ts was growing like crazy. Typing coverage worked like
| magnet for ts vs flow decisions. So it killed flow in effect.
| ImprobableTruth wrote:
| >I miss being able to spread the properties of one type into
| another, rather than having to inherit from an interface)
|
| What would that achieve that intersection types don't
| already?
| Kejistan wrote:
| Spreads are ordered, and try to match the semantics of
| object spreads at runtime. Intersection types don't do
| that, they express that the type is both things at the same
| time. It is most obvious when dealing with types that have
| overlapping properties: [typescript with intersections](htt
| ps://www.typescriptlang.org/play?#code/C4TwDgpgBAglC8UDeA..
| .) [flow with spreads](https://flow.org/try/#0C4TwDgpgBAglC
| 8UDeAfAUFTUBmB7XAXFAHYCu...).
| mirekrusin wrote:
| They map onto same type as runtime spread, ie. order
| matters last one overwrites.
| qudat wrote:
| You can't type generators properly a la redux-saga
| krosaen wrote:
| I don't understand the benefit of nominal typing when
| structural typing is available?
| mirekrusin wrote:
| You can't use `instanceof` ie. for your error types, actually
| every time you use class that extends something - it'll not
| be typed correctly. Basically nothing OO/class/inheritance
| related is typed correctly. Flow does it correctly.
| nine_k wrote:
| The idea is that two types with the same structure aren't
| always the same thing.
|
| This is easily solved by a tagged type in TS [1], though a
| bit of syntactic sugar over it would be nice.
|
| [1]: https://kubyshkin.name/posts/newtype-in-typescript/
| gherkinnn wrote:
| In practice I'm very happy with structural types. It
| provides all the safety I could wish for and slots in well
| with the underlying language and broader ecosystem.
|
| Though I do miss an easy way to create something like a
| type Email of string, as it conforms to a set of rules. But
| that's a small price to pay.
| mirekrusin wrote:
| Flow has structural typing on types and nominal on
| classes with correct inheritance semantics, which simply
| makes sense.
|
| For making Email type distinct from string, you want
| opaque type (first class in flow) which you can emulate
| as tagged type in ts.
| mirekrusin wrote:
| Tagging doesn't solve inheritance problems - object
| oriented inheritance needs to follow liskov substitution
| principles, support variance correctly.
|
| Tagging is good for making sum types out of union types,
| but that's not enough for class inheritance.
|
| Flow does it better by having first class opaque type
| aliases btw (and having nominal types with oo inheritance
| support on classes of course).
| cehrlich wrote:
| TypeScript is the best thing to happen to web dev, and it keeps
| getting better. My only gripe is that sometimes in a codebase
| that is heavy on inferred types I need to restart the TS server
| occasionally. Nonetheless, unless there is a specific requirement
| that TS isn't the right choice for, it's the language I reach to
| for everything.
| nesarkvechnep wrote:
| Do you have interests beyond the JS world? TypeScript being the
| best thing to happen to web dev sounds a bit hyperbolic.
| gavinray wrote:
| TypeScript has my second favorite type system, right behind Scala
| 3
|
| To me, that's saying something.
| gherkinnn wrote:
| The way TS stuck such an expressive type system in top of such a
| dynamic and somewhat clumsy language is nothing short of
| witchcraft. And as a dev it all feels so effortless.
| bricss wrote:
| IMO, it feels more like witchcraft lang for clumsy developers
| umvi wrote:
| I like the idea of typescript.
|
| I tried to port a vanilla js browser game to typescript and I
| found it introduced a lot of complexity to the project. It sucked
| me into the npm ecosystem and forced me to rewrite every file to
| use js modules import/export syntax and a bundler like webpack to
| resolve all the modules business for browsers when none of those
| were needed before.
|
| Of course I could set TS modules to none but then I lose access
| to typing of any third party libraries I'm using like PixiJS.
|
| And my CI pipelines are like 10x slower now because I need npm to
| install and compile and bundle stuff which is really slow
| compared to my previous CI pipeline which simply concatenated the
| js files together with `cat`.
|
| Does this sound right or an I missing something? What I want:
|
| To be able to just type annotate my existing JS without needing
| modules, _but also_ have TS be able to pull in type information
| of 3rd party libraries by pointing it to the appropriate .d.ts
| file. I suppose that 's having your cake and eating it too in
| this case.
| sibit wrote:
| TypeScript let's you import a libraries types using:
|
| import type X from "package"
|
| So assuming you are pulling in PixiJS with a <script> tag you
| could npm install the PixiJS package just for the types. It
| could look like this:
|
| import type * as IPixi from "pixi.js"
|
| declare const PIXI: IPixi
|
| Then when you compile all the "import type" statements will be
| removed.
| gherkinnn wrote:
| You can use JSDoc (or a derivative thereof) in plain JS and get
| hints in the editor. Never used it myself though.
|
| Anyway, ES modules have good browser support these days:
|
| https://caniuse.com/es6-module-dynamic-import
| dynamite-ready wrote:
| This is closer to my opinion.
|
| I write a fair amount of Typescript, but it's frustrating to
| see it used so ubiquitously, when in a lot of cases it's just
| not necessary.
|
| A strongly typed language definitely has a place in web UI
| development though. But my hope is to see it replaced by a WASM
| based language, or better still, a choice of WASM based
| languages.
| ht85 wrote:
| If I understand correctly, before moving to TS / npm, you would
| concatenate your library files and your own code, and in your
| own code reference libraries using some kind of global variable
| a la `$.` for jquery?
|
| If that's the case, you could add the libraries .d.ts to your
| project and augment the global.Window interface with types
| pulled from those definitions. You would then be able to call
| `window.something` and have the correct type and should work
| after cat'ing everything together.
|
| Which bundler are you using? If you don't need any of the
| advanced webpack / rollup stuff, have you tried a fast one like
| esbuild?
| stephen wrote:
| Great post/looking back at the core decisions/bets that worked
| out really well (from the post):
|
| * "Impose no runtime overhead on emitted programs." * "Align with
| current and future ECMAScript proposals." * "Preserve runtime
| behavior of all JavaScript code." * "Avoid adding expression-
| level syntax." * "Use a consistent, fully erasable, structural
| type system."
|
| I also really liked the callout of their approach to "innovating
| in the type system around conventions and patterns found 'in the
| wild' of the JavaScript ecosystem."
|
| This "you can still write the JS-style APIs you want, just
| safely" is a stark contrast to the Dart/ActionScript/others
| options mentioned in the HN thread, which said "you have to give
| up the JS-style APIs you have, and instead write 'basically
| Java'".
|
| It's also amazing how TS 1.x itself was "basically Java" (in
| terms of a type system, albeit except being structural), but so
| many of the TS 2.x type systems innovations (mapped types,
| conditional types, etc) look as if they were designed in the
| language from day 1.
|
| One other point, the post calls out they didn't add extra syntax
| to JS, only types; in this regard, I think TypeScript frankly got
| lucky by how much JavaScript itself has evolved in the last 10
| years. Like if JS had been going through a "10 years of
| sterility" period like Java did from ~2005-2015, then TS itself
| would have been greatly hindered and probably would have had to
| jump to syntax-level changes, like the Scalas and Koltins and
| other Java.nexts had to do.
|
| So, kudos to JS itself for also evolving extremely well from its
| ~2010 everything-is-a-callback early days, and letting TS stand
| on its shoulders.
| Sankozi wrote:
| In most programming languages JS style APIs (i.e. give me
| anything and I will try to interpret it somehow in an
| undocumented or poorly documented way) are antipatterns. TS is
| often bringing sanity to libraries that switch from JS to TS.
|
| I think TS team is doing really great job. I would not call it
| standing on the shoulders of predecessor, more like trying to
| build something stable on the swamp. JS definitely does not
| have a positive influence on TS.
|
| TS is not a great programming language, but it is really great
| accomplishment considering that it supports and extends JS in a
| such good way.
| Yahivin wrote:
| This seems like a great time to announce my successor to
| CoffeeScript: Civet, a language that transpiles to TypeScript.
|
| https://github.com/DanielXMoore/Civet
| msoad wrote:
| TBH I have 99 problems but the syntax is not one
| Yahivin wrote:
| Civet also fixes: `import x from "./x.ts"` and unifies
| `readonly` and `const`.
|
| I'll get back to you when I fix the other 97 but until then
| there's no accounting for taste.
| bilalq wrote:
| Oh, I like this. A pure syntactic sugar over a language that
| otherwise preserves semantics is neat. Nice work on documenting
| what was kept/changed/removed too. Really easy to see at a
| glance what the project is all about.
|
| Love that there's an online playground, LSP, and VSCode
| extension along with it.
| Yahivin wrote:
| Thanks! It's still a work in progress (especially the LSP)
| but it is usable in its current state and is getting better
| all the time.
| smcleod wrote:
| Typescript as a language isn't too bad but the ecosystem is an
| absolute dumpster fire. NPM is terribly fragmented, costs a
| fortune in effort to maintain dependencies, security updates
| etc... Every Typescript/JS project I work on is full of a
| dangerous amount of third party dependencies - it can be hundreds
| if not thousands in a single repo - many of them fragile in their
| own special way. Language packages management is hard - but it
| seems especially hard with TS/JS.
| rlp wrote:
| I've always been a big proponent of TypeScript, but does anyone
| else feel like the type system has gotten a bit _too_ flexible? I
| recently had to fix some errors when upgrading packages on an old
| project, and it was not at all clear what was wrong by just
| reading the compiler output. For some errors, there were like
| 5-10 lines of confusing info /context, it felt like trying to
| understand the errors reported in template-heavy C++.
| ht85 wrote:
| As a web-focused software engineer, I can safely say TypeScript
| is the best thing that happened to my work in the last decade.
|
| Aside from the known direct benefits of safety and self-
| documentation, I've found over time that having a pleasant,
| smooth coding experience and producing elegant code required me
| to think differently. I work on a project with very complicated
| and overloaded business logic, but nowadays my code looks very...
| "algebraic"? state machines within state machines, exhaustive
| switches everywhere...
|
| Maintaining and modifying such code has been a joy compared to
| the old ways. Most of the work is just adding a new member to
| some union or an attribute to a type, following the red trail
| fixing errors and voila.
| dccoolgai wrote:
| The real genius of it is that it's really not a "type" system
| at all: it's a contract system. The nearest thing like it was
| Eiffel. The new "satisfies" feature in 4.9 makes this even more
| clear. Honestly there's so much space to cover here, I think
| it's just going to keep getting better and better.
| dalmo3 wrote:
| Wow! `satisfies` solves a problem I was working on
| _yesterday_. Remarkably, it 's not the first time a new TS
| feature immediately makes way into my code.
| dccoolgai wrote:
| It's such a powerful complement to the "no rules" JS when
| you layer it on top. You really get to have your cake and
| eat it, too. I feel like there's another huge step to take
| in "layering" invariant checking on top of TS for QA/test
| systems... Imagine like "in all 500 of my tests, make sure
| this variable is an integer greater than 10 at all times no
| matter what". I'm waiting for this to show up
| michaelwww wrote:
| Debate (almost 10 years ago) TypeScript vs. Dart about the best
| way to improve JavaScript
|
| Anders Hejlsberg (Microsoft) and Lars Bak (Google): TypeScript,
| JavaScript, and Dart
|
| https://www.youtube.com/watch?v=5AqbCQuK0gM
| blackoil wrote:
| Is there any effort ongoing to add optional type declaration to
| Javascript? Runtime type info. would make lot of use cases
| possible.
| mr_johnson22 wrote:
| Honest question: why did TypeScript succeed while ActionScript
| 3.0, another ECMAScript-superset language with typing and OOP
| (and predates TS by a few years), is all but a distant memory? Is
| it more than just Adobe being a terrible steward of its tech?
|
| With that said, TS is definitely a blessing; I recently had the
| privilege of migrating to it after having written a hobby project
| in plain JS, and the difference in usability between the two is
| night and day. But I can't help but feel that I've seen this all
| before years ago in AS3.
| throw_m239339 wrote:
| > Honest question: why did TypeScript succeed while
| ActionScript 3.0, another ECMAScript-superset language with
| typing and OOP (and predates TS by a few years), is all but a
| distant memory? Is it more than just Adobe being a terrible
| steward of its tech?
|
| Microsoft and Yahoo voted against ES4 adoption at the ECMA
| committee, cause Microsoft had, what was it called again?
| Silverlight, Their flash alternative to promote so they weren't
| interested in improving Javascript in anyway. Due to Microsoft
| stupidity, carelessness for standards, the web lost a decade of
| improvements.
|
| Adding insult to injury in that absurd era, Microsoft had its
| own AS3 implementation called JScript.net before C# became more
| popular.
|
| I'm surprised nobody ever wrote a book about this saga, it's
| completely absurd and petty but there are plenty of stories to
| tell.
| blackoil wrote:
| Wasn't fate of ActionScript strongly tied to Flash? As much as
| some open source community try, they can't beat the full force
| of the investment done and talent assembled by Microsoft.
| jmull wrote:
| I liked AS3 quite a bit, but it was limited to Adobe products.
| I don't think it was ever given a chance to make an impact
| beyond Flash and Air.
| throw_m239339 wrote:
| Well no it wasn't limited to Flash, since it was supposed to
| be ES4. This is why ES4 doesn't exist as a standard,
| Javascript went from ES3 to ES5.
| evilduck wrote:
| As a former Flash/Air/Flex dev way back in the day I agree, AS3
| was a great language that JavaScript still hasn't fully caught
| up with in some ways but it was only really viable to author
| ActionScript within Adobe's endorsed editors and their Eclipse
| fork abomination. Being confined to the Flash runtime also made
| life difficult as a general purpose programming language. It
| was a rough development experience and no amount of language
| superiority would ever fix that.
| quickthrower2 wrote:
| Maybe it was too early? Compiling stuff to JS came popular
| after flash died.
| Xeoncross wrote:
| Also see https://rescript-lang.org/ if you're considering
| learning Typescript
|
| Looking forward to more great ideas in the future of ways to
| 'fix' Javascript.
| CharlesW wrote:
| > _Also seehttps://rescript-lang.org/ if you're considering
| learning Typescript_
|
| I'd never heard of this, so here are a couple things I think
| are true after poking around a bit:
|
| * TypeScript is a strict superset of JavaScript that compiles
| to JavaScript, while ReScript is unique language that compiles
| to JavaScript.
|
| * ReScript is apparently a re-brand of "Reason(ML)", which is
| apparently derived from OCaml.
| argentinian wrote:
| Does Facebook use it abundantly, or only on a few experimental
| projects?
| azangru wrote:
| > "Align with current and future ECMAScript proposals."
|
| But they admitted namespaces, enums, and interfaces into the
| language (the latter becoming more and more confusing as type
| aliases got more expressive),
|
| > "Avoid adding expression-level syntax."
|
| Is "as", "is", or "satisfies" expression-level?
|
| > "Use a consistent, fully erasable, structural type system."
|
| But the enums!
| rektide wrote:
| Generally a huge positive. With tools like swc, there's really
| fast compilation & typechecking now. With --watch, the DX is
| pretty good but yeah sometes has to be restarted anyways.
|
| A couple not so greats:
|
| Typescript has added a lot fo confusion & chaos to the ESM
| transition. A lot of typescript code is in ESM style, byt if you
| pull the package, it outputs cjs or what not. TypeScript 4.8-
| very recent- is the first to actually have a semi-viable Node.js
| + ESM story going; being a respectably modern package hasnt even
| really been possible with typescript until just recently. Not
| fully typescript's issue, but writing a package.json that fully
| helps consumers is quite difficult, and there's a lot more to
| grol.woth typescript in the mix. There's such a long long tail of
| typescript packages that are going to be the long long hold up
| for getting to ESM cleanly. It's not that hard to change, but
| awareness is just low, and friction is high while we are still so
| stuck-in-the-middle. Typescript makes writing code easy, but
| outputting a good respectable usable library has been impossible
| & is still not easy. Woe.
|
| I really hope EcmaScript does get type annotations, which could
| eliminate so much of the need to compile & let typed code just
| run untyped, elide so many of these difficult transpilation
| challenges.
|
| Another major issue for typescript is that it is stil so compile-
| time focused, that type metadata isnt kept intact. It's wild to
| have such a vast typing system, but to just throw it all out at
| compile time. To be fair, object metadata in js has been tied to
| annotations, which has been long long delayed, a huge struggle
| for the language, so there's not clear targets for how to output
| type information, but there have been some goes, some works to
| add runtime type information to typescript & there's so little
| follow up, so little engagement. All TypeScript feels like such a
| sharply more limited less useful less ambitious project than what
| it should be doing, than what a real language+runtime would be.
| It feels like typescript lives in the shadow of a much more clear
| & visible greatness.
| david2ndaccount wrote:
| I thought swc still doesn't do type checking and just strips
| the type annotations?
| rektide wrote:
| Hrrmmm. I've been using the newer Jest testing library
| releases & they are supposedly powered by SWC. I definitely
| see some typechecking errors, & assumed this was also swc.
| But I see little evident in the swc project they've made
| headway here.
|
| Im not sure what Im experiencing in jest. It's definitely not
| the _same_ level of typechecking. But there 's definitely
| something there & it's definitely much faster start time.
| Thanks for writing; Im curious too.
| bluepnume wrote:
| I was a long time Flow hold-out, switched to TypeScript a year
| ago and never looked back.
|
| There are a few things I miss, and a few things that Flow did do
| better; TS is obviously not perfect. But it's a real joy to use.
|
| As for people writing JS in 2022 without any kind of static
| typing: I fear for you.
| dynamite-ready wrote:
| Given the number of codebases littered with 'any', and the fact
| that TS is known to produce app bundles that perform slower than
| handwritten JS code, I'm in two minds about celebrating those ten
| years... But it is strange to think it's been ten years.
| jmull wrote:
| > TS is known to produce app bundles that perform slower than
| handwritten JS code
|
| I'm curious about this, and runs counter to my understanding of
| typescript. Do you have any sources on this?
|
| I'm googling a bit but not really finding anything.
| laundermaf wrote:
| > TS is known to produce app bundles that perform slower than
| handwritten JS code
|
| Wrong. TS doesn't bundle files. TS doesn't produce code unless
| you target an earlier ES version than what you write, in which
| case there's no way around it: native for-of loops and
| await/async will always be faster regardless of what you use to
| transpile it.
|
| I think you're confusing the tool with something else.
| mirekrusin wrote:
| Ts does produce code, ie. for enums, modules/namespaces.
| ksbrooksjr wrote:
| Const enums get completely erased by the compiler, and
| modules are a native js feature.
|
| Non-const enums and namespaces are probably the only
| aspects of typescript that actually have any significance
| at runtime, but they get compiled into simple objects. The
| compiler output is very close to what you'd write by hand.
| Take a look at this compiler output here [1].
|
| Unless you're constantly recreating enums and namespaces
| inside of a loop (which you'd never do in real life code),
| I can't imagine there'd be any performance penalty.
|
| [1] https://www.typescriptlang.org/play?target=99#code/HYQw
| tgpgz...
| mirekrusin wrote:
| So ts does produce code.
| ksbrooksjr wrote:
| It can (depending on which features you're using), but
| the comment that started this thread claimed that the
| produced code was much slower than handwritten js. I was
| just pointing out that the examples you gave (enums and
| namespaces), don't change the performance of your code.
| mirekrusin wrote:
| Yes, that part was nonsense. Typescript maps one to one
| for supported features. However there was comment there
| that ts doesn't generate code by itself unless
| downgrading to historic versions, which is not true.
|
| It would be nice if not only type system but all ts would
| be erasable, ie. so you can write ts to js transpiler by
| replacing ts code by spaces and the remaining part would
| be valid, runnable js.
|
| With enums, modules/namespaces it's violated. And if it's
| violated already then they should just go ahead and
| support things like match expressions and move statements
| to expressions coffeescript style. Because you have
| insight into types, performance would not suffer - you'd
| pay overhead of expression-instead-of-statement if you'd
| actually mean to use it, which is great tradeoff.
| ksbrooksjr wrote:
| I agree that the typescript team should consider using
| the compiler to extend javascript rather than just
| supplement it with types. Like you said, there are
| technically parts of typescript that don't have a direct
| corollary in js (enums/namespaces), so why not take it a
| step further and add some of the features that js is
| missing? The only example where they've really taken that
| next step is with experimental decorators.
|
| I think in general the js/ts community is starting to
| realize that if we're going to have all of these build
| tools, we might as well use them to do more than just
| format, transpile, and bundle. Svelte has sort of pushed
| this idea with its abuse of the js label feature (it can
| detect when a variable is reassigned if you prefix it
| with the dollar sign label, which is technically not
| possible with js, even with proxies). There's also React
| Forget, which is promising to completely rewrite
| components at compile-time to avoid all of the gotchas
| that hooks have (and improve performance) [1].
|
| In terms of making all of ts erasable, you can
| technically just write all your type definitions using
| js-doc comments, in which case the compiler can just be
| run with the --noEmit flag, and then the code is fully
| valid js without any modifications.
|
| [1] https://www.youtube.com/watch?v=lGEMwh32soc
| Gare wrote:
| AFAIK, enums and namespaces are considered past mistakes
| that won't be repeated again.
| mumphster wrote:
| Do you have examples of slower code generated by typescript? TS
| is a superset of JS so it changing anything that has a large
| performance impact seems odd, but maybe I'm missing something
| here. The types aren't even available at runtime, what's the
| biggest slow down you've seen?
| redox99 wrote:
| Most likely polyfills because he's targeting some old ES
| version.
| dynamite-ready wrote:
| https://thenewstack.io/which-programming-languages-use-
| the-l...
| david2ndaccount wrote:
| The number one problem with typescript is how slow it is.
| Compiling a 14k line project takes 5s. This is absurdly slow.
| Tajnymag wrote:
| Typescript by itself is just the language. You could try a
| different typescript compiler like esbuild for example.
| david2ndaccount wrote:
| > However, esbuild does not do any type checking so you will
| still need to run tsc -noEmit in parallel with esbuild to
| check types.
| Tajnymag wrote:
| You're right, I didn't count with that
| wwwigham wrote:
| When you can write a busy beaver machine in the type system,
| LOC ceases to be a good indicator or how long something
| _should_ take to typecheck, imo. If you 're frustrated with
| your build, you should use the trace tools on the TS wiki[1] to
| track down what types are slow to check, so you can attribute
| the slowness to the appropriate library authors/yourself and
| decide for yourself if the speed/correctness tradeoff they've
| made is right for you.
|
| [1]https://github.com/microsoft/TypeScript-
| wiki/blob/main/Perfo...
| david2ndaccount wrote:
| My code is straightforward and doesn't do advanced type
| operations.
| scrollaway wrote:
| Check your libraries. Some are really trash and mess with
| Typescript's speed. Material UI comes to mind.
___________________________________________________________________
(page generated 2022-10-01 23:00 UTC)