Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript support added to Create React App

github.com

Post reply on HN
Print view View original

71–80 of 90 posts

Re: TypeScript support added to Create React App

#71

Post by h1d »

smt88 wrote: post #39
ergothus wrote: post #10

Earlier quoted context omitted.

> There are no downsides but so many upsides I've not used TS, but from what I've read the types from TS are not js compatible, so once you go into TS you have code that just isnt js. (As opposed to flow, where you can just have it not be used) While transpiling is normal, I'm as hesitant to tie myself to TS as I am to, say, a non-standard decorators syntax. Anyone coming to me with "there are no downsides" in such a…

You're wrong. Once you transpile the TS, you have standardized ECMAScript. Want to stop using TS? No problem. Just delete your TS files and work from your JS files. And, beyond that, TS is intended to be a superset -- never incompatible, just "extra". Finally, you can use TypeScript the same way Flow is used, through comments. Tying yourself to TS isn't really something you can do, and there's zero risk in using it.…

> No problem. Just delete your TS files and work from your JS files.

This is quite an irresponsible comment.

The JS code generated isn't really meant for editing especially if you used a feature that isn't present on the runtime (like async/await in browser), not to mention all the formatting is rearranged.

If you're willing to go back to JS, you want to keep the original source.

Re: TypeScript support added to Create React App

#72

Post by lima »

h1d wrote: post #70
netcraft wrote: post #6

offtopic, but I'm in the middle of trying to convince my small team to pick up typescript for a new significant node backend for our company. It seems like a no-brainer from my perspective. Compilation is fast, we would use `strict` but would allow devs to default to `any` if the types got too hard. There are no downsides but so many upsides - better refactoring, intellisense, documentation, communication of interfac…

Out of curiosity, how do you let everyone take the build process in a consistent way? I've only used TS as a single dev but with multiple editors and they could have different version of TS from the other, I wonder what's the best way. Do you just help a guy with vim/vs code/IntelliJ/sublime/etc to set up to use auto TS compile and ask everyone to stick with a specific TS version? Or is it better to use something lik…

We have the entire development environment in Kubernetes. IDE is only used for code editing, which is then synced to the cluster. Auto-generated code and node_modules are synced back for code completion.

That way, everyone has an identical dev environment and we don't depend on any particular IDE (want to use Emacs? sure). No setup steps, just running one script to create a new namespace with all applications running inside. Broke it, messed up an upgrade? Just destroy and redeploy.

We hacked Arcanist[1] to run linters in the cluster. Modified a TypeScript file? "arc lint" will make sure your TypeScript pod is up-to-date and run the linter there, etc.

We're using custom tooling which is faster than https://github.com/GoogleContainerTools/skaffold, but it's the same approach.

Thinking about open sourcing it.

[1]: Phabricator's CLI client

Re: TypeScript support added to Create React App

#73

Post by 255kb »

h1d wrote: post #70
netcraft wrote: post #6

offtopic, but I'm in the middle of trying to convince my small team to pick up typescript for a new significant node backend for our company. It seems like a no-brainer from my perspective. Compilation is fast, we would use `strict` but would allow devs to default to `any` if the types got too hard. There are no downsides but so many upsides - better refactoring, intellisense, documentation, communication of interfac…

Out of curiosity, how do you let everyone take the build process in a consistent way? I've only used TS as a single dev but with multiple editors and they could have different version of TS from the other, I wonder what's the best way. Do you just help a guy with vim/vs code/IntelliJ/sublime/etc to set up to use auto TS compile and ask everyone to stick with a specific TS version? Or is it better to use something lik…

usually you try to stick to the Typescript version defined in dependencies. In VSCode for example you can easily switch Typescript from editor version to project dependencies version. And most of the time what we do where I work is only triggering `tsc` commands (or any other dependency command) through NPM scripts, because they use the dependency installed locally instead of any other globally installed or editor specific version.

Re: TypeScript support added to Create React App

#74

Post by h1d »

eksemplar wrote: post #56
netcraft wrote: post #6

offtopic, but I'm in the middle of trying to convince my small team to pick up typescript for a new significant node backend for our company. It seems like a no-brainer from my perspective. Compilation is fast, we would use `strict` but would allow devs to default to `any` if the types got too hard. There are no downsides but so many upsides - better refactoring, intellisense, documentation, communication of interfac…

Does it add value? I manage enterprise and we’ve tested typescript and found it added little value, but brought in complexity that slowed production. Type safety isn’t worth having more complex prototypes, and having to keep up with both JS and Tyoescript, for us. It’s very easy and forgiving to do a proof of concept though, because it integrates so easily into your existing code base. Just be sure it actually adds r…

Not sure why you're downvoted but for me vanilla JS is like cars running without traffic lights, you know it when you crash but with TS, chance of doing something wrong, like parameters have wrong key or type, before it runs gets less especially under multiple devs.

And then, you can code with TS on the server side as well as take that approach and write with modern language features on the browser side where you still have to write in ES5 (IE11) if it isn't for transpilation and develop with 1 consistent language throughout.

Re: TypeScript support added to Create React App

#75

Post by h1d »

lima wrote: post #72
h1d wrote: post #70

Earlier quoted context omitted.

Out of curiosity, how do you let everyone take the build process in a consistent way? I've only used TS as a single dev but with multiple editors and they could have different version of TS from the other, I wonder what's the best way. Do you just help a guy with vim/vs code/IntelliJ/sublime/etc to set up to use auto TS compile and ask everyone to stick with a specific TS version? Or is it better to use something lik…

We have the entire development environment in Kubernetes. IDE is only used for code editing, which is then synced to the cluster. Auto-generated code and node_modules are synced back for code completion. That way, everyone has an identical dev environment and we don't depend on any particular IDE (want to use Emacs? sure). No setup steps, just running one script to create a new namespace with all applications running…

Having the build on server side seems like the way when you don't have to ask each dev to set stuff up and it will be a hassle to change environment once deployed. I also auto upload my TS to server and let the server handle it but I do wonder if there's an easy way for average shops to deploy.

It seems everyone is doing their own way of build process from local build, gulp, webpack or custom server processing and all has their downsides.

It does seem like a hurdle when this process isn't easy for everyone involved when switching to TS.

Re: TypeScript support added to Create React App

#76

Post by smt88 »

h1d wrote: post #71
smt88 wrote: post #39

Earlier quoted context omitted.

You're wrong. Once you transpile the TS, you have standardized ECMAScript. Want to stop using TS? No problem. Just delete your TS files and work from your JS files. And, beyond that, TS is intended to be a superset -- never incompatible, just "extra". Finally, you can use TypeScript the same way Flow is used, through comments. Tying yourself to TS isn't really something you can do, and there's zero risk in using it.…

> No problem. Just delete your TS files and work from your JS files. This is quite an irresponsible comment. The JS code generated isn't really meant for editing especially if you used a feature that isn't present on the runtime (like async/await in browser), not to mention all the formatting is rearranged. If you're willing to go back to JS, you want to keep the original source.

"Irresponsible" is a bit of an overstatement, don't you think? The TS team explicitly says their goal is to generate readable JS, unlike (for example) Clojure or Scala.

Also, the async/await thing isn't an issue if you target the latest ECMAScript version. That's the only really ugly thing, and it's been easily avoidable for over a year.

Re: TypeScript support added to Create React App

#77

Post by jey »

scottmf wrote: post #29
karmakaze wrote: post #11

BTW, anyone here used ReastReason, BuckleScript is it? I've been meaning to look into it but don't have a sense of the payoff. I read that it can coexist which is a great feature. Wonder how it compares to a TypeScript workflow.

As much as I want to love it, I’ve found it far too restrictive, which makes it difficult to play around with and learn (although error messages have recently improved). And while I like that JSX is built-in, I don’t like that it’s so different. And having to use ReasonReact.stringToElement("Blah") (The spaces are required) everywhere instead of Blah makes it feel like a poor imitation of JSX and isn’t fun at all. Bu…

Yeah, I'm looking forward to syntactic sugar for JSX strings and async/await.

Re: TypeScript support added to Create React App

#78

Post by h1d »

smt88 wrote: post #76
h1d wrote: post #71

Earlier quoted context omitted.

> No problem. Just delete your TS files and work from your JS files. This is quite an irresponsible comment. The JS code generated isn't really meant for editing especially if you used a feature that isn't present on the runtime (like async/await in browser), not to mention all the formatting is rearranged. If you're willing to go back to JS, you want to keep the original source.

"Irresponsible" is a bit of an overstatement, don't you think? The TS team explicitly says their goal is to generate readable JS, unlike (for example) Clojure or Scala. Also, the async/await thing isn't an issue if you target the latest ECMAScript version. That's the only really ugly thing, and it's been easily avoidable for over a year.

Readable JS doesn't mean, convert back to the file in the format you used to for editing.

That comment could make people throw away the original and end up with machine generated code when going back.

Re: TypeScript support added to Create React App

#79

Post by dwaltrip »

BigJono wrote: post #49
dwaltrip wrote: post #21

Earlier quoted context omitted.

Typescript looks interesting and increasingly appealing -- it is high on my list of tech to explore. However, absolutist statements are not very useful... It shouldn't even need saying, but clearly large javascript projects do succeed from time to time.

"Time to time" is reductive even. Large Javascript projects succeed all the time, and have done for decades. This whole thread needs a bit of perspective, no matter what you think of Typescript, the web wasn't invented in 2015...

Very true. I was being soft with my language in an effort to make my point more digestible.

Re: TypeScript support added to Create React App

#80

Post by WorldMaker »

bjz_ wrote: post #65
jasonkillian wrote: post #34

Earlier quoted context omitted.

Yes, your experience mirrors mine completely. It's quite difficult to get complex higher-order components working correctly, especially if you're throwing in things like defaultProps and propTypes. For example, some issues I've hit recently: [0][1]. I think this is likely an artifact though of how powerful TS's type system is. I'm sure there're error-readability improvements possible, but with such complex type const…

I always found react-redux's connect function maddeningly hard to understand, because it does far too many things all in one function. The types just expose that complexity, and make it plainly obvious that it should be split apart. The great thing about types is that the make you think more about keeping you APIs nice and clean on a semantic level, not just about if the syntax in your examples look pretty. I really…

Which gets to my wish that instead it is the React team themselves that adopt and maintain @types/react more directly, rather than leaving it to the community and/or Typescript devs. Seeing CRA add default support for Typescript transpilation with easy opt-in for type checking, is a great sign that plenty more React developers are going to have a chance at Typescript. Hopefully it becomes more of a two-way street where the Typescript community isn't just typing major React libraries after the fact, but more of the libraries are directly written in Typescript or at least the types are directly maintained by the authors of the APIs.
Post reply on HN