21 ms·

TypeScript 3.6

• benatkin 7y ago
  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 well because there are certainly a lot of talented and dedicated developers working on it, but I really don't want to use static typing, even if there is a lot of type inference happening. 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.
  • 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.
• cageface 7y ago
  Typescript has massively improved my quality of life working on JS projects. I occasionally run into constructs that are difficult to type but most of the time TS just works. Thanks to all the people behind this project for all your work!
  • MuffinFlavored 7y ago
    interface IntMap { [name: string]: int } interface StringMap { [name: string]: string } I really feel something like that should come standard so I didn't have to rewrite it so many times when coding in the wild.
    • AaronFriel 7y ago
      These are: type IntMap = Record<string, int>; type StringMap = Record<string, string>;
    • nojvek 7y ago
      You can always make a generic Interface ObjMap<T> = {[name: string]: T} And the use it as const intMap: ObjMap<int> and voila!
    • WorldMaker 7y ago
      If you get a chance, you should also consider moving more towards ES2015 Map<K, V> and Set<V> objects instead of object literals as property maps. Browser support for Map/Set is pretty universal at this point (and easy to polyfill in the worst case that you need to support IE <= 10, which why?). You get better performance in some cases, and better handling of edge cases (strange string keys, accidental prototype inheritance, key name / language keyword clashes).
• _hardwaregeek 7y ago
  Disclaimer: I'm currently interning at Microsoft. Y'know, I can't think of many companies that have as much support for open source programming language development. Between Roslyn, TypeScript, what's left of F#, the Language Server Protocol, Chakra, V8, etc., Microsoft has a veritable powerhouse of compilers and PL development. Google has Go and Dart, but as far as I can tell, the development process is contained in Google mailing lists. Apple has Swift and LLVM and Mozilla has Rust, but each of those footprints isn't as large as the combo of .NET and TypeScript. I mean, ffs, Richard Stallman is coming to speak at Microsoft. Well, Microsoft Research. But still. Stallman. That's insane.
  • breck 7y ago
    > Richard Stallman is coming to speak at Microsoft. Well, Microsoft Research. But still. Stallman. That's insane. Wait, what? That's very interesting. I love Microsoft's language tools (TS, Vs Code, C#, LSP, ...) and I used to work on Azure, but I'm still very skeptical. For these 3 reasons: 1. https://en.wikipedia.org/wiki/Open_Letter_to_Hobbyists https://en.wikipedia.org/wiki/Open_Letter_to_Hobbyists 2. https://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_cancer/ https://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_... 3. http://techrights.org/2009/06/25/bill-gates-office-patents/ http://techrights.org/2009/06/25/bill-gates-office-patents/ Until BillG himself comes out and says Intellectual Slavery laws should be changed, I won't fully trust MSFT's long term motives here.
    • seph-reed 7y ago
      I've heard bad things about working at Microsoft. Perhaps from people masquerading as (ex)employees, though I suspect not. I do use TS, and it's enabled me to have a bit more peace of mind than I might otherwise have. It's also totally wrecked projects before (Loopback + TS = "as any" * 1000). In any case, the sun could shine out Microsofts ass and I'd still be skeptical of them. Windows has an abhorrent amount of code smell to it, and (as stated) I haven't heard good things about working there. Really would rather they weren't any more of a mega corp than they already are. Really don't trust them. But TS is nice.
• breck 7y ago
  Nice to see the TypeScript Playground (https://typescript-play.js.org https://typescript-play.js.org) getting some love. Makes it easier to see what all options are available in TSC.
  • kbd 7y ago
    Frustrating, though, that there's no good repl for TypeScript.
    • JoBrad 7y ago
      I've used ts-node, with pretty good results. https://www.npmjs.com/package/ts-node https://www.npmjs.com/package/ts-node
      • breck 7y ago
        Ts-Node is great. Startup times are slow though. 30x slower. Example for same script using node vs tsnode: "user 0.11s" "user 0m2.839s". Am I doing something dumb?
        • swsieber 7y ago
          Dumb? No, incorrectly maybe though. Ts-node has to scan files for types upon startup - there are various knobs to control this I think. Mu bet is that it's the culprit.
        • kbd 7y ago
          Ts-node is honestly pretty terrible. By-default you need to disable some errors that make sense in code but not in a repl. "You just imported this thing but didn't use it yet, ERROR", which means that nobody uses the thing. Granted, I'm pretty spoiled by how excellent ipython is, but clearly no one actually uses ts-node. It doesn't even remember history between sessions, and they have no interest in making that work, even deferring to rlwrap.
          • 7y ago
• gvkhna 7y ago
  TypeScript is such a fundamental milestone in the web and javascript community. (coming from Microsoft too!) I really do hope front end communities converge on typescript in an idiomatic manner.
  • uvtc 7y ago
    There are many nice modern languages that compile to JavaScript. Personally, I like [Haxe](https://haxe.org/ https://haxe.org/), which compiles to many other target platforms/languages as well. Here's a [comparison of Haxe and TypeScript](https://blog.onthewings.net/2015/08/05/typescript-vs-haxe/ https://blog.onthewings.net/2015/08/05/typescript-vs-haxe/).
    • gvkhna 7y ago
      Thanks for the share! That's a great one that I will read into more, but I do want to add while TS isn't perfect. I think one of the biggest advantages has been community buy-in. A language like TS would be no where if the community wasn't adopting it and increasing its adoption through network effects. If you use TS and include a library that is written in TS, there's a huge advantage to having accurate typings. Many libraries that don't use TS and add typings later usually have conflicting community provided types. I think a list of highly adopted libraries written in TS would be great. One I recently realized was TS is immutable.js!
    • veidr 7y ago
      I'm all for more new and innovative languages, but I think the key thing about TypeScript is not that it compiles to JavaScript, but (to quote basarat's great free book[1]) that "TypeScript is just JavaScript with docs". TypeScript is a strict superset of JavaScript, so all our real-world JavaScript is TypeScript already — you can literally just change the file extension from .js to .ts. Now, our existing JS code probably isn't great TypeScript, since it doesn't leverage those great machine-and-human-readable docs (the type system). So, compared to code written from the beginning with TypeScript, our existing code doesn't go as far toward reducing the likelihood that we humans miss something while programming, and introduce a bug. And we probably won't get all the automated assistance that we could be getting from our machines, in terms of auto-complete, as-you-type errors and warnings, automatic imports, etc. But for projects coming from JavaScript, it's hard to overstate the importance of being able to start from a place where all your existing code works like it always has, and you can choose the right mix of when/if to upgrade your legacy JavaScript code to TypeScript. I think that design decision is probably the key to TypeScript's explosive adoption and popularity. A lot of languages could give you strong typing, and the increased code correctness and massively improved tooling that comes along with that — but I don't know of any others that literally require no code changes to start adopting them. Of course, the choice to remain a superset of JavaScript does place some significant limitations on what kinds of cool improvements TypeScript can add. It can't break JavaScript code so lots of cool things one might imagine won't be possible. Still, a great tradeoff IMO. [1]: https://github.com/basarat/typescript-book https://github.com/basarat/typescript-book
• lacampbell 7y ago
  Is anyone else using javascript + jsdoc + .d.ts files, and using typescript as a kind of linter? I'm really enjoying this setup, I get to use tools that work on JS source code without sticking them in a build typeline. I find it easier to read as well - the function declarations are nice and short as all the type annotations are in a comment above. Also one less transpilation step.
  • lhnz 7y ago
    I do this, too -- sort of. I prefer for type-checking to give useful feedback than for it to act as a control-gate, because the latter increases the length of the feedback loop between writing code and seeing its behaviour. Rather than having the TypeScript compiler not even transpile code into JavaScript unless it perfectly passes type-checking, I use Babel to transpile and run the TypeScript type-checker separately (with the `--noEmit` flag).
  • ryanianian 7y ago
    Yes this has been a lifesaver. We have a nodejs application without a lot of obvious structure and lots of ad-hoc objects thrown around. Gradually adding .d.ts files, adding tsdoc comments (`@param {SomeType} foo`), and running `tsc` at test-time has already caught numerous bugs that otherwise would have required lots of unpleasant time with the debugger. We just mandated that all new code get written in typescript (we transitioned everything to run via `ts-node` before actually using any typescript and it was super painless). Any "significant" changes to existing code (>= 10 lines diff usually) must either first convert the code to TS or add types via tsdoc. This is a "first step" PR that lets us confidently make changes in subsequent PRs after type info is there to help. Forces us to pay down tech-debt in a real way that has immediate payback.
  • lhorie 7y ago
    I do this extensively with Flow comment syntax at work and it's great. I tried it w/ Typescript on a side project recently, but I found it to be a bit limited (e.g. @callback doesn't play well with RORO pattern) and the syntax is a bit clunky. But having runnable code without a build step is definitely a very big plus for me.
• namelosw 7y ago
  Nice, finally, there are typed generators. That could possibly enable us to write something like do-notation in Haskell in a type-safe way.
• AgentME 7y ago
  I was really hoping optional chaining would be in, but turns out that's scheduled for the next minor release, 3.7. The generator improvements are appreciated, though I wish it went even further and supported uses like redux-saga better (so the return type of a yield expression could depend on the type of the value that was yielded).
  • lf-non 7y ago
    Yeah, this is something I had hoped for as well. Mobx-state-tree [1] also makes use of generators for asynchronous tasks and typescript's inability to infer types of values returned from a yield is a pain. But fortunately, atleast in this particular case the usage semantics are really close to async/await so I have had success using a babel macro [2][3] to transform async functions to generators which restores type-safety. This is of-course a hack but has proven to work fairly well in practice. [1] https://github.com/mobxjs/mobx-state-tree https://github.com/mobxjs/mobx-state-tree [2] https://github.com/kentcdodds/babel-plugin-macros https://github.com/kentcdodds/babel-plugin-macros [3] https://github.com/ts-delight/async-to-generator.macro https://github.com/ts-delight/async-to-generator.macro
  • veidr 7y ago
    Oh, it's good to hear that feature is coming in 3.7! That's something I really miss on a regular basis. Where did you learn it's scheduled for 3.7?
    • city41 7y ago
      https://github.com/microsoft/TypeScript/issues/16#issuecomment-515160784 https://github.com/microsoft/TypeScript/issues/16#issuecomme...
• jbaudanza 7y ago
  I love that static typing has come to the Javascript ecosystem and I hope that some of these concepts make their way upstream into future versions of ECMAScript.
• Humphrey 7y ago
  I've been using Typescript for the past year and it's definitely one of the best typing systems I've used (Rust might be up there too - once I've conquered the battle of the borrow checker). The way it handles nullable references and understands code to ensure I'm using values correctly, and the editor integration. Microsoft, I'm impressed! Yes it takes me "slightly" longer to write code initially, but that time is recouped almost straight away by the intellisense suggestions, refactoring, and code checking. My code often "just works" the first or second time. Therefore after using Typescript for a couple of projects, I was excited to start adding type hints into our backend Python code, but I was quite disappointed by the value that they added. Perhaps I'd just become spoilt by Typescript.
  • julien_c 7y ago
    Yes, Python's type system is nowhere near Typescript, and are closer to docblock annotations.
    • h8hawk 7y ago
      How? How it's not close to typescript? I mean what are features that python's type annotation (and mypy) lacks in comparison to typescript?
      • jakear 7y ago
        Conditional types and the `infer` directive, I’d imagine. Which end up being very powerful.
      • bobbylarrybobby 7y ago
        For one, they're not actually enforced
        • NateEag 7y ago
          http://mypy-lang.org/ http://mypy-lang.org/ Disclaimer: I have not used MyPy. I'm just interested.
• wry_discontent 7y ago
  I feel like I'm the only one, but I don't care for Typescript. After working with it for a while, the type checker ends up being painful to work with. I'm using React, and it's difficult to write higher order components that are correctly typed. Additionally, probably related, styled components often get messed up with the type system.
  • fendy3002 7y ago
    Personally I prefer to not use typescript on react (I don't have any experience on it and it seems like a hassle). I use it on mobx / redux instead. However it's a godsend for nodejs.
    • tomduncalf 7y ago
      It’s not really a hassle at all and adds great value with compile time checking of proptypes etc. Give it a go. If you use MobX especially you should find it really quite straightforward - I’m not sure what typing Redux is like these days, didn’t used to be much fun but I’ve not used Redux for about 3 years
  • steve_taylor 7y ago
    You're not the only one. It's an absolute pain dealing with incorrect and incomplete type definitions and lack of TypeScript examples for libraries. If all libraries I used were built and documented using TypeScript, I'd probably use it.
  • ncphillips 7y ago
    All Typescript does is highlight how bad the Higher order Components pattern is. Don’t do it, use hooks or render props instead.
  • abritinthebay 7y ago
    I used to be the same way and I found it came from overuse of types in some applications I worked on. I know the TypeScript working group at Netflix found the same thing. Generally it's best to let its type inference do as much work as possible and then add types to help it. Simple input and output types in functions can help a lot too. Too many types in TypeScript is, imo, a net negative to a project. It sounds counter-intuitive but has been borne out by practical use cases at multiple large companies that I've worked at.
• boarnoah 7y ago
  I think I got off to a bad start with Typescript. Decided to add it to on the frontend of a bog standard Vue + Vuex erp app. Its in quite a bad state with regard to how you have to structure the code to ensure Typescript doesn't throw linting errors (and even then I found the intellisense gained was not much more powerful than what my IDE already provides). My conclusion has been that TypeScript maybe great for extremely large frontend apps, where you want to do a lot of data wrangling on the client itself (with defined Entities etc...). Kind of a shame really since I'm using .NET core on the backend and loving it
  • skeletonjelly 7y ago
    > Its in quite a bad state with regard to how you have to structure the code to ensure Typescript doesn't throw linting errors (and even then I found the intellisense gained was not much more powerful than what my IDE already provides). Can you expand on this? I currently write my apps in .net core/Vue/Typescript and use the same stack for small or large so I might be able to assist
  • Rapzid 7y ago
    Last I checked Vue was not working correctly with certain, newer TypeScript versions. Not sure if they fixed it up but it was that way since late last year through at least a couple months ago. I also got the impression the Vue 3 work was helping issues like that to stagnate.
• oliyoung 7y ago
  Nothing has improved my day-to-day work life more in the last 5 years than typescript. It's joy. Just, joy.
• cutler 7y ago
  Typescript only solves one of Javascript's two main problems. What really makes JS an abysmal experience is it's lack of a standard library. Compile-to-JS languages are in a unique position to solve this problem so I urge Microsoft to focus on a curated set of reliable libraries which can constitute a stdlib for JS. There are plenty out there already so it shouldn't be difficult.
  • megaman821 7y ago
    I feel like lodash and date-fns is like 80% of what I want out of a standard library. I mostly use the built-in fetch but Axios is nice too. I also tend to use js-cookie and uri.js because the browser has horrible APIs for working with cookies and urls.
• anonytrary 7y ago
  If anyone here has switched from TypeScript to Flow or vice versa, care to comment on how that's been working out? I use flow at work, and I am starting to really love it, but it seems like most people prefer TypeScript to flow.
• whsheet 7y ago
  While I think that TS offers probably the best type system out ther, eg way better than Go's, I'd love to see a more balanced view on TS in discussion threads like this one. TS is a must for long-term code which should be maintainable in several years by teams. Any lead engineer with responsibility for some crucial app and dev team not using TS is doing something wrong. But using TS comes at a cost. Even when you are savvy in TS you won't bang out code like with pure JS. But especially in prototyping phases you need this fast-paced coding. And using TS or any type system slows you down, even when you are familiar with typed languages. Often your final code faced many iterations and I sometimes like to introduce TS later, usually at a point where I just need types but not always and as default from the first key press. In early stages I still try to test ideas, algorithms and their general feasibility and a fast 'mind-to-code' interface is crucial and types would stay in the way then. Further, finding the right type can take some time, just google what type a React's children prop should be and find long discussions. Welcome to the TS-what-type-is-actually-xy-rabbit-hole. And declaring everything as any shouldn't be the answer. A big drawback are also TS error messages which are super hard to grasp. You get there and you even find tutorials just for understanding TS error messages but it's unecessarily infuriating. Moreover, VSCode, its TS language server are amazing pieces of tech but here you face also strange behaviours. Types get full Intellisense support while interfaces don't which doesn't make sense. So you need still to go the definition yourself and it's not that IDE-like feeling you hoped for or people told you. In my setups, I use TS instead of Babel but use both JS and TS files in one code base depending on the requirements and situation. So, my message is, yes TS is great, has probably the best type system but the tonality by its community/users needs to be much more balanced and less fanboy-ish. I just can't take devs serious who praise TS to death. This is just not true. More, maintainable code is also not just created by a type system but also sane architectures (eg React) and many other factors. Types won't make bad code maintainable. So, types have their place but not everything in TS-land is shiny.
  • filleduchaos 7y ago
    I wouldn't exactly call what TypeScript has the best type system out there. It's deliberately unsound, doesn't enforce full static type-checking, _and_ doesn't provide for runtime checks (there are third-party libraries, but if you're bringing up third parties one might as well argue that JavaScript has a great type system because TypeScript exists). A lot of it is due to the project's overwhelming priority being as easy to interop with JS as possible, but I've found that quite a few of TypeScript's fancier features are sugar that's entirely up to the developer to enforce.
• kabes 7y ago
  I know typescript is really popular around here. And I do like it for autocompletion and refactoring. But am I the only one who thinks typescript makes code unreadable? It looks so messy. I can understand a piece of normal js way faster than the same code with types. Don't have this problem with, for example, java. Maybe it's the syntax with the colons or the fact that I'm used to types appearing before the name instead of after...
  • nevi-me 7y ago
    Automatically ignoring types comes with intuition. After a while, you start seeing beyond the types. I hope and assume this is normal, because I've experienced this type blindness in all types languages that I've used. It's interesting that you don't have this problem with Java, is it because Java always has types, while TS is lenient?
  • cjbprime 7y ago
    It's also possible that you're providing types that inference was capable of working out on its own. You shouldn't be seeing type annotations everywhere.
  • afraca 7y ago
    I applaud Microsoft for popularizing gradual typing , bringing types to the js world is an enormous task, both technical and (js-)societal. Regarding your syntax criticism: I quite agree. I really really like the path chosen by Haskell. Types are obviously a major part of Haskell, but there you just separate the type signature from the implementation. emap :: (DynGraph gr) => (b -> c) -> gr a b -> gr a c emap f = gmap (\(p,v,l,s)->(map1 f p,v,l,map1 f s)) where map1 g = map (first g) (Of course there are other helping things like type synonyms, which TS also supports) type UPath = [UNode]
    • mcbits 7y ago
      I don't find that remotely readable. By that I mean that nothing in the code gives me the slightest inkling of what kind of command I would type or button I would click, expecting this code to run in response.
• sAbakumoff 7y ago
  typescript is the best thing that happened with web development within 2010-2020.
• rossmohax 7y ago
  Typescript is only language I came across, where documentation is in release notes, so to learn about feature you have to crawl all of them and there is nowhere else to find it.
• siempreb 7y ago
  JS was designed to be dynamically typed, just as Python and others, it is at the root of those languages. I can totally imagine that with all the big web apps of today type safety is a thing for some people working in large code bases. But that doesn't mean all dynamically typed languages need to perish. Why not create a beautiful statically typed language from scratch that compiles to WebAssembly? Why do we have to introduce a type system on top of an old and flawed language? I mean, maybe you'll get some type safety with TS, although it won't be 100%, but what about the future? How long will this toy technology stay? For me, this is so typical for the JS community, jumping the boat in a whim. And IMHO this creates the famous Javascript fatigue. Learning disposable things. Therefore I moved back to C++ after 6 years of web development, learning things that actually make sense and that I can use for years to come. Not having to work with all those temporary black boxes that are praised by the community.
  • barberousse 7y ago
    >For me, this is so typical for the JS community, jumping the boat in a whim. This is Microsoft's product, the company famous for keeping legacy going, hardly the 'JS community'
• stunt 7y ago
  TS is probably the best solution to JS problems today. And something like project Deno may even push it one step further.
• dmix 7y ago
  > For those unfamiliar, TypeScript is a Finally, a release notes that explains what the product is!