Replies: 4 comments 3 replies
-
I completely agree with this. However, @orama254, don't you think using Typescript may lower the amount of contributions? |
Beta Was this translation helpful? Give feedback.
-
Thanks, @orama254. This is a nice proposal. I will add in some of my thoughts:
I am of the opinion that CRA is not meant to be used to build a production app in 2022. It is a great tool but most of the pain points that CRA was developed to address can be better addressed with other more modern tools. CRA was made as a one-size-fits-all tool and because of this, it has accumulated a lot of bloat that is unnecessary for most apps. Most of the tools that CRA is built around like Webpack have since evolved and the use-cases where CRA is a perfect fit are becoming slimmer and slimmer daily. I agree with the decision to switch away from CRA. PS: @orama254 shared with me a nice video that goes into detail on the same https://youtu.be/7m14f0ZzMyY
There is a general assumption that TypeScript is hard and complicated. After using TypeScript for some time, I strongly believe that this is a myth when it comes to using TypeScript for application development. There are two main sub-divisions of how developers use TypeScript: application development and library development. Using TypeScript for library development is difficult since you have to think of how to support all the possible use-cases of the library and this forces you to rely a lot on Generics and more advanced TypeScript syntax. But the story is different when using TypeScript for day-to-day application development. This will be the main use-case for the community website. Most of the libraries in the React ecosystem have been re-written in TypeScript https://twitter.com/swyx/status/1260888049958838272 and this has greatly simplified the learning curve when getting started with TypeScript. While it is true that most of the libraries do not provide 100% Type Safety https://t3.gg/blog/post/types-and-nextjs (ability to completely prevent type errors from happening), we are almost getting there. With the current status, most of the time as an application developer will be spent writing JavaScript code while enjoying TypeScript benefits. Another important point is that TypeScript is highly configurable. You can make it as loose or as strict as you want. If we ever get to a point where having TypeScript is proving to be a real problem that affects the contributions, we can find out what the barrier is and adjust the TypeScript configuration as needed. But from my personal experience, this is rarely the case. Most of the time TypeScript helps you become a better developer and you end up seeing how the lack of static types in JavaScript is not a good thing after all. |
Beta Was this translation helpful? Give feedback.
-
I am for switching to Next.js and Typescript for the reasons mentioned above. |
Beta Was this translation helpful? Give feedback.
-
After reading the discussion, I have a proposition. In order to make this project friendly to the beginners who would want to proudly partake in the open-source challenge, I move we do this in two stages. This way we make sure that those partaking in the challenge both give input and having this in mind, as they contribute within the time span, they can have time to learn the basics of Typescript before the last week of participation. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Table of Contents
Summary
Challenge
Proposal
Goal
Unresolved questions
Summary
Convert the current codebase to Nextjs and Typescript going forward.
Challenge
Our current architecture is basic, a simple approach to creating a landing page for the community website. We are currently using Create React App and react router v6 with vanilla JavaScript. This might be good for a start but might end up being a mess in future as the codebase continues to grow with time and complexity.
Proposal
We are looking into shifting the current codebase from its current form (CRA + React Router v6 + JavaScript) into Next.js + Typescript.
Goal
What are we trying to achieve?
This combination of technologies (Nextjs + Typescript) will be ideal for the community in several ways including:
Unresolved questions
Beta Was this translation helpful? Give feedback.
All reactions