81–90 of 239 posts
The JS ecosystem has its flaws, but one has to appreciate the speed at which momentum shifts, making clear winners obvious. The move towards TypeScript 'winning' has been fast, and to everyone's benefit.
Maybe it's a benefit when moving from Flow, but personally, I would rather have JS projects spend that time adding more tests than converting to static typing. Edit: changed strong to static.
Earlier quoted context omitted.
Does anyone know of any "third choice" around typing JavaScript? I would love to add types to my code, but I want to write "real" JavaScript: so the code I input is the code that is executed by the browser. I just want the compile step to strip away the type annotations. There was initially talk of Flow using comments to actually work without touching the source code at all, but I don't think anything came of that...…
> I would love to add types to my code, but I want to write "real" JavaScript: so the code I input is the code that is executed by the browser. I just want the compile step to strip away the type annotations. That's what Typescript is. Type annotations don't change your code, they're stripped away by babel at compile time. In fact, by default, tsc does compile TS code which fails typechecking, into valid JS code (whi…
With Flow, the type annotations are just stripped away, none of your Flow code affects runtime code.
This is not so with TS since you have things like Enums, which will be compiled into objects and are part of your runtime code.
Yarn has over 1500 open bugs. Rather than working on changes, it'd be nice to stop and address these.
This effort we start is in no small part to decrease the number of issues that will be created by empowering the users to unblock themselves* and solidifying Yarn's codebase.
* You wouldn't believe the number of issues that are simply about things working as they should - we can't really blame their authors because it can be quite hard to find the right paragraph in the documentation, but it's extremely taxing on a small team. Similarly, we often have issues created against older releases, or without reproducible test case.
Earlier quoted context omitted.
Maybe it's a benefit when moving from Flow, but personally, I would rather have JS projects spend that time adding more tests than converting to static typing. Edit: changed strong to static.
Static types are a form of test!
The JS ecosystem has its flaws, but one has to appreciate the speed at which momentum shifts, making clear winners obvious. The move towards TypeScript 'winning' has been fast, and to everyone's benefit.
Do people typically prefer TypeScript over ES6?
The JS ecosystem has its flaws, but one has to appreciate the speed at which momentum shifts, making clear winners obvious. The move towards TypeScript 'winning' has been fast, and to everyone's benefit.
Do people typically prefer TypeScript over ES6?
The JS ecosystem has its flaws, but one has to appreciate the speed at which momentum shifts, making clear winners obvious. The move towards TypeScript 'winning' has been fast, and to everyone's benefit.
The JS ecosystem has its flaws, but one has to appreciate the speed at which momentum shifts, making clear winners obvious. The move towards TypeScript 'winning' has been fast, and to everyone's benefit.
Maybe it's a benefit when moving from Flow, but personally, I would rather have JS projects spend that time adding more tests than converting to static typing. Edit: changed strong to static.
All those kinds of tests can be eliminated with static typing. It's true that a lot of those types of errors would get picked up in functional tests, but at least from my perspective it's not great practice to rely on a functional test to catch that kind of change. If your functional test changes it's easy to lose coverage of your basic unit tests that were only happening implicitly.
Earlier quoted context omitted.
Do people typically prefer TypeScript over ES6?
From what I've seen, yes. I'm a big fan of ES6 and I haven't been a fan of typed languages for a long time but I'm liking using TypeScript. So are my coworkers.
I tend to view TypeScript similar to CoffeeScript — it brings to JavaScript some features from other languages that are convenient and preferred by a subset of frontend developers. It allows for experimentation in the language, and helps inform TC39 proposals.
In time, I suspect support will coalesce around a specific TC39 process proposal to add type support, it will graduate to stage 3 or 4, get integrated into browsers and Babel, and enthusiasm around TypeScript will wane.