
Full-Stack TypeScript, React, Apollo, and Node Example - tiagsters
https://medium.com/@tiagsters/one-full-stack-to-rule-them-all-5ca39ded16c1
======
baybal2
A lot of people getting misguide by very persistent, and I'd say pushy
Typescript promotion.

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

~~~
ng12
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.

~~~
baybal2
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.

~~~
ng12
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.

------
radicalriddler
> 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.

