-
Notifications
You must be signed in to change notification settings - Fork 1
Architecture
This document will go over the general architecture of the application and why we made certain design decisions.
The reason JavaScript was chosen as the language is that JavaScript over time has been stable and consistent. It has existed for decades with stability and resiliency over long periods of time. While other languages like TypeScript provide nicer features it is still an evolving language and it requires a significant amount of overhead to set up. Right now with a solo development team that overhead is not required. If we have more than a handful of developers come onto the project then it would be reasonable to make the transition to TypeScript as TypeScript will make the communication between developers easier.
The reason that we chose web components over a framework is because Web Components have become part of the ECMAscript specification. This means that the API will stay stable over a long period of time and this is why coupling this technology with native JavaScript makes a lot of sense. Other frameworks like React, Angular, Vue or any other framework under the sun provides some utility, but ultimately an amount of overhead that is not required. By not using these frameworks and their ecosystems we're also able to deliver an experience that can make the app available to anyone in the entire world despite their internet speeds.
If the scope of the project were to grow drastically we could consider pulling in a framework, but it would have to be a really difficult problem to justify the incredibly large overhead. We built an initial prototype in React/TypeScript, and ultimately decided the overhead was not worth it. We moved faster in JS with Web Components.
We chose to use Tailwind CSS at the start of the project because it has a series of good systems for color, spacing, sizes, and other common styling problems. After making this initial decision we discovered design tokens and this would be a viable next step. We should move to design tokens when we're ready to establish norms based on the existing subset of tailwind styles we use.
In an effort to move quickly for now we have forgone testing. This is a short term solution to allow us to get a full set of features to MVP, but ultimately we will plan a series of Tech Debt projects after completing the MVP to address this problem.
This app should be installable. This feature has not been completed yet.