11 ms·

I'm hesitant to work in any JavaScript code base that isn't using TypeScript at this point. Two years ago, it was painful to use as any early release is but the

I'm hesitant to work in any JavaScript code base that isn't using TypeScript at this point. Two years ago, it was painful to use as any early release is but the benefits were obvious. My biggest wish for TypeScript is that it was easier to use experimental flavors that supported JS features currently being considered, such as the pipeline operator proposal.

d357r0y3r 8y ago
Yeah, agreed. If I were looking for a regular job, I would probably filter employers based on whether they use TypeScript or not at this point (assuming it was some JavaScript-adjacent project). I'm not sure if there's really a good way of doing this sort of filtering.
TheAceOfHearts 8y ago
TypeScript was released in 2012, I wouldn't call a 4 year old tool an early release. And if you were already using Webpack picking it up was as easy as adding a loader. IMO, using such early proposals isn't worth the risk in production. Especially for proposals that are so young that they haven't even settled on a clear spec as to its behavior, like the pipeline operator.
- egeozcan 8y ago
  Sorry this is self promotion but I think it's relevant if you need something like the pipe operator now: https://github.com/egeozcan/ppipe https://github.com/egeozcan/ppipe It's also ironic that I couldn't write this in Typescript because I simply couldn't figure out how. These days when I use my helper, I just use any and cast the result. It sucks but until I figure out how to type proxies and use variadic generic type parameters (if and when these are supported) I don't have another solution.
  - leppr 8y ago
    The "official" Typescript solution to variadic type parameters is to write a bunch of overloads covering the most frequent cases, e.g. from 1 to 5 parameters.
    - steadicat 8y ago
      TypeScript 3.0 fixed this: https://blogs.msdn.microsoft.com/typescript/2018/07/30/announcing-typescript-3-0/#tuples-and-parameters https://blogs.msdn.microsoft.com/typescript/2018/07/30/annou...
      - mpawelski 8y ago
        no yet really. But it's good first step to have "true" variadic types support. Right now I think you still can't represent stuff like `Promise.all` without many numbers of overloads.
- TulliusCicero 8y ago
  > TypeScript was released in 2012, I wouldn't call a 4 year old tool an early release. Goddamn time travelers, stop messing with chronology!
  - TeMPOraL 8y ago
    4-year old by the time GGP found it "painful to use as any early release", which was 2 years ago.
- mattferderer 8y ago
  I could be slightly off on when I first used it by a year or two. Years start to blend together. It's almost 2019 already! Maybe I shouldn't have used exact numbers. Either way it wasn't Typescript itself that made it difficult. There wasn't as large of community yet, documentation was much less, editor support wasn't as great and very few packages had type definition files. Definitely typed could show all or most of their packages on GitHub at the time and many were incomplete. That was the sole way to get any type definitions. Agreed with your comment on early proposals. Still would like to have the option to use it and double check the transformation of how it outputs. And not everything needs to be for production use. Writing for fun is an enjoyable hobby.
helixten 8y ago
I hope the work they did with the Babel team with help with this. https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-babel-7/ https://blogs.msdn.microsoft.com/typescript/2018/08/27/types...
- kylecordes 8y ago
  I'm really eager to see availability of some extra features via this new pathway. But I am less excited about projects containing TypeScript plus the large number of transitive dependencies from a typical Babel set up; I've been greatly enjoying TypeScript instead of that.
  - crooked-v 8y ago
    For my part, my web projects have generally ended up with both Typescript and Babel because of old-browser-support reasons, so integrated parsing simplifies things for me.
  - untog 8y ago
    100% agreed. It was incredibly liberating to move from Babel with its byzantine level of configuration and plugins to "just run tsc". So much easier to reckon with - Typescript is Typescript is Typescript.
  - pdelgallego 8y ago
    I am looking forward to see some production ready versions of RY latest project Deno "A secure TypeScript runtime on V8" https://github.com/denoland/deno https://github.com/denoland/deno
    - 52-6F-62 8y ago
      Written in Go rather than C++ no less. Edit: wait it looks like they’ve changed to all Rust with C++ for the libraries. I haven’t looked at the codebase since the spring. Am I crazy that i could have sworn it was written in Go previously?
conover 8y ago
The codebase powering www.twitch.tv utilizes TypeScript and I can’t imagine working on a project of any significant size without leveraging it going forward.
- a_humean 8y ago
  So I know you also use React extensively at twitch, so how are you finding react and typescript working together? I've been using the two together recently and its been great. Like you I don't think I could ever go back to not using typescript for anything but the smallest projects. However, often times I've found some common react patterns to be difficult to express in typescript. Namely default props and high order components. The type signatures I'v ended up with for my HoCs aren't as simple as I'd like, but I guess there is no way getting around that. I've actually started to prefer render props over HoCs simply because the type signatures are simpler. Still no idea how to handle default props correctly.
  - williamdclt 8y ago
    Maybe use the defaultProps HOC from recompose? Or take example from it!
  - Alexendoo 8y ago
    For the default props side of things, as of typescript 3 and the latest @types/react it should work as you would expect: https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#support-for-defaultprops-in-jsx https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in...
    - a_humean 8y ago
      I saw that for default props, but can I use it yet? The React typescript definitions are still on 2.8 [1], and I imagine that they plan to stick with 2.8 until maybe the next major react release? I have no idea where people discuss things like react types for DefinitelyTyped. Github issues seem like a mess due to the sheer number of different projects sitting in a single repo. [1] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/1d9679b2dcf7c9643d623b626c0820f84eaa8d7e/types/react/index.d.ts#L22 https://github.com/DefinitelyTyped/DefinitelyTyped/blob/1d96...
MBCook 8y ago
Have you spent any real time with Flow? As I’m starting to get into the modern front end world… I do want the safety of a stronger type system but it doesn’t look like the React ecosystem has really decided which way to go. TypeScript is popular. But flow was developed by Facebook and so it’s obviously heavily used by some of the top people. I’ve only been reading about them, I haven’t chosen to use one yet. But I’ve been leaning on flow since it’s developed by the React team at Facebook.
- _frog 8y ago
  From my personal experience, Flow prioritises soundness in its type system, and thus can catch some bugs that TS won’t, but the TS tooling and editor support is drastically better than Flow’s. Edit: oh and it’s worth noting that I’ve had much more luck finding TS definitions for third party packages than I have with Flow.
  - MBCook 8y ago
    Could you expand some more on the tooling/editor support? I’ve only done a cursory look. My editor (IntelliJ) supports both to some level. Webpack/Babel do too. I’m very new to writing React and modern front end JS so it’s quite possible there are things that I should be looking out for that I don’t even know about.
    - nojvek 8y ago
      Typescript compiler architecture is quite different to flows. Typescript was written from the get go to provide really fast and accurate intellisense to IDEs. The newer refactoring powers are super nice too. Most ides just ask typescripts language service “hey, my user’s cursor is here, what should I show for code completion?” I think that’s what differentiates TS from flow. Typescript thought about the whole developers workflow while flow is just a compile time typechecker.
      - alangpierce 8y ago
        To Flow's credit, their language server does provide IDE features: https://github.com/flowtype/flow-language-server#supported-features https://github.com/flowtype/flow-language-server#supported-f... I still have found TypeScript to be an overall more pleasant developer experience, though.
jhall1468 8y ago
That's the main reason I use Flow almost exclusively. I don't like sacrificing really useful features for the sake of a cleaner code base.
- deleted 8y ago
  [deleted]
sureaboutthis 8y ago
The vast majority of web development is done using JavaScript without TypeScript despite headlines on HN and reddit.
- gspetr 8y ago
  The vast majority of web development was also done without jQuery in 2007 despite headlines on HN and reddit. That did not mean jQuery wasn't better than the ugly ad-hoc kludges in vanilla JS most web developers used at the time.
  - sureaboutthis 8y ago
    Whether jQuery, which is written in vanilla JavaScript, was better or not has nothing to do with my point.

d357r0y3r 8y ago

Yeah, agreed. If I were looking for a regular job, I would probably filter employers based on whether they use TypeScript or not at this point (assuming it was some JavaScript-adjacent project). I'm not sure if there's really a good way of doing this sort of filtering.

TheAceOfHearts 8y ago

TypeScript was released in 2012, I wouldn't call a 4 year old tool an early release. And if you were already using Webpack picking it up was as easy as adding a loader. IMO, using such early proposals isn't worth the risk in production. Especially for proposals that are so young that they haven't even settled on a clear spec as to its behavior, like the pipeline operator.

egeozcan 8y ago
Sorry this is self promotion but I think it's relevant if you need something like the pipe operator now: https://github.com/egeozcan/ppipe https://github.com/egeozcan/ppipe It's also ironic that I couldn't write this in Typescript because I simply couldn't figure out how. These days when I use my helper, I just use any and cast the result. It sucks but until I figure out how to type proxies and use variadic generic type parameters (if and when these are supported) I don't have another solution.
- leppr 8y ago
  The "official" Typescript solution to variadic type parameters is to write a bunch of overloads covering the most frequent cases, e.g. from 1 to 5 parameters.
  - steadicat 8y ago
    TypeScript 3.0 fixed this: https://blogs.msdn.microsoft.com/typescript/2018/07/30/announcing-typescript-3-0/#tuples-and-parameters https://blogs.msdn.microsoft.com/typescript/2018/07/30/annou...
    - mpawelski 8y ago
      no yet really. But it's good first step to have "true" variadic types support. Right now I think you still can't represent stuff like `Promise.all` without many numbers of overloads.
TulliusCicero 8y ago
> TypeScript was released in 2012, I wouldn't call a 4 year old tool an early release. Goddamn time travelers, stop messing with chronology!
- TeMPOraL 8y ago
  4-year old by the time GGP found it "painful to use as any early release", which was 2 years ago.
mattferderer 8y ago
I could be slightly off on when I first used it by a year or two. Years start to blend together. It's almost 2019 already! Maybe I shouldn't have used exact numbers. Either way it wasn't Typescript itself that made it difficult. There wasn't as large of community yet, documentation was much less, editor support wasn't as great and very few packages had type definition files. Definitely typed could show all or most of their packages on GitHub at the time and many were incomplete. That was the sole way to get any type definitions. Agreed with your comment on early proposals. Still would like to have the option to use it and double check the transformation of how it outputs. And not everything needs to be for production use. Writing for fun is an enjoyable hobby.

helixten 8y ago

I hope the work they did with the Babel team with help with this. https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-babel-7/ https://blogs.msdn.microsoft.com/typescript/2018/08/27/types...

kylecordes 8y ago
I'm really eager to see availability of some extra features via this new pathway. But I am less excited about projects containing TypeScript plus the large number of transitive dependencies from a typical Babel set up; I've been greatly enjoying TypeScript instead of that.
- crooked-v 8y ago
  For my part, my web projects have generally ended up with both Typescript and Babel because of old-browser-support reasons, so integrated parsing simplifies things for me.
- untog 8y ago
  100% agreed. It was incredibly liberating to move from Babel with its byzantine level of configuration and plugins to "just run tsc". So much easier to reckon with - Typescript is Typescript is Typescript.
- pdelgallego 8y ago
  I am looking forward to see some production ready versions of RY latest project Deno "A secure TypeScript runtime on V8" https://github.com/denoland/deno https://github.com/denoland/deno
  - 52-6F-62 8y ago
    Written in Go rather than C++ no less. Edit: wait it looks like they’ve changed to all Rust with C++ for the libraries. I haven’t looked at the codebase since the spring. Am I crazy that i could have sworn it was written in Go previously?

conover 8y ago

The codebase powering www.twitch.tv utilizes TypeScript and I can’t imagine working on a project of any significant size without leveraging it going forward.

a_humean 8y ago
So I know you also use React extensively at twitch, so how are you finding react and typescript working together? I've been using the two together recently and its been great. Like you I don't think I could ever go back to not using typescript for anything but the smallest projects. However, often times I've found some common react patterns to be difficult to express in typescript. Namely default props and high order components. The type signatures I'v ended up with for my HoCs aren't as simple as I'd like, but I guess there is no way getting around that. I've actually started to prefer render props over HoCs simply because the type signatures are simpler. Still no idea how to handle default props correctly.
- williamdclt 8y ago
  Maybe use the defaultProps HOC from recompose? Or take example from it!
- Alexendoo 8y ago
  For the default props side of things, as of typescript 3 and the latest @types/react it should work as you would expect: https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#support-for-defaultprops-in-jsx https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in...
  - a_humean 8y ago
    I saw that for default props, but can I use it yet? The React typescript definitions are still on 2.8 [1], and I imagine that they plan to stick with 2.8 until maybe the next major react release? I have no idea where people discuss things like react types for DefinitelyTyped. Github issues seem like a mess due to the sheer number of different projects sitting in a single repo. [1] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/1d9679b2dcf7c9643d623b626c0820f84eaa8d7e/types/react/index.d.ts#L22 https://github.com/DefinitelyTyped/DefinitelyTyped/blob/1d96...

MBCook 8y ago

Have you spent any real time with Flow? As I’m starting to get into the modern front end world… I do want the safety of a stronger type system but it doesn’t look like the React ecosystem has really decided which way to go. TypeScript is popular. But flow was developed by Facebook and so it’s obviously heavily used by some of the top people. I’ve only been reading about them, I haven’t chosen to use one yet. But I’ve been leaning on flow since it’s developed by the React team at Facebook.

_frog 8y ago
From my personal experience, Flow prioritises soundness in its type system, and thus can catch some bugs that TS won’t, but the TS tooling and editor support is drastically better than Flow’s. Edit: oh and it’s worth noting that I’ve had much more luck finding TS definitions for third party packages than I have with Flow.
- MBCook 8y ago
  Could you expand some more on the tooling/editor support? I’ve only done a cursory look. My editor (IntelliJ) supports both to some level. Webpack/Babel do too. I’m very new to writing React and modern front end JS so it’s quite possible there are things that I should be looking out for that I don’t even know about.
  - nojvek 8y ago
    Typescript compiler architecture is quite different to flows. Typescript was written from the get go to provide really fast and accurate intellisense to IDEs. The newer refactoring powers are super nice too. Most ides just ask typescripts language service “hey, my user’s cursor is here, what should I show for code completion?” I think that’s what differentiates TS from flow. Typescript thought about the whole developers workflow while flow is just a compile time typechecker.
    - alangpierce 8y ago
      To Flow's credit, their language server does provide IDE features: https://github.com/flowtype/flow-language-server#supported-features https://github.com/flowtype/flow-language-server#supported-f... I still have found TypeScript to be an overall more pleasant developer experience, though.

jhall1468 8y ago

That's the main reason I use Flow almost exclusively. I don't like sacrificing really useful features for the sake of a cleaner code base.

deleted 8y ago
[deleted]

sureaboutthis 8y ago

The vast majority of web development is done using JavaScript without TypeScript despite headlines on HN and reddit.

gspetr 8y ago
The vast majority of web development was also done without jQuery in 2007 despite headlines on HN and reddit. That did not mean jQuery wasn't better than the ugly ad-hoc kludges in vanilla JS most web developers used at the time.
- sureaboutthis 8y ago
  Whether jQuery, which is written in vanilla JavaScript, was better or not has nothing to do with my point.