Do you happen to have a link to the other announcement handy? We use Flow at $WORK and today I had a great time banging my head against the wall because it was both not happy with me adding a custom matcher in Jest so that internal DateRange type tests would produce some better failing output and also had to be instructed to not freak out about jsverify so that the aforementioned tests could be property-based.
And documentation for Flow built-in types like $ReadOnlyArray simply not existing is its own level of awfulness and.. if a bunch of high profile projects are missing maybe I can get leverage to push for Typescript internally, too.
I’m not thrilled that yet another frontend tool is getting its own plugin ecosystem. I already have Browserify plugins, ESLint plugins, Babel plugins…
How will I manage the packages needed for my package manager to manage my packages? yarn-itself-lock? Multi-stage package-manager bootstrapping where first I compile my own package manager before I can install my packages?
My employer switched to Dart for our frontend development a couple years ago and this was a major reason: one set of blessed tooling that is used for everything. It definitely hasn’t been a perfect experience, but it’s been better in some important ways.
The biggest drawback with Dart is that the Dart-JS interoperability is pretty poor. It can be done, but it’s ugly and usually kind of slow (there is apparently a plan to improve it this year, but we’ll see). The language itself has had some growing pains. Dart was released before types became cool again, so it was very much designed to be a “types optional” language. For the last few years, however, it’s been moving more and more toward being a regular statically typed language. That transition is finally complete with the release of Dart 2 last summer. At the same time, there is concise syntax for runtime type checks and casts, so it’s reasonably simple to deal with data from JS if you need to. Performance is good, as long as you don’t have to talk to JS code.
As far as tooling goes, it’s pretty great. One solid package manager that everyone uses, one solid unit testing package that everyone uses, one linter that everyone uses, etc. Code generation is straightforward and built into the tool chain if you need it (we use it extensively). Good IDE support (JetBrains, Vim, and VSCode all have good support). The syntax is very similar to modern Java, so any capable developer can become productive in a few hours. Finally, with Flutter becoming popular Dart libraries and skills can be reused on mobile.
I’d looked at Dart about 2 years ago (read through The Dart Programming Language), and really liked what the language had to offer, but even at that stage TypeScript seemed a more pragmatic choice. The Dart tooling (from what you’ve described) definitely simplifies some of the problems I have with configuring a TS project (many hours lost to configuring webpack, babel, tslint, etc…).
I found Go very attractive precisely because of the uniformity and simplicity of the tooling.
If I was choosing today, I would very seriously consider TS. The decision would have a lot to do with whether I was going to rely on existing JS libraries that have no good Dart equivalents. If I was planning to do mobile, though, I’d almost certainly go with Dart, Flutter is just fantastic IMO.
There’s so much complexity here. I wonder if one of the generic package managers (guix, nixos et al.) have good stories for packaging software from maven/npm/pip/.. without much delay/patching needed. In that case, learning a single tool’s complexity over many tools’ may be worth it.
This is the second Facebook project (after Jest) to announce switching from Flow to TypeScript in the past week or two. 🤔
The 2nd we know of.
Do you happen to have a link to the other announcement handy? We use Flow at $WORK and today I had a great time banging my head against the wall because it was both not happy with me adding a custom matcher in Jest so that internal DateRange type tests would produce some better failing output and also had to be instructed to not freak out about jsverify so that the aforementioned tests could be property-based.
And documentation for Flow built-in types like $ReadOnlyArray simply not existing is its own level of awfulness and.. if a bunch of high profile projects are missing maybe I can get leverage to push for Typescript internally, too.
I suppose that would be Jest? (edit: sorry, I misread the OP, it is Jest) (Accepted) Proposal thread here: https://github.com/facebook/jest/pull/7554
Got it, thanks! Somehow wasn’t able to find this through google
I’m not thrilled that yet another frontend tool is getting its own plugin ecosystem. I already have Browserify plugins, ESLint plugins, Babel plugins…
How will I manage the packages needed for my package manager to manage my packages? yarn-itself-lock? Multi-stage package-manager bootstrapping where first I compile my own package manager before I can install my packages?
My employer switched to Dart for our frontend development a couple years ago and this was a major reason: one set of blessed tooling that is used for everything. It definitely hasn’t been a perfect experience, but it’s been better in some important ways.
Can you talk a bit about how you’ve found using Dart for frontend development? Tooling, performance, good, bad & ugly?
The biggest drawback with Dart is that the Dart-JS interoperability is pretty poor. It can be done, but it’s ugly and usually kind of slow (there is apparently a plan to improve it this year, but we’ll see). The language itself has had some growing pains. Dart was released before types became cool again, so it was very much designed to be a “types optional” language. For the last few years, however, it’s been moving more and more toward being a regular statically typed language. That transition is finally complete with the release of Dart 2 last summer. At the same time, there is concise syntax for runtime type checks and casts, so it’s reasonably simple to deal with data from JS if you need to. Performance is good, as long as you don’t have to talk to JS code.
As far as tooling goes, it’s pretty great. One solid package manager that everyone uses, one solid unit testing package that everyone uses, one linter that everyone uses, etc. Code generation is straightforward and built into the tool chain if you need it (we use it extensively). Good IDE support (JetBrains, Vim, and VSCode all have good support). The syntax is very similar to modern Java, so any capable developer can become productive in a few hours. Finally, with Flutter becoming popular Dart libraries and skills can be reused on mobile.
I’d be happy to answer other questions.
You’re talking about using package:js here?
I’d looked at Dart about 2 years ago (read through The Dart Programming Language), and really liked what the language had to offer, but even at that stage TypeScript seemed a more pragmatic choice. The Dart tooling (from what you’ve described) definitely simplifies some of the problems I have with configuring a TS project (many hours lost to configuring webpack, babel, tslint, etc…).
I found Go very attractive precisely because of the uniformity and simplicity of the tooling.
Also
dart:js, which is deprecated IIRC.If I was choosing today, I would very seriously consider TS. The decision would have a lot to do with whether I was going to rely on existing JS libraries that have no good Dart equivalents. If I was planning to do mobile, though, I’d almost certainly go with Dart, Flutter is just fantastic IMO.
There’s so much complexity here. I wonder if one of the generic package managers (guix, nixos et al.) have good stories for packaging software from maven/npm/pip/.. without much delay/patching needed. In that case, learning a single tool’s complexity over many tools’ may be worth it.