nelsonic
commented
5 years ago @SimonLab thanks very much for opening this issue to capture our discussion. āļø
Itās worth contextualising for people (now that Iāve moved the issue - hope you donāt mind) that our objective is to (re)build the @dwyl App in the coming months from scratch. We are using Phoenix (Elixir + Postgres) for the server, because we are already quite familiar with it (6 projects) and it has two key features we need Channels and Presence. Phoenix builds on of OTP (āOne Trick Ponyā aka Open Telecom Platform) which removes almost all of the complexity of building scalable/performant real-time apps.
We are thinking of building a super lightweight server in Elixir that provides Auth, Access Control (to data) and an API (REST + WebSockets). And the rest (UI) we were hoping to build in a single language/paradigm.
For the UI of the App, we want it to be mobile first with offline support from day one. Thereās not much point having a āsingle source of truthā App, that only works when online. We donāt want the burden of slow release cycles inherent in a āNative Appā, so we are leaning towards a PWA. (This is not to say that we are ruling out āNativeā completely forever, just that during MVP, we want to build/iterate fast and Web Apps allow us to ship much faster)
Crucially we want:
- Offline support for all single-user actions to ensure zero interruptions to use when network is poor (or when people deliberately switch off their WiFi and still want to get real/ādeepā work done). Sadly, this rules out using Phoenix Liveview for anything except Auth which requires network access.
- A single language/framework to build a rich mobile experience including basic gestures and micro interactions/animations.
- Progressive UI the ability to display the bare minimum UI while the person progresses through learning how to use the App. means the person using the app only sees the features they want to see rather than being spammed/overwhelmed with stuff that doesnāt interest them.
As Simon says: we were considering using Elm UI because itās ājust Elmā to define the UI and are hoping it will be a good way to ensure long-term maintainability of our codebase.
Very much open to suggestions from people who have experience with any other compelling tech.
We briefly looked at Flutter+Dart but determined that it was more complex than Elm in the short-term. We may revisit it later and are open to anyone sharing their experience of it that will help us decide.
On our recent projects we have used Tachyons to build rapidly the user interfaces. At least for the first few sprints I think we could continue to use Tachyons while we are writing done our thought and ideas about the app's features, however I'm keen to investigate other tools which will help us to let people contribute easily to the UI and to let us maintain and involve the UX rapidly.
I've been keen to use and learn more about grid css (combine with flexbox). Tailwind which is similar to Tachyons seems also popular at the moment.
Another idea suggested by @nelsonic is to use Elm UI and have a full frontend build only with Elm (see also https://www.youtube.com/watch?v=Ie-gqwSHQr0&t=2s)
We need to make sure that we are able to build a responsive (mobile first) application with the selected tool and that the UI produced will be easily customisable.