21–30 of 90 posts
Great to see. Any javascript project of reasonable size quickly eventually collapses under its own weight.
However, absolutist statements are not very useful... It shouldn't even need saying, but clearly large javascript projects do succeed from time to time.
Pretty much just file extension support and docs. The support mainly comes from Babel 7.
How well does Babel transpile TS? My initial instinct is that I'd trust the real TS compiler over Babel, but I've never tried compiling TS with Babel. I assume the real TypeScript compiler still does the type-checking and that would be unaffected by Babel.
SO: Any good way to learn TypeScript, particularly the more complicated types?
Pretty much just file extension support and docs. The support mainly comes from Babel 7.
I'd call that a good thing, really. Not needing ever more dependencies. I think this is a solid direction to go. Let's just say I give the React devs... props.
I'd love to use TypeScript, but I've hit walls of errors that are nearly as bad as the old C++ template errors! (Though to be fair, this was a while ago, the compiler may have improved). SO: Any good way to learn TypeScript, particularly the more complicated types?
If you're using Create-React-App-TS, that's a separate fork of CRA 1.x that adds TS support, and has _horribly_ restrictive lint rules (many common style practices are treated as _compile_ errors). See https://github.com/wmonk/create-react-app-typescript/issues/... for discussion. (I ran across this while trying to set up a TS project for another team.)
I'm happy to see the TS support in CRA 2.x, because now I can actually recommend that people use it to get started with TS support.
I personally had never actually _used_ TS at all until this last week, when I was helping that same team rework some of their code. They'd been slapping `someVar : any` across the entire codebase just to make the compiler shut up. I tried adding a type representing their API response object, added it as a prop to the appropriate React component, and showed them how you could start getting autocomplete and compile-time catching of mistakes, and suddenly they began to see that there were actually benefits of using TS, not just overhead. I'm hoping to try adding TS support in to my own team's codebase in the near future.
I'd love to use TypeScript, but I've hit walls of errors that are nearly as bad as the old C++ template errors! (Though to be fair, this was a while ago, the compiler may have improved). SO: Any good way to learn TypeScript, particularly the more complicated types?
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…
> 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…
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.
tldr: Reason is better than both TypeScript and Flow and has equally good interop with native untyped Javascript code.
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.
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. But maybe they’ve fixed some of that.
Someone else said Reason is “better”. The type system might be more sound but TS is far more flexible and forgiving, and doesn’t have ugly and off-putting syntax for promises/async and interop.
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…
The other issue is that if people don't know what they are doing with TS, then imo it's worthless. I don't know your experience level with TS, but it is a non-trivial problem to build types such that it provides all the benefits you describe.
It is, in a lot of ways, a different language with its own set of problems to "solve."
Tread lightly, because adopting TS could be a blessing or a massive time sink for people not familiar with it.