Moim zdaniem nie uśmierci. Za dobrze się to rozwija i widać coraz większe zainteresowanie technologią. Na pub.dev powstaje coraz to więcej bibliotek. Moim zdaniem jesteś w stanie rozwiązać problem Flutterem tak samo jak natywnymi technologiami. Plus jest taki, że macie jeden kod na obie platformy.

Jak to jest pytanie to forum jest lepszym miejscem na pytania. Jak to jest hejt o fluttera to prosze o rozbudowanie. @cerrato jest hejter fluttera tu :P

@KamilAdam: wlasnie nie chciałem żeby to był hejt. Ale ciekawa jest konkurencja w technologiach mobilnych i jak reputacja firmy może mieć wpływ na postrzeganie technologii

To zależy jak bardzo profesjonalnie ma wygladać aplikacja. W przypadku gdy mowimy o dobrze zrobionej apce to inny UI/UX bedzie dla IOS inny dla androida. Takze wspólną będziesz miał co najwyżej logike biznesową.

@Schadoow: Wszystko zależy jak chce to zrobić. Jak będzie chciał, aby apka wyglądała tak samo na obu systemach to przecież może. Oczywiście nie mówimy o różnicach platformowych. Na przykład SwitchListTile będzie inaczej wyglądał na iOS, a inaczej na Androidzie. Od tego jest adaptive(). Tutaj jest bardzo fajnie pokazane od strony Material Design

Co to za aplikacja? nie da się każdej aplikacji napisać we flutterze lub da sie ale pisząc własne biblioteki, te "rozwijanie fluttera" to ja słyszę od 5 lat, tak samo że jest to młoda technologia która przecież może mieć jeszcze błędy

@BialySokol39: nie da się każdej aplikacji napisać we flutterze lub da sie ale pisząc własne biblioteki, - what?! Jakiś przykład? Czego nie mogłeś zrobić we Flutterze, że musiałeś pisać swoją bibliotekę?

@KamilAdam: co do jest hejter fluttera tu - ja bym nie używał tak mocnych słów. Raczej możemy mówić o FlutteroSceptyku ;)

@Artur Koder: Zgadzam się z Kamilem - od zadawania pytań i dyskusji jest forum, więc lepiej, jakbyś założył to w postaci wątku w dziale "mobilne". No chyba, że to nie ma być dyskusja i jedynie wydałeś oświadczenie/podzieliłeś się swoimi przemyśleniami i nie oczekujesz, że ktoś będzie odpisywać tutaj :P

@AdamWox: np. integracja z google health api, jakieś proste crudy to sobie można pisać ale nie bardziej skomplikowane apki, nie wyobrażam sobie aplikacji finansowej we flutterze, na pewno nie chciałbym mieć konta w takim banku

@BialySokol39: tak na szybko - https://pub.dev/packages/health czy https://github.com/metaflowltd/flutter_health_fit

@BialySokol39: W jakim banku masz konto, bo Credit Agricole ma apkę we Flutterze

@cerrato: Uważasz że to ejst stabilne? 195 issue na githubie

Dodatkowo ile flutter jest już na rynku a kiedy dopiero weszła ta biblioteka ;)

@AdamWox: ciekawe :D generalnie moje zdanie jest takie że lepiej jest pisać native a rn czy flutter są dobre do bardzo prostych aplikacji, w przyszłości umrą jak xamarin

@BialySokol39: dotnet/core ma 414, angular ma 1200, react ma 903, electron ma 918. W czym piszesz? Sprawdź ile twoje frameworki mają issue. To nie jest miara. Dodatkowo ile flutter jest już na rynku a kiedy dopiero weszła ta biblioteka - Wcześniej napisałeś, że o rozwijaniu fluttera słyszysz od 5 lat, a teraz pytasz ile flutter jest na rynku

@BialySokol39: a kiedy dopiero weszła ta biblioteka możesz zobaczyć kiedy weszła na zakładce Versions. Ta pierwsza weszła 3 lata temu... Nie masz argumentu, nie spróbowałeś pewnie Flutter, a tylko papugujesz to co inni mówią na około

@AdamWox: Issue nie są wyznacznikiem ale jak widzisz kogoś(nie firmę) co napisał bibliotekę która ma dużo issue to jej użyjesz? bo ja nie. Za każdym razem jak mam użyć jakieś niewiadomej biblioteki nie np. od google to 3 razy się zastanawiam. Przeczytaj jeszcze raz co napisałem, flutter jest od dawna już na rynku a biblioteka do google fit została stworzona niedawno

@AdamWox: próbowałem fluttera, dlatego się wypowiadam, brak porządnej biblioteki do di, wewnętrznej bazy danych, dart który jest sklejką najgorszych cech języka, nie jest czytelny, porównaj sobie natywny kod w swiftcie lub w kotlinie z tym co jest we fluttrze ;)

@BialySokol39: Ja mam takie zdanie na temat natywek. Java to ścierwo, próbują to ratować Kotlinem. Ten cały XML do UI to jakiś masochizm. Jak patrzysz na ilość issue na git to ja się nie dziwie, ze ty piszesz swoje biblioteki. Poczytałeś wszystkie issue? Czy któryś z nich spowoduje, że twoje oprogramowanie nie bedzie działać? Ile musi mieć issue żebyś użył biblioteki? Jaki jest próg użycia?

W naszym przypadku dochodzi jeszcze zastanowienie nad zespołami w firmie. Bo pisząc w RN można wciągnąć react devów do projektów. W zasadzie RN nie rozni sie od Reacta. (dla doświdczonych). Ale i tak w RN potrzeba przynajmniej natywnego z iOS i z Androida.
Albo osobne zespoly dla native.
Za to we fluterze zakładam że nie potrzeba natywnych devów, a tylko flutterowców. A
Do PWA nic nie trzeba, jeżeli ma sie aplikacje mobile first, to PWA jest out of the box

Dużo za i przeciw. A widze że nawet tutaj zdania są mocno podzielone.

@Artur Koder: Podzielne zdania są odwieczną wojną technologiczną. Taka sama dyskusja będzie przy frameworkach JS'owych.

@AdamWox: w JS naszczęscie się troche ustabilizowało. Większość nowych to klony reacta/angulara. A tutaj każda z technologii jest zupełenie inna. Nawet RN i fultter są niepodobne do siebie

@AdamWox: java to syf, podobny do darta, kotlin to całkiem inny poziom, na androidzie nie musisz pisać widoków w xmlu, jest od jakiś dwóch lat jetpack compose

@BialySokol39: i właśnie jetpack compose jest jednym z atutów native obecnie. Gdyby nie on, wcale byśmy nie rozważali kontynuacji developmentu natywnych. Podobno ze SwiftUI też nie jest najgorzej.

@cerrato: nie oczekiwałem aż takiej zawiłej dyskusji. Raczej podzieliłem się rozterkami "młodego" tech leada ;)

Jestem devem RN od paru lat i jak wychodził Flutter to byłem przekonany, że to będzie nowy lider.

Okazało się jednak w praktyce, że komponenty funkcyjne w Reactcie są dużo szybsze w pisaniu od klas w Darcie. Do tego te klasy na froncie to jest jakaś kula u nogi, bo nieintuicyjny jest cykl życia tego wszystkiego np. przez to, że metody zmieniają stan klasy. Jest dużo jakiegoś takiego właśnie metaprogramowania.
IMO na froncie najczęściej wygrywają technologie, gdzie można coś szybko napisać bo jest duże prawdopodobieństwo, że za niedługo trzeba to będzie wywalić xd

No, a teraz środowisko React Native ma dojrzałe Expo, w czym robimy praktycznie każdą apkę. Nowy RN ma nowy wydajniejszy native<-> JS bridge, szybszy silnik js o nazwie Hermes.

I na dodatek, RN wyciągnął z Fluttera chyba najfajniejszą rzecz, mianowicie renderer Skia i musze powiedzieć, że działa to super.

RN devów jest więcej, środowisko jest prostsze, RN jest wystarczająco wydajny, wszystko jest tańsze, community jest ogromne. Naprawdę nie wiem gdzie flutter teraz ma swoje miejsce - chyba jakby ktoś pisał Figme. Ale i tak bym się zastanowił wtedy czy nie napisać tego w Rust->Web Assembly xd

@Garen_eye: ciakawe spojrzenie. Czyli Expo jest teraz na topie i się pisze aplikacje w aplikacji a później eject Expo? Bo jeżeli tak, to strasznie musi to przyspieszać development.

Dobre stwierdzenie co do klas. Nie lubię ich ;)

ja tam pisze w ionicu ale w firmie u mnie lecą na flutterze.

Google przepisał Google Paya na Flutter więc myślę że Flutter pożyje.

Jak produkt jest dobry i ktoś go porzuci lub nie daje rady sam go prowadzić, to zawsze ktoś forka zrobi i gdzieś się będzie rozwijał. Nie koniecznie dla twórcy taki fork jest fajny jeśli ludzie się na niego przerzucą :>

Jest jeszcze kotlin native multiplatform jak ktoś nie lubi używać dart i woli pisać natywne aplikacje.

@Artur Koder: Flutter jest ok, jak piszesz sobie prostą apkę typu przeglądarka newsów, ale jak trzeba napisać bardziej złożoną apkę z jakimiś zależnościami do natywnych bibliotek, albo integrować jakieś biblioteki od vendorów, to już nie jest kolorowo. Mamy przerośniętą apkę, żeby działała jednocześnie na dwóch platformach i ifologię do tego. Inny przykład: Jest apka we flutterze i vendor ma bibliotekę na androida i iOS i teraz co - będziemy mu kazać pisać kolejną frankensteinową bibliotekę we flutterze żeby się zintegrować z apką? W praktyce to będzie pełno kopiowania i wklejania i wiązania tego trytytkami we Flutterze. Flutter z tych cross-platformowych technologii wypada najlepiej, ale fakty są takie, że aby coś było zrobione porządnie oraz było łatwe w utrzymaniu i rozwoju, to trzeba to pisać natywnie.

@wiciu: Czyli vendor woli napisać bibliotekę dwa razy, w dwóch różnych technologiach/językach (android i ios) niż w jednej pod Fluttera? Ja rozumiem, że native w dalszym ciągu jest popularny i vendor nie będzie "ryzykował" pisania swoich bibliotek pod niszowego Fluttera, ale skoro nie widzi problemu w pisaniu dwa razy tego samego pod natywność, to ja na jego miejscu napisał bym też tą bibliotekę na pub.dev

@AdamWox: Fakty są takie, że większość apek jest natywnych, więc i tak trzeba pisać biblioteki na iOSa, Androida i dodatkowo na Fluttera, a jak ktoś sobie wymyśli jeszcze jakąś inną technologię to na nią też. No i zamiast pisać dwa razy kod, to pisze się 3 albo 4 razy. Poza tym, są pewne niuanse pomiędzy platformami i nie da się wszystkiego od strzała napisać cross-platformowo, żeby od razu działało na iOS i Androidzie. Sam mam perspektywę takiego vendora, są wdrożenia na iOS, na Androida, przyszedł klient z Flutterem no i prawdopodobnie nie wdrożymy u niego rozwiązania, albo zrobimy to nie wiadomo kiedy, bo brakuje na to czasu i ludzi.

@AdamWox: Weź pod uwagę, że nie każdej firmie zależy aby wchodzić na wiele platform. Więc firma może mieć w dupie np androida i wypuszczać biblioteki tylko na ios'a.(albo odwrotnie)

@Schadoow: albo mega upierdliwe jest api, taki windows, a linux to dwa różne światy, praktycznie całą fasadę trzeba od zera zrobić dla każdego systemu oddzielnie, mega demotywujące to jest, bo każdy system jest inny, a w dodatku windows jest obrzydliwy, wszystko tam jest brzydkie.

@wiciu: Głęboko w duchu wierze, że to się zmieni i pewnego dnia Flutter wystrzeli w kwestii popularności. Jedyne co mnie boli we Flutterze to ten boilerplate, który się generuje za pomocą build_runner. Tyle dobrze, że się generuje, bo wcześniej trzeba było wszystkie klasy do JSONów klepać ręcznie. @Schadoow wydaje mi się, że wiele platform nie jest tutaj punktem odniesienia. Mało kto wie o czymś takim jak Flutter. A jak już wie to boi się zaryzykować, bo Google i ich tendencja do uśmieracania projektów.

@AdamWox: google nie uśmierca projektów, ale jak ma statystyki, że nikt z nich nie korzysta to mogą przejść na emeryturę i to jest logiczne, też bym zakopał projekt jakby nikt go nie chciał nic nie zarobisz, depresja itp.

@CloudPro: Oczywiście, że uśmierca. Np GWT w pizdu firm dalej tego używa bo koszt przepisania jest ogromny.

@CloudPro: Ale ja tego nie neguje. Też bym nie chciał trzymać trupa w domu. Problemem jest, że przez ten pryzmat patrzą firmy/programiści i nie biorą w ogóle Fluttera pod uwagę. Nawet w tym wątku parę razy chyba było o tym wspomniane.

@Schadoow: hmm, jak hajs przynosi technologia to nie wiem czemu uśmiercona jest, a nikt forka nie robi? ktoś może przejąć pałeczkę

@CloudPro: zależy co masz na myśli mówiąc "forka". Ale nikt juz tego nie rozwija. Tylko krytyczne bugi są łatane.

@Schadoow: czasem ludzie sobie kopiują projekt i tworzą jako swój coś jak fork, trochę hamówa że komuś projekt kradną.

@CloudPro: W krytycznym projekcie wartym parenaści-paredziesiąt milionow usd nikt nie będzie się bawił w forki jakiegoś randomowego deva.

@Schadoow: ja nie powiedziałem, że flutter umiera... To dobra technologia, to już sam sobie dodałeś :>

@CloudPro: Dziwnie łaczysz wątki. Ja odniosłem się do tego, że google uśmierca projekty. I żadne forki nie są ratunkiem.

@Schadoow: skąd wiesz, że uśmierca? pascal od 50 lat próbują go zabić i żyje

@CloudPro: Killed by Google

NIe da się dobrego produktu uśmiercić, możliwe że kupą się okazały to uśmiercają, ale tak taki flutter to zajebista technologia to tak łatwo nie zginie.

@CloudPro: O Google Stadia też tak mówili

Ale ja tak nie mówiłem,

Lubię google, bo mnie szanuję i pomogę im.

@CloudPro: Ale ja tak nie mówiłem, - i pewnie dlatego to ubili

@AdamWox: wyobraź sobie, że to twój ukochany projekt, i dużo pracy w niego włożyłeś, myślisz że on zginie od tak?

@CloudPro: Widzę, że młody w IT :). Corpo nie ma sentymentów.

@CloudPro: Jakby miał jedną z najpopularniejszych i najbogatszych firm na świecie i inwestorów, którym trzeba ścieme sprzedać, że to będzie sztos program i, że ludzie tego chcą to nawet bym nie zauważył, że program zginął

bez jaj panowie, na flutterze dużo powstaje apek, flutter sie utrzyma tak jak angular.

@ehhhhh: w xamarinie też sporo powstawało :p

@Schadoow: A to w sumie dalej nie jest rozwijane ale pod domena .net maui ? (nie znam samego xamarina), ale wyglada jak by maui na nim było oparte?

Hm, ciekawe z tym killedbygoogle. Widze tam dwie biblioteki do JSa i jeden język. GWT jeszcze nie widzę, a myślałem że juz ubili oficjalnie. A w zeszłym roku po dwóch latach był nawet update XD

@KamilAdam: i w tym roku wyszła wersja https://github.com/gwtproject/gwt/releases/tag/2.10.0 ale to zazwyczaj jest support dla javy xyz, pare jre symulation jak ktos z community się troszeczkę zdenerwuje i doda wrappera xD

@Schadoow: a co jest z xamarinem? bo według strony dalej żyje i można pisać w nim apki na androida i iosa więc nikt tego nie ubił.

@ehhhhh: ale co to za życie. Sam microsoft już wydał następce jak wspomniał @szok

@Schadoow: każda technologia przemija

@ehhhhh: Pierwsze co mi do głowy przyszło do jQuery

@AdamWox: Jquery nigdy nie umrze :D

@AdamWox: u mnie w firmie takie projekty szybkie małem dalej są pisane w jquery.

@AdamWox: jQuery to takie rakowisko, ja umiem react i javascript, a tego jquary nie ogarniam, co to za diabeł to wymyślił.

@CloudPro: jquery jest prostsze niż czysty js ;)

Dla mnie trudniejszy, wolę czysty js.

@CloudPro: a dla mnie react to rak, i go palcem nie tknę, vue i angular są dużo lepsze.

czyli mamy kosę, ja umiem reacta tylko :> Mamy wojnę

@CloudPro: jak zobaczyłem, że na to co w angularze potrzebuje jednej linijki w reakcie potrzebuje pisac osobną metodę i kilka linii to podziękowałem, szkoda czasu.

Możliwe, że angular jest łatwy, mi tam react pasuje też jest łatwy i fajnie się pisze łatwo.

ja tam lubię pytorch sztuczną inteligencję

@CloudPro: jeśli uważasz że w react piszesz łatwo i szybko to po spróbowaniu vue lub angulara byś zmienił zdanie.

@ehhhhh: react jest fajny chyba nie zmienię zdania, mi się tam fajnie pisze.

Ja też Angular i bardzo chciałem przejść na Svelte (SvelteKit), ale za duże różnice we frameworku względem Angulara i ciężko mi się było przestawić.

Ale o co w sumie pytasz?

Flutter wygląda solidnie, próbowałem kiedyś ze Swiftem i odpuściłbym sobie te rozwiązanie, Ionic ssie pałe a react native wydaje się nawet git :D

Flutter moglby byc bardziej popularny gdyby nie dart, tragiczny jezyk ;)

Gdyby zrobili fluttera, ale w Kotlinie. To byłoby coś

@KamilAdam: Nazywa sie to KMM, trzeba tylko widoki w swift tworzyc

Tak w ogóle to już w zasadzie i widoki da się tworzyć w kotlinie dla iOS, ale na razie to experimental

Dorzucę od siebie jeszcze tyle, że Swift z biegiem czasu okazał się niewypałem - Change my mind proszę ;)

Tak, bo wjechał Kotlin i pozamiatał.

Swift z biegiem czasu okazał się niewypałem @Mateuszto Ale w jakim sensie? Że nie używa się go do pisania apek natywnych na iOSa czy że nie używa się go do pisania aplikacji natywnych na macOSa?

@Mateuszto: What? Jakim to niewypałem?

Trochę ognia do dyskusji, a ogólnie, patrząc i na oferty pracy i na rozwój rozwiązań Js'owych

@Mateuszto: Dorzucę od siebie jeszcze tyle, że Swift z biegiem czasu okazał się niewypałem - Change my mind proszę Co Ty piszesz? Niby dlaczego niewypałem? Przecież prawie wszystkie współczesne apki na iOS są pisane w Swifcie xD. Już wolę pisać w Swifcie zamiast Obj-C. Co prawda, development androidowy jest IMO lepszy i bardziej stabilny, niż iOSowy i wolę osobiście pisać w Javie, niż w Swifcie, ale nie wiem, dlaczego Swift miałby być niewypałem. Jakie mamy alternatywy, żeby pisać apki na iOS? Obj-C i jakieś cross-platformowe wynalazki. Na desktop jest więcej wariantów pisania apek, ale gdybym miał pisać apkę na desktop pod macOS, to raczej wybrałbym Swifta, bo to natywne rozwiązanie. Pozostałe rozwiązania, to podchodzenie do tematu naokoło.

@Mateuszto: JS najlepszy wybór, a nie ogień do dyskusji...

Bardziej niż tego, że którakolwiek z tych technologii upadnie bałbym się, że zabraknie rzeczy, które trzeba w nich napisać. Jeżeli na desktopie nie mam aplikacji bankowej, klienta jakiegoś streamingu, aplikacji do YouTube, fejsbunia i klienta poczty, to jakie właściwie są powody do "mania" tych aplikacji w telefonie, inne niż upośledzenie technologii webowych? A to upośledzenie z roku na rok jest coraz mniejsze.

@wiciu: a jak znasz i swtifta i androida, to co Cie najbardziej wkurza w swficie? Nie mam zadnego doswiadczenia, wyglada na dosc nowoczesny jezyk. Słyszałem że observable w swifice są mocno bugogenne, ale to mógłbyć skrót myślowy kolegi

@piotrpo: no najlepiej byłoby utrzymywać PWA, szczególnie ze można je umieszać w storach. Niestety push notifications na iOS dla PWA mają wejść dopiero w tym roku. Niestety konkurencja którą stalkowaliśmy i która wybrała PWA, nie ma najlepszych aplikacji. Jest ciągle feeling webowy i, brak tych natywnych płynnych animacji itp. Po prostu widać że to web. Ja personalnie używam PWA dość sporo, a moja ulubione aplikacje to outlook i facebook :)

Uczyłem się Swifta dobrych pare lat temu i zrezygnowałem przez wymagania rynkowe + dość mało tych ofert pracy jednak, czy ten mobile to naprawdę taki future? hah

@Artur Koder: Desktopowy outlook jest w stanie prawie każdego przekonać do korzystania z wersji przeglądarkowej - nie ma co ukrywać. To "widać, że to nie natywna aplikacja" to jedynie kwestia upośledzenia technologii frontendowych, które wymiękają na mobilnych procesorkach. To się będzie zmieniać, jak nie z rozwojem FE, to z lepszymi procesorami mobilnymi. Pozostają kwestie jak obsługa sensorów i działanie w tle, ale to też nie są rzeczy nie do przeskoczenia.

@piotrpo: to by było piękne. Ale jeżeli są podejmowane na wytwarzanie nowych aplikacji w firmie nawet w prespektywnie 5 lat, to PWA jeszcze nie jest to. Plus jest taki, że jeżeli buduje się systemy webowe z nastawieniem mobile-first, to PWA praktycznie jest załatwione i w przyszłości może być łatwo zmigrować

@Artur Koder: Dlatego też, jakiś czas temu (~5-6 lat) postanowiłem odejść z programowania aplikacji mobilnych, po tym jak zauważyłem, że liczba ofert i kasa w backendzie jest na innym poziomie. Jedyne czego brakuje, to satysfakcji z tego, że samodzielnie wykonało się jakiś tam kawałek porządnej roboty, którą widać.

@piotrpo: to będzie offtop. Ale za to kocham Typescript. Napiszę sobie wszystko, od skryptów dev opisowych, po BE, FE, mobile

To nie technologie FE są problemem tylko ludzie którzy ich używają.

@marian pazdzioch: są wygodne

@Mateuszto: No tak ofert jest mało i wymagania na swifta też są spore. Nie jest to moja główna technologia, tylko taka, którą poznałem przy okazji, ale full-time bym w swifta raczej nie poszedł no chyba, że oferta byłaby dobra, hehe.

najbezpieczniej to swift

@Artur Koder: a jak znasz i swtifta i androida, to co Cie najbardziej wkurza w swficie? Nie mam zadnego doswiadczenia, wyglada na dosc nowoczesny jezyk. Słyszałem że observable w swifice są mocno bugogenne, ale to mógłbyć skrót myślowy kolegi - Ogólnie Swift nie jest zły. Z Androidem i Javą mam większe doświadczenie, niż ze Swiftem. W Androidzie i Javie jest lepszy package management, więcej stabilnych paczek, większe community, build management, jest lepsze IDE, lepszy debugger (można co prawda użyć AppCode, ale nie wiem, czy można zupełnie zrezygnować z XCode), brak możliwości zarządzania cyklem życia ekranu z poziomu jednego kontrolera jak w Activity w Androidzie (trzeba to rozbić na ViewController i AppDelegate). Jak mamy CI linuxowy, to dla iOS trzeba specjalny CI przygotowywać pod to środowisko, bo tylko na makach można budować projekty, w iOSie są jakieś dziwne patenty z certyfikatami i nawet jak piszesz prostą apkę dla celów samorozwojowych, to te certyfikaty tracą ważność i trzeba je przegenerowywać, albo zmieniać nazwę pakietu lub zapłacić pieniądze za konto developerskie. Jak wielu programistów pracuje nad jednym projektem i coś zmieniają w strukturze projektu, to zmienia się autogenerowany plik pbxproj i później rozwiązywanie konfliktów na tym to jest dramat (są jakieś third-party toole i patenty na to, ale nie działają w 100%). To tyle mi na szybko do głowy przyszło. Nie są to typowo swiftowe uwagi, tylko takie ogólno-iOS-owe. Osobiście jestem zwolennikiem języków bardziej explicit i silnie typowanych (jak java), ponieważ są łatwiejsze w czytaniu/analizie, utrzymaniu, debugowaniu i mniej podatne na jakieś błędy w runtime, ale to już moja osobista preferencja. Podczas pisania kodu w językach typu Swift/Kotlin też można się sporo nauczyć i rozwinąć swój "warsztat" programistyczny.

@ungoogled: to super, ale co to ma do wytwarzania aplikacji mobilnych? XD XD XD

@ungoogled: nie nie o różnych językach, tylko o językach do apek mobilnych.

@Artur Koder: problem tkwi nie w technologii, a w tym, że próbujecie na nią stawiać.

@znowutosamo: na coś musimy. Jeżeli w ciągu 3 lat chcemy wytworzyć soft w jakiejś technologii to developerów powinniśmy zacząć szukać miesiąc temu ;)

Lepiej jest uzależnić ryzyko projektu od utalentowanych, najlepszych ludzi na jakich Was stać (powiązanych z obszarem problemów jakie chcecie rozwiązać!) i to im pozwolić im pracować w tym co uznają za słuszne niż na odwrót. Inaczej to będzie miało skutek jak przy wyborze łopaty jako narzędzia pracy, wówczas tych, których zwerbujesz będą ograniczeni do bezmyślnego kopania dołów, niekoniecznie do zadania jakiego potrzebujesz.

@znowutosamo: to nie programiści podejmują decyzję o technologii bo oni wybiorą co umieją lub co im się zachce a nie co jest lepsze dla firmy. Takie decyzje podejmują architekci i liderzy.

@wiciu: dzieki za info. To są problemy z którymi spotkałem się przy pracy nad projektami napisanymi w RN. Mam wrażenie że RN troche rozwijązuje tych problemów powodu warstwy JS, ale finalnie i tak trzeba robić jako tako maitanance kodu swifta i javy

@Artur Koder: Rzadko kiedy potrzebujemy ejectować tak na dobrą sprawę - wszystkie libki już wspierają Expo (naprawdę!). Jak potrzebujemy natywnego kodu to piszemy w Expo Modules bo jest prościej (https://docs.expo.dev/modules/native-module-tutorial/). Jedynie często są problemy z Expo Go - ale wtedy wystarczy po prostu lokalnie sobie kompilować builda za pomocą expo run:ios/expo run:android co w expo i tak jest szybsze niż w bare workflow :P

Do tego odchodzi całe CI (bitrise, appcenter etc.) bo expo EAS robi to automatycznie.
No bajka, nie zmyślam.

@Garen_eye: świetnie, nie jestem osobą finalnie decyzyjną, ale dzięki temu wątkowi, oraz researchowi przez pare ostatnich tygodnii,raczej będe optował za react native. Ciekawe że każdy developer RN jest bardzo zadowolony z developmentu