Any Association
-
|
I was considering making some contributions and was looking around the codebase. I have a question, was there a particular reason for splitting the project into separate code bases as opposed to using tsx with let's say Progressive Web Apps or Electron or any other tech that allows to just keep one codebase? It seems that if we had just one code base we could go much much faster? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 3 replies
-
|
I'm guessing you're referring to splitting the codebase of mobile and desktop apps? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I thought mabe if we just use the same base, as you know there many techniques to make UI adopt to the size of the screen. If you right the UI that would be aware of the screen size and adopt and than just use a wrapper PWA, Electron, Cordova etc. |
Beta Was this translation helpful? Give feedback.
-
|
If I remember correctly, the team really wanted to make native apps instead, but I'm not sure why tbh. |
Beta Was this translation helpful? Give feedback.
-
|
Although using a universal framework has its benefits in terms of faster development and code reuse, we chose to prioritize performance, native experience, and development flexibility by developing native mobile apps. Native mobile apps offer superior user experience in terms of speed, responsiveness, and access to device capabilities. They fully leverage the underlying operating system, resulting in a more seamless and efficient experience compared to web-based solutions. Furthermore, maintaining separate code bases allows for better customization and optimization for each platform. It enables us to utilize platform-specific libraries, tools, and optimizations, leading to a more efficient and polished final product. |
Beta Was this translation helpful? Give feedback.
-
|
It's not a stupid question. I appreciate the response, and it makes a lot of sense to focus on performance. OTOH, that also means that contributors need to master Typescript, Kotlin, Go and Swift if their work has to run everywhere. Interesting point of view. |
Beta Was this translation helpful? Give feedback.
-
|
Yes one can argue a lot back and forth which approach is better, I was just curious. Too many times I've seen OpenSource projects like this one get abandoned because you lose a main developer for some architecture. And too many times I tried to do something in one client and it doesn't work because it is essentially another app. LogSeq for example It is so awesome on the desktop, I load it up on Android and you ge only maybe half the features of the dektop app. Same thing with Joplin. You can argue that oh from example (MS Teams) is slow and it sucks and some of it might be true, but it is one code base for all the platforms out there. And VSCode the same thing works everywhere and it is fast and performant. Anyway I'm not here to convince anyone here I was just wondering why this team chose such a complicated path. |
Beta Was this translation helpful? Give feedback.
Although using a universal framework has its benefits in terms of faster development and code reuse, we chose to prioritize performance, native experience, and development flexibility by developing native mobile apps.
Native mobile apps offer superior user experience in terms of speed, responsiveness, and access to device capabilities. They fully leverage the underlying operating system, resulting in a more seamless and efficient experience compared to web-based solutions.
Furthermore, maintaining separate code bases allows for better customization and optimization for each platform. It enables us to utilize platform-specific libraries, tools, and optimizations, leading to a more efficien…