Live data from Hacker News

If TypeScript is so great, how come all notable ReactJS projects use Babel?

discuss.reactjs.org

221–230 of 247 posts

Re: If TypeScript is so great, how come all notable ReactJS projects use Babel?

#221
post #189

I've been using React + Redux + Typescript stack and I've been quite happy with it (It's hard for me to image how you could do big refactoring without TS). The fact that components props are verified by compiler instantly when I type is a big win. I believe with PropTypes you can't specifically describe what is the shape of your data, for example object with property of such name and the value of this property is obj…

> I use Typescript 2.0 RC No need to use the RC any more. 2.0 is out! https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...

I have to say, I'm pretty confused about what the state of 2.0 is. There's been no official announcement and the latest stable version on npm is 1.8.10[1]. That being said the latest release on GitHub is 2.0.2, with no official release of 2.0 (or 2.0.1 for that matter) listed anywhere[2]. There's also no active milestone on GitHub for the 2.0 release, but there is for patch versions of 2.0? I'm sure this all just means 2.0 hasn't been released yet, but it's super confusing.

[1]: https://www.npmjs.com/package/typescript

[2]: https://github.com/Microsoft/TypeScript/releases

Re: If TypeScript is so great, how come all notable ReactJS projects use Babel?

#222
post #138

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

Indeed. This is actually the point of DHH's much maligned "Rails is Omakase" article.

Why was that article maligned? Seemed pretty solid to me.

Re: If TypeScript is so great, how come all notable ReactJS projects use Babel?

#223

Why not both? I just installed flow and checked the JavaScript output of my TypeScript project (~2000 lines) and was a little disappointed it didn't turn up any errors.

Flow only type-checks files that have opted into it with the //@flow comment. It will have some trouble dealing with the compiled output of another tool like Typescript. For example, it probably wouldn't understand that output of how Typescript compiles classes into ES5 represents a class. Even if using both of them on the same code worked, Flow and Typescript are both a bit anal about certain dynamic javascript patt…

I made the necessary mods (flow doc is not very clear by the way) and thought it was funny flow complained about TypeScript emitting this:

var live_items = new Array(); ^^^^^^^^^^^ Use array literal instead of new Array(..)

Re: If TypeScript is so great, how come all notable ReactJS projects use Babel?

#224

Earlier quoted context omitted.

Things like babel-core are still a must though.

They are? I haven't run into any problems with the latest typescript@next.

As great as TypeScript is for enforcing certain guidelines for your own code, it does not provide much in terms of supplying polyfills so certain browsers can support some ES5/ES6 features. If you're working with the cutting edge of browsers it shouldn't be a problem, but if you need to go back a couple of years, you either need that or at the very least core-js.

Even the ECMAScript feature table (https://kangax.github.io/compat-table/es6/) uses Babel and TS with core-js when comparing features, otherwise it'd be heavily browser dependent.

Re: If TypeScript is so great, how come all notable ReactJS projects use Babel?

#225

Earlier quoted context omitted.

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: *…

I find webpack to be quite a 'holistic' solution I got pretty much everything out of the box or with minimal googling. I agree though over-fragmentation is a huge problem for JS, we need the big players (either foundations or companies) to put their weight behind one or two solutions and just get on with it :-)

Google sort of already has one, and has for a long time.

Now that their Closure Compiler supports ES6 quite well, I've had a decent amount of success writing my app using straightforward ES6 and referencing the extensive Closure Library for functionality I would've previously pulled in npm packages for.

And the nice thing is that the whole library is written in such a way that all of the compiler's advanced optimizations and branch pruning, and dead code elimination work nicely on it so your compiled JS ends up containing only the code you need, and none of the code your don't need. If you want to use JSX in React projects, you can still zip the code through Babel or Typescript before feeding it to Closure.

It certainly won't work for every project, but it's one way to write modern JS without having to deal with the node/npm ecosystem too much...at least until things settle down a bit.

Re: If TypeScript is so great, how come all notable ReactJS projects use Babel?

#226
post #209

Earlier quoted context omitted.

We finally have tolerable garbage collectors.

And languages like Rust, which are working toward eliminating the need for a garbage collector.

I think I would rather do future "systems level" work in Rust than C, but I'm not sure it would eliminate the desire for automatic memory management in a casual or "ENTERPRISE!!!" (... no intelligent life here, Scottie) app :-)

Re: If TypeScript is so great, how come all notable ReactJS projects use Babel?

#227
post #213
post #190

Earlier quoted context omitted.

When using TypeScript subtly forces you into a MS toolchain. Then when everyone's hooked on VS Code BAM VS Code Pro Extreme Edition!

Strangely enough, I'd feel this would be fine. I would pay for a non-free upgrade of VSCode if it really brings in enough value. Its already on par with Sublime, and I paid for that... edit: Though if you mean TypeScript depending on VSCode to build, I doubt thats even possible at this point. Everything is available via the command line. Heck, there are even tools that build on top of the compiler API. (dts-generator…

Well not that it won't compile without VS, but maybe as a vehicle to for the occasional new feature that just doesn't work quite right on Mac, one drive hosted git tie in's, I dunno but their up to something.

Re: If TypeScript is so great, how come all notable ReactJS projects use Babel?

#228
post #211

Earlier quoted context omitted.

I feel like TypeScript needs some work in areas around typing methods - for example, I ran into type issues when trying to go more functional via ramda.js ( http://ramdajs.com/ ) using stuff like compose, and ultimately it felt like a limitation of TypeScript.

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.

Re: If TypeScript is so great, how come all notable ReactJS projects use Babel?

#229

I was always wondering why HN crowd is ok with TS and so prejudiced against Dart - Dart has NG2, await async in older browsers and good tooling (webstorm, vscode) and much saner package system. When doing lot of small web apps - it's easier to mantain.

I've been a long time fan of Dart but I've recently (this week) given up on it for my purposes, which are write browser SPA's that need to run in different browsers. My sense is that after the Chrome team decided not to include the Dart VM in Chrome, Dart started looking for a new story. That story is Flutter, which is Dart running in the Dart VM on mobile devices [1] It is not Dart converted to JavaScript so it can run in any browser, despite the awesome work of the dart2js authors and the relatively new dev_compiler project [2]. The latter will be awesome when done, because the goal is to convert Dart to ES6/ES2015. However, it is my impression that Google really doesn't care that much about transpiling Dart to JavaScript. I was willing to put up with the huge file size dart2js produced, because Dart made my life easier and something better was coming. However, it's been a long time and the pace of Dart transpiling work is too slow. I converted my Dart app to TypeScript (size dropped from 650kb to 60 kb) and am happy for that, but sad that Google does not put more people on the dev_compiler team to keep long term enthusiasts like me on board. I'm sure Flutter is fantastic and will take a look when I have a need for that kind of solution. I can't really blame Google, because the JavaScript community turned it's back on Dart, but I wish they would just state the new goals and not leave us hanging.

[1] https://flutter.io/faq/ [2] https://github.com/dart-lang/dev_compiler

Post reply on HN