4 ms·

>Having to compile your javascript sucks. That's why I don't like typescript :) Also because typescript makes things way less understandable than without type

by bacro 8y ago

>Having to compile your javascript sucks. That's why I don't like typescript :) Also because typescript makes things way less understandable than without type annotations

mixedCase 8y ago
>makes things way less understandable than without type annotations Strange proposition. No dev I know who has professionally worked with both would claim the same, even the skeptics long term ended up grokking types as a way to make it easier to understand the intent behind a piece of code, even when they prefer JS for writing, never for reading other people's code. How long have you worked with each? What editor tools have you used for TS? I'm really curious about your experience.
- bacro 8y ago
  I was investigating typescript to use in a react native project and while checking some of the definitions contained in a package in Visual Studio Code (I believe it was react-navigation) the way they were presented was so confusing that I aborted immediately going with typescript. It was a function that returned a function that accepted as a parameter another function and the extra syntax was really taxing to my brain to fully understand what the function was all about. When I removed the extra syntax it was way clearer for me to understand it. Sometimes, pure javascript with a good variable naming is better. Sure, I could use some of static type checking to avoid some bugs but there weren't many bugs that I remember when I was doing the app so I think it didn't impact me too much. Also I am a solo developer in my company, I don't work in a team so it's not a big problem here.
  - com2kid 8y ago
    RN and Typescript is interesting. The getting started, learning curve, and "wtf is happening here" curve is rather high. Especially once you add in Redux and React Navigation. It doesn't help that all of the "getting started with RN and TS!" assume a decent understanding of TS. I eventually got TSX working, but yeah, figuring out what you need to declare to make it all work is not easy. Redux having 5 major ways (or whatever it is) of using it didn't help any. I use the shorthand form of mapDispatchToProps in my connect call, which none of the "TS in Redux" tutorials seem to use. (Why not? It is so much easier and shorter!) I eventually gave up on typing Redux, IMHO the last thing Redux needs is more boilerplate! I rarely have type problems in my Redux code anyway. I probably understand enough to do it now (or maybe not, haven't investigated what typing redux-thunk looks like), but I'm going for "less bugs" not ideological purity in my code. The tl;dr is that you have to declare an interface for your props, an interface for your state, and your props interface has to include a NavigationScreenProp which I honestly declared as navigation: NavigationScreenProp<any>; because I have better things to do in life than spend yet more time trying to figure out how to type something I never actually use. (state is in Redux, so the NavigationScreenProp is of very little use to me) All that said, the one time learning curve was worth it. Typescript definitions can get super complicated though, my 90% use case is preventing typos and allowing for refactoring, so I only type objects I pass around as interfaces and I type functions that have been the source of bugs. Mostly anything that comes from my backend DB I want typed end to end. The majority of my REST endpoints use Typescript to pull from the DB so I just share interfaces across my backend and frontend. It has been worth the hassle just for that.
  - mixedCase 8y ago
    >It was a function that returned a function that accepted as a parameter another function and the extra syntax was really taxing to my brain to fully understand what the function was all about. When I removed the extra syntax it was way clearer for me to understand it. Interesting. Was that your first time reading TS? Higher order functions, specially when combined with optional arguments, in JavaScript are an easy source of bugs for me but never when using TS, since I can simply see what I'm being asked for and getting back. >Also I am a solo developer in my company I actually forgot that scenario. Yes, unless you have adapted to the type-driven development way of thinking you will hardly see many of the benefits of maintaining code that has types vs code that does not. When you're the one that wrote the code, you'll have an unfair advantage at understanding how the author meant the code to be used. When you don't have that luxury, types can be a great aid in most situations. Of course, it's a question of time and codebase size until you break your own preconditions when changing something, but you'll not notice how the type system can save you from that until it you actually learn how to take advantage of it. It's a catch-22, so if you're curious and want to see what's meant by "taking advantage of the type system", I can only suggest you that you give something like Elm a try. There you'll see many times in the first couple of weeks what types can do for you when changing code.
    - bacro 8y ago
      I have developed in many static typed languages like C# and Java in my career but now I am being converted to web and mobile development so I know the advantages and disadvantages of a static type system. In my experience, I am much more productive in a dynamic instead of a static type system when implementing frontends. For you to have an idea, this react native project I developed alone was sold to the client to be implemented in 3 months. The catch was I didn't have any experience in mobile development and I was still developing another web project. So I had to learn react native, ios and android development as fast as possible to do a medium-sized app. Having more friction using typescript for me was a killer. But for a backend I would certainly have used static types as it's way more critical.
pault 8y ago
I think you are confusing "less understandable" with unfamiliar.

by bacro 8y ago

>Having to compile your javascript sucks. That's why I don't like typescript :) Also because typescript makes things way less understandable than without type annotations

mixedCase 8y ago

>makes things way less understandable than without type annotations Strange proposition. No dev I know who has professionally worked with both would claim the same, even the skeptics long term ended up grokking types as a way to make it easier to understand the intent behind a piece of code, even when they prefer JS for writing, never for reading other people's code. How long have you worked with each? What editor tools have you used for TS? I'm really curious about your experience.

bacro 8y ago
I was investigating typescript to use in a react native project and while checking some of the definitions contained in a package in Visual Studio Code (I believe it was react-navigation) the way they were presented was so confusing that I aborted immediately going with typescript. It was a function that returned a function that accepted as a parameter another function and the extra syntax was really taxing to my brain to fully understand what the function was all about. When I removed the extra syntax it was way clearer for me to understand it. Sometimes, pure javascript with a good variable naming is better. Sure, I could use some of static type checking to avoid some bugs but there weren't many bugs that I remember when I was doing the app so I think it didn't impact me too much. Also I am a solo developer in my company, I don't work in a team so it's not a big problem here.
- com2kid 8y ago
  RN and Typescript is interesting. The getting started, learning curve, and "wtf is happening here" curve is rather high. Especially once you add in Redux and React Navigation. It doesn't help that all of the "getting started with RN and TS!" assume a decent understanding of TS. I eventually got TSX working, but yeah, figuring out what you need to declare to make it all work is not easy. Redux having 5 major ways (or whatever it is) of using it didn't help any. I use the shorthand form of mapDispatchToProps in my connect call, which none of the "TS in Redux" tutorials seem to use. (Why not? It is so much easier and shorter!) I eventually gave up on typing Redux, IMHO the last thing Redux needs is more boilerplate! I rarely have type problems in my Redux code anyway. I probably understand enough to do it now (or maybe not, haven't investigated what typing redux-thunk looks like), but I'm going for "less bugs" not ideological purity in my code. The tl;dr is that you have to declare an interface for your props, an interface for your state, and your props interface has to include a NavigationScreenProp which I honestly declared as navigation: NavigationScreenProp<any>; because I have better things to do in life than spend yet more time trying to figure out how to type something I never actually use. (state is in Redux, so the NavigationScreenProp is of very little use to me) All that said, the one time learning curve was worth it. Typescript definitions can get super complicated though, my 90% use case is preventing typos and allowing for refactoring, so I only type objects I pass around as interfaces and I type functions that have been the source of bugs. Mostly anything that comes from my backend DB I want typed end to end. The majority of my REST endpoints use Typescript to pull from the DB so I just share interfaces across my backend and frontend. It has been worth the hassle just for that.
- mixedCase 8y ago
  >It was a function that returned a function that accepted as a parameter another function and the extra syntax was really taxing to my brain to fully understand what the function was all about. When I removed the extra syntax it was way clearer for me to understand it. Interesting. Was that your first time reading TS? Higher order functions, specially when combined with optional arguments, in JavaScript are an easy source of bugs for me but never when using TS, since I can simply see what I'm being asked for and getting back. >Also I am a solo developer in my company I actually forgot that scenario. Yes, unless you have adapted to the type-driven development way of thinking you will hardly see many of the benefits of maintaining code that has types vs code that does not. When you're the one that wrote the code, you'll have an unfair advantage at understanding how the author meant the code to be used. When you don't have that luxury, types can be a great aid in most situations. Of course, it's a question of time and codebase size until you break your own preconditions when changing something, but you'll not notice how the type system can save you from that until it you actually learn how to take advantage of it. It's a catch-22, so if you're curious and want to see what's meant by "taking advantage of the type system", I can only suggest you that you give something like Elm a try. There you'll see many times in the first couple of weeks what types can do for you when changing code.
  - bacro 8y ago
    I have developed in many static typed languages like C# and Java in my career but now I am being converted to web and mobile development so I know the advantages and disadvantages of a static type system. In my experience, I am much more productive in a dynamic instead of a static type system when implementing frontends. For you to have an idea, this react native project I developed alone was sold to the client to be implemented in 3 months. The catch was I didn't have any experience in mobile development and I was still developing another web project. So I had to learn react native, ios and android development as fast as possible to do a medium-sized app. Having more friction using typescript for me was a killer. But for a backend I would certainly have used static types as it's way more critical.

pault 8y ago

I think you are confusing "less understandable" with unfamiliar.