Should this project switch from Typescript to JavaScript?

[Mr0grog]

In porting this project to React (#48) it became obvious that there’s some added complexity and friction in particular between Typescript and React. We want this project to be as accessible to new contributors as possible. The idea of dropping Typescript and just going back to JS (albeit still with some Babel compilation/bundling step) was floated on Slack, so I’m bringing that conversation over to Github where it’s a little more visible and is better archived.

Original thread: https://archivers.slack.com/conversation/C4470HNBD/p1495153254170597

[Mr0grog]

@Mr0grog: See also https://github.com/edgi-govdata-archiving/web-monitoring-ui/issues/41

[Mr0grog]

@patcon: i don't know typescript myself, but my impression is that of all the "other" things to know, it's not one that someone would learn begrudgingly, as type systems seem very practical and on the upswing in favourability...?

but if there are anecdotes about it scaring people away, then that's def overriding!

i can imagine someone saying "i don't know typescript", and perhaps it sounds like a reason they don't end of contributing, but maybe they just ended up going elsewhere to learn it anyway (and so it wasn't the actual reason for losing them)?

[Mr0grog]

@mhucka: My $0.02 is that I'd aim for something that has broader familiarity, which would be Javascript rather than Typescript, unless there is something really crucial that argues for keeping Typescript.

[Mr0grog]

@lightandluck: @patcon The basic components of the language itself are easy to learn, appeasing the compiler is the where most of the trouble stems from.

When Typescript is added to the build process, it complains about a lot of errors where code doesn't conform to what it wants. It takes some time to understand the conventions expected and how to fix the errors. Think of it like a linter that complains about the structure of your code, instead of syntax.

It's definitely harder to fix then just adding semi-colons or changing double-quotes to single-quotes. And until you figure out what to do, the code won't compile!

It took some fighting to get the google api libraries to work with Typescript, and I think Rob had similar issues with React. The potential contributor had to learn both and get them working. I can see why she might have been discouraged. I didn't even attempt it.

In the interest of accessibility to the project, I think we should drop TS for now.

[Mr0grog]

@Mr0grog: FWIW, I’d say the following: strong typing isn’t an issue on its own, but since JavaScript isn’t typed and we are always going to be using plenty of libraries that are not strongly typed, Typescript often becomes an exercise in massaging your code to work with the compiler in a way that is not the case in environments that are strongly typed at their core.

You have to make sure you acquire not just a library, but also the typings for that library (assuming they are both available and up-to-date). Further, the typings are developed by third parties and might not always reflect what you expect (e.g. React event types are all generic, so you can’t type an event handler as receiving MouseEvent, but rather MouseEvent, and you can see here that the right answer depends on the element your listener is being attached to).

That’s not to say it’s all bad. Declaring component interfaces in Typescript is really nice and having the compiler or text editor yell at you for doing something in a way that’s a little too ad-hoc helps to enforce better approaches. But I am finding the overhead with TS is higher than what I might have expected.

[Mr0grog]

@lightandluck: Totally agree that declaring parameter types and component interfaces is awesome, but the overhead is killer. :sweat:

[Mr0grog]

@danielballan: No strong preference, but two observations:

• Jupyter weighed this decision for awhile, specifically interested in making the choice that would make their codebase as accessible as possible. They had concerns at first, but now feel that the typing is actually making it easier for new contributors to learn their way around the code.
• As someone who is a clumsy JS dev and recently started contributing to TS projects, I find it has an approachable learning curve.

[Mr0grog]

@Mr0grog: Oh, that is a super-interesting anecdote! I didn’t know Jupyter was using Python 3's type annotations. (Would be nice if JS had blessed-by-the-language ones, but I don’t think any of the proposals have survived.) Good to know, also, that you’ve found it helpful.

FWIW, just to mark these out here, competing type annotation tools include Flow (https://flow.org) and tools that leverage JSDoc type tags, like Closure Compiler (https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler). (I am usually pretty good about types in JSDoc, but I like both TS and Flow as actual typing tools much more than Closure Compiler.)

[Mr0grog]

@danielballan: Actually I meant Jupyter is using TypeScript. Jupyter is more a JavaScript project than a Python project these days. As an aside, very few projects are dipping a toe into Python 3's type annotations because the official line from the core devs advises caution. Since the annotations can mean whatever you want them to mean, there are concerns about composability across libraries with different conventions/expectations. The most interesting application I've seen so far is using them to autogenerate GUI data-processing pipelines based on functions with annotated inputs and outputs.

[Mr0grog]

@Mr0grog:

very few projects are dipping a toe into Python 3's type annotations

Heh, yeah, that’s what I’d thought and hence my surprise. I totally misunderstood, though :stuck_out_tongue: (Similarly, I keep seeing ApiStar pop up as a good example of exactly what you’re talking about in action, though I haven’t looked into it.)

@danielballan do you have more info on that? (TS in Jupyter)

[Mr0grog]

@danielballan: Sure. What aspect?

[Mr0grog]

@Mr0grog:

• Having trouble finding .ts sources
• Any blog posts/writeups/discussions about what’s worked well/not well about it

[Mr0grog]

@danielballan: We have had to roll some of our own ts sources, but they have all been short-lived: upstream projects are taking this on themselves at a good pace. The discussions I've been in have all been in person, but there might be write-ups somewhere. I've pinged our gitter -- I'll let you know.

…

Nothing written down about the decision to use TS, unfortunately.

[Mr0grog]

From this afternoon’s community call, @b5 noted he’s seen two other projects go React + Typescript, then back off for similar reasons. There was a general feeling that some tools work great with Typescript (e.g. Angular 2, Vue, Phosphor), but most of those were developed in Typescript or with Typescript in mind. React is/was not.

[danielballan]

That's convincing.

[b5]

no surprise here, I'd vote to lose the TS. With the logic that it opens up opportunities to cross-pollinate with the archiving team's stuff. I'm thinking specifically about irritating-to-implement stuff like date pickers, valid form inputs, etc. We have lots of that stuff already written, also, we can bring more webpack / babel / sass build tools & publication pipelines to the mix

[Mr0grog]

Ok, I think we are generally leaning towards removing Typescript. I think we should leave this until next week—after the Mozilla sprint—to do because I think getting better docs, sane setup process, and clear issues ready for it are higher priority.

If anybody has more thoughts/comments to weigh in here between now and next week, feel free to keep posting.

[Mr0grog]

After working together this weekend with @b5 and @danielballan, I think we are all feeling pretty strongly that TypeScript should be removed. For now, I think we are going to leave it until we can push out V0, but we should move back to JS as soon as possible afterward.