search

mitmproxy / mitmweb

GSoC Issue tracking for mitmweb.
11 stars 3 forks source link

Consider Typescript #43

Open cortesi opened 7 years ago

cortesi commented 7 years ago

I recently moved a bunch of web projects to Typescript, and the benefits were immediate. We're at a point where ecosystem momentum is coalescing behind Typescript as the "JavaScript+" of choice. It's well-designed, lightweight, clear, and has really, really great developer tool support. We should consider shifting the codebase over.

mhils commented 7 years ago

How are your feelings about Flow as an alternative? (I haven't looked into either one in depth, but given that Flow is Facebook's child as well this may make sense)

cortesi commented 7 years ago

I evaluated both Flow and Typescript, and I favour Typescript. I think it's cleaner and better designed, has more momentum, has better editor support (Typescript is best in class here, by a mile), and is more inline with where ECMAscript itself is going. Both Typescript and Flow support React very well.

MatthewShao commented 7 years ago

Here's a table about the compare, it convinces me that Typescript is a better choice. https://github.com/niieani/typescript-vs-flowtype/blob/master/README.md Another question is about the priority, if we want to introduce this into mitmweb, should we start as soon as possible or do it later?

mhils commented 7 years ago

Ok, sounds good. I'd be open to gradually adopt it for new components right away. @cortesi, you got experience with gulp/babel integration?

cortesi commented 7 years ago

If we plan to convert, we should do it in one go and ditch babel entirely. The typescript transpiler replaces babel for all intents and purposes. The allowJS option for Typescript should let us migrate portions of the codebase gradually if we want.

Regarding gulp, it's a monstrous, over-complicated, badly designed abomination that should be shot then dissolved in acid to make sure it doesn't resurrect. I use modd and devd, and my entire prep step for most projects looks like this:

prep: cd web; ./node_modules/.bin/tsc

This is my opinionated take, and I'm not about to force my own tools on this project unless there's good reason, but you did ask. ;)

mhils commented 7 years ago

Not defending gulp... but most of the complexity in our gulpfile comes from stuff we deliberately want (e.g. working sourcemaps and app/vendor split). But that's besides the point, I'd be happy to welcome both modd and devd as blessed tools to the project. :)

Back to the topic: I looked into TypeScript + React/Redux a bit closer for the last thirty minutes and I'm not that convinced for mitmweb. I don't see how TypeScript (or Flow, for that matter) would play nicely with redux and react-redux's connect(), which eleminates many of its benefits for our codebase. React's PropTypes + snapshot testing should serve our purpose pretty well here, and we avoid a whole bunch of porting work and additional complexity. I don't want to throw the possibility of using it out of the window, but right now I'd rather catch up on new mitmweb features, e.g. the options editor and the visualizations @MatthewShao proposed. :-)

cortesi commented 7 years ago

I don't want to get sidetracked on Gulp, but I can't resist saying that all of those (necessary) features are orthogonal to gulp and can be achieved outside it. My beef is with gulp itself and the ecosystem that surrounds it.

I'm happy to go with your judgement here, but I think the time to introduce a type system is before we approach complicated things like visualisations, not after. I've become very used to Typescript, it's a very big step forward in terms of code solidity, and it will certainly have wide benefits beyond just the core Redux dispatch process. Even there, a typed approach can be helpful, eg this (and a bunch of other examples).