[HN Gopher] TypeScript is now officially 10 years old
___________________________________________________________________
TypeScript is now officially 10 years old
Author : bubblehack3r
Score : 187 points
Date : 2022-10-09 08:17 UTC (14 hours ago)
(HTM) web link (coderoasis.com)
(TXT) w3m dump (coderoasis.com)
| coffeeblack wrote:
| So what is the best book (under 250 pages!) to learn TS?
| cehrlich wrote:
| If you're comfortable with JS, you don't need a book to learn
| TS.
|
| There are two main resources I would recommend:
|
| - for those who prefer written content, the TypeScript Handbook
| [1]
|
| - for those who prefer video content, the first couple videos
| of Jack Herrington's No BS TS series [2]
|
| Other than that, just start using it. My main advice would be
| that your TS code should look as much like JS code as possible,
| ie don't explicitly type everything, just rely on inference
| where possible. Basic generics can be useful occasionally, but
| most of the "Type Challenge" type stuff is only really useful
| to library developers.
|
| [1] https://www.typescriptlang.org/docs/handbook/intro.html
|
| [2]
| https://www.youtube.com/watch?v=LKVHFHJsiO0&list=PLNqp92_EXZ...
| b0afc375b5 wrote:
| Can this be considered a book?
| https://basarat.gitbook.io/typescript/
|
| Not sure if it's <250 pages though.
| Jcampuzano2 wrote:
| I wouldn't waste time buying/using a book to learn TS. If you
| have experience in any statically typed language you should be
| able to pick up the basics just by a quick peruse of the TS
| docs.
|
| And then even if you don't I'd still say reading the docs and
| just browsing existing code assuming you already know JS would
| get you all the way there.
| mattlondon wrote:
| I was unsure of Typescript at first, but it has become an
| absolute joy and absolute pleasure to develop in.
|
| I was reluctant to introduce a build step (having got used to the
| simple refresh cycle of a browser plus vanilla javascript) but I
| am pleased to say that this is a bit of a non-issue now with
| modern tooling like esbuild et al.
|
| I still avoid NPM like the absolute plague, but the good news is
| that tooling like Deno have made typescript first server-side
| development in the ECMAScript world a total joy.
|
| I've said it before - it's like floating through the air. So
| serene, so expressive. A true joy.
| throwamon wrote:
| Wait until you try a language that was supposed to have a
| decent type system from the beginning!
| justsomeuser wrote:
| I like type systems as you can design with types and check
| things tie together before even running the code. This gives
| you very fast iteration cycles compared to CMD-R refreshing
| the browser/code.
|
| Some issues with TS are:
|
| - There is no hard guarantee at runtime as everything is
| partially/optionally typed (including your deps).
|
| - The types are not used to produce faster code at runtime
| (like in a compiled language).
|
| It is almost like TS leaves half of the benefits of type
| checking on the table, obviously by design by being a JS
| superset.
| eyelidlessness wrote:
| > There is no hard guarantee at runtime
|
| You can get very close if you place fine-grained, well
| tested, type guards at IO boundaries, wrap poorly typed or
| overly dynamic dependencies, and have good discipline about
| internal boundaries. It's a lot of work up front in a
| greenfield project, but it really pays off.
|
| > The types are not used to produce faster code at runtime
|
| Not directly, but in my experience good up front interface
| design tends to produce either immediately optimal JS (eg
| it tends to be monomorphic) or makes optimization much
| easier (as it makes any refactoring easier).
|
| Edit:
|
| > I like type systems as you can design with types and
| check things tie together before even running the code.
| This gives you very fast iteration cycles compared to CMD-R
| refreshing the browser/code.
|
| I'd be remiss not to emphasize this! And not just skipping
| the reload cycle, it lets you skip a whole lot of test runs
| too. Type error in editor? Yep, those tests are gonna fail
| too.
| phi-y wrote:
| >> - There is no hard guarantee at runtime as everything is
| partially/optionally typed (including your deps).
|
| Most typed languages don't have hard guarantees at runtime.
| With java, using reflection you can do all kinds of weird
| things at runtime. C++ has fewer guarantees because there
| is no VM and can't even introspect objects to see their
| real type. Dependencies are a real issue with TS, but many
| libraries are written in typescript and the type files are
| really robust.
|
| >> The types are not used to produce faster code at runtime
| (like in a compiled language).
|
| The V8 intepreter will actually do this at runtime. Usually
| it takes less than a second for v8 to optimize the
| javascript, and it will recognize that many functions and
| objects use the same interface and optimize appropriately.
| If you think about it the types only help so much because
| once you have the code graph, it becomes really easy to
| find the type and optimize the memory layout.
| willtemperley wrote:
| Validating JSON against TS types avoids most runtime type
| errors, I've found.
| dmitriid wrote:
| The thing is, TS has a very _pragmatic_ type system [1], with
| multiple opt-outs or workarounds if necessary.
|
| "Decent type systems" are usually in your way (especially if
| you want to quickly prototype something), and despite
| "decency" have abysmal tools (like "hey I've changed this
| function signature, update all call sites etc.)
|
| [1] It's getting more and more complex, but even if you write
| something like this, it's still aiming to help you:
| Partial<Record<typeof keyof SomeEnum, boolean>>>
| sgt wrote:
| Can be said about regular modern JS as well. Whether your
| project has types or not is not alone going to determine the
| success of the project.
| zarzavat wrote:
| I personally can't agree with that. TS catches me writing
| numerous bugs a day, the structural typing plus static
| analysis is a superb combination. If your code base is in JS
| without types, you probably have _many_ bugs, you just don't
| know about them. Especially around undefined /null handling.
|
| TypeScript also allows me to refactor fearlessly, which
| substantially improves the quality of my code as I can do
| mini-rewrites without worrying about breaking interfaces.
| adamddev1 wrote:
| Nothing as satisfying as quickly adjusting all the red
| squiggly lines after a big refactor and then seeing
| everything run perfectly again.
| xodeus wrote:
| > TS catches me writing numerous bugs a day
|
| I see this sentiment a lot but I honestly can't think of
| any non-trivial bugs that TS has caught for me. 99% of the
| bugs it catches I would see 1 second later when my page hot
| reloads and crashes.
| vsnf wrote:
| That's the beauty though, isn't it. Most bugs are
| trivial. I appreciate typescript getting the trivial bugs
| right more often than I'd trust myself to do so.
| dleslie wrote:
| Right? The argument that static/strict typing mostly
| catches trivial bugs isn't an argument against the value
| of that language, and yet people seem to think it is!
| alrlroipsp wrote:
| Let them fight windmills while we have a good time.
| DogLover_ wrote:
| I have to disagree. Adding the types will increase the
| number of the characters/lines of code which with a
| 80-char formatter limit can make functions look almost
| gibberish at a glance. Do that on a whole codebase and it
| becomes a mess to look at.
| fpoling wrote:
| The verbosity of TypeScript types can be attributed to
| poor choice of syntax and names that became obvious
| retrospectively.
|
| Still even with TypeScript if types makes your functions
| ugly, then it shows the complexity of the code. Often it
| also suggests sensible refactoring that without types
| would not be apparent.
| DogLover_ wrote:
| Typscript: "function area(left: number, top: number,
| right: number, bottom: number): number {"
|
| Javascript: "function area(left, top, right, bottom)"
|
| In an editor the typescript function would likely be
| split into five separate lines.
|
| "function area(
|
| left: number,
|
| top: number,
|
| right: number,
|
| bottom: number)
|
| : number {"
|
| None of the functions are complex but the the typescript
| function with the formatter creates a lot of noise.
| dleslie wrote:
| It's not noise, it's informative content.
|
| It also means it's not going to explode when fed the
| wrong types, because that's not possible.
| eyelidlessness wrote:
| And I have to disagree in turn. Those additional
| characters and lines of code are documentation, and turn
| gibberish into not only human-readable clarity about the
| code you're reading, but a machine-traversable dependency
| graph as well.
| dleslie wrote:
| Character input time is a vanishingly small concern for
| overall productivity. If it's a concern then you'll
| probably catch more bugs by slowing down to think.
| DogLover_ wrote:
| Typing it is not the problem. It is reading at a glance
| that becomes much harder since lines oftentimes get split
| into multilines. I get less of an overview.
| dleslie wrote:
| It's all still there, except with even more helpful
| information.
|
| If there are so many parameters that it falls out of
| mental context then there's too many parameters.
| jjnoakes wrote:
| You get 100% code coverage within 1 second of page load?
| fifticon wrote:
| well I can, I wrote a year-long js project that I
| abandoned as refactorings gradually turned into eternal
| bug-fests. I started from scratch in typescript, and the
| project is now 3x the dead project, with none of the
| bugs. and refactorings have become painless, with the
| compiler tools and editor telling me what I must fix up.
| There may be a special breed of programmers who need no
| such help, but I have yet to meet them in my 32+y long
| professional programming career :-)
| mixmastamyk wrote:
| You still have bugs, you just haven't found them yet.
| When strict typing is not available you adjust and use
| other tooling and tests.
|
| Of course with a big, venerable project the balance
| changes drastically. But an experienced single-person
| project should be doable with javascript for a long while
| and may even get to MVP faster by focusing on things that
| are essential.
| CodeWriter23 wrote:
| I've been coding professionally for 39 years. ts seemed
| very strange to me at first. Only even started using it
| because I had to do some customization in NetSuite and
| some third party type and build support in ts made
| comprehensible the typically-stilted and insane NetSuite
| js required by SuiteScript.
|
| Now I'm addicted to it. Specifically the lightweight and
| easy to use _interface_ directive feeds my practice of
| self-documenting code with good doc and reusable data
| structures.
| davnicwil wrote:
| I find it catches a lot of design mistakes for me which I
| would put in the non-trivial bugs category. Many bugs
| that result from design mistakes are less immediate, like
| hard to spot edge cases (a better design makes them
| impossible) or code that lends itself to becoming messier
| and more bug prone in the future as it's changed/extended
| (a better design makes this less likely).
| jshen wrote:
| I've had the opposite experience with complex type
| systems. They make it harder to evolve out of bad
| designs. This is particularly true when a lot of
| inheritance is used.
| davnicwil wrote:
| Interesting. What I've found is that when I come up with
| some pattern that is hard to type, or I have two parts of
| a system that need to work together but the interface
| can't be typed simply or doesn't quite 'fit', it is
| almost always the case that changing things around until
| the types do work straightforwardly uncovers a better
| design.
|
| This is definitely sometimes not easy, and of course
| it'll get more difficult generally the more code there is
| or the more complex (usually meaning bad!) the design is,
| but I'd almost put it the other way round to your
| perspective - the types are like the signposts in this
| design evolution and discovery process. They don't make
| it easier to do the work of refactoring a design, but
| they _do_ make it much easier to understand when I 'm
| going in a good/bad direction and also when I have
| succeeded.
| jshen wrote:
| You are describing writing code alone. I'm thinking about
| other peoples code I've had to deal with where I didn't
| create the types. Not saying I'm great at it, but that
| you can't always control the quality of the code you have
| to work on.
| miiiiiike wrote:
| Many bugs are trivial until they slip into production.
| throwaway0asd wrote:
| Exactly, you have to run the code before you realize it's
| defective and even then only the defects that execute
| will get any attention. With TypeScript the defects yell
| at you before executing the code.
| jshen wrote:
| But at what cost? We shouldn't assume it's free
| throwaway0asd wrote:
| The cost is the compile time. My personal application is
| about 50k loc so the compile time is about 9 seconds with
| TSC or 1.5 seconds with SWC.
| jshen wrote:
| There are other costs. One study I've seen found that
| writing libraries with typed generic code too longer to
| write, but we're slightly faster to use. I've found that
| changing peoples badly typed code is worse than changing
| similar dynamic code.
|
| In short, there is very little empirical data on this,
| and it's almost entirely anecdotal. My gut feeling is
| that if typing were a huge benefit it wouldn't be so hard
| to prove.
| throwaway0asd wrote:
| Avoid things like generics. Keep your types as primitive
| as possible. Strong typing will covert an excellent
| developer into an amazing developer but won't do anything
| for extremely bad developers. Data types are not a
| solution to people problems.
| jshen wrote:
| Agree, but the question for me is whether it is clear
| that it's better at organizational scale over decades. I
| think it is, but not hugely so.
|
| Edit: I should add that I think there are a ton of things
| that are far more important for a high performing dev
| team than types.
| adamddev1 wrote:
| I've written some projects w really complicated data and I
| personally think it would take 5x as long or push me to
| almost give up if I didn't have type checking.
| nathias wrote:
| TS on frontend feels like devs making their editor choice
| (VScode) a hard dependancy
| hurflmurfl wrote:
| What do you mean? I'm editing TS perfectly fine in Jetbrains
| IDEs, and some coworkers use emacs and vim without any issues,
| still getting all the error highlights, etc.
|
| Is there an editor that doesn't work with Typescript? Even
| without type error integration into the editor view, you could
| still run tsc in your shell of choice to manually check if
| everything is OK.
| christophilus wrote:
| What? Works fine in my editor (neovim). It also worked fine in
| helix when I gave it a try.
| nathias wrote:
| I don't mean that it doesn't work on others, but that I don't
| need it and people who use vscode seem to.
| kuramitropolis wrote:
| chuckSu wrote:
| RunSet wrote:
| > When people say, like, "blah blah VSCode this blah blah
| TypeScript that", all I hear is "Embrace, Extend, Extinguish
| the open Web ecosystem".
|
| Your memory may be too long to fit the TypeScript demographic.
| kuramitropolis wrote:
| Seems so :(
| xcambar wrote:
| Brace yourself, a new trend is near.
| xodeus wrote:
| I hope you're right, I've been waiting for Typescript to die
| for years
| kuramitropolis wrote:
| Someone _please_ make WASM source maps JustWork!
| wildpeaks wrote:
| At the time, the turning point that finally made me switch from
| Flow to TS was when it added the JSdoc mode that allows you to
| have VSCode intellisense without a compile step.
| kuramitropolis wrote:
| Any survivors of
| https://www.typescriptlang.org/docs/handbook/esm-node.html wanna
| share their experiences?
| zebracanevra wrote:
| type module in the package.json, and import every and all .ts
| file with a .js extension. zero problems for a year or two.
| kuramitropolis wrote:
| >import every and all .ts file with a .js extension
|
| And recompile on every change, gotcha. I am emphatically
| _not_ doing either.
|
| EDIT: for future reference, `"type": "module"` is not part of
| the fix but the thing that opens that particular can of
| worms. Rotten ones.
| seumars wrote:
| >TypeScript never set out to build a separate, distinct, and
| prescriptive language. Instead, TypeScript had to be descriptive.
|
| Sadly, the majority of people writing Typescript rarely care
| about descriptive and readable code these days. Somehow the focus
| shifted from using types to better understand complex systems
| through the _code itself_ , to writing whatever polymorphic union
| type abomination that yields the best IntelliSense auto-
| completion in VSCode.
| ilaksh wrote:
| The whole reason Microsoft made TypeScript was so that
| Intellisense would work. Then that became part of the religion
| and elaborated on with millions of dollars of marketing.
| montroser wrote:
| I think you meant to write TypeScript.
| [deleted]
| zarzavat wrote:
| The polymorphic union type abominations are precisely because
| TypeScript is insistent on being a thin layer on top of JS.
|
| In particular there is no built-in ADT syntax, but the type
| system does support ADTs using the aforementioned polymorphic
| union abominations, so it is possible yet tedious to write
| them.
|
| They are in a tricky situation because TC39 really does not
| care about TypeScript at all when introducing new features into
| JS. So TypeScript is doing its best to avoid breaking future
| compatibility with a standard they have no control over.
| Sometimes this makes the language worse, but they are playing
| the long game.
| traspler wrote:
| I'm not well versed in type theory and some of the types
| libraries require, especially in the React ecosystem, really
| make my brain hurt. And sometimes it seems unnaturally hard to
| figure out what is even expected to type something correctly.
| iLoveOncall wrote:
| I agree, but I would like to say that this is more due to the
| limitations of TypeScript (and JavaScript) and the need for
| developers to work around those limits, rather than anything
| else.
|
| TypeScript is great, but it is also still very far from being
| complete in my opinion.
|
| I used to do mostly Java and a bit of TypeScript, changed teams
| and now do mostly TypeScript and a bit of Java, and this
| unfinished feeling is striking, even for relatively basic
| things (enums).
|
| I think the modern compiler options / TypeScript rules such as
| "hey this variable can be undefined but you didn't specify it",
| "hey, it can also be null, don't forget that" are commandable,
| but just don't work well for the web. I know it's configurable,
| but it just makes for a bad experience.
|
| Still, love TypeScript. I wouldn't do any JavaScript project
| anymore, installing the TS compiler is always my first step.
| regularjack wrote:
| I've had a very different experience than yours with the
| Typescript codebases I've encountered, which were mostly well
| designed.
|
| I have no doubt codebases with polymorphic union type
| abominations exist, but I wouldn't say they are the majority,
| far from it in my experience.
|
| It also seems to me those are a case of "problem lies between
| chair and keyboard", not a fault of the language. Bad code can
| be written in any language.
| whynotminot wrote:
| > I've had a very different experience than yours with the
| Typescript codebases I've encountered, which were mostly well
| designed.
|
| Agreed. And in fact, the founders of a project having
| _explicitly chosen TypeScript_ is often in and of itself an
| indicator that the team cares about code quality and writing
| style.
|
| As you say, you can write poorly in any language. But people
| who care about quality choose TypeScript.
| itsmeste wrote:
| This. Probably every TS codebase I ever worked in had zero to
| none function- or inline docs with people always claiming
| "documented by TS". I call that BS, and you can see that in
| their projects. "Typescript codebase" became the equivalent of
| "generic low quality codebase" imo.
|
| I'll never understand why people need a programming language
| inside a programming language and refuse simplicity (i.e. using
| jsdocs, which has perfect IntelliSense support).
| CapsAdmin wrote:
| You can use some jsdoc in typescript, see
| https://www.typescriptlang.org/docs/handbook/jsdoc-
| supported...
|
| However I tend to only use /** a comment */ before a type
| definition or argument which will add the comment along with
| the type in autocomplete.
|
| I get the feeling you've stumbled more on the debate about
| commenting code/inline docs vs code that self documents. My
| general impression of Javascript developers is that they are
| comfortable adding comments whereas Typescript people are not
| so comfortable for some reason. Maybe because a lot of them
| are coming from Java and C# where writing clean code(tm) is
| more preferable to adding comments.
|
| Personally I think there's a middle ground. I've met some
| Javascript developers insisting on adding a comment before
| each statement and I've met some java developers having a no
| comment policy in their codebase (so that pull requests wont
| merge if there are comments).
| auggierose wrote:
| I tried jsdoc + JavaScript for a while to minimise the
| distance between me and the browser, but in the end
| TypeScript was just the easier choice. Less documentation to
| type, and the checks are better. I found that using
| TypeScript basically like JavaScript + jsdoc delivers the
| best value. I avoid any advanced TypeScript features as
| TypeScript is just not a proper statically typed language.
| scrollaway wrote:
| This is entirely applicable to JavaScript codebases, except
| that at least in typescript you have less reverse engineering
| work to do.
|
| If you want to have documented codebases, work with people
| who document their code. You'll find that typescript doesn't
| always mean undocumented, and incidentally you'll find that
| documented doesn't mean high quality.
|
| Most high quality codebases in the JS ecosystem after 2016
| ish are in typescript.
| olitech wrote:
| Typescript was my stepping stone into the world of Rust.
|
| Even before Deno made it easy, it was straightforward enough to
| configure a simple tsconfig and just run tsc. Much like cargo,
| there is a lot to be said for "it just works" tooling -
| especially for beginners or even new programmers.
|
| It is probably fair to say it is one of the most influential and
| impactful languages of all time. There's even the future
| possibility of much of its type syntax being absorbed back into
| JavaScript: https://github.com/tc39/proposal-type-annotations
| kuramitropolis wrote:
| Opposite experience. Rust was my stepping stone into "hey,
| maybe JS will be better with some degree of static typing?" Yes
| it would. But not the way TypeScript does it though, and there
| aren't any other viable options, are there?
|
| TypeScript brands itself a "superset" of JavaScript. In
| practice, it arbitrarily invalidates completely sensible
| JavaScript idioms.
| wiseowise wrote:
| > In practice, it arbitrarily invalidates completely sensible
| JavaScript idioms.
|
| Such as?
| [deleted]
| oblak wrote:
| One of the first things that made a bad impression on me
| was back in the day when classes were still used in the js
| world.
|
| I was not pleased when it told me I have have to do
|
| this.blahBlah = value
|
| in the constructor because it didn't quite catch, and maybe
| still doesn't, that
|
| Object.defineProperties(this, { bla: { value: ... } blah:
| {get, set} })
|
| is completely legit
|
| That said, I do prefer ts to vanilla. It's less work than
| maintaining d.ts files
| reitanqild wrote:
| But who want to use
| Object.defineProperties
|
| when there is a clearer and shorter way?
|
| Or am I misunderstanding something?
| kuramitropolis wrote:
| For one, try redefining a property as a getter/setter pair
| in a subclass.
|
| Also, try implementing a function that takes keyword
| arguments, some of which are required, and some of which
| have default values.
|
| I'll wait. When you're back I might've remembered some
| more.
| purplerabbit wrote:
| You're right on the first (although classes are out of
| fashion, so this is low impact)
|
| On the second, doesn't this work?: 'function foo({ bar =
| 3 }: { bar?: number })'
| kuramitropolis wrote:
| >You're right on the first
|
| Strictly speaking, it takes exactly _one_ such behavior
| (that you cannot even disable) for TS to _stop_ being a
| superset of JS.
|
| >although classes are out of fashion, so this is low
| impact
|
| Looking at the TSC codebase, so are keyword arguments.
| The "in" thing is just to write very very long lines of
| multiple verbosely named positional arguments instead.
|
| That said, "clases are out of fashion" is a complete non-
| argument. I'm of the functional persuasion, yet I've
| found that classes are the ony way to write TypeScript
| that fits on your screen at all.
|
| Especially now that classes are being introduced in
| JavaScript proper, and of course TypeScript does them
| _only slightly_ differently (handling of default property
| values and "definedness" differs).
|
| >On the second, doesn't this work?: 'function foo({ bar =
| 3 }: { bar?: number })'
|
| You also need a `= {}` there, otherwise you'll need to
| call `foo({})` - it won't let you call `foo()`. This is
| also in JS though, so a bad example of TS breaking things
| (`function foo ({ bar })` still won't work though). There
| are probably better ones that people encounter, work
| around, and forget about, because nobody's listening
| anyway. "The code making sense is not important, what's
| important is helping the user" lol.
|
| Now imagine how the above looks with 5-10 kwargs (because
| keeping context in the class instance is "out of
| fashion", so it's either a ton of args per function or a
| "context" record which is effectively reimplementing
| classes but with a worse experience), and an aggressive
| formatter insisting every individual thing has to be in
| its own line.
|
| Here's another: failing to infer the type of
| `this.constructor`.
|
| Sure, the constructor signature may change in a subclass
| (why not disallow incompatible constructor overrides,
| given incompatible property/method signatures are already
| disallowed?); then what about static methods accessed via
| `this.constructor`?
|
| So you end up defining an interface type for the
| constructor and using `(this.constructor as
| MyConstructorType).staticMethod` or whatever. Which is
| just visual noise where the fucking intent of the code
| was previously clear as day, so clear that TSC should've
| been able to infer it (yeah the type inference also
| sucks).
|
| Also, ever seen TS2322? It's my pet now. What it do
|
| All in all, TS really puts the "Java" back in JavaScript,
| and then some.
|
| EDIT: Also crap like not being able to have a question
| mark and a default value in positional arguments so you
| gotta add `|undefined` there. Even the stuff it adds on
| top of JS is poorly thought out.
| eyelidlessness wrote:
| > I'm of the functional persuasion, yet I've found that
| classes are the ony way to write TypeScript that fits on
| your screen at all.
|
| Huh? I'm of the functional persuasion too, and I use
| classes in TS too, but for strategic reasons (well
| defined value objects are easier to reason about than
| duck typed POJOs, and they perform better too). But I've
| never found them more space-dense than the equivalent
| function-only code. Often quite the opposite, as so many
| functions' return types can be fully inferred. Which of
| course, this is how you get ~~ants~~ duck typed POJOs,
| but you can't have explicit type defs without _explicit
| defining them somewhere_ , and of course the syntax that
| collocates the field type and its value is more dense
| than the syntax which is wholly incompatible with that
| concept.
|
| > handling of default property values and "definedness"
| differs
|
| The only difference is that TS provides a fully optional
| shorthand for assigning both the type and value in
| constructor arguments. The actual behavior isn't any
| different. This: class Foo {
| constructor(readonly bar: number) {} }
|
| is identical to: class Foo {
| readonly bar: number; constructor(bar:
| number) { this.bar = bar; } }
|
| is identical to: class Foo { bar;
| constructor(bar) { this.bar = bar; }
| }
|
| And this type error: class Foo {
| readonly bar: number; constructor(bar:
| number) {} }
|
| is identical to this type error, just caught sooner:
| class Foo { bar; constructor(bar:
| number) {} } const foo = new Foo();
| foo.bar.toFixed(2);
|
| > Sure, the constructor signature may change in a
| subclass (why not disallow incompatible constructor
| overrides, given incompatible property/method signatures
| are already disallowed?)
|
| Because the compatibility is checked on the `super` call
| which is required both at compile time and runtime, and
| because many use cases for subclasses are impossible or
| even invalid without different construction contracts.
|
| I know there are many strong feelings about examples like
| this being "wrong", but it's a common enough inheritance
| example to illustrate the point: class
| Square extends Rectangle { constructor(/* ? */)
| {} }
|
| You _cannot_ satisfy both Square and Rectangle with the
| same constructor arguments. This of course bolsters the
| point that this inheritance model is "wrong", but it's
| _exactly right_ according to the domain, and the
| equivalent functional code to calculate eg area would
| similarly have to be either polymorphic over different
| shapes or expect a single shape constructed with
| different parameters.
|
| > this.constructor
|
| You got this one right, and it's worse than you describe
| because of the weird rules for where you can't have type
| parameters or explicit `this` types. The workaround is to
| use a static factory method, but it's a shitty workaround
| with a lot of ceremony to do something that TS generally
| does well: model the types of real world JS code.
|
| > Also crap like not being able to have a question mark
| and a default value in positional arguments so you gotta
| add `|undefined` there. Even the stuff it adds on top of
| JS is poorly thought out.
|
| Ima help you out! Assuming your default satisfies the
| non-undefined type, you can just skip the union, it's
| implied. This: const foo = (bar: Bar =
| someBarSatisfyingValue) => {};
|
| is identical to this: const foo = (bar:
| Bar | undefined = someBarSatisfyingValue) => {};
|
| is identical to this: const foo = (bar?:
| Bar) => { bar = bar ?? someBarSatisfyingValue;
| };
| spankalee wrote:
| > For one, try redefining a property as a getter/setter
| pair in a subclass.
|
| This is actually a completely invalid pattern in
| JavaScript, and it's really good that TypeScript errors
| for it.
|
| Class fields are created with a define property step in
| the constructor, so they would shadow the getter/setter
| in the subclass.
|
| The super class needs to have a getter/setter pair itself
| to be overrideable.
|
| The upcoming `accessor` keyword will help by makes
| getter/setter pairs automatically.
|
| As for required args and defaults, TypeScript doesn't
| really change anything over JavaScript except adding type
| warnings: https://www.typescriptlang.org/play?#code/MYewd
| gzgLgBAZiEMC8...
| an1sotropy wrote:
| Is there any news about the status of the type-annotations-as-
| comments proposal? The README has said "Details will change in
| the coming days" since March 31. I know TCs are supposed to
| move deliberately, but this is such a neat idea I'm impatient.
| krapp wrote:
| > There's even the future possibility of much of its type
| syntax being absorbed back into JavaScript:
| https://github.com/tc39/proposal-type-annotations
|
| ... as comments. Which superficially resemble the syntax of
| type hints but do nothing. Which has to be one of the worst
| language design decisions of all time.
| kuramitropolis wrote:
| ...as _optional_ _hints_ that don 't require you to buy into
| a whole new toolchain.
| jmull wrote:
| I don't see the problem with this design decision.
|
| I'm not the biggest fan of static type checking (especially
| in a language like Javascript, where it isn't used for safety
| guarantees), but it has its uses.
|
| The "as comments" part of it isn't about syntax. They really
| mean no runtime overhead/behavior. (I don't think they should
| have put it that way -- it's just going to cause confusion.)
|
| Is there really any question that "no runtime overhead" needs
| to be an option? (I think any proposal that didn't include
| this would be DOA.)
|
| It also seems clear to me it needs to be the default option,
| for multiple reasons (language changes should be backwards
| compatible as much as possible, it should be easy to adopt
| new language features incrementally, type usage is an
| application-level concern.
|
| Note: there's nothing in this proposal that _prevents_ run-
| time enforcement. Good design limits scope but keeps your
| options open.
| seeekr wrote:
| I just want to note that it seems incorrect to call this a
| superficial resemblance in terms of syntax. I went and read
| through the whole thing, and the syntax for the type hints
| seems to be as close to 100% TypeScript as possible, which is
| to say, it is very close. There may be some features missing
| that TS supports, but the bulk of it is there, and what's
| there is basically Typescript, which is the best thing that
| could possibly be accomplished here.
|
| Typescript has been doing a fantastic job, and this proposal
| is continuing in that same vein, truly absorbing as much of
| that as possible back into JS!
|
| Kudos to everyone involved, great effort!
|
| And re "[the type hints] do nothing": The section at the end
| of the proposal clearly explains why that must necessarily be
| the case: Evolutions of JS must not break the web
| (especially) for the users.
|
| Quoting: "TypeScript's model -- which has been highly
| successful for JS developers -- is around non-local, best-
| effort checks. (...) Additionally, defining a type system to
| run directly in the browser means that improved type analyses
| would become breaking changes for the users of JavaScript
| applications, rather than for developers. This would violate
| goals around web compatibility (i.e. "don't break the web"),
| so type system innovation would become near-impossible.
| Allowing other type systems to analyze code separately
| provides developers with choice, innovation, and freedom for
| developers to opt-out of checking at any time."
|
| So this proposal provides the best possible path forward for
| JS, based on what folks are voting for with their feet by
| using TS: Making JS compatible with TS-style type hints that
| can be used by external tools (i.e. not the JS engines
| executing the code at runtime) to validate the code in a
| best-effort manner _while the developer is looking at it_ ,
| while not changing JS runtime semantics and thus never
| breaking the code _while the user is running it_.
| olitech wrote:
| I'd disagree that its a poor decision, some help is better
| than no help when reading code - and if it's inline then it's
| intrinsically meaningful.
|
| By no means is it perfect, the language doesn't enforce the
| type rules, but that the developer has the option is far
| better than not. As far as I can tell the proposal would
| pretty similar to Python; one can misleadingly or
| accidentally misuse type hints like the following:
| def myfn(a: int) -> str: return int(a)
| print(myfn("42"))
|
| But when done right, it gives you a leg up when you come back
| to read your own code or scan over someone else's. When
| you're reading over other's code in group programming
| assignments, comments make a world of difference (a niche
| example).
|
| It is a choice, but its use in code might just inspire
| someone to investigate further - my own introduction to types
| in programming came when I wondered what these oddly placed
| colons and arrows were in some Python I came across. If they
| do add these annotations to JavaScript, some future
| programmer browsing the source of a web page may well just
| stumble upon types and have a whole new world of theory
| opened up to them - I'm all for it.
| schwartzworld wrote:
| That's fine for atomic types like string or int, but
| typescript goes a lot deeper than that with powerful
| generics. For example, I'm working on a library of
| functional data wrappers. This would be useless without
| Typescript and impossible to type without generics.
|
| There's also no way to share and reuse types in comments.
| Do you copy paste comments to "type" things? What about
| complex objects? What happens if the comments get out of
| sync? How do you test them?
|
| I used to be a typescript skeptic too, but much of that
| skepticism tends to come from drastically underestimating
| the power of the TS type system.
| magnio wrote:
| Thank you, Anders Hejlsberg. As a newbie in front-end
| development, I am grateful to TypeScript (and its integration
| with VSCode) for taming the dynamic beast and keeping me and my
| codebases sane. The pragmatic design and composable nature of TS
| help it fit easily within the JS ecosystem, and the productivity
| boon helps it survive in that tumultuous landscape.
| k__ wrote:
| I wouldn't have bet on it.
|
| When it came out alongside Dart, I thought Dart to be the better,
| cleaner solution. After all, Google created V8.
|
| Microsoft and Hejlsberg didn't seem well suited to tackle
| something so lightweight as JS. The whole .net suite seemed like
| an overengineeres mess to me and MS wasn't liked after the IE6
| incident.
|
| But on recent years I came to like TypeScript. It really is just
| JS.
| rini17 wrote:
| Wanted to try it, proceeded to install it with npm and it was
| incredibly scary, both the amount of stuff it pulled in and
| various warnings. No thanks, I'll stay with languages with more
| self-contained compiler.
| paavohtl wrote:
| I don't understand what you are referring to - the TypeScript
| compiler has 0 (non-dev) dependencies: https://github.com/micro
| soft/TypeScript/blob/main/package.js....
| kuramitropolis wrote:
| Yes, it also comes delivered as several near-identical builds
| for different contexts, each of which is nearly non-
| extensible. Have you seen the kind of monkey patching Volar
| (Vue tooling) does to enable type checking of TypeScript
| embedded in Vue templates? Meanwhile, native JSX support lol
| lf-non wrote:
| Well TS does have its complexities, but it is somewhat
| surprising to see the complaint being that supporting
| typechecking for something that is not TS at all (and
| something TS authors know nothing about) is complex.
|
| It is amazing that the whole langserver stacking that volar
| does is possible at all - I don't believe there is any
| equivalent prior art that worked as well as it does.
| Despite all the complexity the end user experience is
| pretty good. If someone had mentioned to me this kind of
| cross language type-checking can work as nicely before I
| used volar I would have been super skeptical.
|
| Sure it has its caveats. But it is also completely possible
| to use vue in pure typescript.
|
| I don't fault them for having native jsx support, React was
| just too popular in the target user base. I do hope that
| someday js+ts gets kotlin style builders, but until I'll
| gladly use volar.
| kuramitropolis wrote:
| JSX is also not TS at all, yet it gets preferential
| treatment (TSX). Unlike JSX/TSX, the TypeScript used by
| Vue _is just TypeScript_ - wrapped in a tag next to some
| other stuff, so _you know where the part you need to type
| check starts and where it ends_. All TS needs to do to
| support this, on a basic level, is ignore the non-TS
| parts, i.e. let you turn each non-TS line into a comment.
|
| But no, even adding supported _extensions_ to the
| compiler, that 's right, not even formats, just making TS
| recognize a new _extension_ as a file that it can load
| code from, is a no-go; a pre-load hook is the simplest
| thing to add, had they not made it _explicitly,
| intentionally non-extensible_.
|
| I didn't even have time to get into the "stacking of
| language servers" (something that can and should be as
| simple as a _pipe_ , and of course Microsoft has all the
| reasons to make it the opposite of that). So the Volar
| people literally had to _monkey patch Node 's the
| standard library_ and _edit TSC 's source on the fly_ to
| make _anything_ , _work_ , _at all_.
|
| It all just goes downhill from there. Designing good APIs
| is hard enough - having to design them around the
| arbitrary barriers of some Microsoft boffins who decided
| to add _a complex type system_ to a language which
| desperately needs _a simple macro system_ - and took 10
| years to do a shit tier job - oh, such an enlightening
| experience! Let 's just say that I have become acutely
| aware that during the past year I have, well, degraded.
| As a person. _And I literally attribute about 50% of that
| degradation to my ill-advised choice to do my work in
| TypeScript._ Because like everyone I thought "hey, it's
| just a superset of JS, can't be that bad..."
| samhuk wrote:
| I have a rather funny story about Typescript from ~4 years ago. I
| joined a team that had, amongst other things, an Node-Express.js
| and React-redux stack, all in vanilla Javascript.
|
| I was a bit younger and bolder then; I lamented with the lead
| developer about how vanilla JS was probably not a good idea for
| what was to be a large enterprise platform. The response I got
| back was probably what you would expect from a senior developer
| receiving criticism from a rather newly minted developer: _Oh i
| 've tried Typescript, but it's just SO VERBOSE. I feel like I
| can't get ANYTHING done_, etc. etc. etc.
|
| I've personally been all in on TS from close to day one - around
| 2013 when I started some very early web development (hooray for
| the AngularJS/Angular days! /s). It somewhat scratches my ego and
| has been rather interesting to see the developer mindset change,
| particularly that of vanilla JS developers of old. Response like
| ones I had have gone from often negative, complaining about
| verbosity and I guess frustration with anything different from
| what they are used to, to overwhelmingly positive. Old guards
| join us, or fade away, I suppose.
| shp0ngle wrote:
| I wish Flow, Facebook's TypeScript, was more popular, as I think
| it has some better properties.
|
| But yeah, the tooling is kind of bad and it is all written in
| OCaml, while TypeScript is in TypeScript...
| lf-non wrote:
| I always felt the decision to write flow in ocaml was ahead of
| its time. Flow compiler is much faster than TS.
|
| Native bundlers like esbuild, swc etc. are mainstream now but
| they came much later.
| josteink wrote:
| But writing Typescript in Typescript allowed the language-
| designers to dogfood the developer-experience of being a
| Typescript-developer.
|
| Just like MS eventually did with C# too. After the
| C#-compiler was reimplemented in C# (Roslyn), that's when the
| language was truly allowed to develop. And it also made it
| much easier to make C# a truly cross-platform language.
|
| When the language-designers don't have to use their own
| language, they have objectively much less motivation to
| improve upon the language or it's tooling than if they do.
|
| The Flow-team didn't use Flow to write Flow and that shows in
| its lack of development, its lack of tooling, its lack of
| contributors and ultimately in its lack of adoption.
| rr808 wrote:
| As a C++/C#/Java developer I just couldn't deal with Javascript.
| Since discovering TS its fast becoming my favorite language. I
| think I might even use in the back end going forward.
| lizardking wrote:
| I like TS as a language but the single threaded nature of js
| will eventually weigh you down.
| osigurdson wrote:
| How do you feel about the performance tradeoffs of doing so?
| DogLover_ wrote:
| I feel like I am the only one in the world not liking typescript.
| It is not that I don't like types, it is what those types do to
| the readability of the codebase in terms of verbosity. My
| original programming language was Java but I switched to Node.js
| because I liked the simplicity of the code written in it.
| Nowadays every Javascript project seems worse than a Java project
| in terms of verbosity.
|
| My main gripe with projects becoming verbose is that the code
| becomes hard to understand at a glance. Functions that usually
| could be 10 lines are now 15 lines becomes of the formatter and
| each line looks more gibberish because everything has a type. You
| have to manually filter out that noise. The best way I can
| describe it is that entropy is increased in order to get type
| safety.
| bottlepalm wrote:
| I tried to find an example to see what you mean, take this file
| -
| https://github.com/microsoft/vscode/blob/main/src/vs/editor/...
|
| The typings on the class variables are useful to have. There
| are also typings on the function signatures, not a huge deal.
|
| In the method bodies there are almost no typings as all of it
| is already inferred. Seems pretty readable to me.
| DogLover_ wrote:
| I agree that in your example it is not bad. Throughout that
| codebase it is clear though that they don't have a formatter
| that enforces a char-limit per line. It is when you combine
| those things it gets messy. Prettier uses a default of 80.
|
| Looking at the code there is an awful lot of 'null's returned
| which I find hard to work with but that is a different topic.
| RedShift1 wrote:
| I'm also in the not-liking typescript camp. I was an early
| adopter (I think my first version was 1.7 or 1.8) and it put me
| off forever. What increased my productivity the most was not
| languages, linters, build tools, compilers, transpilers, etc...
| it was a good IDE. Now I just write plain Javascript with JSdoc
| and I don't need to update my toolchain every week.
| eyelidlessness wrote:
| I maintain several JS+JSDoc projects for work, and several TS
| personal projects. You can certainly get a very similar IDE
| experience with plain JSDoc, but the tradeoffs are pretty
| severe. Certain aspects of the type system have no JSDoc
| equivalent (assigning a type to a class _definition_ ), or
| worse have conflicting equivalents (eg enum, which I know
| everyone hates in TS but the JSDoc version is worse), or
| require cramming TypeScript syntax onto a single line in (eg
| conditional types).
|
| Most plain JS projects use some build tooling even without
| compiling TS, my work projects are no exception. When I
| started the job, the build tools (Rollup and Terser) worked
| just fine and had been in place for years. A short while
| later I made the case to switch to ESBuild to improve
| iteration speed, which took a couple hours maybe? It's been
| almost totally untouched since. And if I had more time, I'd
| be able to gradually convert the code to TS without any
| additional tooling effort.
|
| I get that tooling pain in the JS/TS ecosystem is basically a
| running joke at this point, but no one is forcing you or
| anyone else to update anything. Plain old tsc still works if
| you want to keep it simple (and it's what I recommend to
| anyone who wants to try out TS and feels confused or
| intimidated by the whole Tooling Thing).
|
| To each their own of course, but living on both sides of the
| fence... the JSDoc-types side isn't nearly so green as it can
| sometimes sound.
|
| Here's hoping the types-as-comments proposal keeps gaining
| traction. I'll still use a build tool to strip types out for
| prod, but I think the no-tooling/JSDoc-types crowd would
| benefit a lot from a syntax much closer to TypeScript too.
| yrgulation wrote:
| And still useless if you are at least half decent in js.
| kuramitropolis wrote:
| Worse than useless.
| BigJono wrote:
| It actually is. TS is like a force multiplier for shit devs.
| All the worst code I've ever seen has been in TS and within
| the last 5 years. The average code quality has fucking
| plummetted in that time too, it's not just the worst
| offenders.
| Jcampuzano2 wrote:
| I'd argue it's not actually TS that causes this. There are
| just a lot of unskilled devs.
|
| You mention "within the last 5 years" without also taking
| into account the absolute explosion in the popularity of
| becoming a software dev in the last 10 years. So of course
| theres going to be a lot of bad (and some good) devs. With
| TS being one of the literal most popular languages in use
| right now, of course a lot of bad code will be concentrated
| there, but I wouldn't blame TS itself for it.
|
| You can also blame hiring practices somewhat for it, since
| a lot of places I've worked for even myself recently hire
| anybody who can recite a couple ECMA features rather than
| focusing on good dev practices in general.
| shanghaikid wrote:
| Typescript is for big project and team collaboration. JS is still
| my choice for personal or small project. Fast!
| [deleted]
| iLoveOncall wrote:
| > Typescript is for big project and team collaboration.
|
| TypeScript is for any kind of project, it just makes your code
| safer, easier to debug, easier to read / come back to in the
| future, etc.
|
| > Fast!
|
| That doesn't mean anything.
|
| Especially for a small project, the TypeScript to JavaScript
| compilation will take milliseconds, there is no speed impact at
| all.
| kuramitropolis wrote:
| My project is small but TS takes 4-5 seconds to compile it
| from scratch on each run.
|
| The main speed impact is in developer productivity though. If
| something ain't working right, now I first gotta fix the
| types before I can see if I've fixed the actual logic.
|
| I imagine if my codebase was more "OOP-y" (i.e. if I replaced
| every layer of my domain model with 3 layers of dependency
| injection, turning the whole thing into an inscrutable ball
| of spaghetti like the cartel wants me to) I could probably
| iterate without breaking the types.
|
| But for any sane developer having made the mistake to touch
| TypeScript, the capability to strip the types and run the
| code with broken types, is essential.
|
| "But then why have types at all?" Exactly. They're a crutch
| for people who want their IDE to understand the code instead
| of them.
| CapsAdmin wrote:
| For me the best experience during development is to build
| ts to js first with something fast like esbuild and check
| types in parallel without preventing the output in any way
| from running in the browser.
|
| A perfect scenario for me is having all errors in the
| project caught by vscode. At the moment vscode only checks
| files that are currently open. I think type checking should
| only be done when building to some sort of production or
| realtime in your editor. Templates like "create react app"
| can report runtime errors but it's somewhat strange that it
| also report typescript errors. (although understandable
| given that it wants to be tooling agnostic)
|
| One potential major upside with adding optional type hints
| to javascript is the ability to run typescript files
| directly in the browser without needing to strip types in a
| build step. Advanced type checking could be done the same
| way we use linters like eslint.
| kuramitropolis wrote:
| >At the moment vscode only checks files that are
| currently open
|
| While TSC checks everything by default - even files that
| are not even part of the dependency graph. That's how
| great the "great tooling" is in reality.
|
| >I think type checking should only be done when building
| to some sort of production or realtime in your editor.
|
| Agreed, that's the lest awful option. The problem is that
| they had 10 years to think of it, and didn't.
|
| >Templates like "create react app"
|
| ...are a big part of the problem. "But I don't want to
| spend a whole day just setting up a project!" You
| wouldn't have to, if you didn't drink the React kool-aid
| in the first place.
| josteink wrote:
| > But for any sane developer having made the mistake to
| touch TypeScript, the capability to strip the types and run
| the code with broken types, is essential.
|
| You're free to hold that opinion, but I think you see
| (based on downvoting) that your definition of a "sane"
| developer is not as universal as you may have thought.
|
| Personally I almost never see any value in running known
| broken code.
|
| If I need to run/test a subset of my code without a
| complete working system, I have unit-tests for that
| purpose.
| kuramitropolis wrote:
| >your definition of a "sane" developer is not as
| universal as you may have thought
|
| Where I'm from, sanity has historically been the minority
| opinion, so we don't really have a word for this, but I
| think the English one is... "gaslighting"? "TS is a
| superset of JS", "there are 4/5 lights", "this line is
| longer/shorter", etc. (Look those up if you haven't,
| Microsoft marketers surely have.)
|
| What I'm saying is, I am well aware that I represent a
| minority, and guess what, getting downvoted (not nearly
| as much as expected) still beats keeping silent about the
| things that have been fucking with my head for the past,
| what, year and a half? Considering I've been writing Node
| for barely 6, the fact that every year the number of
| software developers doubles [cit needed] probably has a
| lot to do with it.
|
| No matter if we're talking about a very simple or a very
| complex system: if there are a lot of subtle
| inconsistencies in it, and you have to gradually learn
| your way around them, your ability to keep a consistent
| mental model of it in your head, and reason about what
| you're doing, will be impaired: _-1 sanity._
|
| Ironically this is the same as people's gripes about the
| original JS type system. IMHO `==` and `===` should've
| been the other way around, and 1000 ships wouldn't've
| been launched. This unwieldy choice of notation (implicit
| type coercion on `==`) made it just enough _subtly
| different_ for people expecting C-like strict equality,
| to create a feeling of confusion and distress.
|
| But since the underlying design principle was not
| clarified (in browsers all input comes from text boxes,
| as _strings_ , anyway; and the original "source of truth"
| was only the HTML file, where element attributes are also
| strings; so in some limited sense it makes sense to have
| convert-from-string by default), we get all these
| (generations of) people with the impression that JS is a
| "low sanity" language... and that it needs, of all
| possible features, _even more of a type system_.
|
| >Personally I almost never see any value in running known
| broken code.
|
| That's completely subjective. Personally, I don't know
| how to fix a piece of code without being able to see with
| my own eyes how/where/why it breaks, but surely that's
| just my deficiency and everyone else is just telepathic.
| Boo, shame on me! (I'm also the guy with the months-long
| pull request because guess what, TypeScript did _not_
| make it easier for me to see what I 'm doing wrong, just
| looped me into a waves of type refactors, sometimes
| causing me to break working code to get dat "spellcheck"
| out of everyone's faces. I do semver, but most libs on
| NPM don't ...)
|
| So, in my experience, TypeScript prevents me from running
| known good code way more often than it prevents me from
| running known/unknown broken code. As for what value you
| see in either, sure - that's a matter of style.
|
| Rust was mentioned elsewhere in the thread. It's great to
| work in a language where "compiles"="works". But TS is
| _not_ a static language, where types actually matter; it
| 's a restrictive "sanity checker" overlay on top of a
| dynamic language. And not one that's good enough for me
| to sacrifice the expressivity that JavaScript allows.
|
| Maybe it's good enough for many other people who never
| came to rely on JavaScript's flexibility that much in the
| first place. Thoughts and prayers to 'em. Each one has to
| make the choice which is the right tool for a job - and
| when there's an incipient monoculture trying to make that
| choice for me, I'm bound to make a ruckus.
|
| > If I need to run/test a subset of my code without a
| complete working system, I have unit-tests for that
| purpose.
|
| Amen to that! Thing is... you see how elsewhere in the
| thread, it's mentioned that people use TS annotations as
| an excuse not to write documentation? Well, in my purely
| anecdotal personal experience, they also use it for an
| excuse not to write unit tests! And considering what unit
| testing in JS looks like... well, no surprise there,
| either. "Ubiquitous JS" is supposed to be _accessible_.
| Instead, we have a number of onramps to it covered with
| rusty razor blades,
|
| TypeScript is not without its good parts, but overall my
| journey with it has been one of frustration and, as I'm
| sure you can see from miles a way, a whoooooole lot of
| mismatched expectations. Like, ESM working...
|
| Hence the exaggerations, and generally the lots of
| writing. I like JS/Node, I consider them _simple_ I 've
| been round the block just enough to see it evolve a bit,
| I gotta adapt to what others are doing (TS) because
| otherwise good luck getting help, right? So this is my
| honest perspective about that and I'm here to represent
| it because it's gotta amount to at least as much as the
| usual "nah bruh everything ok... u ok?"
| blackoil wrote:
| Considering how mature is the TS ecosystem, I see no reason to
| not use it for my personal projects.
| jmull wrote:
| You tend to have to write a bunch of code that mostly catches
| problems you don't have.
|
| Personally, I'm marginally on the side of using TS even for
| small 1-2 person projects, but only slightly, and I can
| understand the case not to.
|
| Well designed projects are no more complex than they need to
| be, and for many smaller projects that means -- at least for
| web ones -- that you have few significant "type barriers"
| where types are non-trivial and communicate or structure
| things in a way that is useful. And the type-heavy areas also
| tend to be where the app is ingesting data from a non-local
| source -- exactly where static type checking is useless.
| (It's always extra annoying when you're fighting the type
| checker when writing the code that _really_ ensures the data
| has a valid form.)
| twstdzppr wrote:
| It's a great language. I find it jarring to go back to regular
| JavaScript codebases after working in TypeScript for a bit now.
| an1sotropy wrote:
| sed s/vanilla/pure/g
|
| (my wish for what we call javascript itself)
| moomin wrote:
| The post mentions one of the most important factors in
| TypeScript's adoption: it launched, from the start, with good
| tooling.
| junon wrote:
| Which, frankly, has become an unwieldy mess over the years.
| solids wrote:
| Incremental adoption and syntax close to JS
| kuramitropolis wrote:
| >Incremental adoption
|
| i.e. "it stays out of your way if you don't actually try to
| use it"
| jbverschoor wrote:
| Microsoft always had great tooling
| kuramitropolis wrote:
| > great tooling
|
| "go to definition" -> goes to type definition
|
| Microsoft makes it intentionally impossible to get anything
| done in their ecosystem without having "great tooling".
| tester756 wrote:
| Lol? what's the reasoning behind this?
|
| Java does it too?
| pjmlp wrote:
| Mostly, not when the domain is COM, and WinDev uses it all
| over the place.
| matt89 wrote:
| In my opinion the most important factor was that it is a
| superset of JS and any valid Javascript code is/was valid TS
| code. That allowed for gradual adoption and you didn't have to
| risk going all-in into new technology.
| ly3xqhl8g9 wrote:
| Also the `any` type [1]. It makes porting an existing project
| ridiculously easy: just type everything as `any`, and it also
| gives freedom to the developer to think in code when
| developing, trusting that they (will) know what they are
| doing, instead of screaming at the smallest mis-type with
| annoying bright red squiggly lines.
|
| It is so liberating to type a variable as `any` when
| sketching new code, figuring things out, that I would venture
| to say that any language not having the `any` type actually
| actively hates the developer.
|
| [1] https://www.typescriptlang.org/docs/handbook/2/everyday-
| type...
| kuramitropolis wrote:
| And then you have to contribute to a codebase with
| restrictive ESLint (bleurgh!) configuration, so _you can 't
| even try out whether your code works because the tooling
| disallows you from compiling it_ as long as it contains
| "any", and the other devs are like "but muh best
| practices". So not only you gotta work around TS, you gotta
| do it _invisibly_. How did people even live before VSCode
| 's type hint popups covered up the previous line?
| wiseowise wrote:
| > How did people even live before VSCode's type hint
| popups covered up the previous line?
|
| Same. Like normal people do when they use Visual
| Studio/IntelliJ/QTCreator
| kuramitropolis wrote:
| I.e. cringing all the time?
| wiseowise wrote:
| Cringing at compile time safety or what?
| kuramitropolis wrote:
| No, cringing at some "helpful" popup appearing right over
| the _previous_ line of code. If anything, they could 've
| made it appear _under_ the current line; code 's still
| written top to bottom so it's less likely for "suggested
| relevant info" to obscure the actual relevant info.
| Tyriar wrote:
| You can press f8 to view the problem in a "peek view"
| under the problem line, or view on the problems panel.
| kuramitropolis wrote:
| > 10542667 Aug 9 20:40
| node_modules/typescript/lib/typescript.js
|
| aint fitting ten megs in a peek view... :(
| xodeus wrote:
| This comment has just triggered my PTSD from every
| Typescript project I've had to work on.
| kuramitropolis wrote:
| TS is emphatically _not_ a superset of JS. It rejects
| perfectly valid JS leaving you no recourse other than design
| your whole architecture around what TypeScript allows. Which
| is what Microsoft wants of course.
| uup wrote:
| That's not true. You can import JS directly into TS or use
| ts-ignore annotations.
| kuramitropolis wrote:
| Hahahahaha no.
|
| >You can import JS directly into TS
|
| Using FFI, you can also import all compiled languages
| into each other, _provided you provide the type
| annotations on the importing side_. Does that make them
| supersets of each other?
|
| >use ts-ignore annotations
|
| Which do not get propagated into the compiled .d.ts. So
| if you're trying to publish a library with TypeScript,
| you know, like this thing called "open source", and
| naively expect it to work like a normal NPM package does,
| you're in for a bad time. You'll probably end up using a
| frontend bundler to smash the whole thing into a CJS
| monolith like an absolute genius, in the process
| preventing "muh tree shaking" downstream.
| uup wrote:
| You can directly import any valid JS module using
| TypeScript if you have "allowJS": true in the compiler
| options of your tsconfig.json file. The comparison to FFI
| doesn't make any sense. FFI requires compiling a special
| library that explicitly exports the C types. This is
| different than TS. Using TS, you can import any valid JS
| module without any special preparation. Also, you can't
| import all compiled languages into each other using FFI.
| You can only import and export C-based types. There is no
| way to export a Go struct for consumption via FFI, for
| instance. All valid JS modules will work with TypeScript.
| kuramitropolis wrote:
| >There is no way to export a Go struct for consumption
| via FFI, for instance.
|
| I hope not.
|
| >Using TS, you can import any valid JS module without any
| special preparation
|
| Why does the DTS ecosystem exist then
| (https://www.npmjs.com/package/@types/node etc)
| uup wrote:
| d.ts files allow you to add types to imported JS. You're
| free to import raw JS as an any type and the compiler
| won't complain.
| throwaway0x7E6 wrote:
| that's maybe the second or the third most important factor. the
| first is aggressive marketing that microsoft does for its
| products.
| scarface74 wrote:
| That unfortunately hasn't helped C# become more popular
| outside of Microsoft legacy shops even when it did go cross
| platform and open source.
| christogreeff wrote:
| What is a "Microsoft legacy shop" ?
| xboxnolifes wrote:
| Businesses that profit money without VC funding.
| scarface74 wrote:
| Banks, insurance companies, government agencies,
| "enterprise development".
| LudwigNagasena wrote:
| So, 90% of the world GDP?
| scarface74 wrote:
| Yes
|
| In the US though, compensation for software developers is
| very bi-modal. You have the "enterprise shops" that start
| off around $80K and max out in the mid $100s and the
| "tech companies" that start out in the mid $100s and end
| up in the $350K+ range.
|
| Most of the 2.7 million developers in the US are on the
| "enterprise dev" side. If you have a choice, you want to
| be on the "tech company" side if you care about your
| compensation.
|
| For context: because of path dependencies and bad career
| choices, I spent most of my career from 1996 - 2020 on
| the "enterprise dev" side and only got into $BigTech by
| pivoting to cloud consulting (enterprise dev + cloud + a
| shit ton of yaml/HCL PowerPoint slides and diagrams)
|
| Before anyone "well actually"'s me with numbers they are
| directionally correct on the enterprise dev side in most
| major cities.
| [deleted]
| iLoveOncall wrote:
| Well the fact that it was available solely on Windows for
| so long was its doom.
|
| Actually I thought of using C# a few months ago, and I was
| like "Oh wait, does it even work on other platforms than
| Windows now?". Sure I'm not a C# developer, so I'm not up
| to date on C# news, but that's an issue if your goal is to
| drive adoption. Everyone that has heard of C# should know
| that it's now cross-platform.
| cesarb wrote:
| Some things still seem to be Windows specific. If I want
| offline documentation (of the sort one can find at
| /usr/share/javadoc/java or /usr/share/doc/rust/html by
| installing the correct packages), every place I look tell
| me how to enable offline help in Visual Studio (for
| instance, https://learn.microsoft.com/en-
| us/teamblog/offline-book-refr...). Someone here told me
| last time that there's a way to download whole sections
| of the MSDN documentation as PDF, which helps, but it's
| not the same thing.
| Kwpolska wrote:
| Off-line documentation being kind of a pain sounds like a
| very minor thing.
|
| Other than that, and other than the obviously Windows-
| specific GUI and system management libraries, the rest of
| C#/.NET is pretty much fully multi-platform, maybe except
| a few obscure things.
| ido wrote:
| C# is extremely popular, maybe just not in your particular
| field.
| scarface74 wrote:
| "My field" is a 20+ year MS ecosystem developer from
| C++/MFC, VB6, .Net Compact framework, .Net Framework,
| .Net Core, etc.
|
| As I said, very few new companies that aren't "legacy"
| shops are choosing .Net.
|
| In my current job in cloud consulting at $BigTech, almost
| all of the .Net projects that come through are older
| companies compared to newer companies that are using non
| compiled languages.
|
| These days I write in almost any language they prefer
| among the popular languages.
| keewee7 wrote:
| C# and ASP.NET Core feels like the default stack in Western
| Europe, even among startups. You have to look harder to
| find companies using Node.js, Rails, Django etc.
| scarface74 wrote:
| See my previous post about the bimodal nature of tech
| salaries in the US.
|
| https://news.ycombinator.com/item?id=33140210
|
| The "startups" in the US are even bimodal. You have the
| ones that set up shop outside of the west coast in big
| cities that hire "enterprise devs" and you have the well
| funded ones that try to compete with big tech salary
| compensation.
| trinovantes wrote:
| It's used in Unity game development
|
| I think Godot also supports it
| fabian2k wrote:
| I tried using Flow at some point when TypeScript was much newer
| and wasn't the obvious choice for typed Javascript yet. I
| couldn't get it to work properly. I probably could have with
| more effort, but I didn't feel like I would be able to keep it
| running well and debug issues if they would arise.
___________________________________________________________________
(page generated 2022-10-09 23:01 UTC)