[HN Gopher] How an Anti-TypeScript "JavaScript developer" like m...
___________________________________________________________________
How an Anti-TypeScript "JavaScript developer" like me became a
TypeScript fan
Author : chiragswadia
Score : 143 points
Date : 2021-03-02 12:52 UTC (10 hours ago)
(HTM) web link (chiragswadia.medium.com)
(TXT) w3m dump (chiragswadia.medium.com)
| h1fra wrote:
| Currently maintaining a very large codebase in TS, and never
| going back to vanilla. The initial migration found hundreds of
| bugs, typos, imperfections. And now every refacto, bugfix, new
| features... can be trusted.
|
| More than that, when you use JS in the back and the front, your
| types can follow from the database, to the api, to react... even
| to your integration tests or your public SDK.
|
| Add one more column in your DB and suddenly 1000 errors pops, but
| those are good errors, you just have to follow them until nothing
| scream and you have done a perfect migration. It can feels
| negative at first but it is actually very pleasant and
| reassuring, like having an angel watching over your code.
| madeofpalk wrote:
| It's probably worth taking a step back and interrogating why the
| actual "Why was I Anti-TypeScript?" a little bit more and use it
| as an opportunity for broader self development.
|
| The author didn't use and understand something, and rather than
| trying to they instead just defaulted to rejection. It's midly
| disapointing seeing this in people who label themselves as
| "Senior".
| junon wrote:
| As a "senior" I'm still not sold. Running across bugs in the
| type checking that blocked us for a while (trying to avoid
| Broken Windows to boot) and the fact our development times
| skyrocketed (including on personal projects) or that the answer
| to poor tooling was "just use VSCode" is not something that
| really screams "developer friendly".
| fladrif wrote:
| Sure, like all systems, there are overhead costs involved.
| But with something like a typed system, the overhead costs
| are minimal compared to the benefits you reap from them.
|
| One of the projects I worked on during my transition to
| typescript was to convert an existing project into it. Sure
| there was a lot of head banging against walls at some point
| to get the types to work out, but during that process I
| finally really understood how everything fit together and
| gained a sense of assurance that I could use a return of a
| function with complete confidence. Developing on that project
| afterwards was also a breeze, moving faster and more
| confidently knowing that the object types were set, and that
| guardrails were in place to prevent myself from shooting my
| own foot.
|
| It's a new system to work within the guidelines of, but
| guardrails are there for a reason, to prevent you from
| falling off a cliff.
| zackees wrote:
| You are either going to catch the bugs in the type checker
| or you are going to have to write unit tests to catch them.
|
| For me, typed python saves me a bunch of time.
| baybal2 wrote:
| Yes, type checking do not require a new language.
| watwut wrote:
| Senior does not mean "all around great zen person". It means an
| experienced person.
|
| Seniors occasionally rejecting this or that, seniors
| occasionally blindly accepting this or that are both completely
| normal in majority of seniors.
| Zelphyr wrote:
| I'd consider myself senior. I've been using Javascript since it
| was beta. I like Javascript. I don't mind TypeScript. I mean,
| it's nice and all but it doesn't strike me as the be-all that
| others make it out to be. Maybe I just don't use it for the
| types of project for which it was designed.
|
| It's like I'm a metal worker and I get along fine with a ball
| peen hammer. You come along and give me your claw hammer with
| great excitement. Sure, it can mostly do the same job, but my
| ball peen hammer is what I'm used to so I'm sticking with it.
| myguysi wrote:
| I understand the sentiment, but a better comparison would be
| if your tool of choice had to be shared between everyone on
| your team.
| ysavir wrote:
| Would that imply that the GP needs to reconsider their
| willingness to use TypeScript, or is it just a friendly
| reminder that there is utility in finding teams with shared
| values?
| irrational wrote:
| Senior probably means they've been doing JS for decades before
| TS was invented. They got along just fine without it for so
| many years, why rock the boat now? Or maybe it is more of a
| Senior person has a ton of work to do and not enough time to do
| it in so there isn't time left to learn a whole new way of
| writing JS. Or maybe many of the errors TS is meant to catch,
| the Senior developer has already learned over the decades not
| to do that bad thing, so they don't see the need to adopt TS.
| Or maybe they are just jaded and tired of learning new things.
| baron816 wrote:
| > Senior probably means they've been doing JS for decades
| before TS was invented.
|
| JS has only been around for 25 years. I'm a "Senior person"
| and I've been seriously working with JS for less than 5
| years.
| irrational wrote:
| Well, I'm Senior too and I've been working with JS for
| 23-24 years. So I guess I'm projecting my own experience.
| madeofpalk wrote:
| I cannot wait to be the type of developer who just never
| makes typos.
| irrational wrote:
| Your IDE should be catching any typos. But it's not about
| typos, it's about understanding the quirky nature of JS and
| knowing what things not to do. For instance, an
| inexperienced developer might try to use .sort() to sort an
| array of numbers. It wouldn't even occur to an experienced
| developer to try that since they know from vast past
| experience that it won't work (or, at least, won't do what
| the inexperience developer is thinking it might do).
| j-krieger wrote:
| Why not use something if you have an added benefit? It's like
| writing code in ,,ed" just because it worked for decades
| kyranjamie wrote:
| Agreed, though at least there's one less developer writing
| about the "TypeScript Tax".
| uh_uh wrote:
| I am a TypeScript fan but I do acknowledge the existence of
| the tax. TS is another cog in the machine that does useful
| work but can sometimes confusingly interact with other cogs
| (e.g. miles long unreadable TS errors coming out of React).
| Using or not using TS is not a trivial decision to me and
| should be made with consideration to the complexity of your
| stack.
| zodiakzz wrote:
| Can relate about illegible React stack traces in production
| builds. One of the reasons in my case was Create-React-App
| obfuscating ES6 class names, which is just insane! Just
| why???! Why throw all code structure away just to save a
| couple KBs. The worst part is CRA folks acting like
| dictators when asked to provide an option to toggle that:
| "Why in heavens earth would you need that?". "You can fork
| our 30K+ line repo [just to toggle minification] if you
| want".
|
| Sorry for the off topic rant!
|
| P.S: Yes I know source maps exist. They suck/aren't
| reliable.
| j-krieger wrote:
| You could also use customize-cra and skip on
| minifications in about 10 lines of code
| Cthulhu_ wrote:
| I don't believe whether or not using TS has to do with the
| rest of your stack, but more about data consistency and the
| like.
|
| I for one am building a large CRUD application with dozens
| of models spanning hundreds of fields, and Typescript is
| helping me (though not a panacea) keeping things correct.
|
| I'm comparing it to a project I did years ago, first
| Backbone, then Angular, but both before 'typesave JS' was a
| thing, and that one relied heavily on reading and comparing
| keys and a deep knowledge of the domain.
|
| But nearly ten years later, I don't have the mental
| capacity for that anymore and I need the crutches that
| typed languages offer me. By crutches I mean securities,
| safeguards and IDE assistance.
|
| It makes sense for anything nontrivial IMO. Types allow you
| to be able to free up mental space. You can trust the type
| checker instead of having to rely on your own abilities.
| [deleted]
| nickysielicki wrote:
| I think that he is presenting his prior attitude towards
| typescript a certain way for dramatic effect / so that it was
| easier to write a blog post about it. In reality he probably
| was not as skeptical as he sounds here -- otherwise we wouldn't
| be reading an article by him about how great typescript is.
| lhorie wrote:
| Ironically, as someone who has experience w/ both fast-and-
| loose JS and with "properly" statically typed languages, my
| beef with typescript is precisely that it allows people to be
| fast and loose, sometimes in ways that are not super obvious.
| For example: type Thing = { name:
| string, }; function getThing(): Thing {
| return JSON.parse('{"error": "invalid id"}') }
| const thing: Thing = getThing(); // lie to me!
| console.log(thing.name);
|
| This is a trivial example to illustrate the idea that it's
| relatively easy to make a type that cascades through a very
| large app but which is backed by a complete lie.
|
| I definitely think that there's also something to be said about
| meta-programming yak shaving (e.g. people wasting hours trying
| to write a "function" that takes an enum and outputs another
| enum w/ a fixed prefix, when simply writing out the enums
| would've taken 30 seconds w/ VSCode's multiple cursor feature)
|
| Personally, the value I see in TS is in cementing documentable
| facts about a system: e.g. such and such function takes such
| and such well-defined entity, dot not treat this `options`
| argument as a generic bucket for pass-through garbage.
| Orphis wrote:
| To me, the solution is simple: use a single source (some IDL
| format) to define objects at API boundaries and have your
| frontend and backend use it.
|
| It will make it a lot harder to return wrong types from your
| calls. Personally, I like gRPC + Protobuf.
| kipple wrote:
| This particular example is close to my heart: the definition
| files for things like JSON.parse() were written before the
| "unknown" type was introduced as an alternative to "any"
|
| And because this "any" is coming from an external definition
| file, it can't be caught by tsc's --noImplicitAny nor
| eslint's no-explicit-any
|
| Those two rules allow us to protect us from our own code, but
| not external definitions/libraries. Relevant GitHub issue
| here -- https://github.com/microsoft/TypeScript/issues/26188
| kipple wrote:
| Looks like eslint is working on a new set of rules that
| would help with these currently-unprotected any cases:
| https://github.com/typescript-eslint/typescript-
| eslint/issue...
|
| _> Create a rule which uses type information to determine
| when you 're inadvertently breaking type safety by using an
| any, potentially without knowing._
|
| _> Often libraries (or even the typescript defs
| themselves) can have weak( /lazy) types which return any.
| If you're not careful, you can inadvertently introduce anys
| within your codebase, leading to bugs that aren't caught by
| the compiler._
| evmar wrote:
| It's worth noting that this (good) example is unrelated to
| unsoundness, too -- it's related to built-in APIs using
| 'any'.
|
| Within Google we include a "strict" d.ts in every compilation
| that shadows this API (and one other) with one that instead
| returns "unknown". We have talked about going through the
| whole TS API and removing all the 'any' in this manner for
| this reason.
| joshAg wrote:
| That's a great idea! What's the other built-in that you
| shadow?
| evmar wrote:
| The definition of `new Map`:
|
| https://www.typescriptlang.org/play?#code/FDDGHsDsGcBcAJr
| wLz...
|
| (I still think this is actually due to bug in TypeScript,
| see https://github.com/microsoft/TypeScript/issues/31990
| .)
| _fullpint wrote:
| Check out io-ts -- it can take a minute if you're not
| familiar with functional programming, it's built on top of
| fp-ts.
|
| Being able to encode/decode IO safely has been a huge
| blessing when working with JSON.
| chadlavi wrote:
| Sure, but you also should never just blindly trust a
| JSON.parse, and if possible you should avoid typing functions
| for exactly this reason, and let their return types be
| implied instead. If you didn't type `getThing` then its
| return type would be `any` and you'd get an error in your IDE
| on the last line.
| uryga wrote:
| sorry but i feel like this is backwards. the error -
| incorrectly assuming an `any` will be a `Thing` - is in
| `getThing`, and that's where the error message should be.
| getting an error in code that calls `getThing` instead
| would just obscure the real issue.
|
| also, i think "avoid typing functions [...] and let their
| return types be implied" is terrible advice. argument and
| return types are _the_ thing you should type explicitly,
| because it makes the errors local. otherwise you 'll get
| all the fun of tracking down where that `null has no
| property "blah"` error came from, just at compile time
| jehlakj wrote:
| If you have to rely on restrictively typed languages to
| produce maintainable code, I think that's a different topic.
|
| Typescript isn't perfect by any means but it does a good job
| keeping code based easier to work with in a larger team. Much
| better than vanilla JavaScript
| damagednoob wrote:
| This is an argument against strongly typed languages, not
| Typescript. You could do a similar thing in Java and C#.
|
| I don't know of any language that can stop someone from being
| a sloppy coder.
| qw3rty01 wrote:
| It's actually the opposite. This would throw an exception
| in a strongly typed language. It would silently return the
| wrong thing in javascript because it's not strongly typed.
| damagednoob wrote:
| The point of the argument is catching errors at compile-
| time. Typescript doesn't make (and can't make) any
| guarantees at runtime.
| lhorie wrote:
| In case it wasn't clear, that example compiles without
| error, whereas a more strict compiler would complain that
| a any is not a Thing, or some similar error.
|
| The code doesn't even throw runtime errors, but you
| wouldn't be able to tell something is wrong unless a) a
| request providing the json string actually responded with
| the error string in the example (an edge case that is
| very easy to overlook during regular development) and you
| managed to catch the problem in tests, or b) you
| specifically went digging into the file that defines
| getThing looking for the implicit any cast that the
| compiler didn't tell you about or c) there's a compiler
| update that turns that any cast into an error
|
| What others are saying is that Java and friends do c)
| (throw compilation errors when implicitly casting between
| incompatible types)
| xxpor wrote:
| Java would absolutely stop you from returning a JSON object
| when you're supposed to return a Thing. You could cast it
| but you'd still get a ClassCastException. Now I haven't
| written JS or TS, so maybe I'm not understanding what
| you're saying?
| damagednoob wrote:
| Just like Generics in Java, Typescript only exists at
| compile time. Talking about what Typescript doesn't do at
| runtime is moot.
| ufmace wrote:
| No, those languages actually enforce type checking at
| runtime. The libraries for parsing JS that support parsing
| into a custom type will blow up right there if the provided
| JSON cannot be parsed into the provided class, not 5 steps
| later when you try to use something from that class that
| isn't actually there.
| damagednoob wrote:
| Typescript doesn't exist at runtime.
| pattrn wrote:
| This is the one thing that bothers me about TypeScript as
| well. I've ended up using frameworks like `zod` to do runtime
| type checking of endpoints. It has gone a long way towards
| decreasing edge case failures -- I just wish they had
| something like this built into the language.
| gherkinnn wrote:
| Not doing runtime checks is a deliberate decision:
| https://github.com/Microsoft/TypeScript/wiki/TypeScript-
| Desi...
|
| So Zod it is. I like it.
| joshAg wrote:
| If you're not using a bunch of generics, check out
| typescript-is [1]. It takes little work to get it setup, but
| it generates run time type checks for you. I understand why
| typescript decided to not add this functionality to the core
| of the language, but it's starting to feel like the largest
| missing piece of typescript is a built-in way to generate
| run-time type-checks for user-defined types from just the
| type definition.
|
| The happy medium we've found with that module is using the
| runtime type-check on anything "unsafe" to bless the result
| using typescript-is's equals functionality, but still
| allowing programmers to use casting with a comment justifying
| its necessity. For us our list of unsafe is results pulled
| from the db, anything parsed from JSON, and incoming request
| bodies (which can be a special case of parsing from JSON, but
| not always).
|
| [1]: https://github.com/woutervh-/typescript-is
| Shacklz wrote:
| Doing runtime-typechecks really is a blessing, and it would
| be great if typescript would provide this as a language-
| feature. There are two more libraries I know which are
| great for that:
|
| * Zod: https://github.com/colinhacks/zod * io-ts:
| https://github.com/gcanti/io-ts (for the more functional-
| programming-oriented)
| joshAg wrote:
| We decided against io-ts because we'd still have to write
| the validator ourself (unless we used their type system
| as the source of truth, which wouldn't easily work for
| our project because we generate most of our types from an
| openAPI schema), which is exactly what we wanted to avoid
| doing.
|
| I hadn't heard of Zod before, but i really liked the
| "parse don't validate" blog post linked. Turns out that's
| exactly how we've been using typescript-is. But it still
| suffers from the problem of expecting to be the source of
| truth and thus not working well with generated types.
| madeofpalk wrote:
| The "curse" of Typescript is that it's built on Javascript,
| so you can tell it to lie to you all the time. This is the
| problem with introducing Typescript to a larger group of
| _Javascript_ developers who arent all on board (because of
| either experience or being stubborn) - you still need to
| establish good habits and patterns for how to write
| typescript.
|
| I'm working through the very lie you're showing now because
| the disclipline wasnt established from the start to avoid
| these anti-patterns. Typescript isnt the perfect magic bullet
| that will disappear all your problems - you still need to
| have good developers writing good code, but TS will make it
| easier.
| dnautics wrote:
| In the large this curse is true for everything. The
| difference between 8 u8s and an f64 is thin for all
| architectures I can think of.
| lhorie wrote:
| > you still need to have good developers writing good code,
| but TS will make it easier
|
| Very true. Typescript is still immensely helpful in the
| sense that it will complain if you pass a Thing to a
| function expecting a Foo, regardless of the fact that Thing
| is meant to be a thing but is actually an error.
|
| But IMHO, by sticking to a decision to be lean in terms of
| transpiled JS, TS suffers greatly from cases like the one I
| showed. It would be great if the compiler enforced that
| these types of unsafe casts had to be explicitly specified
| (even if via some strictness flag), and even better if it
| could do a better job at refining types through runtime
| constructs like `if (typeof thing.name == 'string')` (it
| does do it to some limited extent, but not enough to cover
| many common scenarios, due to the curse of targeting
| Javascript, as you mentioned)
| WorldMaker wrote:
| You can easily write your own "type guard functions" when
| you think TS is missing an inference from a runtime check
| you would like. The syntax is simple enough, it's just a
| slightly different return type from boolean:
| function isThing(value: unknown): value is Thing {
| return typeof value === 'object' && typeof value.name ===
| 'string' }
|
| The `unknown` type in general is still pretty new, but
| will be greatly helpful for cleaning up a lot of code
| that assumes a type or used to use `any` or `{}` because
| there wasn't a better type to use in that situation. The
| Typescript team is hesitant to change the last few cases
| of `any` in lib.d.ts to `unknown` directly (such as
| `JSON.parse`) because that would be a big compatibility
| breaking bug. There was a proposal for a flag to do that
| (treat `any` as `unknown` in lib.d.ts), but I'm not
| currently aware of whatever happened to that idea. I
| would love to see it or something like it happen.
| prophesi wrote:
| Just a quick tip that helped my team with such issues:
|
| - For every call to an API, or input from the user, there
| should be a few tests checking for unexpected data
|
| This rule alone forces us to fix the majority of runtime
| errors such as this example (since JSON.parse() is usually
| called when handling an API response)
| kelnos wrote:
| Wait... so I assume `JSON.parse()` returns `any`, yeah? TS
| automatically downcasts (in function returns and assignment)?
| How is that at all useful?
| ben509 wrote:
| > (e.g. people wasting hours trying to write a "function"
| that takes an enum and outputs another enum w/ a fixed
| prefix...
|
| Metaprogramming shouldn't suck so much that this takes hours.
| adverbly wrote:
| You're not wrong. That's a good example of why someone might
| have beef with typescript. But as others have been saying,
| tooling enabling faster dev is one of the main reasons people
| use typescript. Safety comes second for most folks. And the
| tooling works just fine in that example.
| fendy3002 wrote:
| Senior here. I was afraid if typescript will follow C# or
| Java's type checking. Both are too strict, verbose and
| inflexible.
|
| I was afraid to introduce complex generic types because it
| isn't easily represented in typescript, or to change a struct
| from "person" to "employee" will need to map each properties
| individually.
|
| Thankfully that wasn't the case.
| mekoka wrote:
| I find your interpretation and subsequent extrapolation on his
| qualification as senior unfair. He clearly tried TS and was
| frustrated by his initial experience, because there were
| certain things he had a hard time understanding or justifying.
| There's no opportunity for broader self development here. I try
| stuff out and I scratch my head, should I risk sticking with it
| or should I move on. It's a gamble. Others have made the
| alternative bet with a different tech du jour and lost. So your
| results may vary.
| cosmotic wrote:
| I think the skepticism of new shiny things is healthy. Of the
| set of things that exist, most things are worse than the things
| one already uses/prefers. Most new things solve a specific
| problem that may not overlap with the problems one is trying to
| solve. With software development, a huge part of the puzzle is
| tooling (as the article points out), so even if typescript is
| obviously superior as a language, the tooling needs to catch up
| before it's a reasonable/useful alternative. In this case, the
| tooling quality, enabled by the static typing, shot typescript
| way past the thing it was replacing.
| nickysielicki wrote:
| Strong typing is not shiny or new and, even if you're a
| javascript guy, not being remotely familiar with any
| strongly-typed language (or generics?!) is a red flag.
|
| (edit: red flag is a bad description, because he ended up
| being self-reflective and looking deeper, which is just about
| the furthest thing from a red flag.)
| ben509 wrote:
| > red flag is a bad description, because he ended up being
| self-reflective and looking deeper
|
| No, red flag is fair since it's just a warning sign. Even
| if we take it as a mark on the guy, it's true that he ought
| to get outside the scripty bubble.
| mywittyname wrote:
| Agreed. But some people have an attitude of Strongly Typed
| == Needlessly Verbose. Probably because most developers
| have only experienced Strong Typing via Java.
| vbsteven wrote:
| This, and usually Java from 10-15 years ago before the
| `var` keyword and diamond operator.
| dandersh wrote:
| I definitely fell in this camp. To be fair I was fairly
| junior and was used to JS.
|
| It wasn't until I started using Haskell that I saw the
| benefits of knowing exactly what I was working with. It
| also helped me be more deliberate and thoughtful as you
| had to define everything up front.
| capableweb wrote:
| I'm in neither camps (I don't have anything against types
| in places but I also don't try to put them everywhere).
| Could you explain how TypeScripts types would be
| more/less verbose than the types from Java? At a glance,
| TypeScript looks a bit more flexible, but mostly the
| same.
|
| Then Java is a verbose language in general (forced
| directory structure, one-class-per-file and yadda yadda)
| but that's besides the point as you're pointing to
| TypeScripts types being less verbose than Javas.
| lalaithion wrote:
| 1) TypeScript has local type inference, meaning that `let
| x = returnsComplicatedThing();` will work, where in Java
| it would be `Complicated<Generic<Type>> x =
| returnsComplicatedThing();`. (At least up until the last
| few years)
|
| 2) TypeScript has type aliases, meaning you can write
| `type MyTable = List<Map<string, number | string | Foo>>`
| and not have to repeat yourself everywhere.
|
| 3) TypeScript has anonymous unions and tuples, so instead
| of writing `Triple<Integer, String, Foo>` you can just
| write `[number, string, Foo]`, and likewise instead of
| `OneOf<Integer, String, Foo>` you can write `number |
| string | Foo`. These are also built in and very
| ergonomic, so you don't have to write a OneOf4 class
| whenever you want to have one of 4 things, and you don't
| have to write helper methods to convert between different
| sized OneOfs.
| crocarneiro wrote:
| Don't know about the other two, but the first one is
| available in java 10 and later.
| mgkimsal wrote:
| Worked on a project with an old (12+ years?) - but still
| being developed/used - Java system. Just last year a move
| was made up to Java 11 (from 8). Decent test coverage,
| but moving multiple systems is still a big task, but...
| they did it. Java 11. Yay.
|
| But... teammates were running in to issues with 'new'
| stuff - like, using 'var'. There were others, but this
| was sort of the archetypal argument. "Well, it doesn't
| match the rest of the style of the file/app - it'll make
| it hard to read". Well... hrm... any new feature
| literally doesn't match the style of what came before it,
| because you have new keywords/features/syntax to handle
| processes a new way. It's definitional. But just because
| there's a new feature doesn't mean it'll be adopted (for
| better or worse, I supposed, depending on your stance).
| Quekid5 wrote:
| Java-the-language/JVM has picked up pace hugely in the
| last few years, but Java-the-ecosystem tends to lag quite
| severely. Not least because these systems tend to be
| entrenched systems that move quite a lot of money
| around... or are highly business critical in some other
| way. This leads to extreme conservatism wrt. upgrades,
| etc.
|
| (That part has also gotten better, but especially the
| Java 8 -> anything later upgrade has been extremely
| painful because of modularization. Past Java 9 it usually
| isn't that much of an issue. However, JDK 11 was the
| first LTS release after 8, so most shops basically
| delayed the transition until JDK 11.)
| [deleted]
| mixmastamyk wrote:
| This BS made me want to tear my hair out:
| VerboseTypeName foo = new VerboseTypeName();
| madeofpalk wrote:
| The author actively describes themselves as being "Anti-
| Typescript" and "hating" something they have no experience
| with. That's not skepticism.
| victorbojica wrote:
| Being skeptical shouldn't mean being ignorant. Being
| skeptical should mean Trying to understand the pros and cons
| and believing it's not worth it.
| Vinnl wrote:
| Or alternatively waiting it out a bit until it's more
| obvious what the pros and cons are (because others have
| tried it out in depth and shared their experience). Still a
| far cry from actively dismissing it.
| ozim wrote:
| I think moment when I really could call myself "senior
| developer" came when I realized annoying things I was
| struggling with are not stupid, it is just that I don't
| understand them very well.
| ben509 wrote:
| My senior moment came when we were talking about graphics and
| I mentioned some various things and CGA. My coworkers let me
| ramble a bit and then one politely asked what CGA was.
| airza wrote:
| The heuristic of "new JS tech is just needless complexity/over-
| engineering" is not a bad one to have in the JS ecosystem imo
| :)
| j-krieger wrote:
| Heuristics shouldn't really be a factor when you are a
| senior. Make a decision based on your competence and
| experience.
| blacktriangle wrote:
| That's my personal heuristic and why I continue to reject TS
| just like I avoided coffee script, flow, clojurescript, and
| so on.
|
| But this article reads like "Developer who only used dynamic
| typing learns about static types." You could sub in any two
| such languages and get the same article.
| smnplk wrote:
| One of the things you listed is not like the others. Why
| didn't you give Clojurescript a chance. It's like being in
| Hell and then someone brings you infinite amounts of cold
| fiji water. Hell becomes more bearable ;)
| blacktriangle wrote:
| Clojurescript is the worst offender on that list from the
| point of view of "needlessly complicated." I can't
| imagine a dependency I want less than the Google Closure
| tools. I swear Closure is probably the only tool with
| fewer devs who understand it than autoconf.
|
| I'm not critiquing any of those languages, in a perfect
| world any of them in the browser would have been
| preferable to Javascript. The issue is the tower of
| dependancies we are building, and you have to stop
| somewhere.
| madeofpalk wrote:
| Typescript is hardly "new", it's fairly widely accepted now.
| It might be worth thinking "why do all these people enjoy
| using Typescript?".
|
| or idk just say that no, its the kids that are wrong.
| baybal2 wrote:
| Typescript is _not_ accepted. How AngularJS stuck on 1.* is
| the best proof, and an illustration for the problem. Pretty
| serious people are working in Angular community, it 's
| immensely popular in the enterprise webapp space, so I will
| not take the "Ah, it's just amateurs who are stuck there."
|
| It adds to countless attempts of other transpiled *scripts
| to extend Javascript.
|
| They, and Coffeescript in particular, are good historical
| references to what will happen to TS in a few years.
| striking wrote:
| I'd really like to hear what alternatives you have in
| mind for code in the JavaScript family that needs to have
| types. At my workplace, types are an important part of
| our workflow.
|
| We've been using Flow as a type checker but are
| converting our code to TypeScript for the tooling,
| ecosystem, support, and hopefully improved performance.
|
| TS has been running as a project for quite a while and a
| whole lot of folks have a stake in it. I think it's a
| pretty good bet.
|
| Additionally, I was there when Angular 2 was announced,
| and the community had no idea what to do or when it was
| coming out and didn't know whether to dig their heels in
| and stay on 1 or what the migration path to 2 would look
| like. I think that's a slightly different story given the
| context.
| servercobra wrote:
| I don't recall most major projects shipping with support
| for Coffeescript. Looking at my projects, the amount of
| "@types/*" I have are pretty small compared to a year or
| two ago because most projects ship types directly in
| their package now. Personally, I think it's here to stay.
| arcturus17 wrote:
| About 95% of React components I see in the wild are in
| TypeScript. The most rapidly growing JS backend framework
| (Nest) is in TS. Deno, the evolution of Node, is based on
| TS. Pretty much everything in the JavaScript OSS world
| has TS options or is based on TS.
|
| I doubt Coffeescript ever saw this scale of adoption.
| pjmlp wrote:
| We only use TypeScript on frameworks that make it a
| requirement, the language is starting to look like
| Haskell.
|
| As much as I like Anders work, it is impossible to
| understand modern TypeScript without looking into
| tsconfig.json before looking into source code.
| madeofpalk wrote:
| This does not align with my experience of writing
| Typescript at multiple companies of varying sizes and
| open source projects.
| pjmlp wrote:
| Lucky you for not having devs that would rather be using
| Haskell Lens and stuff like that.
| zaccusl wrote:
| I don't understand what the tsconfig has to do with
| understanding the source? Maybe when using different path
| resolving or different tsconfigs to compile test files
| vs. production files?
|
| Many toolings make it so you don't even need to worry
| about the tsconfig anymore (though in reality it is very
| helpful to understand it).
| pjmlp wrote:
| To avoid breaking existing source bases, many features or
| corrections across the language versions are opt-in, so
| in some projects it looks like GHC feature pragmas.
| [deleted]
| shakow wrote:
| > Coffeescript in particular, are good historical
| references to what will happen to TS in a few years.
|
| The thing is that many good ideas of Coffee ended up
| being integrated in newer versions of JS, so of course
| the need for it decreased; one could argue that Coffee's
| legacy lives in ES201x.
|
| But there are no types in JS, and none planned.
| WorldMaker wrote:
| Yeah, it would be great if TC39 made type hints
| syntactically valid but semantically ignored (ala
| Python's PEPs to that effect) so that type erasure was no
| longer needed as a "build step", but so far TC39 is still
| hugely aware of the controversies surrounding ES4 (the
| "lost" version of JS) and still very hesitant to do
| anything type related in JS.
| naavis wrote:
| Looking at GitHub statistics, I would dare say TypeScript
| is pretty accepted:
| https://madnight.github.io/githut/#/pull_requests/2020/4
|
| Out of all pull requests on GitHub in Q4/2020, 18.8% were
| JavaScript and 6.7% were TypeScript.
|
| For reference CoffeeScript was at 0.25%. At its peak in
| 2014 it was at around 1.5%, when plain JavaScript was at
| over 20%.
| jogjayr wrote:
| I wrote AngularJS 1.x in TypeScript in an enterprise
| application. Being "stuck there" ("there" meaning pure JS
| for Angular 1.x) is a choice.
| acemarke wrote:
| I took over a legacy AngularJS 1.x MEAN app early last
| year. One of the first things I did was to convert it
| from using Gulp to building the client with Create-React-
| App's build tooling:
|
| https://blog.isquaredsoftware.com/2020/03/codebase-
| conversio...
|
| That unlocked the ability to add React and TypeScript
| code embedded directly in the existing AngularJS UI,
| using the `react2angular` library, as a short-term
| migration approach. I was also able to migrate some of
| our existing AngularJS controllers and client logic to TS
| to get a bit more safety.
|
| Since then, I've set up a new Next.js subproject that
| sits behind the existing Express app server, and was able
| to show content from Next by inserting iframes into the
| AngularJS templates and proxying those URLs from the
| Express app to the Next app. That's let us build new
| features from scratch inside of the Next codebase while
| showing them seamlessly in the AngularJS UI, giving us a
| long-term migration path.
| cableshaft wrote:
| I'll second that. We used AngularJS 1.x with TypeScript
| in an enterprise application.
| airza wrote:
| I myself am quite fond of it actually! I was initially
| suspicious of Node at first and of TS as well, but like the
| author, I eventually gave it a try and liked it a lot.
| (Probably after many of the pain points had been worked
| out!)
| gameswithgo wrote:
| All the kids enjoyed using Javascript too. Language
| popularity is a bit of a random walk.
| ForHackernews wrote:
| I mean, Coffeescript was fairly widely used at its peak,
| and now it's all but dead.
|
| Front-end fads are fickle. At least TypeScript has
| Microsoft backing it so they'll likely continue to support
| even if the rest of the webdev world moves on to the next
| shiny object.
| scrollaway wrote:
| I don't think I've ever heard of any in-production, large
| apps in Coffeescript, even from when it was at its peak.
| I know of a handful of companies that tried it and even
| enjoyed it quite a bit but none of it was for mass
| consumption.
|
| Typescript, meanwhile, is used for hugely popular apps,
| is used by very large companies, has Microsoft's full
| backing, etc.
|
| The two are not comparable.
|
| Edit: Clearly I'm misremembering its popularity.
| akavi wrote:
| PagerDuty's front end was 100% coffeescript until at
| least 2016
| ForHackernews wrote:
| At one time, Dropbox and Github were all-in on
| Coffeescript e.g. https://web.archive.org/web/20130815075
| 924/https://github.co...
| ChrisLTD wrote:
| Wasn't CoffeeScript the preferred way to write JS in Ruby
| on Rails for years?
| nullserver wrote:
| HAML and coffeescript.
| aendruk wrote:
| I miss the elegance of Haml. Moving from an indented
| syntax for DOM literals to the likes of JSX felt like a
| step backwards.
| scrose wrote:
| I think the Rails resource generators still default to
| creating Coffeescript files. I could be wrong though -- I
| switch between Rails 4,5 and 6 projects right now. I've
| been on over a dozen Rails projects at different
| companies and only ever worked one project that used
| Coffeescript in production, and that was an app built
| pre-2010.
| jitl wrote:
| A significant portion of Airbnb was written in
| Coffeescript, including most of the complex app-like
| stuff used by hosts to manage listings and calendars.
|
| We ported off of Coffeescript when ES6 and Babel came
| out, and you could start writing `class` and using `() =>
| {...}` function expressions with lexical `this` scoping.
|
| Coffeescript lost because it stood still next to the
| ecosystem and next to the new Ecmascript language
| standards, which obliviated its advantages. The only
| advantage Coffeescript had over ES6 was "some of your
| code is already written in it".
|
| Once Ecmascript formalizes a type system, we'll see the
| same process happen with Typescript. But, I think it will
| be many years before that sort of feature is
| standardized. In the mean time, I'm happy to use
| Typescript today.
| bananabreakfast wrote:
| Square's entire merchant dashboard was in CoffeeScript.
| Half a million lines of code.
|
| Took over a year to convert to ES6.
| tenaciousDaniel wrote:
| I also have fond memories of painstakingly converting
| hundreds of coffeescript files back to JS. There's
| something to be said for using the native language.
| runarberg wrote:
| In my private projects I always write in JavaScript and
| provide static typing using JSDoc comments (which
| typescript can check). Then I run the type checker with
| `--noEmit`. I have yet to run into a problem with this
| approach.
| nullserver wrote:
| Browser support and consistency got a lot better.
|
| JavaScript was a minefield of compatibility problems.
| Many intentional, cough: Microsoft.
|
| Jquery was awesome because it dealt with most of that
| recursive wrote:
| JQuery dealt with DOM and browser stuff. Coffeescript
| dealt with syntactic language stuff. I can't think of a
| case where Coffeescript helps with the same thing JQuery
| does, although it may exist.
| tenaciousDaniel wrote:
| Yeah as best I can tell, Coffeescript was a thing because
| Ruby was very popular at the time, and some Ruby devs
| _had_ to write JS but they _wanted_ to write Ruby.
| ForHackernews wrote:
| I think everyone except JS devs wishes they could write
| something other than JS for the browser.
|
| Maybe eventually with WebAssembly...
| WorldMaker wrote:
| That was definitely the case before ES2015. I think many
| of the non-JS devs that still hugely wish they could
| write something other than JS for the browser haven't
| kept up with ES2015+ nor Typescript. ES2015 is a much
| improved language and vanilla JS isn't painful anymore,
| especially with type="module" support now green enough in
| caniuse statistics that we can finally kill AMD and
| CommonJS for good in greenfield vanilla JS projects. The
| sky is quite sunny and ES2015+ is a better language than
| a lot of non-JS devs think JS is.
|
| It will still be a while before all the brownfields in
| the larger ecosystem get cleaned up (if some of them ever
| do), but that's no longer a language problem, that's a a
| long tail ecosystem problem.
| tenaciousDaniel wrote:
| Yup. I don't find myself using classes much, but some of
| the other new features remove the vast number of issues
| you tend to face.
|
| Is scoping an issue for you? Just use arrow functions!
|
| Is callback nesting an issue for you? Just use
| `async/await`!
|
| I love it so much.
| recursive wrote:
| I use classes a fair amount, but there's still some weird
| stuff in the language I'd take out if I could.
|
| Sparse arrays, all object keys are strings (or symbols),
| crazy coercion rules, the existence of `null`, weird
| float vs int rules.
| runarberg wrote:
| You can use `Map` instead of object which allows keys of
| any type, or typecheck your objects with `Record<K, V>`
| and let typescript warn you about any weirdness.
| Typescript can also warn you if you do some weird
| implicit coercion. You can typeguard against `null`
| (although I admit it is annoying, I just want to use an
| optional+). And if you really want to use integer types
| there is always `BigInt`.
|
| ---
|
| +: I haven't checked, but I bet there are some libraries
| out there that provide proper optionals using Proxy.
| mixedCase wrote:
| CoffeeScript served a purpose, and was not a fad. It got
| deprecated by an ECMAScript that adapted most of the good
| parts.
|
| TypeScript brought something good for the JS ecosystem
| (although Flow did it too, in a different way) and it
| doesn't look like anything will be able to replace it at
| what it does anytime soon.
| runarberg wrote:
| I am really hoping TC-39 starts considering optional
| static types (similar to python), using a simpler syntax
| then TypeScript (e.g. no enums). However I don't have
| high hopes they will any time soon.
| specialp wrote:
| Coffeescript was a good thing when we only had ES5. In
| fact many of the things it championed made it into ES6
| and beyond. I think with TypeScript it isn't just a shiny
| thing. If it does substantially change I believe it will
| be to break the forced compat with JS. As WebAssembly
| gets more adopted it will be possible to not have JS
| targets, and thus remove a lot of the weird JS things
| that have been kept for compatibility. Typescript has the
| gravity to continue.
| jdxcode wrote:
| Agreed. A senior engineer should know when they don't
| understand something and keep an open mind about it rather than
| rejecting it outright.
|
| If this article started with legitimate reasons for not wanting
| to adopt TS it would be different. "It is hard for people to
| learn" is actually a legit reason but "I don't understand it"
| is probably not!
|
| That doesn't imply all new things are good or that senior
| engineers need to understand all new things either. I think
| there is some confusion about this.
|
| Skepticism !== reject everything without grokking.
| bcheung wrote:
| I have a love hate relationship with Typescript. I have come to
| see it as a tool and to use it when it makes sense and avoid it
| when it doesn't.
|
| I like the language at a conceptual level and find what it does
| very useful. The syntax I find less than desirable (especially
| nested generics).
|
| For smaller projects I tend to use just JS because it's faster if
| I just want to prototype an idea and I'm not planning on keeping
| the code around for long.
|
| Where Typescript shines is when working with a team on longer
| term projects.
|
| The generic syntax gets derives from C++ which I don't think is a
| very good syntax. When dealing with more complex generic type
| declarations with nested generics / types your eye is scanning
| back and forth trying to match angle brackets and it is really
| hard to parse visually. Other languages like Haskell allow you to
| just read the "generics" left to right. Aliasing the type helps
| to some degree.
|
| The other thing I don't like is when you are experimenting and
| fleshing out an idea you want to take a try it and see approach
| but with Typescript you have to really commit even though you
| just want to experiment. When you want to change something there
| is so much more code that you have to change.
|
| The pros are when dealing with code you wrote in the past and
| forgot about what the types / parameters are or when dealing with
| code written by other people. Having the IDE suggest what you
| need to pass it is amazing.
|
| The contrast to that is having to jump to a function to see what
| POJO style object it will return, what the exact spelling of the
| property / key are, and things like that. Having static typing
| saves so much time when dealing with other code.
|
| If your project involves you working with others' code or code
| you wrote in the past and don't remember well then this is
| Typescript's sweet spot and it is a huge win.
|
| One of the things I find most lacking in Typescript is pattern
| matching. If you have strong static typing like Typescript does
| then pattern matching pairs really well with that. It makes your
| code much more declarative and easier to read / write.
| frenchy wrote:
| > The other thing I don't like is when you are experimenting
| and fleshing out an idea you want to take a try it and see
| approach but with Typescript you have to really commit even
| though you just want to experiment. When you want to change
| something there is so much more code that you have to change.
|
| I've seen this opinion before, and I don't understand it in the
| slightest.
|
| Let's say you're modeling a "user". You might initially think
| that users should have a first & last name, so you write it
| this way. Then later on you realize that there's no point in
| this distinction, and some of your users from Indonesia don't
| even have separate first & last names, so you want to switch to
| a single name.
|
| * With weak/no typing, you have search around for anything that
| matches the field names, and hope to God you didn't miss
| anything.
|
| * With stronger typing you just change it let the compiler tell
| you all the places you need to fix up.
| bengalister wrote:
| Not sure if I am a Typescript fan but I would most of the time
| choose Typescript over Javascript most of the time for frontend
| or backend NodeJs development.
|
| I used to think the same. Coming from the Java world (might
| explain why I like it) colleagues convinced me that it would be
| better to use another runtime (JVM/CLR) than trying to use types
| on NodeJs (it was stupid). I used Typescript in the first
| versions it was painful, trying to find type definitions, writing
| my owns, etc. So I did not insist and moved to Javascript for
| NodeJs.
|
| I rediscovered the language 1 year ago and uses it for some
| frontend (Vue) and backend (api gateway, lambda,
| mongoDB/dynamoDB) Nowadays I very much like the language, union
| and intersection types make it very expressive and precise.
| Compilation (or translation) is a little slow but bearable, and
| it is nice to have a common language and tooling between the
| frontend and backend. Most of the libraries provide and maintain
| typescript definition files when they are not themselves written
| in Typescript. Sometimes I think the language goes too far in the
| features, I had a look at the latest versions and was a little
| bit puzzled by the complexity. But even for small projects to
| larger ones, I definitely prefer statically typed languages (with
| type inference and even implicit ones) especially when time is
| limited to write tests and have a good test coverage.
| DrFell wrote:
| I have a theory that TypeScript was not actually invented for
| frontend developers, it was created for non-frontend developers
| who were forced to deal with the frontend, and hated JavaScript.
|
| That's also why I think it's very funny that JavaScript
| developers are starting to use TypeScript on be backend, i.e.
| Deno.
|
| You are using the patch to JavaScript that backend devs needed to
| make JavaScript more like backend languages in the very place
| that the languages it is trying to be like already exist. It's
| ludicrous.
| SavantIdiot wrote:
| Yes.
|
| I write large Node projects and Electron apps and TS has been a
| huge help.
| nerdkid93 wrote:
| Looking at the Internet Archive for typescriptlang.org, most
| (but not all) of their original samples are doing something in
| a browser[0], so while it definitely became popular with
| backend developers, I don't know if I would go so far as to say
| it was created for non-frontend developers who were forced to
| deal with the frontend.
|
| [0]
| https://web.archive.org/web/20121004030106/http://www.typesc...
| hckrnwsthrwwy wrote:
| I don't understand any arguments of this variety because TS
| just compiles to JS
|
| TS hasn't changed the way I write applications too much,
| besides giving me a bit of safety/enforcement of good practices
| and productivity boost
| CraigJPerry wrote:
| >> satisfying the TypeScript compiler is an over-engineering and
| not providing any meaningful benefits
|
| I tend to rail quite hard against the "type everything" world
| view but I've always been crystal clear on the benefits of types
| at boundaries between components. They can be a succinct way to
| codify the invariants and contract between components in a
| software architecture - with a nice quick feedback loop when you
| appreciate it most (when you're exploring an unfamiliar API).
| They can also be a total train wreck for productivity when
| abused.
|
| Where they fall down for me and always become a productivity
| penalty is working inside those component boundaries. Tests are a
| better answer then. I care that the actual behaviour is sound, if
| i say concat(list1, list2); something like Java's type system
| guarantees of only "hey you put two lists in, you get some list
| back which might or might not be a concatenation of the two you
| provided" aren't sufficient, you might as well not type it at
| all. Tests are necessary.
|
| In typescript you could actually type concat in a meaningful way
| but i digress.
|
| I think tests are also a better tool for handling people
| boundaries, that is developers separated by time (i.e. myself in
| 1 year) or separated by space, (i.e. between groups of developers
| in different orgs). The fundamental difference is the
| explanation, a test explains how something should behave, an
| intention. A type is a terse expression of how a person
| interpreted the problem domain and is not guaranteed to be an
| appropriate or useful model, it's just a rule.
|
| There's a possible exception to all of this for me - dependant
| types. I'm still learning and undecided on the value.
|
| All said and done, I'm happy that things like mypy and typescript
| exist, but I'm not convinced they are a cost effective way to
| maintain reliable software if over-used or used in rubbish ways.
| Used appropriately, they're great. Used all the time, no thanks.
| acemarke wrote:
| Yep, I'm a firm believer in using TS pragmatically. Type the
| obvious code (React component props, API responses, function
| arguments), and start by aiming for an "80% sweet spot" of type
| coverage. Don't get into arguments with the compiler, and avoid
| writing really complex types unless you've got a key spot in
| your code where adding that type now makes it a lot easier to
| infer types in other places:
|
| https://blog.isquaredsoftware.com/2019/11/blogged-answers-le...
| yboris wrote:
| Mildly-related project I have: generate call graph for typescript
| files
|
| https://github.com/whyboris/TypeScript-Call-Graph
|
| The TypeScript language service is really neat -- you can use it
| to parse through .ts files so you can, for example, see which
| functions call which functions.
| Tade0 wrote:
| My _aha_ moment with TypeScript was when I realized that, in
| spirit, it 's the same thing as ActionScript - a superset of
| ECMAScript with a stricter type discipline.
|
| I had no issues with that back when I was a teenager trying to
| put together flash games, so apparently the only thing preventing
| me from writing exclusively in TypeScript was a lack of a decent
| toolchain.
| [deleted]
| matsemann wrote:
| While I'm fan of statically typing, there is something with
| Typescript I don't like, but don't know exactly what it is. In my
| day-to-day it's mostly Kotlin and Elm, which also are both
| statically typed, which I don't mind and mostly don't even
| notice.
|
| But with Typescript it is as if I'm always fighting the
| compilator, trying to make it happy with whatever code I wrote.
| Maybe it's just the JS ecosystem being too lax that makes having
| types for everything difficult? Like you have a react hook and
| some components that you can compose, and the typedefs just
| become unwieldy and impossible to get right. Often they end up
| not even catching what should be compilation errors.
| fimbulvetr wrote:
| I had this too - when I first started I fought typescript quite
| a bit. I struggled through this because I kept finding more and
| more code on github that was TS, kept seeing more articles that
| were TS, kept seeing big improvements from MS on TS, etc. So I
| kept learning the best practices and trying to understand why I
| shouldn't use "any[]" or "{key: string?}" and so on - trying to
| get past the parts where I wanted to be lazy. Eventually on one
| of my projects I had to reorganize my model structure, where
| some classes held other classes and so on. I had to both move
| one and rename one. This was early on, but since I did a
| reasonable job with typescript, I was able to just run `tsc -p
| .` over and over and it found all of the places I missed, which
| were far more than I would have guessed. It only took maybe 20
| minutes to do that massive refactor. From that day forward, I
| really enjoy working in typescript. I think it's different from
| (some) other strongly/statically typed languages because it
| allows you be be a little more expressive in what you're
| defining. Perhaps expressive is the wrong word, but I find that
| it's quite flexible in this area, and I really enjoy that
| because if I take the time to flesh things out it can really
| help me find or prevent bugs.
| exhaze wrote:
| > Like you have a react hook and some components that you can
| compose, and the typedefs just become unwieldy and impossible
| to get right. Often they end up not even catching what should
| be compilation errors.
|
| I'm curious - how do Elm and Kotlin solve these problems in a
| way that balances the often competing goals of "add types to
| reduce errors" vs "have a high productivity environment where
| it's quick and easy for engineers to write new code"?
| nobody0 wrote:
| Elm and other ML-family languages have type inference, it
| does not ask a major part of human annoation of types while
| catches errors in compile time nonethelessly
| vbsteven wrote:
| Kotlin has type inference as well so typically you only
| write types in function signatures. It's rare that you
| write a type in a function body. Coupled with good IDE
| support for showing you the type of x in `var x = myFunc()`
| when you need it.
| jamil7 wrote:
| Basically in the same boat, although I still use TS as it's
| become kind of defacto in JS land, I'm not sure that I dislike
| it so much as am not sure it's always worth it. Maybe I tend to
| approach it too much like Swift or Kotlin and get annoyed when
| a dependency is missing typings or the compiler is so easily
| tricked/lax about a lot of the actual type-saftey.
|
| Maybe putting Typescript it into the bucket of a "better
| linter" is the mindset to have.
| dep_b wrote:
| TS has a bit of Java feel to me. Forces me to follow all kinds
| of hard compiler requirements that take some time to implement,
| like generics, but then there's still all of these edge cases
| like null-pointers that make it feel like you're still building
| a house of cards.
|
| Kotlin and Elm are more functional, don't know about Elm but
| Kotlin has non-null pointers as a base feature of it's
| language, not some later bolted on tie-wrapped solution.
| danielrhodes wrote:
| The other benefit is refactoring. That saying which goes along
| the lines of: "you're going to be reading a lot more code than
| writing it" is very true. After your project gets to a certain
| size, and it need not be large, you start making smaller changes
| and moving code around -- having some guard rails there is a huge
| productivity boost. Being able to read code and know that it does
| what it says because you know the types also improves your
| productivity.
|
| The critique of typed languages being slow to write was somewhat
| true in the past. However, more modern typed languages (e.g.
| Swift or Typescript) do a lot of inference and have some
| flexibility built in. Because of that I think you get many of the
| same benefits of loose typing while maintaining type safety. One
| worry I had with starting Typescript was a fear it was going to
| make engineers over-engineer things, which is a behavior that
| Java seems to promote -- that turned out to not be true. You can
| go off the deep-end on generics, but in practice I haven't seen
| this.
|
| Also with Typescript, you're not so far from Javascript where
| it's an entirely new language. So if you love Javascript, you
| don't lose anything.
| Barrin92 wrote:
| I don't really buy this argument about readability because the
| sort of information stored in types very quickly becomes pretty
| meaningless for humans. I remember working on a Haskell
| codebase and getting into an argument about this with a
| developer who was very much in the typed language camp.
|
| Then I saw a function that had like 8 parameters, some were
| just String, or Int, some where synonyms, and I asked him what
| it does based on the type signature. He didn't know. I didn't
| know either. Int -> Int -> Foo -> String -> Foo very quickly
| starts to mean nothing.
|
| Types don't enhance the meaning of the code. if you want to
| understand your code better, what you're looking for is _better
| names, not better types_. As far as understanding code is
| concerned, in the best case types have the exact function as
| names, in the worst case they entice people to write 'int x'
| rather than giving something a proper name.
| j-krieger wrote:
| The magic is in the combination of types and proper names.
| What use is a variable that's nicely named when you don't
| know what it holds?
| nobody0 wrote:
| Typescript is boring, and boring is definitely something need to
| be treasured in the frontend world.
| cableshaft wrote:
| For me, I can handle the lack of static typing when I'm doing
| small scripts, like if it's going to be 100 lines or so of Python
| (my go-to language if I need to test some math out in a sandbox
| or do some file manipulation on my system). I might actually be a
| little faster in writing those scripts because of the lack of
| typing.
|
| Once it starts getting any bigger than that, though, static
| typing really catches and points out a lot of problems before I
| even launch the program, that I'd otherwise be spending time
| debugging and looking for anyway, most likely.
|
| I also think static typing has the benefit of enforced self-
| documentation a bit, so other developers know just by checking
| the type what sort of data they should expect to see in there,
| and not trying to give it garbage to begin with. Granted good
| variable naming and proper documentation would alleviate that,
| but that's never been fully consistent at any organization I've
| ever worked for.
|
| And considering I mostly work with relational SQL databases,
| there's no escaping typing on the database end for that, so I
| might as well have models that map to the typing of what's in the
| database so I don't have to keep checking the database tables to
| make sure I'm giving it good data.
| ogre_codes wrote:
| Seems like an easy cutoff is when you add a build step as
| opposed to just including your script on the page. If you need
| to use Webpack for a project, you might as well add TypeScript
| as well.
| oblio wrote:
| Naming is incredibly hard, though. And refactoring is hard.
|
| It's a pain in the neck when something starts out as bla_list
| or whatever and you discover that after half a decade of
| changes bla_list isn't actually a list anymore, it's a
| dictionary, and that it doesn't only hold Bla these days, it
| can also contain Foo or Bar. This type of stuff is immediately
| obvious with modern static typing.
| blacktriangle wrote:
| This feels more like developers learning that any variation
| on Hungarian notation is a bad idea.
| ysavir wrote:
| This feels less like a case of Hungarian Notation being a
| bad idea and more like a case where developers are making
| irresponsible updates to their code. If a
| variable/function/class/whatever is being updated, the
| naming should be updated as well, if appropriate.
|
| Blaming the original author for the actions of the
| maintainer is not fair.
| blacktriangle wrote:
| I'd still blame the individual developer for poor naming.
| Naming a variable something like int_list is terrible in
| that it's both very specific and semantically
| meaningless. Either choose a semantic name like grades or
| part_numbers, or take a hint from ML convention and use
| semantically void names like "xs".
| oblio wrote:
| You have to account for developers learning, for any code
| base, though. Let alone for third party dependencies :-)
| cableshaft wrote:
| I agree, naming can be incredibly hard. I periodically spend
| a long time trying to decide the best name for variables, and
| at times whatever I come up with isn't satisfactory to me
| even then (and I usually try to explain it better in a
| comment at its declaration).
|
| I don't always change the names if their use drifts a bit
| either because I know the other developers might be used to
| the code where it's named something else and it might confuse
| them, and/or I have to rename it in a bunch of places that
| might make a merge particularly messy, especially if I'm
| working in the same place that I think another dev might be
| working on at the same time (it's happened more often than
| you'd expect actually, I've had to do some particularly
| gnarly merges at times).
| strogonoff wrote:
| > I also think static typing has the benefit of enforced self-
| documentation a bit, so other developers know just by checking
| the type what sort of data they should expect to see in there,
| and not trying to give it garbage to begin with. Granted good
| variable naming and proper documentation would alleviate that,
| but that's never been fully consistent at any organization I've
| ever worked for.
|
| I don't think naming is fully alleviated by static typing;
| however, on the other hand, static typing allows IDEs to offer
| better refactoring capabilities, since they can presumably
| build such functionality on top of the compiler's structured
| syntax tree representations.
|
| As an example, lately I fairly frequently find myself using VS
| Code capabilities to rename TS identifiers as my code evolves.
| It always handles correctly the scope and everything, I'm sure
| it'd be more error-prone with plain JS.
|
| Agreed about statically typed code being more self-documenting
| in general. It's a bit of a double-edged sword in that it may
| give an illusion that your project is easier to understand than
| it actually is, but it usefully shifts the focus of
| documentation from minute details of code itself to subject
| domain specifics and how you represent them in your
| architecture.
| pid_0 wrote:
| I use type annotations in Python no matter what. It really
| helps skim the code faster and mentally understand what values
| I am expecting. Its very useful to know which var is a
| List[dict] and so on.
|
| I don't like TS because javascript is just a silly language to
| do anything serious with (besides front end), and its so
| stringent it takes forever to write quickly.
| agumonkey wrote:
| I guess static first is a chore because at that point you have
| no idea what invariant or structure is required for the task.
| After prototyping you know where to tighten the bolts.
| meheleventyone wrote:
| Sort of but at the same time being forced to think about
| those things also helps get a handle on exactly those parts
| of the program. Remember you still need to think about them
| in a dynamically typed language but it's obfuscated because
| they're implicit.
| munchbunny wrote:
| > you have no idea what invariant or structure is required
| for the task
|
| In my experience, in general, if you don't already have an
| idea, you should probably be spending the up-front time
| thinking about it. If we're talking React/Redux, then
| carefully thinking through both data representation and what
| goes into components' properties/states helps a lot for
| designing a clean and understandable structure.
| cercatrova wrote:
| > you have no idea what invariant or structure is required
| for the task
|
| I often write the program in TypeScript types/interfaces
| first because it forces me to think about the data flow both
| in and out. In my opinion, data, not code, is the most
| important thing about a program.
| agumonkey wrote:
| that way of working was my only pleasurable experience in
| eclipse/java
|
| start with interfaces and let the live type checker tell
| you where your incoherences are. Very very smooth way to
| work.
| tshaddox wrote:
| Designing my types first is _precisely_ how I want to begin
| prototyping.
| zaccusl wrote:
| There is why TypeScript IS so great.
|
| In the early days of a new app or feature, you have no idea
| what the correct data/type shapes are.
|
| In TypeScript you can define the types and then easily do
| major refactors even if you have 1000's of lines already
| written.
|
| It becomes so tedious to do the same refactoring in
| JavaScript.
|
| TypeScript makes it trivial to change an object or function
| signature when developing new code (or old code).
|
| Refactors that take 3 minutes in TypeScript take 3 days in
| JavaScript and you better hope you catch all the uses.
|
| The refactor ability that TypeScript gives you makes it so
| much easier to change data types and function signatures
| dozens of times until you get things right.
| gameswithgo wrote:
| There are some languages that give you a bit of both worlds,
| like F#.
| dfgdghdf wrote:
| This! My favourite thing about working with F# is the tiny
| delta between prototype script and production MVP.
| agumonkey wrote:
| hey, the ml family is only 40+ years old, maybe in 50 years
| they'll be mainstream
| mentioal wrote:
| SQL is not typed, it is just text sent over a network or
| whatever and then parsed...
| ok123456 wrote:
| The schema and functions are typed.
| gamesbrainiac wrote:
| I think a large part of the support for Typescript comes from
| being able to create good tools for the language.
|
| But, I still have an aversion to front-end development itself,
| because it just feels too _involved_. You have to set up so much,
| and it has become a lot more difficult since you need to install
| webpack, postcss, and many other plugins just to do a hello world
| app.
|
| It's still bearable if you have to do all of that, and you
| _understand_ what is going on, but most of the time, especially
| when it comes to front-end, I do things "because that's how it's
| done".
|
| This makes me feel very insecure about my code.
| seph-reed wrote:
| I've spent the last two years writing my own framework because
| I hated React so damn much.
|
| It really doesn't have to be that complicated. Granted, I still
| use a bundler, but it's really easy to set up. I had my friend
| walk through it all... he seems to think it's great.
|
| I should probably release this project some day.
| j-krieger wrote:
| Why did you hate react? It's really one of the less
| complicated frameworks out there.
| Octoth0rpe wrote:
| > You have to set up so much
|
| I think tooling has mostly addressed this, or at least provided
| a mostly braindead path for 90% of needs. For example, npx
| create-react-app $YOURAPPNAME sets up practically everything
| you need to get a reasonable react app going, at least in terms
| of the transpiler/set of plugins. It makes very few choices re:
| actual react libs though (no preferred router, flux, etc). The
| preact equivalents are somewhat more opinionated, and go a bit
| farther in setting up routing/splitting nicely for you.
|
| > This makes me feel very insecure about my code.
|
| I get this. While I stand by what I mentioned above, it also
| makes me nervous that I understand so little of my setup given
| how much of it was setup automatically for me, which makes me
| trust the environment less. FWIW, outside of web dev it seems
| like _most_ people have no idea how their setup works re:
| compiling a project. How many devs for say postgres understand
| the make file or configure scripts? Probably not that many.
| Maybe that's getting better with newer tools like cargo, but
| web dev always seemed like the exception wrt understanding the
| bundling environment, and we're just now catching up to the
| level of complexity that other types of dev have had for
| decades.
|
| Edit: apparently that was a bad example. Postgres's make file
| is very simple:
| https://github.com/postgres/postgres/blob/master/Makefile
|
| The configure script is less so:
| https://github.com/postgres/postgres/blob/master/configure
| spyke112 wrote:
| This argument also holds for backend development. I've spent
| days trying to get a big Java app working with Jboss at a new
| place, it was more or less a rite of passage when joining the
| team. Also setting up some local obscure Microsoft IIS setting
| because reasons.
|
| These days I find frontend tooling quite delightful, Typescript
| for instance Just Work(tm) our the box.
| gamesbrainiac wrote:
| I can't comment on this, since I haven't really worked with
| JBoss, and haven't had to touch the .net stack in ages.
|
| The python stack is pretty okay though. You just containerize
| it, and ship it. Some providers will even allow you to run
| containers as a function/lambda.
| nothis wrote:
| "First I didn't like it because it takes longer to learn, then I
| discovered the obvious features that are the reason TypeScript
| was invented in the first place."
| SavantIdiot wrote:
| Two downsides to TS: an extra step to transpile, and having to
| write shims when it bugs out and can't verify an external
| declaration.
|
| Upsides? When tuned to its most pedantic settings I've uncovered
| a handful of bugs that would have otherwise launched.
|
| That's worth far more than a few tiny annoyances. tslint >
| jslint.
| deckard1 wrote:
| FYI, tslint is deprecated since 2019.
|
| Most people use eslint. But eslint on TS is _excruciatingly_
| slow.
| SmellyPotato22 wrote:
| If you are working on the server side, ts-node has been a huge
| timesaver. It removes the extra step of compiling and lets you
| just run your script with `ts-node script.ts` or even
| `#!/usr/bin/env ts-node` at the top of your file works.
|
| https://github.com/TypeStrong/ts-node
| hasmolo wrote:
| babel-node is also very nice, and more lenient about type
| checking. i've discovered nodemon with babel node gives me
| the ability to hack something together and adding a tsc build
| pipeline helps me correct the types when i'm done
| SavantIdiot wrote:
| Thanks for the node tip!
|
| I built an electron webpack framework and it uses hot
| reloads, but since i fork a lot of processes, it doesn't
| quite understand those need to be reloaded too! Got a fix for
| that by any chance?
| steenreem wrote:
| Here's an alternative to TypeScript that people who dislike type
| complexity but want better tooling, might find interesting:
| https://github.com/keyboardDrummer/typeless
|
| Disclaimer: I'm the author
| vergessenmir wrote:
| Not much said on the category of bugs caught by Typescript. That
| would have been an interesting discussion.
|
| I dip between javascript and typescript and hesitate recommending
| it for large scale project for a large team as much as I would
| like to, coming from a background of typed languages on the
| backend. There appears to be a need for experienced senior
| typescripters on the team to prevent falling into certain traps
| and onboarding [1].
|
| I do wonder though how he saw typing as over-engineering. It may
| cause intertia which he hints at in the next sentence but over-
| engineering is a bit uncharitable.
|
| [1] https://medium.com/javascript-scene/the-typescript-
| tax-132ff...
| MFogleman wrote:
| This article echos the common complaint I've seen from people
| hesitant to adopt TS.
|
| "I always used to get some compilation errors which were hard to
| understand initially, and I scratched my head trying to figure
| out the problem. "
|
| Which is like saying, "I got rid of my carbon monoxide detector
| because it kept beeping at me"
| mushishi wrote:
| I kinda like what you are saying, but it's not that clear-cut
| in my experience / skill-level.
|
| One can write code that would work correctly, but trying to
| express the types as precisely as one would like may be painful
| and doesn't necessarily be productive.
|
| Sometimes when I feel it is cumbersome to express my intent in
| typing, I may feel satisfied enough to make a runtime check,
| (and perhaps add a note but depends...). Especially if that
| functionality is used in scoped area (e.g. module) and not
| exposed to the rest of the app.
|
| When trying to make a generic and flexible functionality, the
| typing experience seems get harder and more time-consuming for
| human to grok, and it may not even be that useful when you look
| how the code is used.
|
| So I usually try to make typing as good as I can by finding
| documentation related to what I'm trying to do and banging my
| head to the wall from a couple of angles, and for some specific
| parts I may give up and type any.
|
| Perhaps sometimes when typing feels hard it may tell that the
| abstraction is just plain wrong, so there's that plus side!
| mouzogu wrote:
| I'm a senior developer and I've never touched TypeScript and
| don't have any desire to unless I have no choice.
|
| I haven't worked on any projects that were large enough to
| warrant type checking or where I felt it would make a huge
| difference. Also I find it a bit verbose and ugly and I'm just
| not a fan of pseduo Javascript languages that need to be compiled
| down into JavaScript.
| Aldipower wrote:
| Same here. I still do not get it. I see the benefits of typed
| languages for use cases controlling binary data, like hardware
| controlling, drivers or binary file formats.
|
| And actually you can write very type safe code in pure
| JavaScript.
|
| 1. (arg) => if (typeof arg !== "string) throw new Error()
|
| Of course, this is executed during runtime (which could have
| benefits too sometimes) and not at transpile time.
|
| Yes, you can laugh at me. But.. You should be always aware of
| the types you are using, which data is coming in and if the
| function is type critical, which is only the case for some
| functions, it is even more fault safe doing it this way,
| because your app is spitting an error during runtime, which
| will definitely be fixed very quickly. :) To validate data, use
| typed structs.
|
| 2. You need to write good tests anyway. Tests should test with
| malformed and faulty data always.
|
| I and the teams I had, maintained and coded big JS
| applications. I can remember only one case, where TypeScript
| could have been helped with typing. But also, we had no test
| written for it, so..
| MentallyRetired wrote:
| Same. Lead dev here.
|
| Part of my problem stems from the lack of typed libraries
| across the JS ecosystem. Party supported typing leads to more
| issues, I've found.
|
| Then there's the IDE. I don't use code hinting. In fact, I find
| it irritating. So, I draw no benefit from TS in this regard.
|
| Then there's the cryptic error messages. They've gotten better
| over the years but I always seem to spend more time debugging
| TS than writing code.
|
| And finally, I just don't run into the kinds of errors people
| talk about solving with TS.
|
| That said, I did enjoy the strong typing that AS4 provided back
| in the day. But TS is intolerable to me and I've worked with it
| for years.
| antihero wrote:
| As another lead/senior dev, I've found that onboarding hires
| that know some TS into a TS codebase is a hugely slicker
| process than onboarding people into a pure JS codebase,
| simply because the typechecker can do the overhead of having
| to check each call etcetera.
|
| The issues you are having sound like teething issues but as
| someone who's worked with TS for years I've found they aren't
| hugely difficult to overcome, either with @types packages, or
| writing declarations, or declaring module (and having an
| "unsafe" library that people use with care).
|
| > I don't use code hinting. In fact, I find it irritating.
|
| I mean that's a personal preference, but if you're a lead dev
| and you have people starting work on a codebase they have
| little experience with, it's a godsend because they aren't
| totally blind.
| meheleventyone wrote:
| > I mean that's a personal preference, but if you're a lead
| dev and you have people starting work on a codebase they
| have little experience with, it's a godsend because they
| aren't totally blind.
|
| Very much this. I pushed to move the scripting language for
| our game engine project dot big bang from JS to TS
| primarily because the typing makes the entire codebase much
| more discoverable and beginner friendly. Using Monaco
| embedded in the browser programmers get great auto-complete
| and inline code documentation as well as the compilation
| step making some simple and common runtime errors much
| harder or impossible to run into. Qualitatively the mixed
| experience bunch we have using it now all much prefer the
| TS experience to the JS one we had before.
| pcthrowaway wrote:
| I'm learning typescript on-the-fly as I migrate an
| existing React+express codebase to it; Curious if you'd
| recommend Monaco over VS Code, and if so, why?
| meheleventyone wrote:
| Monaco is the engine that powers VS Code. It's super neat
| you can just embed it.
|
| https://github.com/microsoft/monaco-editor
| antihero wrote:
| > I haven't worked on any projects that were large enough to
| warrant type checking or where I felt it would make a huge
| difference.
|
| Can I esk exactly how you're considered senior if you've not
| worked on any projects large enough to warrant type checking?
| prussian wrote:
| Short article, felt like what has been said before numerous
| times. I will opine why I was hesitant at first. The biggest
| reason was I didn't want to start writing a bunch of not-js (as
| in not a "strict superset" of js) and also having to deal with
| writing my own type definitions. I remember trying things like
| flow and reasonml and got quickly annoyed bending over backwards
| to use non-reason/flow code.
|
| It seems like as of 2021 though that typescript has sort of won
| and the community has done great work in covering virtually every
| package I seem to use. npm helpfully points out which libraries
| have typescript definitions or a @types/<package>. I'm still not
| entirely sold on the strengths of strong typing in terms of bug
| avoidance, but the IDE like features are enormous. For me
| personally I see typescript more as a forced, never stale or
| mostly-incorrect, JSDoc.
| MatekCopatek wrote:
| Don't want to oversimplify since the article has some useful
| insights, but overall it reads like a typical transition from
| thinking static typing is a burden to realizing type safety can
| be incredibly useful.
|
| I distinctly remember that in college I believed the history of
| programming languages is purely evolutionary in the sense that
| newer languages are objectively better than older ones. As in -
| people wrote assembly until C came along and gave them if clauses
| and for loops and then came Java where you didn't need to
| manually manage memory anymore and could use classes and then
| with Python you didn't even need to specify types anymore!
|
| I.e. the newest language with the most everything is the best!
|
| Nowadays it feels like I'm replaying that in reverse - doing less
| and less OOP, loving statically typed languages, wanting to learn
| some Rust etc.
| beaconstudios wrote:
| If you're anything like me, once you've swung back in the other
| direction for a while you'll synthesise and realise that
| engineering is choosing trade offs and that every tool has an
| area where it shines - so its worth applying that tool to that
| area and not treating every problem like a nail to be hammered.
| disgrunt wrote:
| Of the languages you listed, Java is the new kid on the block.
| Python is older than Java.
| MatekCopatek wrote:
| Interesting, I didn't know that! Guess I still have some of
| my youngster naivite :). But that's exactly how I felt - I
| remember the introductory programming courses being in Java,
| there was talk about switching to Python, but it only
| happened a few years after I was a student. Same with
| companies - Java was for "old corpos" and Python for "hip
| startups".
| _fat_santa wrote:
| > but overall it reads like a typical transition from thinking
| static typing is a burden to realizing type safety can be
| incredibly useful.
|
| I got this impression too, I was just like the Author in that I
| hated static type checking as a Junior, but as I gained more
| experience it flipped from "I hate this" to "this is the first
| thing I implement in a new project".
|
| To your point of thinking that newer languages being "better"
| than older ones. I think that also comes down to experience. At
| first I thought the same way, but the most experience I gained
| the more I realized that each language is a specialized tool
| for using in specific cases, some tools are very very
| specialized (WASM for example) while others are broad (like
| Javascript).
| vermilingua wrote:
| As a relatively fresh "JavaScript developer", how do I make the
| transition to TS? How do I convert existing projects, including
| React projects, and configure npm to run smoothly with TS?
|
| Is there some authoritative guide on this?
| robgibbons wrote:
| I often write Typescript and don't mind it; type safety is neat.
| But my personal take is that if I can't drop code into a
| webpage/console and have it execute immediately, it's not a
| "real" part of the web stack. It's a very useful abstraction for
| large projects, but it's still an abstraction from the actual
| syntax of the web.
| johnday wrote:
| If anything, TS is a concretion of JS rather than an
| abstraction over it.
|
| When you write TS, you are (literally) writing JS, except that
| you are _also_ writing miniature contracts (types) which are
| shared between components of the system and between authors of
| the code. This helps to ensure that the JS everyone is writing
| is mutually compatible, and that pieces of JS that _should_ fit
| together actually _do_.
|
| The idea that something's not part of the web stack if you
| can't throw it at a browser seems a bit weak; especially as, in
| this case, you can throw a subset of what you write at a
| browser and have it perform as intended.
| 29athrowaway wrote:
| Verifying types is something computers can do faster and more
| reliably.
|
| By removing type annotations you are going against automation.
| And, as a software developer, automation is your job.
| throwaway4good wrote:
| I like you can type check stuff like this: type
| State = { id: "initial" } | { id: "running", speed: number }
| const f = (s: State) => { switch (s.id) {
| case "initial": // s.id available break;
| case "running": // s.id and s.speed available break;
| } }
|
| The problem with Typescript shows up when people with background
| in Java or C# starts taking oo design patterns into js-land where
| they don't really belong (patterns like dependency injection,
| factories, singletons etc.).
| henearkr wrote:
| Not long ago I used to hate Javascript, and it was because I did
| not understand it very well, and then I read Flanagan's book
| "Javascript the definitive guide" and now I like it!
|
| So, is there a good book that some of you would recommend, that
| would have the same impact as Flanagan's, but about TypeScript?
| macspoofing wrote:
| I like the post, but the author's original perspectives are
| something I was always perplexed by. There was a period in late
| 2000s and early 2010s where dynamic languages were all the range
| (Ruby, Python, CoffeScript) and static typic was seen as archaic
| and slow by an entire segment of development community and I
| never understood it.
|
| >I always felt that adding types to the functions/variables and
| satisfying the TypeScript compiler is an over-engineering and not
| providing any meaningful benefits.
|
| I mean ... that is a perspective. EJB 2.0 was over-engineered for
| many use-cases. SOAP is an over-engineered standard for many use-
| cases. Static typing is not. Maybe for small scripts, static
| typing doesn't provide that much value (although even then I
| don't really buy it - why wouldn't you want to know what you're
| working with at any given time), but for sizable (web)
| applications that need to be maintained for years, it's critical.
|
| >also it felt slow to work on, as I always used to get some
| compilation errors which were hard to understand initially, and I
| scratched my head trying to figure out the problem.
|
| Another interesting perspective. Every single one of those
| compilation errors was a runtime error waiting to bite you in the
| butt. If you think solving compilation errors is slow, debugging
| and solving runtime errors is way slower. I'm glad the author
| learned the value of compile-time checks.
|
| >The other reason was Advanced TypeScript concepts like Generics
| felt very hard to understand initially and I started feeling that
| I am in the Java world where every piece of code is strongly
| typed and overwhelming.
|
| This right here is the big problem in a nutshell. There is
| nothing wrong with ignorance - we all start there. But it's one
| thing to be 'overwhelmed' by something when starting out, and
| another to being ANTI that something BECAUSE you don't understand
| it. The author admits he was overwhelmed by TypeScript and that
| caused him to be ANTI-Typescript. That is something you see in
| places. And that the author justified his Anti-Typescript
| perspective by having an ignorant view of Java to boot. The
| author talks about 'Java world', but does he have any experience
| with Java development at all?
| symlinkk wrote:
| Not all type systems are created equal. I could see how someone
| whose only typed language was C++ could think that it's a waste
| of time.
| btbuildem wrote:
| I was hesitantly open to TS when the hype was first ramping up.
| The team I was on (and I've seen this in lots of code elsewhere
| too) was doing stuff like this: declare let
| myColor: Color | undefined;
|
| Suddenly everything turned into Java with signatures cascading
| endlessly. I'm not blaming TS, it's more of a.. lack of faith to
| make the full jump? Or limitation of the underlying Javascript?
| This problem should be solved with having multiple function
| signatures, in the example above one with and one without the
| Color param.
|
| I've been toying with Erlang for years, once I grokked how they
| flow control can be done via different method signatures, the
| Other Way started looking really inadequate.
| gagege wrote:
| This is my problem with TS. The underlying JavaScript peeks
| it's gross head through the cracks way too much. I end up not
| bothering with types since they're often wrong at runtime
| anyway.
| munchbunny wrote:
| If "| undefined" is spreading through your code like a virus in
| cases where it's not actually optional, then I'd argue that the
| problem is upstream where the data is ingested, and the code
| should be enforcing "must be defined" at input validation so
| that you can carry a clean "Color" type everywhere else.
|
| If it's about optional parameter weirdness and TypeScript's
| lack of method overloading, I suspect that's inherited from
| JavaScript's laxness with method signatures. I don't like it
| either.
| zaccusl wrote:
| TypeScript does have method overloading same as other typed
| languages (except you have to do runtime checks, but that is
| a JavaScript limitation).
| munchbunny wrote:
| > except you have to do runtime checks, but that is a
| JavaScript limitation
|
| IMO not having to do runtime checks is a big part of the
| value proposition of method overloading the way many
| languages do it. Whether or not it's a limitation inherited
| from JavaScript, it's still really klunky compared to other
| mainstream languages.
|
| It's one of the few things that I actually dislike about
| TypeScript, despite overall loving it.
| jdxcode wrote:
| assuming you meant let myColor: Color |
| undefined;
|
| I don't understand what the problem is. Native JS would require
| you to define the starting scope of the variable (unless you're
| relying on global scope!).
|
| Then you declare what the type is: Color or undefined. The
| state of the variable can be one of two things. Perhaps I've
| been writing TS for too long but I think I'm missing the
| problem here.
| tomca32 wrote:
| The problem is that if anything can be undefined, then you
| don't really have a big typing advantage over regular
| JavaScript.
|
| It's just like being in Java land where typing adds a lot of
| boilerplate to the code, but you still have to do null checks
| everywhere.
| symlinkk wrote:
| That's a problem with your codebase, not with TS.
| mdoms wrote:
| > I always felt that adding types to the functions/variables and
| satisfying the TypeScript compiler is an over-engineering and not
| providing any meaningful benefits.
|
| I honestly find this attitude horrifying. I'm glad the author was
| able to move on from this, but it is utterly pervasive in some
| parts of our industry.
|
| As far as "engineering" goes, specifying your types is about as
| low-hanging, basic a step as you can take. If this is "over-
| engineering" then I think that says a lot about how much thought,
| design and engineering goes into some of these code bases.
| axguscbklp wrote:
| Much of web development doesn't need extreme levels of
| attention to safety. A good fraction of web development is such
| that errors are quickly caught in manual testing and at worst
| just make some button look weird for the short span of time
| before the problem is noticed and fixed. Also, time spent using
| generic safety tools is time that could instead be spent
| reworking and better understanding the specific code to make it
| safer. There is a lot of cultism in the industry about testing
| and type safety. I have seen people demand almost 100% test
| coverage for code that displayed some extremely simple UX
| which, if it broke, would be completely obviously broken the
| first time you tried actually interacting with it. I have seen
| TypeScript used for short code that basically just displays
| simple UX and is made up largely of calls to third party
| libraries anyway. I think there is no generic appropriate level
| of attention to safety. It depends on the context. If you're
| working on code that controls a spacecraft or a medical device,
| it makes sense to spend an enormous amount of thought and work
| on safety. For much of web development, that just doesn't make
| sense, but organizations seem to often fall into a trap of
| mandating bondage-and-discipline features for stuff that
| doesn't need it - why, I don't know. Maybe because there's an
| impression that "everyone else is doing it". I guess also, some
| people just enjoy it.
|
| But I don't enjoy it. I like writing JavaScript. I think I can
| often do it elegantly and that the perceived elegance at least
| somewhat corresponds to objective quality. TypeScript makes my
| code uglier, to my taste at least, and makes development less
| fun for me. This impacts not just my feelings, but also my
| productivity. TypeScript had better provide me with something
| great to make up for this. I rarely make the kind of errors
| that TypeScript is capable of catching or feel like I need the
| help with readability and code discovery that it provides. But
| other people, I recognize, do benefit from it sometimes and in
| any case, other people pay me to use TypeScript.
| mekoka wrote:
| > As far as "engineering" goes, specifying your types is about
| as low-hanging, basic a step as you can take.
|
| How do you come to such a conclusion when there have been many
| languages whose success was specifically tied to the fact that
| they were dynamically typed? Doesn't that indicate a pain
| point?
|
| > If this is "over-engineering" then I think that says a lot
| about how much thought, design and engineering goes into some
| of these code bases.
|
| "Over-engineering" means drawing blueprints when the job is to
| change a bulb. It does not mean that blueprints are useless.
| It's about the job and the tools picked to do it. I can
| conceive of many jobs that fit the scope of a dynamic language
| and where bringing the big typed cannons could be seen as over-
| engineering.
| luuio wrote:
| > there have been many languages whose success was
| specifically tied to the fact that they were dynamically
| typed
|
| Language success does not mean product success. A language is
| just one of the many things in your toolbox. There's a reason
| why when many products grew larger, they all are migrating to
| statically/strictly typed languages.
| throwaway894345 wrote:
| I've worked with a lot of people in the Python world who just
| wanted to move tickets across the kanban board as fast as
| possible, and they'd do a quick check of the happy path and
| call it a ticket. They'd be praised for their output and we
| (rightly, I think) didn't try to trace bugs back to a
| developer. They would do all sorts of dynamic-typing hacks to
| get the immediate task at hand done with little regard for the
| mess that was made, and they strongly disliked static types
| because they made those error prone, unmaintainable hacks
| really difficult to express.
|
| Let me pull that out into a block quote:
|
| > [types] made those error prone, unmaintainable hacks really
| difficult to express
|
| This is, in my mind, the most valuable feature of static types,
| and one that at least some dynamic typing enthusiasts can't
| easily get their heads around. Types are like rails that guide
| you to code which is maintainable. Another very valuable
| feature is that they serve as documentation that would
| otherwise never be written or quickly fall out of date in a
| dynamically typed language. _Lastly_ in importance is that the
| compiler /type-checker precludes certain errors.
| spideymans wrote:
| I did one of my internships at a financial services company.
| Their web applications were responsible for performing
| transformations on _massive_ JSON datasets, with a huge variety
| of financial data. This is precisely the kind of project that
| would benefit most from typing.
|
| I was relieved to find out that they were smart enough to use
| TS, yet horrified when I looked at the code base and found that
| the entire codebase was littered with the "any" keyword, making
| typing damn near useless.
|
| We had so many bugs reports that essentially boiled down to
| "this data is being transformed in a way it shouldn't be".
| Almost invariably these bugs were due to the developer thinking
| that some variable represented one thing, when it really
| represented something else, and they thus performed an
| incorrect transformation on it. _Typing would 've eliminated
| this entire class of bugs_.
|
| Figuring out what any variable represented often involved
| traversing the huge codebase to find out where the variable
| originated. On some occasions, I even had to talk to the back-
| end developers to figure out what the heck was going on.
| _Typing is self-documenting, and would 've completely
| eliminated the need to go on a scavenger hunt to figure out
| what a variable meant_.
|
| Anyways I got sick of this rather quickly, and made sure to add
| types to any new code that I wrote. I was the only developer on
| the 20 person team that bothered to do so.
|
| As an intern, I didn't understand why these developers refused
| to use types. I just assumed that with their years of
| experience, they must've had a good reason. Now looking back at
| it, it's clear that they didn't understand types, didn't want
| to learn how to use types, and thus just chose to completely
| ignore typing.
|
| As you said, this is utterly horrifying (especially for a
| financial services company dealing with _real money_ ).
| polishdude20 wrote:
| I have a personal project ive worked on a lot last year.
| There was a part in my code which at the time scared me a bit
| because of the complicated data organization and manipulation
| that was going on. When I first wrote it, I had to have a
| clear picture in my kind about what properties an object had
| and what their properties had and do on. I had to write this
| down all on paper.
|
| This year, when I came back to the code. I converted
| everything to typescript. I made sure that every variable
| that my manipulation worked on had a type. It not only helped
| me remember how the code worked but it made it so much easier
| to understand it and modify it without fear of breaking
| things.
|
| It's been super useful and I don't think I'll be writing any
| big programs in the future without it.
| lfxyz wrote:
| I've had a similar experience. My team is using Vue 2 and,
| while the VueX store is almost entirely correctly typed,
| inside the Vue components everything was typed as 'any'.
| There was no value being added in the slightest, but
| attempting to upgrade packages resulted in many new
| TypeScript and ESLint errors.
|
| I ended up opening a PR to strip out TypeScript from all the
| Vue components so I could get things up to date (and ease a
| possible transition to Vue 3, which behaves much better with
| TypeScript).
|
| I'm starting a new job soon and really hope I can work with
| React and TypeScript again.
| munificent wrote:
| This comment and many others in this thread seem to be missing
| something. I see a lot of anger here or blame on the author for
| deliberately _choosing_ to not use types, but I think the
| author actually does a very admirable job explaining what 's
| going on in their head:
|
| "... concepts like Generics felt very hard to understand ...
| every piece of code is strongly typed and overwhelming. Even
| simple code like below scared me ..."
|
| The author isn't claiming to have had an informed opinion of
| types. They're saying that they found _learning_ about types to
| be difficult and stressful. That 's a real problem that I think
| people who understand types forget.
|
| _> specifying your types is about as low-hanging, basic a step
| as you can take._
|
| No, absolutely not. Learning _an entirely new syntax, static
| semantics, and entire way of reasoning about code_ is about as
| high-hanging as you can get. Sure, once you know how to use
| static types, _applying_ that knowledge is fairly easy. But it
| 's a big mountain to climb _before_ you get to do that.
|
| This is the key advantage of dynamic types. You can make a
| computer do useful things without having to invest the large
| effort required to learn how static types work.
|
| Now, personally, I think it is worth learning that. And,
| certainly, once you learn it, you get to amortize that benefit
| through the rest of your career. But there's a lot of people
| standing at the base of the mountain, realizing only how far
| they have to climb with no idea of the view they'll have once
| they're up there. Those people deserve sympathy, understanding,
| and encouragement to climb. Not criticism and mockery like I
| see all over this thread.
| spideymans wrote:
| >The author isn't claiming to have had an informed opinion of
| types. They're saying that they found learning about types to
| be difficult and stressful. That's a real problem that I
| think people who understand types forget.
|
| Respectfully, its really hard for me to wrap my head around
| this mindset.
|
| When I wrote my first line of code, almost 10 years ago, one
| of the very first concepts I learned was types. You know the
| basic OOP lessons where they teach that a Dog is a type of
| Mammal which is a type of Animal, etc. Typing was ingrained
| in me before I wrote any meaningful code. So from my
| perspective (and the perspective of anyone who learned
| similarly), typing is basic, foundational knowledge, and
| programming without an understanding of types is akin to
| running before you can walk
|
| I think a lot of the developers learning nowadays are
| learning to code only on JS. And on JS you can do _a lot_
| without ever thinking about types. So they get stuck in the
| mentality that typing isn 't necessary, and don't ever put in
| the effort to learn types.
|
| Learning about types isn't that hard. But if you've been
| conditioned into thinking that typing is esoteric (perhaps
| due to modern coding courses completely glazing over types),
| then you're likely going to find it very challenging.
| bobthepanda wrote:
| A move at my alma mater to switch the introductory course
| from Java to Python was criticized on the same grounds. The
| students had a hard time in successive levels of
| coursework.
|
| It seems to be a lot harder to get people who learn dynamic
| typing first to learn static typing, than the other way
| around.
| mmcdermott wrote:
| I've been thinking about this (and will probably try to put
| together an essay about it at some point). I think that the
| types you learn in programming 101 and the advanced types
| (the kinds of things written about in type theory books and
| papers) are related, but different beasts.
|
| If we drop down to the lowest level, basic-programming-
| types are about one thing - interpreting what is otherwise
| a pile of bits in memory. Without any notion of the
| difference, how would you interpret the difference between
| characters and integers and floating points? There is
| nothing about the ones and zeroes to tell you. So the first
| thing you learn is to write something like `char a = 'b';`
|
| Dependent types (and related type theory constructs) do get
| used for this in languages built from the ground up with
| that as a theoretical foundation, but they have their basis
| in ideas that are more related to formal verification and
| logic.
|
| And that's where the divide comes in.
|
| Using types to pick a codec for some bytes and using them
| to verify systems are very, very different mindsets.
|
| And we simply call both "types".
| kelnos wrote:
| That's an excellent point. "Do we interpret these 8 bytes
| as a 64-bit integer or a double-precision floating point
| value?" is "typing", but it's hugely different from
| defining a typeclass that describes a monad and then
| implementing it for a list type.
| akiselev wrote:
| _> This comment and many others in this thread seem to be
| missing something._
|
| I think they're also shoehorning their experiences. Some
| coders are cogs in giant tech companies that emphasize code
| quality, others are on teams in large business in an
| unrelated field, others are solo hobbyists, and still others
| are the only tech guys at their medium or small business.
| Some write code to run a business, others write code to probe
| the mysteries of the universe. Some write life or death
| firmware that'll survive for decades, others create landing
| or promo pages that will be deleted next month and are
| subject to the whims of the marketing department. Those are
| all vastly different contexts for a programmer and each
| requires its own set of trade offs vis a vis typing.
|
| For example, I couldn't care less about strong vs weak or
| static vs dynamic typing at my current frontend job because
| the stakeholders don't know what they want, stuff changes
| rapidly, and there's little I can reuse from one request to
| the other but I was a full blown static typing crusader at my
| last job where I worked on a payment system that had to deal
| with schizophrenic regulations.
| kelnos wrote:
| > _I think they 're also shoehorning their experiences._
|
| Yup, agreed. I first learned to program in the late 80s
| (when I was around 7 or 8 years old) using BASIC, and my
| first part-time programming job in college was a mix of C
| and Java. All of my EE and CS programming coursework was
| done in C, C++, or (pre-generics!) Java.
|
| It is really hard for me to put my feet in the shoes of
| someone who switched careers in their 20s or 30s by joining
| a bootcamp that teaches node, HTML, and CSS, and helps them
| find web dev jobs.
|
| Their journey is so different from mine that I have very
| little ability to guess as to what should be easy or hard
| for them to do as they grow in their career.
|
| Having said that, I still do believe that everyone who
| wants to write code should learn about static typing
| eventually, and the sooner they're introduced to the
| concept, the easier it will be for them to integrate it
| into their mental model of how software works.
| spideymans wrote:
| >The author isn't claiming to have had an informed opinion of
| types. They're saying that they found learning about types to
| be difficult and stressful. That's a real problem that I
| think people who understand types forget.
|
| I don't understand how one can be a great (or even half-
| decent) SWE with such an aversion to learning something so
| common and foundational as types.
| Frost1x wrote:
| After working in the industry for many years, I have
| aversions to learning many things. Usually, it's clearly a
| failed recycled idea with a small twist, poor approach to a
| problem, or someone selling new shiny.
|
| I have no aversion to learning something when it shows
| potential value, but you must explain the value without
| gimmicks. Maybe typing hasn't been well sold to this
| person. The new thing I learn should make my life easier,
| not harder. If you don't apply a filter, cargo cult and
| marketing nonsense will sweep you away in a world hidden in
| unnecessary complexity to make a few bucks.
|
| If learning and using something new adds more stress and
| difficulty and little-to-no benefit than life without it,
| I'll pass. When it comes to typing... I don't think that's
| the case. Typing can be annoying when you first use it (I'm
| sure I complained a lot) but it's well worth it when you
| need a stable maintainable codebase.
| mdoms wrote:
| > They're saying that they found learning about types to be
| difficult and stressful
|
| No, they're saying that types (which they don't understand)
| are "over-engineering". This is, frankly, not acceptable to
| me.
| jolux wrote:
| They're describing how they felt _before_ learning about
| types.
| mdoms wrote:
| Yes. Like I said.
|
| > I'm glad the author was able to move on from this, but
| it is utterly pervasive in some parts of our industry.
| kelnos wrote:
| Not the parent, but I think it's possible to simultaneously
| believe two things:
|
| 1) It is completely understandable that, considering how easy
| it is to for a new programmer to get started in a
| dynamically-typed language (and that those languages are
| pushed very hard as beginner-friendly), many developers have
| a hard time grasping the idea of static typing and how to
| apply it to code, because their mental model just never
| included that, and changing mental models is hard for
| everyone.
|
| 2) It is absolutely horrifying that this is the state of new-
| developer education (or the lack thereof) in our industry,
| and I would put this on the (long) list of reasons why
| software in general is so unreliable.
|
| I give the OP a lot of credit for writing about his journey,
| and by doing so making himself vulnerable to criticism. And
| it makes me really happy that he was able to not only
| eventually see the benefits of typing, but concretely
| articulate some of the benefits he found helpful[0]. That,
| IMO, is a sign of a solid developer who is willing to expand
| his skills and change his mind when given new information.
| But from a structural standpoint, I wish he had better
| mentorship when he started out and had never fallen into the
| "typing is bad" camp in the first place.
|
| [0] "Making impossible states impossible" is something that I
| sometimes still struggle to impress upon developers with
| years of experience under their belts. The compiler is there
| to help you and catch your mistakes before you even check in
| the code, if you give the type system enough information to
| do so.
| rowanG077 wrote:
| This is wrong. Dynamically typed languages still have types
| that need to be understood by the developer. They are only
| checked at runtime and not at compile time.
| jpgvm wrote:
| JS the language isn't great but it's JS the culture that is the
| real problem.
|
| There is a subset of JS codebases that are good, well
| engineered and written by people that understand the languages
| faults and limitations but the list is incredibly small and
| even smaller still now Joyent isn't really around anymore.
|
| If there was one ecosystem I wish I never needed to touch again
| it would be JS but unfortunately it's become so pervasive that
| isn't really a tenable position anymore.
| rovek wrote:
| > JS the language isn't great but it's JS the culture that is
| the real problem.
|
| This is the money quote of the thread for me. From the
| perspective of someone whose main language has been JS or TS
| for about 8 years, it's getting worse since some of the
| biggest names in the discipline just seem to be people with
| large social followings giving terrible advice. This advice
| is then eaten up by hoardes of bootcamp alumni who have been
| given a loose understanding of React and unleashed on the
| world as "junior developers".
|
| But maybe I'm just cynical.
| spideymans wrote:
| >JS the language isn't great but it's JS the culture that is
| the real problem.
|
| I'm happy you bring this up. Us developers have a tendency to
| blame bad code on poor tooling/languages or on individual
| developers or organizations. Not enough attention is given to
| cultural factors within various ecosystems that systemically
| induce bad coding practices.
| radicalbyte wrote:
| It's the same thing with PHP (and Ruby). You can write
| reasonable code in it, the problem is that the engineering
| culture leaves a lot to be desired.
|
| In Java, the engineering culture is strong but stagnant.
|
| Python is toxic, it's full of scientists, the engineering is
| bad (but a little better than PHP because the community is of
| a higher calibre).
| 29athrowaway wrote:
| In the movie Minority Report, there is a scene where the
| protagonist is blindfolded and opens a fridge that contains
| one fresh and one spoiled version of each item.
|
| Eventually, he bites a spoiled sandwich with mold and drinks
| spoiled milk.
|
| That is the best analogy for npm.
| svachalek wrote:
| That's true to a point but it depends on perspective. On a big
| team with a mix of experience levels, you are going to want to
| put up as many barriers to mistakes as possible and it doesn't
| matter how much it slows anyone down because it can't be more
| than dealing with the problems will be.
|
| But less people, smaller projects, higher experience levels,
| and better testing are all factors that shift the balance
| between effort and expected return. Before TypeScript came
| around I wrote multiple 5-10k loc apps alone in JS and the
| number of bugs that TypeScript would have caught in those was
| pretty minimal. Working on a team of 5 on apps twice that big,
| I see errors that TS could catch in almost every single file.
| aeturnum wrote:
| I think one of the sources of this kind of attitude is
| experience with type systems that are clumsy or slow to use.
| This goes equally for languages without type declarations and
| those with.
|
| Personally, the two things I informally look for are:
|
| * Does the language allow instant-to-a-human static analysis so
| I can see warnings when I'm passing the wrong type to a call?
|
| * Will this language allow me to leave sections (almost always
| something I get off the wire) with minimal / no type
| information in order to come back to it later?
|
| Typing is hugely powerful for avoiding problems. I've done a
| lot of work in Python, which I think has missed huge
| opportunities to introduce a more robust type-checking system.
| My current favorite is Elixir / Erlang, which I think uses
| pattern matching and static analysis to balance strong typing
| v.s. weak typing wins. It's interesting to compare Elixir to
| Elm. Elm has a much stronger type system, which means I almost
| never pass the wrong thing, but it also makes dealing with
| unstructured data much more frustrating.
| fallingknife wrote:
| I worked on one of those code bases. The team thought fixing
| endpoints where the ORM was being used incorrectly and
| generating N+1 queries was "premature optimization."
| bqmjjx0kac wrote:
| Yikes. The only way I could imagine this being okay is if N
| is bounded and small, or if the DB is SQLite.
| mdoms wrote:
| The term "premature optimization" has been weaponized in the
| industry at large. Especially in front end development. And
| it really, really shows.
| hajile wrote:
| I'd say that's only partly true.
|
| Even at large companies, there's often pressure to deliver
| quickly and often. Throwing out large parts of the UI and
| starting over to please the marketing department is SOP at
| a lot of places too.
|
| If it were a normal desktop application, they would throw a
| 30-man team at the problem, but because "it's just a web
| page/site", it'll be a team of 3-5 people and the time
| tables will be pushed up.
|
| When you combine these problems, it's no wonder that a lot
| of JS devs view almost anything that isn't a new
| deliverable as overly-optimized.
| akiselev wrote:
| It's especially ironic considering the source of the
| phrase:
|
| _> Programmers waste enormous amounts of time thinking
| about, or worrying about, the speed of noncritical parts of
| their programs, and these attempts at efficiency actually
| have a strong negative impact when debugging and
| maintenance are considered. We should forget about small
| efficiencies, say about 97% of the time: premature
| optimization is the root of all evil. Yet we should not
| pass up our opportunities in that critical 3%. -Knuth_
|
| It's like that cliche "it's only a few bad apples" from the
| proverb "a few bad apples spoils the bunch."
| trixrabbit wrote:
| I've been using typescript for years and one complaint I have is
| that it hides really powerful features of prototype based
| programming and make javascript look like a normal class based
| language.
| hocuspocus wrote:
| Are there big companies still doing untyped JS at scale out
| there?
|
| I'm not a frontend person and I always disliked dynamic type
| systems. But I vaguely remember the skepticism when Angular moved
| to TS. To me it made a lot of sense that most projects at Google,
| MS and the like would hugely benefit from a language that is kind
| of a C# on the JS runtime. And in 2021 I see TS pretty much
| everywhere, but maybe I'm missing something?
| jakub_g wrote:
| In my team people object to TS due to a few things: additional
| complexity, additional build step, build time increase, copy-
| pasting code around (to console, code snippets etc.) does not
| work anymore (but last time we talked it was soon after
| coffeescript -> esmodules migration and I guess everyone was
| tired of coffeescript which might have affected the mood).
|
| There's no unanimous consensus that TS is all gold; some people
| who are fine with types don't like certain TS implementation
| details and in fact some devs start saying out loud that
| sometimes it's very difficult to fight TS with certain
| constructs.
|
| Something that's gaining popularity and what I'm trying lately
| is using JS + jsdoc annotations more thoroughly, which gives
| the niceties of TS (when using vscode) without the downsides
| and heavy compilation step:
|
| https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
| gcmeplz wrote:
| I loathed typescript at first because of the heavy
| compilation step, but setting it up to compile only when it
| was necessary (building for production), and to transpile the
| rest of the time (running tests, starting a server locally)
| made a huge difference for our team. A slow compilation step
| really is a huge cost!
| lucasyvas wrote:
| While gaining popularity, JS + JSDoc is misguided and not a
| solution. The compiler is what is required to actually
| enforce standards within a team - otherwise what you have is
| a completely informal process.
|
| I don't think type docs are useless - on the contrary, they
| are super helpful while migrating. But I think this trend is
| indicative of a different issue - what we are really seeing
| is more of a protest that JS needs native optional type
| support as soon as possible.
| mentioal wrote:
| I have noticed a lot of people who grew up only using dynamic
| typing languages are discovering static typing for the first time
| and proclaiming it to be the "new way forward" or something.
| Kids...
| antihero wrote:
| What exact value does this comment add other than some weird
| attempt to give off some air of superiority?
|
| A lot of of people are "discovering" TypeScript because it is
| the first widely used and well supported attempt to bring
| static typing to a language that is currently the only
| mainstream option for programming to web.
| jokethrowaway wrote:
| I had the opposite experience. I like languages with static types
| a lot and I used to be a fan of TypeScript.
|
| After using it for a few OSS projects and professionally, I came
| to the conclusion that, if I need types, I'll use a real
| statically typed language if I need types and JS for what doesn't
| matter.
|
| TypeScript works but: - it's a major pain to work with if your
| dependencies don't have type definitions - if another developer
| in your codebase left a hole somewhere you won't be able to rely
| on your types, you'll get runtime errors and you basically ruin
| the capability to reason around your code - it's slow (hopefully
| deno's efforts will bring some news in that regard)
|
| TL;DR: TypeScript should be much stricter and don't compromise
| with JS.
| deckard1 wrote:
| bingo.
|
| TypeScript had absolutely _no_ excuse to keep JavaScript,
| beyond the misguided idea that because so many JavaScript
| developers exist that it should be easy to get them to learn
| types.
|
| First, they introduced a compiler. At that point, you may as
| well toss out JavaScript for a better language that actually
| has nice type syntax. TypeScript syntax is _horrible_. It makes
| JavaScript completely unreadable in many places.
|
| Second, JavaScript developers tend to be the type that have
| never learned another language _beyond_ JavaScript. They come
| from bootcamps and elsewhere that only teaches JavaScript and
| that 's all these developers know. They do not have the
| experience necessary to not make a mess of TypeScript's
| structural typing system. You'll end up with incoherent ad hoc
| types all over the place. You still have JavaScript's ad hoc
| data flow all over the place, but now you have TypeScript
| yelling at you while trying to formalize the mess and failing
| badly at it.
|
| What I find is that often when people say they like TypeScript
| they really mean they like VSCode.
| gagege wrote:
| Yep. My experience as well. In a large project, the types often
| end up being pointless since you can easily just ignore them at
| any time, and the "compiled" JS will just happily go along with
| it all. Eventually I hit a point where I wonder why we're even
| bothering using types.
| Blackthorn wrote:
| Still not a typescript fan here. It feels like a half-baked
| language because of the insistence of not having a runtime (even
| though some information makes it through to the underlying
| js...so this objection of theirs isn't total). In a usual typed
| language, you could extract the type of an intersection type
| using pattern matching. But you can't do that in typescript.
| Instead you get to pick the most relevant ugly hack for your
| situation.
|
| Typescript feels like every one of its features has some catch,
| and it's very irritating.
| foobarian wrote:
| The issue that broke the camel's back for me was when I saw
| "cstomerName is not defined" in production. I just could not
| accept that it is OK to live with tools that let that happen.
| tvphan wrote:
| Did you go back to using JS?
| elwell wrote:
| > broke the camel's back for me was when I saw "cstomerName
|
| Truly the camelcase's back...
| boredpandas777 wrote:
| It takes a lot of mental and emotional capital in the creative
| process to produce something that is truly wonderful. Microsoft
| is systemically incapable of approaching creative perfection.
| Very few are.
| mdoms wrote:
| This is extremely unfair and rude. The TS language designer
| and lead developer is Anders Hejlsberg, who is also the chief
| architect of C# and Delphi. C# has been tremendously
| successful and, in my opinion, is truly wonderful as a
| general purpose language.
|
| In the case of Typescript the team were working under very
| difficult constraints - the language must maintain strict
| compatibility with Javascript, and the output must be
| executable by a web browser that has never even heard of the
| language.
| hc-taway wrote:
| That the output is (or can be, with the right settings,
| anyway) very reasonable looking JS that would be easy to
| navigate and work on for anyone who'd been working on the
| same project in TS is a huge selling point. It's a nearly-
| instant, high-quality escape hatch if you decide you hate
| TypeScript, even if you're deeply into your project and
| have a ton of TS code already written. It's why comparisons
| to things like CoffeeScript don't hold up well, and (part
| of) why it's easier to sell to technical management than
| something like PureScript. Switching from TS to JS is very
| low-cost.
|
| It's not just that the output is well-formed and sensible
| JS, it's that it's structured so similarly to the TS. With
| a recent EcmaScript version as your output, it's
| practically just the TypeScript with the type-related
| keywords & blocks stripped out.
|
| As much as it could provide more and better features by
| breaking that guarantee, I think it's a brilliant decision
| & guideline, at least until WebAssembly is far more mature
| and the space starts to open up.
| Kinrany wrote:
| It could provide a separate but official and supported
| parsing library. Going back to JS would not be a problem.
| BluSyn wrote:
| My problem with TypeScript is the lack of runtime benefits. Yes,
| you get some benefits of static checks during compile time, but
| at the cost of huge additional effort. This effort _maybe_ makes
| sense for a large project with many team members pushing code,
| but for small hobby projects I think this just makes quick
| iteration far more difficult. To me this defeats the whole
| purpose of using a dynamic garbage-collected language to begin
| with.
|
| If TypeScript was a first-class language, you could do all sorts
| of great runtime optimizations (perhaps a v8 fork will do this
| eventually?). In this case I would absolutely jump all over it,
| even for small hobby projects.
|
| As it is, going from JS -> TS, one might as well just skip the
| extra translation step and just start writing everything in Go or
| Rust, especially for back-end nodejs/deno projects. In these
| languages the runtime benefits makes the abstractions worth the
| effort.
| hanselot wrote:
| Now I just need a guide to solve my anti-javascript and I can
| travel freely through all abstraction levels.
| kgin wrote:
| It's a lot of extra stuff on the screen to help sometimes find a
| very specific type of bug in a different way than you would have
| found it otherwise.
| ilaksh wrote:
| TypeScript feels like a kludge and requires giving up some of the
| useful aspects of JavaScript.
|
| I feel that things like using WebAssembly to bring in other
| languages, or compiling down Ocaml/Ocaml-like languages such as
| with BuckleScript or Reason etc. is more appealing than
| TypeScript to me.
| drazulay wrote:
| For me it was "How a repl hater became a Julia lover..."
|
| Multiple Dispatch, I love it.
| stupidcar wrote:
| Here's a project idea I'd really like to see: A version of
| Chromium, targeted at web developers, that is is modified to
| accept TypeScript syntax as a variant of JavaScript.
|
| This hypothetical browser wouldn't perform type-checking, just be
| able to parse TS syntax and convert it to plain JS, in the same
| way tools like Babel do.
|
| This would let you use TypeScript without the need for any
| transformation pipeline in dev. You could then separately run
| TypeScript in a console to get async checking. Then only when you
| build for production do you run everything through a
| compiler/bundler to get a plain JS bundle that will work in
| everyone's browsers.
| speedgoose wrote:
| After being an early adopter of TypeScript, I decided to skip
| TypeScript in my next projects for a few years because I thought
| it was not worth the hassle. I remember spending a lot of time in
| DefinitelyTyped to create and fix type definitions, and when
| Babel and ES6 were popular I used that instead.
|
| I recently changed my mind and started to migrate a large
| JavaScript codebase to TypeScript, in strict mode. I consider my
| team to be composed of only good developers but still, I found so
| many bugs. I still spend time on DefinitelyTyped definitions, but
| if you do more than prototyping or work on a project also
| developed with other people for more than a few weeks, TypeScript
| is for sure worth it in my opinion.
| wwww4all wrote:
| Typescript is more popular now because projects are migrating
| more and more business logic layer to front end. Thus the need
| for type safety and static analysis.
|
| I'm agnostic about Typescript. Bare JavaScript is very
| efficient and optimized language, well suited for smaller
| projects.
|
| However, when project scope balloons up, then Typescript
| becomes more useful. It's way of enforcing descriptive comments
| a code, than trying to be a type safe language.
| qwerty456127 wrote:
| Although I like the actual language of TypeScript more than
| JavaScript, it still doesn't feel useful enough to justify its
| usage. Computers' native language is Assembly but we rarely use
| it and prefer to code in C/Python/whatever because this is so
| much easier (+ portable). Browsers' native language is JavaScript
| and it isn't much harder nor less powerful than TypeScript, nor
| does it provide a seriously different perspective (like
| Clojure/Elm/Reason do) so why not just use JavaScript (you have
| to understand it anyway)?
| macspoofing wrote:
| The value of TypeScript is a function of the codebase size,
| size of team, and length of time for maintaining this codebase.
|
| If you're an individual, putting together dinky little web
| sites that you don't need to maintain for years - the value of
| TypeScript over JavaScript isn't as pronounced.
|
| If you have a web application that counts hundreds of thousands
| of lines of code, maintained by team of developers over many
| years - JavaScript does not cut it ... at all.
| toolslive wrote:
| TypeScript is definitely an improvement over pure Javascript.
| However, you can still lie about the types and it still allows
| you to write nonsense (even in pure TS). >
| const x = 'xxxx' > if(x === undefined) { >
| console.log('never happens') > }
|
| will compile without any problems
| mschuetz wrote:
| That example looks like a strawman to me. In practice, x would
| probably originate from outside the function, as a parameter or
| class member, and there is a good chance it could hold the
| value null or undefined. Seems like way too much additional
| work with little to no benefit to make the compiler track
| things like that through the whole application. Worse, the
| variable state could intentionally be hardcoded to try things
| and it would be weird if the compiler would error because the
| variable is never set to undefined, when I might be hardcoding
| it to undefined later on.
| curtisf wrote:
| TypeScript _does_ detect some such impossible conditions (like
| `x === 1`), so this omission is intentional.
|
| I think this is partly necessitated by one particularly large
| soundness hole in TypeScript, which is that expressions are
| typed as though dictionary and array subscripts are always in
| bounds: function foo(arr: number[]) {
| const m: number = arr[3]; // typechecks if (m ===
| undefined) { // this IS reachable
| console.log("arr does not contain key `[3]`"); }
| }
|
| The alternative would be forcing all array and record accesses
| to have type `whatever | undefined`, despite the fact that
| almost all such accesses are clearly in bounds.
|
| This is in fact now a part of TypeScript behind a flag since
| 4.1: https://devblogs.microsoft.com/typescript/announcing-
| typescr...
|
| Adding a compile-time bounds-checker to TypeScript to find
| cases where the `| undefined` is unnecessary would definitely
| be helpful and interesting, but would do nothing to help
| TypeScript's reputation of being difficult to wield and slow to
| compile.
|
| It's also not an easy problem to solve, due to the semantics of
| JavaScript arrays: let a = []; a[5] =
| "five"; console.log(a.length); // 6
| console.log(a[4]); // undefined (!)
| adenozine wrote:
| I just can't bring myself to use curly bracket languages. I can't
| make a good enough case for any of them.
|
| I read way too much code to make myself read code that's not
| beautiful.
| shadowgovt wrote:
| Do you use a different solution for frontend web development,
| or is frontend web development a domain you get to avoid?
| jdxcode wrote:
| that's an odd take considering the article is comparing JS/TS
| which have an identical amount of curly brackets
| tester34 wrote:
| what are alternatives?
|
| python's tabs?
| recursive wrote:
| lisp?
| ben509 wrote:
| The major choices that avoid braces are indentation and
| keywords.
|
| Indentation's upsides are less line noise. In my opion, while
| there's less noise, there's less symmetry, so it's a wash on
| the beauty count.
|
| Indentation breaks many tools, especially the way amateur
| coders use them. They're frequently showing code snippets by
| copy-pasting into web pages that strip indentation.
|
| Notably, the standard pylint rules insist on two lines
| between functions and classes because the extra whitespace
| helps people find things. That same whitespace you get if you
| close a function with a single brace...
|
| Keywords are surprisingly nice. Lua does them very well:
| function foo() doSomeStuff end
|
| You get rid of the pointless { at function, and you have a
| simple "end" when you're done.
| badtakemaybe wrote:
| Oh boy do I have a programming language for you. Enjoy!
| https://en.wikipedia.org/wiki/Curl_(programming_language)
___________________________________________________________________
(page generated 2021-03-02 23:02 UTC)