Earlier quoted context omitted.
My opinion is that all the extensions on JavaScript should be implemented as Babel plugins, including Typescript. That would solve all the compatibility problems. Well, when Babel first came out I also thought that it should have been a Sweet.js plugin so maybe I don't have the best understanding of this "transpiling" circus.
It's tempting to think this way, but it's a performance/complexity nightmare. If everything is a plugin, then you need ways for different parsers to talk to each other to deal with nested syntax, plus ways for different syntactic transformers to correctly handle nesting of certain things. For example, if you desired to implement a plugin for "thin arrows", and a plugin for JSX, how would you parse this? const x = } /…
If TypeScript is so great, how come all notable ReactJS projects use Babel?
241–247 of 247 posts
Re: If TypeScript is so great, how come all notable ReactJS projects use Babel?
#242Earlier quoted context omitted.
Perhaps menu-driven refactoring is overrated? (much like IDE generated getter/setter code, which is solving the wrong problem)
What do you mean? It's the typescript compiler that catches your errors. The IDE stuff is nice to have, but it's not the main benefit typescript adds to refactoring. Typescript doesn't rely on an IDE.
If you write fewer classes and class hierarchies, and use higher order functions (see also - partial function application), you will have much less "refactoring" to do - often, simply small changes such as to increase the visible scope of a function you now want to reuse elsewhere, or to "pre bind" another argument to a function so the caller(s) don't need to know a particular detail.
This probably has a lot to do with why the static OOP people think the dynamic FP people are insane: they have no idea how we really work.
We have garbage collectors and closures now. Stop writing code as if in some crippled version of Simula 67 :-)
Re: If TypeScript is so great, how come all notable ReactJS projects use Babel?
#243I would have switched to typescript but I had to rename EVERYTHING from something to something else in order to use TypeScript. If that's how "compatible" starts, well, no thanks cause clearly that's just the start of the pain. Compatible should be same files, new compiler = "just works".
Re: If TypeScript is so great, how come all notable ReactJS projects use Babel?
#244Earlier quoted context omitted.
To properly type Ramda, you need higher kinded types, which are not yet a feature of TypeScript. Though I find that Ramda's curried style isn't that useful now that we have arrow functions...
Hmm. I find that classes and subclasses aren't all that useful, now that I can use higher order functions :-) (I still use classes/objects for services with multiple related operations or polymorphism, but not for one trick pony "Executioners" for which Java would use a lambda -- which is what ES6 arrow funcs look like) I wish I could vote the grandparent post up more.
* JavaScript is not suited for it (no composition operator, no interop with existing multi-argument functions)
* It doesn't improve readability over arrow syntax.
compose(f, flip(g)(y), h)
vs x => f(g(h(x), y))Re: If TypeScript is so great, how come all notable ReactJS projects use Babel?
#245Earlier quoted context omitted.
This is basically my frustration with the whole trend toward smaller pieces over big monoliths. I don't need a best-in-class every tiny little thing; I just want reasonable tools I can expect to work together well.
The JS build system ecosystem could definitely use some help along the whole "reasonable tools I can expect to work together well" front. I swear, 30% of my time is spent fighting the build systems and their plugins that hate each other. EDIT: to add, I think the TS team has done such a bangup job on Typescript that I would love it if they could create a build system as well. Some things that would be nice to have: *…
Gulp is the source of so much pain for people and yet so much of the ecosystem keeps suggesting that more gulp is the answer to their gulp problems.
Re: If TypeScript is so great, how come all notable ReactJS projects use Babel?
#246I am using TypeScript in a middle sized app (around 200 react components) and its help is invaluable for collaborating and sharing APIs. Currently it is based on redux, but I have a feeling I have to write too much code, I am looking into MobX as an alternative. I think TypeScript is the best thing that happened to the JS community in a long time.
I just did that (redux -> mobx) as mentioned in another comment and it made the code easier to understand, everything typed with less than half of the code. No more connect or action, we just call the store method (equivalent to a reducer fn) directly. I also moved most of the components that had state to use observable variables and it's been working well.
I cannot really speak in term of maintenance or architecture quality yet. But it works.
Re: If TypeScript is so great, how come all notable ReactJS projects use Babel?
#247Speaking as the person who implemented JSX support for TypeScript, I question the premise! JSX support (and implementation of React semantics for typechecking that JSX) was a very popular feature request. I can tell you just from how quickly people notice when something JSX-related changes in the nightly build that there are a lot of people using TypeScript with React. Also, since this seem to be a popular misconcept…
> TypeScript is not wedded to React Practially not, but it's a bit of a hassle. either you leave the JSX be and parse it with Babel or you need some wrappers for you VDOM lib, because tsc assumes a namespace, while most not-React-vdom libs just deliver a function out of the box.