Technologia dla front/mobile na XXI wiek

Jeśli chodzi o front to jestem ignorantem. Kompletnie się nie znam i prawdopodobnie rzucam się na głęboką wodę, ale mam pewien pomysł i chce zrobić MVP, najpierw sam, wybadać rynek.

Chcę by domyślnie moja apka była dostępna z poziomu przeglądarki jak i aplikacji mobilnej. Zastanawiam się jednak czy lepiej rozdzielić te dwa światy, czy pójść w jedno rozwiązanie działające na obu płaszczyznach?

Niby jest Flutter i korzystam z niego teraz (w tym momencie jeden projekt mi został), ale to co robi google np. z go i telemetria jest dla mnie niesmaczne i tylko kwestią czasu będzie jak i dla darta obiorą taki kierunek IMO.

Z perspektywy zwykłego usera apka ma być jak najprostsza, panel administratora będzie jednak dość złożony i pewnie dostępny tylko od strony przeglądarki.

Proszę o opinie oraz argumenty za/przeciw jeśli takowe macie, jaką technologie wy byście wybrali

Jak nie masz skilla to nie wybieraj rozwiązań w stylu all-in-one.

Będziesz miał mniej źródeł do nauki, mniej jakościowych materiałów, przykładów, sprawdzonych w boju bibliotek, narzędzi oraz dużo częściej napotkasz nieszablonowe błędy, które utrudnią Ci parcie naprzód, a może i nawet zablokują drogę.

Rozwiązania all-in-one przyspieszają pracę o ile masz doświadczenie, masz rozeznanie w wymaganiach i ograniczeniach poszczególnych narzędzi.

Do web wybierz :

• php (gdy większość pracy jest w jakimś istniejącym CMS, wtedy mniej się napracujesz) lub
• ruby / python (w zależności od bibliotek; jak dla mnie to python jest lepszy do wystawiania api; a ruby lepszy do kompletnych serwisów) lub
• nodejs / go (jesli będziesz polegał na websocketach w większym stopniu).

Do mobilnych rzeczy:

• android + kotlin,
• ios + swift

@znowutosamo: Jak to co napisałeś ma się do tematu? Backend mam już zrobiony i działa od dawna. Teraz chce zrobić front do tego by user nie musiał bawic się w CLI. Piłeś, nie pisz.

Dregorio napisał(a):

Zastanawiam się jednak czy lepiej rozdzielić te dwa światy, czy pójść w jedno rozwiązanie działające na obu płaszczyznach?

To drugie, lub chociaż przynajmniej w jak największym stopniu współdzielenie codebase bo nie widzę jak jedna osoba miałaby ogarniać całkiem osobno jedno i drugie. Nie chodzi o umiejętności, a czas.

Piszesz że nie znasz się na froncie, ale co ze znajomością JavaScript (bo to nie tylko frontowy język)?

Jak nie znasz JS to od tego zacząć. A jak znasz to pozostaje wybór frameworka, i w zasadzie nie ma znaczenia czy np. Vue czy React bo we wszystkim zrobisz PWA.

@Verona: Chcę tylko napisać MVP, potem jak inwestorzy będą zadowoleni to zatrudnię osoby znające się na swojej robocie. Wiem jednak, że jak zaczyna się MVP to potem już ta technologia zostanie, dlatego chcę wybrać w miarę dobrze

Dregorio napisał(a):

@Verona: Chcę tylko napisać MVP, potem jak inwestorzy będą zadowoleni to zatrudnię osoby znające się na swojej robocie. Wiem jednak, że jak zaczyna się MVP to potem już ta technologia zostanie, dlatego chcę wybrać w miarę dobrze

I czego ci brakuje w mojej odpowiedzi konkretnie? Jeżeli zapytasz "jaki framework najlepszy" to spodziewaj się g**no-burzy. To tak jak z pytaniami jaka marka samochodu lepsza. Dostaniesz tyle odpowiedzi ile marek, podczas gdy każde auto dowiezie cię z punktu A do B.

Właśnie na to liczyłem, na dużo odpowiedzi z argumentami, a ja sobie wybiore "mniejsze zło"

W MVP liczy się czas i pieniądze - rób wszystko na web. Jak coś zacznie stanowić problem to będziesz rozwiązywał, możliwe, że nawet hybrydowo (część appki to np. natywny Flutter, część zwykły webview)

@dzek69: Też tak chciałem, ale potencjalny inwestor chce zobaczyć apke mobilną też :(

Jak mu PWA nie wystarcza no to mu zapakuj wersję webową w aplikację przez zwykłe webview, co za problem? :)

A jeżeli uważasz, że MUSISZ postąpić w ten sposób, bo inwestor, to nie rozumiem po co pytanie, skoro rozwiązanie jest narzucone ;)

@dzek69: Hmm, może nie potrafię przekazać tego co chce, przepraszam. Postaram się jeszcze raz przekazać swoje mysli.

W mojej głowie, mogę rozwiązać to na trzy sposoby:

1. Pisać w JS i mieć apke web + mobile
2. Pisać w JS web + mobile w kotlinie
3. Pisać w dart web + mobile
   I zastanawiam się, które rozwiązanie będzie najmniej problematyczne nie tylko dla mnie przy pisaniu MVP, ale potem przy ewentualnym rozwijaniu

3. Ja jestem stary i nie lubię "wrapperów na web", więc u mnie ostatnia opcja odpada. Dodatkowo mocno na jej niekorzyść działa ilość dostępnych devów JS a Dart.
1. Brzmi spoko, jeżeli tylko nie jest to dużym obciążeniem utrzymywać wersję mobilną też na web. Jeżeli to tylko zeskalować i poprzestawiać boxy to spoko, ale jak już trzeba mocno innego "flow" na telefonie to bez sensu i zostaje opcja 2.

Dzięki, chyba najrozsądniej będzie zrobić tak jak mowisz. Na SO podobnie proponują.