Full-Stack TypeScript, React, Apollo, and Node Example(medium.com)
medium.com
Full-Stack TypeScript, React, Apollo, and Node Example
https://medium.com/@tiagsters/one-full-stack-to-rule-them-all-5ca39ded16c1
8 comments
This has not been my experience at all. TypeScript's tooling is great, it's interoperability with non-TypeScript code is a non-issue. You're drastically overstating how different it is from an ES6 toolchain.
Also remember that TypeScript is very forgiving if you decide to avoid types in some part of your codebase. However, I will tell you that I always end up regretting not using types when I come back to the code in 6 months.
> Library authors opting for TS may well be closing door for contributors from mainstream dev demographic.
I think it's the complete opposite. Good typings make it easier for new contributors to get up to speed, make changes without breaking anything, and document those changes. Furthermore, it makes it significantly easier to push out new versions of your libraries since TypeScript will help users debug breaking changes.
Also remember that TypeScript is very forgiving if you decide to avoid types in some part of your codebase. However, I will tell you that I always end up regretting not using types when I come back to the code in 6 months.
> Library authors opting for TS may well be closing door for contributors from mainstream dev demographic.
I think it's the complete opposite. Good typings make it easier for new contributors to get up to speed, make changes without breaking anything, and document those changes. Furthermore, it makes it significantly easier to push out new versions of your libraries since TypeScript will help users debug breaking changes.
I say ease of debugging is not there. Spotting API breakages in case of type changes in them is one of very few advantages on debugging side.
Just as with as with any transpiler, you never have 100% confidence in your source maps, especially if you mix and match your tooling.
And you almost always loose some part of native debugger functionality in browser or node. I never ever saw a transpiler that does not break correct display of properties along the prototype chain or breakpoints inside constructor functions.
This is where vanilla es6 blows everything away. I know not so few dotcom tier companies with 1m+ per hour websites which stick with handwritten JS on the frontend solely because of that: productivity gains for them simply not worth losing few percents of visitors because of hard to catch and debug bugs.
Just as with as with any transpiler, you never have 100% confidence in your source maps, especially if you mix and match your tooling.
And you almost always loose some part of native debugger functionality in browser or node. I never ever saw a transpiler that does not break correct display of properties along the prototype chain or breakpoints inside constructor functions.
This is where vanilla es6 blows everything away. I know not so few dotcom tier companies with 1m+ per hour websites which stick with handwritten JS on the frontend solely because of that: productivity gains for them simply not worth losing few percents of visitors because of hard to catch and debug bugs.
I am completely unconvinced by this argument. Who's shipping un-minified, un-transpiled, un-bundled ES6? And even if you were, TypeScript is just a superset of ES6, to the point where there's even a babel plugin to simply strip the types leaving you with regular ES6 JavaScript. I don't believe that the addition of TypeScript would add any debugging burden to an existing ES6 project.
It's not like we're compiling Haskell to JavaScript, I've never had trouble debugging because of differences between TypeScript and my build output. I honestly don't even think about it.
It's not like we're compiling Haskell to JavaScript, I've never had trouble debugging because of differences between TypeScript and my build output. I honestly don't even think about it.
This 100%. I would also add that it seems alot of companies have been substituting type checking for a proper testing strategy. Eric Elliot goes into great length about this in this article: https://medium.com/javascript-scene/the-typescript-tax-132ff...
I'm a little disappointed/surprised flow is viewed by some as a pet project by Facebook, I really think it is a great type checking tool that works nicely with other tooling.
I'm a little disappointed/surprised flow is viewed by some as a pet project by Facebook, I really think it is a great type checking tool that works nicely with other tooling.
This is my least favorite article about TypeScript. It's chock-full of misleading tidbits and questionable interpretations of cited material. The HN discussion on the article is pretty illuminating: https://news.ycombinator.com/item?id=18977700
Flow was built for a very specific usecase: incrementally adding types to an existing untyped project. TypeScript is better for almost everything else.
Flow was built for a very specific usecase: incrementally adding types to an existing untyped project. TypeScript is better for almost everything else.
Ohh yeah great discussions there.
I see now, that it's not about which is better, more just different approaches thanks!
I see now, that it's not about which is better, more just different approaches thanks!
> It’s 2019! MVC should be dead! Long live JS in templates and one-direction data flow!
Is it though? I'd thoroughly disagree. MVC is perfectly fine for a majority of applications out there.
Is it though? I'd thoroughly disagree. MVC is perfectly fine for a majority of applications out there.
It is deceptive to say that Typescript is just "a backward compatible tool for type checks"
Will Typescript add more troubles for you? Yes, it will.
People have little idea for what they sign for: it is not just some script to do build time type checks, but an entire language + ecosystem standing apart from standard JS along with expected interoperability issues and "one way door" problem
Library authors opting for TS may well be closing door for contributors from mainstream dev demographic.
Commercial dev shops may loose out on trading type checks for smaller ecosystem, smaller dev base, and productivity loss
For one man companies, and smaller shops: you will be ready pull your hair after few months dealing with tooling. TS tooling problems make usual webpack breakages look trivial, and will greatly affect your productivity