201–210 of 239 posts
I'm curious as to why yarn instead of contributing to NPM? I am aware that yarn was the inspiration for many improvements for NPM by providing an alternative, but going forward do we need two systems? Is the plan for yarn to be compatible with NPM and package.json?
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.
> , and to everyone's benefit. Why? I've worked on large codebases in Coffeescript, ES6 and Typescript. Whatever this whole community sings and believes, but Coffeescript still wins for me. ES6 is still trying to catch up but will probably never reach the beauty and ease of Coffeescript. Both are transpilers, only ES6 with Babel is a total horror to manage (just upgraded a large codebase to Babel 7..). Typescript tak…
...
> Both are transpilers
You don't have to transpile es6 if you don't want older browser support.
Earlier quoted context omitted.
Typescript doesn't try to be a different language. It tries to be an exact superset of JS: JS with annotations. And you can absolutely implement what you linked, it exists and it's called tsc: the "compiler" you're somehow upset Typescript has (this + checking types is all it does!). Babel does it natively. Enums are a fair point, those aren't in the ES specs (though I suspect at some point they will be). However, th…
Not sure where you got the idea that I'm upset that TS has a compiler, I'm just pointing out my perspective on the differences between the two tools. I use both on a daily basis. You might not think the differences is a big deal, but affecting runtime code is a pretty major line to cross. Not that there is anything inherently wrong with that, but at that point it becomes a different tool, in my opinion.
enums are a tiny, extremely useful and extremely optional part of the language and they don't warrant this label of "philosophical difference", IMO.
Earlier quoted context omitted.
> , and to everyone's benefit. Why? I've worked on large codebases in Coffeescript, ES6 and Typescript. Whatever this whole community sings and believes, but Coffeescript still wins for me. ES6 is still trying to catch up but will probably never reach the beauty and ease of Coffeescript. Both are transpilers, only ES6 with Babel is a total horror to manage (just upgraded a large codebase to Babel 7..). Typescript tak…
> Show me a Typescript codebase not using the type 'any'! In a decent system language you can't get away with that, it's just a fake sense of security. I don't know the comparison to system languages is fair though, because the use-case for JS is quite different from system languages. Javascript (and by extension, Typescript) is commonly used to interface between the user and the network, both of which often are outs…
Earlier quoted context omitted.
> Show me a Typescript codebase not using the type 'any'! In a decent system language you can't get away with that, it's just a fake sense of security. I don't know the comparison to system languages is fair though, because the use-case for JS is quite different from system languages. Javascript (and by extension, Typescript) is commonly used to interface between the user and the network, both of which often are outs…
Exactly. Even strongly-typed languages have this problem. In C, it looks like `void *`, while in Java, it's `Object`. The `any` keyword is just the latest in a long line of escape hatches. Pretty much every language has one.
C is clearly statically typed, but among statically typed language it is quite weakly typed.
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.
I agree with your sentiment but I find the location of it almost ironic. One thing I hate is when I go into a language and it's full of, "oh don't use the built-in, use this thing over here...". If we want a clear winner to everyone's benefit, wouldn't we want Yarn to go away and for npm to gain whatever it's missing that makes Yarn relevant? To be fair, I haven't touched Yarn in years. I switched to it, loved it, an…
NPM and Yarn don't have this problem, since they are pretty much drop-in replacements for each other. As long as `yarn install` and `npm install` both get the job done equally well, picking one becomes a personal choice. Every project that adopts a standard package.json is a win for both NPM and Yarn. There doesn't need to be a loser in this case, and diversity is good.
Earlier quoted context omitted.
This sucks because, in the first few years, flow had much better soundness and typescript had some serious issues. I'm a little disappointed and feel as though, similar with Kube vs Swarmkit, the worse technology is winning.
I don't think that holds anymore. Have you used both Flow and Typescript recently? Speaking from experience: I can't imagine anyone doing so and concluding that Typescript is the "worse technology" at this point.
> The codebase will be ported from Flow to TypeScript. To understand the rational please continue reading, but a quick summary is that we hope this will help our community ramp up on Yarn, and will help you build awesome new features on top of it. Another major project moving from flow to typescript
This sucks because, in the first few years, flow had much better soundness and typescript had some serious issues. I'm a little disappointed and feel as though, similar with Kube vs Swarmkit, the worse technology is winning.
/* @flow */
interface HasIdentityFunction {
id(a: A): A
}
class Example implements HasIdentityFunction {
id(a: A): number {
return 42;
}
}
var x: string = (new Example(): HasIdentityFunction).id("hello")
I’m glad that Yarn will continue. Npm has improved, but it’s still less pleasant to work with than yarn (which basically always does what I expect, not so for npm).
npm has eroded so much of my trust that I am hesitant to switch back to it any time soon. I've tried npm out every few months (since npm 3), and have consistently run into infuriating bugs or unexpected behaviors. Much of it has been fixed over time, but the frequency and duration of these issues is concerning—and, I think, points to architectural deficiencies being the root of the problem. (And the project is so mas…
* Whenever I, a coworker, or our CI system pulls changes, we need to make sure that we have the correct dependencies installed because package.json or the lockfile may have been updated. We don't necessarily know if anyone else has changed package.json; we just want to run a command that makes sure node_modules matched the package.json and lockfile. Running `yarn` when there are no changes to package.json takes under a second, so it's easy to just always get in the habit of running, and doesn't slow down CI. We can make our build and deploy scripts just run `yarn` to be on the safe side because it's so cheap to run. But with npm, running `npm install` when there are no changes to package.json in a big project still often takes 10-30 seconds.
* I've run into many bugs like this one with npm: https://github.com/npm/npm/issues/19839. For a while, I actually made our deploy script run `npm install` in a loop until it stopped changing things just to be sure it successfully installed everything (but then it turns out running `npm install` multiple times can actually cause issues! https://github.com/npm/npm/issues/18084. To work around that, if you pull changes that include a change to package.json, you have to remove node_modules and then run `npm install`. This made our CI system so slow...). I've reported various bugs like this. The bugs would get no attention, but sometimes they'd mysteriously go away after a few versions. But bugs that go away on their own tend to come back on their own in my experience.
Yarn has only given me one issue in my use of it and it was promptly fixed. I swear by it now.
There appears to be a real movement to move from Flow to typescript. Is Flow dying?
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...…