Shout out to @rhymes for giving this post a review. 👏
Before the dev.to codebase was opensourced, I was working on it in the private repository and created an issue in there that has since been copied to the public repository (thanks @maestromac !).
Having worked on several projects with large JS codebases, I can definitely say that it eliminates a lot of silly mistakes, improves dx and it gives developers a clearer view of what contracts and shapes of things are in the codebase. I've even written about it in the context of TypeScript.
The reason why I'm proposing this is twofold. The first is everything above, the second reason is it may (no guarantees) pique developers interest in contributing to dev.to OSS on the front-end more than say on a project that does not use TypeScript or Flow.
I've used Preact with TypeScript and the support seems solid since their last release, but for Flow, I'm not sure as I haven't really used Flow. I threw out this question to the Twitterverse, https://twitter.com/nickytonline/status/990768742178152448.
A third proposal, if this was a no go for everyone, is you can still get some type checking from TypeScript if you're using VS Code without event having a whole TypeScript build pipeline set up. If you add a
I was wondering what peoples' thoughts are on this?
@benhalpern commented on Tue May 01 2018
I"m in favor of this. And I think we're getting towards the end of a sprint where I and we collectively haven't been in the mindset to go back to the drawing board, but we're getting there now. This is definitely a convo I'd like to be having.
@ben , this is probably something good to discuss before open sourcing the code base.
Looking at Flow and TS, I would probably lean more towards TypeScript. Not just because it's what I've been using professionally for quite some time, but because I think the ecosystem of types is larger and it has more adoption/tooling.
For reference, my blog post, Consider Using TypeScript mentions some fairly large/popular projects using TS, e.g. Slack, MobX, LinkedIn, RxJS etc.
Even though the new Preact components are currently just JS, you can go into a hybrid mode and slowly convert things to TS while still having JS live in TS land as valid JS is valid TS. This is what we do at the moment with a large project that we're converting slowly to TS.
This could also be a good way to have some live sessions about contributing to the code base. Maybe a few sessions about TS.
@maestromac , when you have a chance, can you migrate this issue to the public repo? No rush as I'm off for another week. Thanks.
For those new to types, here's a post from Preethi Kasireddy about types.
I'm partial to TypeScript myself. I've written about it here before.
There appears to be a shift towards TypeScript for those that are interested in types. I wrote a bit about it here
There is also a great episode on the React Podcast that talks about TypeScript with Jared Palmer.
chantasticI love chatting with @jaredpalmer about hyped technologies.
He's pragmatic, considered, and methodical when exploring new tech.
If you want to successfully explore @typescriptlang in your React apps, this is a great place to start. twitter.com/ReactPodcast/s…17:36 PM - 28 Mar 2019React Podcast @ReactPodcast📣 New React Podcast! 📰 Be Super with TypeScript 💬 Typescript. What is it? How do I get some in my React apps? And where does it outshine languages like Flow, Reason, and Elm? 🎙@jaredpalmer and @chantastic 🏷 #reactjs @typescriptlang @code 🔗 https://t.co/vbohHjYhPP 🤗
Also check out the TypeScript tag
Take TypeScript for a spin in one of the playgrounds:
- Unofficial Playground
Flow is another option in the frontend in regards to types, although I've never used it myself.
Here are some links if you want to read up on Flow.
- An Introduction to Flow
- I honestly did not really find many posts on dev.to about Flow, but feel free to check out these tags.
Take Flow for a spin in the Flow REPL
I've narrowed it down to TypeScript and Flow as they are the most popular, but feel free to bring others to the table to discuss, e.g. Elm, Reason. (Thanks for chiming in on Twitter @magellol !)
Thomas Lefebvre@thomlbvr@nickytonline Nice. I think It would also be interesting to mention how Elm and possibly Reason compare to TS as well. I've been looking at Elm these days and I feel resources are much lighter.13:20 PM - 08 Apr 2019
If you really don't want to see the codebase converted to use types, that's OK too.
Are static types something that would interest people in the dev.to community who are contributing to or are thinking about contributing to the frontend codebase? Feel free to discuss in the comments here and/or jump on over to the GitHub issue and comment there.