6 ms·

I've noticed there's a lot of talk on twitter about making TypeScript be an agreed upon best practice for frontend web developers. I'm glad TypeScript is doing

• sqs 7y ago
  Do you believe static typing is harmful (to the type of company you want to join), or is this a personal preference (which is totally valid)? Honestly curious.
  • wintorez 7y ago
    I don't like static typing, as a personal preference. I like the rapid prototyping of dynamic typing, and a type system often times gets in the way of that.
    • wwwigham 7y ago
      Even if you don't opt in to full TypeScript, please do remember that the same engine powering the TypeScript language is also what powers IDE support and completions for JS in vscode and VS, so even if you're not using TypeScript _the language_, you're potentially still using TypeScript, _the static analysis tool_. Even without opting in to full type safety, having those tools available can still be a huge quality of life improvement.
    • wvenable 7y ago
      That's funny, I don't like dynamic typing for the same reason. Rapid prototyping without types makes the whole process so much slower! With dynamic typing, you don't get the immediate feedback of breaks when making frequent changes. You don't get the safety of automatic refactoring. You don't get auto-complete and easy of discovery of APIs. I really don't understand the idea behind dynamic typing being better for prototyping unless that "prototype" is only a few lines long.
  • benatkin 7y ago
    It's a personal preference. Being able to make, fix, and guard against (with testing) type errors is a freedom that I've enjoyed with ruby, python, lisp (scheme/racket), scheme, and JavaScript.
    • deleted 7y ago
      [deleted]
    • deleted 7y ago
      [deleted]
  • Ididntdothis 7y ago
    I am starting to wonder if the preference static vs dynamic is some kind of character trait like introvert vs extrovert. I personally prefer static typing and use it to my advantage during development but I know very smart people who hate static typing and think it impedes them. Both sides have valid arguments but seem to prioritize things differently. However I think it’s important to have used both for a while so you can make a good decision what you prefer.
    • ajxs 7y ago
      At first I thought I was going to read "I am starting to wonder if the preference static vs dynamic is some kind of character trait like intelligent vs ignorant", which would have been much closer to the truth. I think you're very incorrect. Maintaining a codebase of any sufficient size and complexity without static typing is a poor investment of development time. It can be done, obviously, but it's a nightmare. Typescript is a bandaid for web-development's biggest open wound. Taken on its own merits ( ignoring the garbage ecosystem, terrible tooling, etc ) Typescript is a decent enough language, but it's not a clever one. Is Typescript better than vanilla Node.js? Absolutely. Is it worth introducing to an area without Node.js? Absolutely not. If your project is any more complex than a four page CRUD app, in my opinion you're better off going with a bigger player like Java/.Net. These languages are more robust, more mature, there's better tooling, better community... The list goes on.
      • Ididntdothis 7y ago
        I am not sure if I want to work with you if you think it’s about “intelligent vs ignorant"... Even though I seem to be in the “intelligent” camp by your definition.
        • ajxs 7y ago
          That's fine.
    • Old_Thrashbarg 7y ago
      > However I think it’s important to have used both for a while so you can make a good decision what you prefer. Exactly, I always found static typing to be annoying clutter and Python seemed to work even at scale. I removed the few type hints the codebase had. Then I had to spend a year in C# professionally. At the end, I was fine with both, no preference. Then I jumped back into our Python and only then realized the utility of typing - it felt chaotic, my (IntelliJ) IDE was no longer helping me and every time I had Prod type related bug, it feeling dumb. Ended up type hinting the critical parts of the Python.
  • eleclady 7y ago
    Personal preference is valid only to an extent. At a certain point, with enough scale/team size/complexity TypeScript becomes invaluable. I've worked on projects that would have been intractable without TypeScript. This is a huge problem with front-end. Too many people who don't know what they don't know, and think their use case is the only one.
  • lewisl9029 7y ago
    I've found that the kinds of errors that static typing guards against are often things that would have been trivial to debug and fix in the first place (mostly things like typos). Given that you have a good system for monitoring errors in production and a low friction deploy process so you can quickly and easily fix errors when you discover them, I feel these kinds of errors are honestly not worth guarding against in most contexts outside of those where getting everything perfectly right the first time is a hard requirement (health, fintech, other safety-critical industries, etc). Of course, most companies lack either or both of these ( a good system for monitoring errors in production and a low friction deploy process), so they use static typing as a clutch to try to reduce the chance of errors making it into prod simply because they know they'd be slow to fix/detect those errors. That's a poor reason to choose static typing IMO, but I think that's by far the most common reason.
    • almostdeadguy 7y ago
      I think “debugging errors in prod” is not generally how I like to spend my working life, with or without excellent logging and tooling for surfacing errors.
      • lewisl9029 7y ago
        How this works in practice is usually 1) deploy some change, 2) errors start showing up that correspond to that change, 3) click a button to revert the change instantaneously (some systems can even do this automatically), 4) debug the change in dev
        • almostdeadguy 7y ago
          There is no way any of this process takes less time to solve than "I got a red squiggle in my editor and fixed the variable spelling". I don't think typos are really the only things type systems fix (type systems provide powerful ways of preventing screw-ups by allowing you to encode invariants about a piece of data and how it may be used), but if typos are indeed the extent of it, it seems unimaginable to me that the process to fix would be faster by going through code review -> CI pipeline -> deploy and then back again, no matter how fast it is to revert a change in production. Honestly that's just the compile-time safety advantage of types, half the time saved in typescript is just not spending time having to read someone else's source code to figure out how a function may be used because cowboy js devs were too lazy to document them (knex is an especially egregious offender in this regard that I thankfully don't have to use anymore).
• 2bitencryption 7y ago
  > I will need to make sure I don't plan on finding job or gig opportunities at the types of companies that are going require the use of TypeScript. If you're really dynamic, the type of company won't matter, right :)
  • benatkin 7y ago
    It's generally pushing towards the type of projects I want to work on anyways, with small codebases, and things broken down into components, and lots of freedom in how to implement things.
    • vnorilo 7y ago
      Sounds like you might enjoy Lisps even more (clojurescript for frontend?). In my experience, that's the pinnacle of dynamically typed.
• rq1 7y ago
  This you will need to explain. :o What kind of griefs static typing is giving you?
  • benatkin 7y ago
    It changes the order in which I think about solving problems, to something I'm less comfortable with.
    • Koshkin 7y ago
      That's understandable - being pestered with error messages early on is not to everyone's taste and can indeed interfere with one's creative process. But can't one always start with JS and switch to TS later?
    • rq1 7y ago
      Isn’t it preferable to start with data modeling? You can disagree but: > Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust. http://www.faqs.org/docs/artu/ch01s06.html#id2878263 http://www.faqs.org/docs/artu/ch01s06.html#id2878263 Statically and strongly typed languages excel exactly at this.
    • ajxs 7y ago
      Is that really true though? To me this sounds more like making the validation of the program an afterthought, at best. Even in very academic mathematical models, introducing types early usually doesn't introduce much of a cognitive burden. I maintain that even when developers don't think that they're reasoning in terms of types, in many cases they are: "This is function 'x'. It takes two items of type 'T', which have to have a member 'a', which is a number. Function 'x' multiples the two 't.a' values together and returns a new 'T' with the result in its 'a' field." If you opted to forego static typing, every step of the above function would require you to validate that you're dealing with the types you think you are. This kind of example isn't even at all uncommon.
• tony 7y ago
  What would be the downsides of TypeScript, from your perspective? In a large codebase, having typings, even basic ones, go a long way. I don't know about the term static typing or if that's what really helps. I also annotate for readabilities sake. For instance, it's nice to know a variable in python is only intended to be 'ACTIVE' or 'INACTIVE': from typing_extensions import Literal ActivityStateLiteral = Literal['ACTIVE', 'INACTIVE'] # Lower in the code, e.g. inside a flask view activity_state = ActivityStateLiteral = request.GET.get('activityState') For TypeScript: type ActivityStateLiteral = 'ACTIVE' | 'INACTIVE' // e.g. react component const activityState: ActivityStateLiteral = props.activityState || 'ACTIVE' That leaves me no doubt when I/a team member comes back 3/6 months later that I'm only dealing with 2 possibilities of what that variable can be (or should be). The intention itself also valuable, even if incorrect.
  • benatkin 7y ago
    For your example, I would prefer a variable called active that can be true or false (True or False in python). This is just an example but I see stuff like this in statically typed projects, where integer enums are used when a string will suffice, and strings are used where booleans will suffice. If I wasn't aware of valid values, I might search my codebase for uses of it. Usually if something is being set to true or false, it's a variable that can be true or false, or true, false, or empty (None in python, null or undefined in JavaScript).
    • ajxs 7y ago
      "I see stuff like this in statically typed projects, where integer enums are used when a string will suffice, and strings are used where booleans will suffice." Typescript has proper enumerated types, so you really shouldn't be using either? Using magic number values for an enum is even poor programming practice in C. You've already listed one reason why you'd use a proper enumerated type over boolean, the fact that NULL is not part of the type's domain. The other big reason is that it is semantically correct. You can limit the type's domain to only values that make sense semantically. No more comments like: // A value of '1' means the missile is armed.
• gvkhna 7y ago
  I think another way to look at some of the benefits of TypeScript is class introspection. By writing your classes in an idiomatic manner, it makes it trivial to see the shape of your api’s without you having to write large amounts of documentation. As well TS compiler will check you’re using the api’s correctly. Huge wins!
  • Scarbutt 7y ago
    For another perspective, the TS compiler which is written in TS has zero classes.
• lacampbell 7y ago
  I quite like static typing, though with some caveats. I strongly believe automated testing is more important. And I am also not afraid to make something an 'any' if it's proving particularly hard to type. Have you considered thinking of static typing as a tool? A kind of ESLint on steroids. The great thing about typescript (or checking JS with the typescript compiler) is that you can set the dynamic/static continuum anywhere you want, pretty much.
• root_axis 7y ago
  A proper type system offers a level of safety and correctness that simply cannot be achieved without one, especially as the complexity of an application grows. Also, the supposed lack of cognitive overhead without a type system is actually a subtle form of technical debt where you move faster because you eschew thinking deeply about your data structures up front, but inevitably pay a bigger price in production when you have to debug data type errors at run-time. The debt has to be paid again by every new developer tasked with working on the project because they have to organically absorb an understanding of the application's data structures that could have been explicitly defined and enforced by the computer. Finally, the extent of defensive programming required to begin to make up for a type system actually adds a ton of extra code itself (e.g. tons of guard blocks testing brittle application values at run time). Not all type systems are created equally, but a code base without types is pretty much always worse than a comparable one with types (the exception being shell scripts and other relatively simple programs that aren't maintained by a team of developers)
• codr7 7y ago
  There are usually plenty of opportunities to infer types and check identifiers etc. at compile time without the need to annotate anything. And the more you annotate, the more opportunities for the compiler to help. I don't have enough TypeScript experience; but from what I've seen, it comes pretty close to providing tools without mandating use and help where it can in the same spirit as Common Lisp. I guess if your company mandates checking all boxes, which unfortunately seems bound to happen sooner or later, that doesn't help; but it's hardly TypeScript's fault. The various Haskell-ish web languages popping up all over the place though, that's a different story. I wouldn't touch those with a ten foot pole. I'm so done with academic hoops.