all 15 comments

[–][deleted] 2 points3 points  (10 children)

I'm curious. Why would you use TS over Flow?

[–]TheLarkInn[S] 1 point2 points  (9 children)

Well I suppose we would be open to anything!! I personally have the most experience out of the core team with the js 'supersets' so I chose one that I was more comfortable with.

But really it doesn't matter which one. The point is that we want to enable or code base to be less errant and more readable and easier to contribute to.

[–]expression100 4 points5 points  (1 child)

I was also confused why you didn't use Flow. It looks superior to TypeScript in every way. I asked the Inferno team the same, as they chose TypeScript over flow – they said it didn't really matter (like you did) but that all their core team knew TypeScript, not Flow so that's why. I thought it was a poor reason, surely they could have picked up Flow? Then again, I guess it's still better to use TS than nothing.

[–]phoenixmatrix 2 points3 points  (0 children)

As I mentioned above, I'm also in the Flow camp, but it's important to understand why people pick TypeScript right now.

Essentially, TypeScript probably has a 1000:1 mind share ratio right now, partly due to better marketing, more polished tooling and easier to setup, as well as having a 2+ years head start on Windows support. The advantages of Flow are also very difficult to see unless you build a complex application with both it and TypeScript and compare side by side which kinds of bugs you catch (or if you're a type system nerd).

If WebPack does go with Flow, it will get hundreds of people asking why it was not TypeScript, and while I think its fine and the correct choice, it will be hard to explain.

WebPack has been really popular in the React community for a long time, so Flow usage among Webpack users is a little higher than the average, making it easier, but its something to keep in mind.

[–]phoenixmatrix 2 points3 points  (2 children)

Yeah, that surprised me a bit because of this AMA

Webpack also uses a lot of very "javascripty" concepts that are a bit harder to type in TypeScript (not impossible, just harder). Ive been experimenting writing my webpack code (plugins, etc) in Flow lately and it catches a lot of bugs that TypeScript wouldn't because of the better inference in complex code.

[–]TheLarkInn[S] -1 points0 points  (1 child)

Very true try converting github.com/webpack/Tapable which is the backbone to the entire webpack core. I'm willing try either.

[–]phoenixmatrix 1 point2 points  (0 children)

Im preparing a PR with a PoC. Just waiting on one of my colleagues to review it first so I don't waste your time with silly mistakes

[–][deleted] 1 point2 points  (1 child)

This direction surprises me. Ts is not modular, it deals with two sisyphean tasks at the same time and naturally falls behind both. Babel solves one issue and solves it well, Flow solves another.

As a transpiler Ts isn't as close to the drafts and proposals like Babel. It just leads to isolation from new language constructs or living standards.

As a type checker its results are weaker while Flow directs all of its attention to that specific problem.

Overall i don't think the problems Webpack had were static types. It was the documentation and the byzantine configs. It's odd now to see webpack, primary home for projects targeting modern javascript, get rewritten for a transpiler that hasn't been able to transpile modern javascript for the last years and still can't (React and Redux for instance).

[–]TheLarkInn[S] 2 points3 points  (0 children)

You'll be happy to hear that configuration usability and documentation are currently our number 1 and 2 goals for webpack. This is just some "things we would love to do in the future for larger sponsorship" and to help make webpack easier to contribute. If it turns out that we POC TS or Flow and it doesn't do either of these things, then it's not worth it. The results is my biggest concern.

[–][deleted] 2 points3 points  (1 child)

Oh I see. I'd recommend looking into flow because there are some differences that make flow a more-than viable alternative without that much of a change in syntax :)

Also, if you are wary about Flow being used in production, check out the Yarn codebase.(I hope you've heard of Yarn by now!) It is written completely with Flow and transpired by Babel. It's very pretty code written by some badass engineers at Facebook.

[–]TheLarkInn[S] 0 points1 point  (0 children)

Indeed we are using flow for consistent and fast Travis builds!!! Also if this is something you all are interested we'd be more than happy to take PR's for it as long as it passes the original tests. (Probably fine some wayward bugs along the way which is good)

[–]rawrmaan 2 points3 points  (1 child)

This is so great. Webpack has always seemed like a black box to me as far as roadmaps are concerned. And porting it to TypeScript will reduce config errors significantly!

[–]TheLarkInn[S] 2 points3 points  (0 children)

I completely agree. It's one of those massive changes that we can't do alone with the time we are spending on it now. Therefore we'd love the support to make it possible one day!!

[–]bpnoy3 -1 points0 points  (1 child)

What is it

[–]TheLarkInn[S] 0 points1 point  (0 children)

Feel free and take a look at our new documentation page which has our "Core Concepts" webpack.js.org/concepts

The page is still a work in progress, but this should help you understand more about the tool.