Live data from Hacker News

Yarn's Future – v2 and beyond

github.com

181–190 of 239 posts

Re: Yarn's Future – v2 and beyond

#181
post #3

There appears to be a real movement to move from Flow to typescript. Is Flow dying?

The writing has been on the wall for a very [1] very [2] long [3] time. Facebook and some consumers of their ecosystem have been holding the fort, but it was inevitable something like this would happen.

1: https://npm-stat.com/charts.html?package=babel-core&package=...

2: https://trends.google.com/trends/explore?date=today%205-y&q=...

3: https://developers.slashdot.org/story/18/11/25/017227/micros...

Re: Yarn's Future – v2 and beyond

#182
post #75

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.

Things are quite different from the first few years. Typescript has largely converged with the capabilities of Flow as a type system, though from its "different direction". It's not entirely ML-ish algebraic types, but it's a usefully fair approximation that has a lot of pragmatic tools to get the job done. Similarly too, the type inferencing engine isn't a "proper" ML-ish one, but it's gotten very good at what it do…

Anders (and the people he works with) has a track record of producing useful pragmatic tools/languages that help developers develop going back about 3 decades.

I've yet to find anything he's done/worked on that I don't like, one of my programming heroes actually.

Re: Yarn's Future – v2 and beyond

#183
post #118

Earlier quoted context omitted.

Do people typically prefer TypeScript over ES6?

I'd prefer Eiffel or Oberon, but almost anything is better than ES6. I just wish there was some kind of standard library movement to coincide with it, but even MS seems okay with left-pad.

> even MS seems okay with left-pad

That's a strange choice of example to highlight the sparseness of the standard library.

Re: Yarn's Future – v2 and beyond

#184
post #52

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, and then npm got the package-lock and some performance fixes and I suddenly didn't understand why I'd want to use Yarn.

I'm conflicted because on one hand I strongly believe that we're all better off using the same tools so we can help each other more easily. But that suggests that alternatives shouldn't exist, which stymies innovation.

Re: Yarn's Future – v2 and beyond

#185
post #178

Earlier quoted context omitted.

If you write type annotations in TS, they're stripped away. If you write type annotations in Flow, they're stripped away. There's no difference. TS has some additional features which are purely optional that don't get purely stripped out, but you're not mandated to use them.

There is no difference if you limit the use of the tool to not use these features. In my eyes, it's a philosophical difference between the two, Flow can be more easily integrated into an existing codebase by just adding //@flow at the top the file and has no features which can affect runtime code. Whereas TypeScript tries to be a different language altogether that uses a new file extension, adds new features, and has…

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, they're an incredible addition and they really are just syntactic sugar for a more complex type of object.

BTW, typescript supports jsdoc-style annotations, and --allowjs even lets it typecheck javascript code. It also supports more, because nobody actually only wants those things; they're not that great on their own.

Re: Yarn's Future – v2 and beyond

#186
post #178

Earlier quoted context omitted.

If you write type annotations in TS, they're stripped away. If you write type annotations in Flow, they're stripped away. There's no difference. TS has some additional features which are purely optional that don't get purely stripped out, but you're not mandated to use them.

There is no difference if you limit the use of the tool to not use these features. In my eyes, it's a philosophical difference between the two, Flow can be more easily integrated into an existing codebase by just adding //@flow at the top the file and has no features which can affect runtime code. Whereas TypeScript tries to be a different language altogether that uses a new file extension, adds new features, and has…

I think Babel does excatly that if only enable the typescript-preset.

Re: Yarn's Future – v2 and beyond

#187
post #178

Earlier quoted context omitted.

There is no difference if you limit the use of the tool to not use these features. In my eyes, it's a philosophical difference between the two, Flow can be more easily integrated into an existing codebase by just adding //@flow at the top the file and has no features which can affect runtime code. Whereas TypeScript tries to be a different language altogether that uses a new file extension, adds new features, and has…

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.

Re: Yarn's Future – v2 and beyond

#188
post #9

Earlier quoted context omitted.

Facebook (excuse me, bunch of FB employees from the Flow team) says no: https://github.com/facebook/flow/issues/7365#issuecomment-45... . Of course, that's exactly what I'd say if I was in charge of a dying project. Edit: but, their main codebase is in Flow, and that sounds like a mess to migrate, so I wouldn't be _too_ worried. It might slow down, but I doubt it will become unmaintained anytime before Facebook gets…

I recalled when Microsoft employees and MVPs denied when Silverlight was dying. :-( I think the TypeScript momentum is too strong now.

I think Flow's in more direct trouble, but I wouldn't announce victory for TypeScript just yet. With wasm around the corner, things may (or may not, shrug) change significantly.

Re: Yarn's Future – v2 and beyond

#190

Earlier quoted context omitted.

Do people typically prefer TypeScript over ES6?

I'm a fan of functional programming over OOP as such, I don't need all of the OOP constructs just give me some immutable primitives, first-class functions and let's get to work. There's not much I can do with a class that can't be accomplished with a simple function. I think I've evolved in my thinking over this in the last several years of experience.

You can continue to code the way you've been enjoying, just with the option to type your inputs and outputs if you choose to. Writing classical OOP isn't imposed on you by TypeScript, nor do you miss out on anything by not writing classical OOP.
Post reply on HN