Web vs desktop

5

Żeby nie zaśmiecać tematu Desktop + swing - propozycja pracy tworzę kolejny

@katakrowa:

Moim zdaniem robienie wszystkiego jako WEB to chwilowa moda. Pociągająca jest pewna ogólność tego typu rozwiązań ale praktyka pokazuje, że nie zawsze jest to potrzebne a coraz częściej okazuje się zbyt kosztowne.

W jaki sposób jest to zbyt kosztowne? Znaczna częśc systemów ma backend w którym jest zawarta pewna logika + persystencja stanu. Przykładowo, robiąć przelew musi być odpowiednia walidacja środków na koncie itp która musi być zrobiona na serwerach banku ze względu na bezpieczeństwo oraz to że w aplikacji desktopowej nie obsłużysz chociażby sensownie Kafki.
Dodatkowo dochodzi fakt że backend umożliwia bezpieczne trzymanie danych, wygodną replikację itp. Tak więc backend tak czy owak jest potrzebny w znacznej części, a aplikacje desktopowe to byłby po prostu zupełnie inny rodzaj frontu, i tyle. Dodatkowo bardziej upierdliwy, ze względu na trudniejsze przeprowadzenie aktualizacji.

Warto spojrzeć na aplikacje mobilne... w większości bliżej im do architektury desktopowej z komunikacją z serwerem niż do typowych aplikacji WEB.

Aplikacje mobilne często mają inne zastosowanie.
Po pierwsze, na początku urządzenia mobilne miały o wiele gorszą wydajność i możliwości sprzętowe (ram, procesor). Natywne aplikacje mobilne umożliwiały lepsze wykorzystanie tego.
Po drugie, dochodzi całe to działanie w tle i pushe notyfikacyjne, a ludzie mają telefony na ogół przy sobie.
Po trzecie, chodzi o cachowanie danych i tryb offline. Jeśli masz aplikację mobilną taką jak Anki, to możesz wykorzystać tryb offline nawet na szczycie Tatr, bo tam bierzesz komórkę, dziala ona w trybie offline, a laptopa tam nie weźmiesz.
Ale to tez ma swoje koszty, bo taka aplikacja mobina pozwalająca na lokalny zapis danych i późniejszą synchronizację z backendem który trzyma stan jest w praktyce multi-leader database. Trzeba rozwiązywać konflikty, przykładowo, użytkownik przejszy flashcardy z danego dnia na komputerze, następnego dnia wykorzysta do tego aplikacje mobilną której wczesniej nie synchronizował bo nie włączył neta. Przejrzy również te flashcardy z dnia poprzedniego, włączy internet i spróbuje dokonać aktualizacji. I cyk, konflikt zapisu.

6

no dobra, to od początku:
Aplikacje desktopowe/mobilne tworzy się prościej niż aplikacje web'owe. Powody to:

  • Możliwość wykorzystania natywnych kontrolek systemowych. Na przykład, jakiegoś guzika z Windowsa, czy Androida.
  • Ma się większe możliwości wykorzystania API systemu, co w przypadku przeglądarek jest niemożliwe ze względu bezpieczeństwa.
  • Znacznie wydajniejsze narzędzia do tworzenia UI. Przeciągnięcie kontrolki z palety do jakiegoś tam layoutu jest prostsze i szybsze niż klepanie DIV'ów w WWW.
  • Wydajność jest kluczowym problemem w niektórych zastosowaniach. Nie piszę o jakimś ERP'ie, ale np. możliwości wykorzystania GPU w edytorze grafiki.
  • Można (zwykle) utrzymywać wspólny stack technologiczny dla frontu i backendu. Np. Swing na froncie ze Spring na backend, albo C# w .NET

Aplikacje OPA to skutek powolnej ewolucji HTML, CSS, JS i patrząc po tempie z jakim zmieniają się frameworki frontendowe daleko jeszcze do osiągnięcia stabilnego rozwiązania. To tempo jest skutkiem braku naprawdę sensownych rozwiązań na rynku. Bo o ile aplikacje GUI są z nami od jakiś 50 lat, to całe WWW ma raptem 30, JS 25, koncepcja, ze można zmieniać jedynie fragmenty wyświetlanego dokumentu (AJAX) powiedzmy 15. Koncepcja aplikacji działającej w przeglądarce w obecnej formie, to pewnie coś koło 10 lat, wcześniej mieliśmy przecież jakieś ActiveX, JavaApplets, Adobe Flash i to drugie, Silverlight, JavaFX.

Udostępnienie jakiejś funkcjonalności przez przeglądarkę ma natomiast od groma zalet, które w większości przypadków przewyższają wady takiego rozwiązania:

  • Brak potrzeby instalacji. Wrzucasz na jakąś już istniejącą stronę link do twojej aplikacji, użytkownik wchodzi, klika "zalkoguj przez Google/Facebook/..." i koniec
  • Brak problemu kompatybilności wstecznej. Mając zewnętrzną aplikację trzeba myśleć o wszystkich wersjach, które użytkownicy mają u siebie. W przypadku OPA wystarczy zgrać moment publikacji komponentów.
  • Bezpieczeństwo - wypuścisz wadliwą wersję aplikacji desktopowej - podatność będzie wieczna. W przypadku wersji przeglądarkowej, luka zostanie załatana przy najbliższym deployu.
  • Możliwości sprzedaży. To co działa ostatnio to SaaS. Użytkownicy indywidualni nie podchodzą do tego z entuzjazmem (chcę zapłacić i mieć), ale instytucje już postrzegają to jako zbawienie. Podpisuję umowę, płacę wdrożenie zakończone. Nie muszę nikogo zatrudniać do utrzymania infrastruktury, zarządzać zmianami produktu i co najważniejsze jak coś się rypnie, to nie będzie to moja wina. Użytkownicy korporacyjni nie mają problemu z "kasą". Mają problem ze zrobieniem czegokolwiek użytecznego w sensownym czasie. Jeżeli mogą mieć gotowe rozwiązanie za 2 bańki, albo coś własnego za bańkę, ale za 2 lata, to w 90% przypadków wybiorą bramkę nr 1.

Czyli, podsumowując, moje prognozy są takie:

  • Użytkownicy instytucjonalni będą wybierać całościowe aplikacje w modelu SaaS. => aplikacje przeglądarkowe.
  • Użytkownicy indywidualni podejdą do tego z większą ostrożnością, bo mają przyzwyczajenie do "posiadania czegoś", a nie "korzystania z czegoś". Jednak na rynku już widać trend przechodzenia do modelu SaaS gdzie się da => aplikacje przeglądarkowe. Bronią się jeszcze kawałki rynku, gdzie wydajność/latencja jest kluczowa. Pakiety graficzne, gry. Ale coraz bardziej idzie to w kierunku modelu przeglądarkowego. Chcesz sobie pograć w najnowszą grę w momencie jej premiery? Odpalasz na czymkolwiek url, płacisz grasz. Masz potrzebę zrobienia jakiegoś obrazka? To samo.
  • Producenci oprogramowania też prą w kierunku świadczenia usług, bo odpada im masa kłopotów z cyklem życia produktu, stabilnością dochodów, zabezpieczeniami antypirackimi itd.
1

ale np. możliwości wykorzystania GPU w edytorze grafiki.
Można (zwykle) utrzymywać wspólny stack technologiczny dla frontu i backendu. Np. Swing na froncie ze Spring na backend, albo C# w .NET

Niewątpliwie, CAD zdecydowanie nadaje się bardziej na desktop, tylko ze jest to raczej mniejsza część softu.

Ma się większe możliwości wykorzystania API systemu, co w przypadku przeglądarek jest niemożliwe ze względu bezpieczeństwa.

Z punktu widzenia mnie jako odbiorcy systemu to na ogół jest wada i dlatego preferuje aplikacje przeglądarkowe bo wiem że aplikacja w takim sandboxie jakim jest przegladarka może mniej.

4

Desktop to już dawno jest nisza z powodów, o których już napisano wyżej. Czy aplikacje pod desktop tworzy się łatwiej? Nie wiem, czy łatwiej, na pewno inaczej. Chociaż przejście z desktop na web wymaga sporo nauki.
Ja to widzę tak: obecnie 80% to web, 20% mobile a desktop to granica błędu statystycznego. Web wlewa się też na mobile - mowa o tych pseudo mobilnych aplikacjach pwa, ale słabo się to póki co przyjmuje.

2

@scibi_92: Jak patrzę na Fusion 360, to mam wrażenie, ze dużo im do przejścia na WWW nie zostało. Co do bezpieczeństwa - 99% użytkowników (użyszkodników), ma na to kompletnie wyrąbane. U nich WWW rozwiązuje zupełnie inny problem - zainstalowanie aplikacji, składające się z więcej niż kliknięcie "install", no może jeszcze "next" jest dla nich mission impossible. Ostatecznie "wchodzę na stronkę i działa" jest argumentem przebijającym wszystko.

8
gajusz800 napisał(a):

Ja to widzę tak: obecnie 80% to web, 20% mobile a desktop to granica błędu statystycznego.

To, że coraz więcej ludzi używa komputera jedynie do przeglądania Internetu i YT nie oznacza, że ilość używanych aplikacji typu desktop zmalała.

  • nie zmalała ilość używanych IDE a wręcz przeciwnie... wzrosła ;
  • nie zmalała ilość osób tworzących muzykę w offline a wręcz przeciwnie... wzrosła ;
  • nie zmalała ilość osób obrabiających Video w offline a wręcz przeciwnie... wzrosła ;
    itp... itd..

W desktop ciągle mamy:

  • gry ;
  • środowiska IDE ;
  • kompilatory ;
  • programy graficzne ;
  • przeglądarki zdjęć ;
  • nie wspominając o samej przeglądarce, która jest aplikacją desktop ;
  • programy do tworzenia / obróbki muzyki ;
  • komunikatory ;
  • edytory tekstów ;
  • systemy raportowe do baz danych ;
  • excele itp...

Procentowy udział ilości aplikacji desktop w globalnej funkcji czasu ich używania może zmalał ale ilościowo desktop jest wciąż rynkiem rosnącym i rozwijającym się.
Rozwijane są narzędzia do tworzenia aplikacji desktop na coraz to nowe platformy i środowiska a także mamy coraz więcej aplikacji stosowanych w nowych obszarach.

5
katakrowa napisał(a):
gajusz800 napisał(a):

Ja to widzę tak: obecnie 80% to web, 20% mobile a desktop to granica błędu statystycznego.

To, że coraz więcej ludzi używa komputera jedynie do przeglądania Internetu i YT nie oznacza, że ilość używanych aplikacji typu desktop zmalała.

Zaklinasz rzeczywistość, albo masz kompletnie inną perspektywę niż moja.

W desktop ciągle mamy:

  • gry ;

Google stadia nvidia coś tam.... Jeszcze wymagają instalacji "klienta", ale to raczej przejściowa sytuacja.

  • środowiska IDE ;

No tutaj masz już od dłuższego czasu przeglądarkowe alternatywy. VSCode, Jetbrains coś tam...

  • kompilatory ;

Raczej ciężko nazwać je programami desktopowymi.

  • programy graficzne ;

Adobe od dłuższego czasu idzie w kierunku przeglądarek. Photoshop pewnie jeszcze długo zostanie rozwiązaniem desktopowym, ale już taki Lightroom ma wersję przeglądarkową i przynajmniej wg. producenta to właśnie ona ma być tą wiodącą.

  • przeglądarki zdjęć ;

e... naciągane. Usług do przeglądania, korekty i przechowywania zdjęć masz od groma. Gdyby nie to, że się trochę lubię pobawić fotografią, to spokojnie by mi wystarczyły rozwiązania typu google photos.

  • nie wspominając o samej przeglądarce, która jest aplikacją desktop ;

No, trochę to jednak poza konkurencją...

  • programy do tworzenia / obróbki muzyki ;

Zależy jakie.

  • komunikatory ;

Przeszłość. Dzisiaj trudniej spotkać komunikator, który nie ma wersji www, niż taki, który nie ma wersji desktop. Oczywiście wersje mobilne się bronią.

  • edytory tekstów ;

Google docs, office 360

  • systemy raportowe do baz danych ;

Dawno poszły w przeglądarki. Tworzysz taki raport, publikujesz z tego dashboard, zapytanie. Przeglądarki kostek OLAP widziałem w przeglądarce jakieś 15 lat temu.

  • excele itp...

Office 365, Google docs...

Rozwijane są narzędzia do tworzenia aplikacji desktop na coraz to nowe platformy i środowiska a także mamy coraz więcej aplikacji stosowanych w nowych obszarach.

Masz jakieś przykłady? Bo serio, kompletnie nie zauważyłem tego zatrzęsienia narzędzi do tworzenia aplikacji desktopowych, podobnie jak rozkwitu rynku dla nich.

2
piotrpo napisał(a):

Zaklinasz rzeczywistość, albo masz kompletnie inną perspektywę niż moja.

Jakoś większość czasu spędzam pracując na aplikacjach desktop niż online. Poczynając od narzędzi do pracy, księgowości, CRM'ach, poprzez gry, obróbkę muzyki, video, zarządzanie plikami, edycję tekstów, hobbystyczne projektowanie elektroniki, poczta e-mail.
Zdecydowana większość wykorzystywanych przeze mnie programów to aplikacje desktop. To webowe są marginesem.
Nie przeczę, może ktoś ma inaczej ale pisanie, że koniec aplikacji desktop na rzecz webowych już bliski to grube przegięcie pały.

2

Wolałbym aby Desktop nie umierał bo ma w miarę spójne zachowania w systemie (kontrolki, skróty klawiszowe, itd)

ale z drugiej strony nie lubię nic instalować, więc wolę np. Google Docs, pomimo tego że wersje webowe zazwyczaj są o wiele bardziej okrojone niż desktopowe (np. Office 365)

5

aplikacje przeglądarkowe mają bardzo dużą zaletę - nie są w stanie wywalić na wierzch popupa w czasie, gdy korzystam z innej aplikacji. dzięki temu można zachować resztki zdrowia psychicznego.

0

Aplikacje przeglądarkowe i desktopowe tworzy się i działają inaczej, jeden sposób ani nie jest lepszy ani gorszy.

Sam nieraz tworzę sobie różne aplikacje jednego i drugiego typu, te bardziej udane wrzucam na swój GitHub.
Główną zaletą jest wieloplatformowość z natury, tą samą aplikację można uruchomić i na komputerze i na telefonie.

Jednak tworzenie takiej aplikacji przypomina trochę programowanie dla DOS, czylu pusty ekran tekstowy lub graficzny bez żadnego menedżera interfejsu. W przypadku aplikacji desktopowej, system operacyjny zapewnia okienka, kontrolki w określonym stylu kolorystycznym. W aplikacji przeglądarkowej styl kolorystyczny i czcionki można ogarnąć za pomocą CSS, ale zawsze zaczyna się od pustej strony. Jeżeli ma się pomysł, żeby aplikacja miała wiele okien wyświetlanych obok siebie, to w aplikacji desktopowej nie ma żadnego problemu, natomiast w przeglądarkowej takiego czegoś nie ma, da się zrobić wyskakujące okienka w DIV, ale co aplikacja to trzeba to tworzyć od początku, oprogramować przeciąganie myszki, pasek tytułu. Można to też rozłożyć na kilka zakładek lub okien samej preglądarki, ale to też trzeba to samemu obsłużyć.

Standardowe czcionki i style są po prostu brzydkie, Zwykła czarna czcionka na białym tle, to nie pasuje do stylów współczesnych OS, a z drugiej strony nie ma możliwości, żeby aplikacja przeglądarkowa przyjęła styl OS (czcionki, kolory, odstępy). W przypadku layoutu to trzeba się pomęczyć z div. Często szybciej i łatwiej użyć table/tr/td, ale jest to uważane za nieprawidłowy sposób, pomimo, że pozwala uzyskać zamierzony efekt.

Sam proces programowania przeglądarkowej aplikacji jest trudniejszy. Do desktopu czy konsoli jest duzo języków, w większości ze statycznym typowaniem, co znacznie ułatwia programowanie, współczesne IDE potrafią same wyświetlić metody dostępne dla danej zmiennej, które zależą od typu. W aplikacji przeglądarkowej jest tak naprawdę używany jeden język, jakim jest JavaScript. On jest niestety dynamicznie typowany, czyli ta sama zmienna raz może być liczbą, a raz napisem, również deklarowanie zmiennej nie jest obowiązkowe, a możliwe jest wielokrotne deklarowanie, to prowadzi do trudnych do wychwycenia błędów. Kolejna sprawa jest taka, że JavaScript ma tylko jeden typ liczbowy i to zmiennoprzecinkowy. W wielu przypadkach to się sprawdza, ale to odbija się na wydajności, a także może prowadzić do błędów. Dodatkowo, z powodu dynamiczności typów, nie ma możliwości, żeby IDE do JavaScript po napisaniu zmiennej umiał podać, jaki to jest typ zmiennej i jakie ma metody lub pola, bo nie wiadomo, czy w danym momencie będzie to tekst, czy taki obiekt, czy inny obiekt.

Jakiś czas temu napisałem w C++ aplikację wyświetlającą spectrogram w czasie rzeczywistym. Później napisałem identyczną aplikację w HTML5/JavaScript i wydajnościowo nie udało mi się dorównać wersji w C++, Udało się uzyskać może góra 30% wydajności.

Kolejną sprawą jest obsługa plików binarnych. W desktopie nie ma z tym żadnego problemu, natomiast w JavaScript trzeba się namęczyc. Można plik jakoś zaczytać do bloba, wyciągnąć bajty, ale one będą albo jako napis (tekst), albo jako ciąg liczb, więc abo dane będą nieprawidłowe, albo wydajność będzie słaba. Nawet z plikami tekstowymi też jest trochę zachodu, choćby zwykłe zaczytanie pliku .txt do zmiennej tekstowej, albo odczyt tekstu linia po linii. W C# to nie problem, a w JS trzeba się gimnastykować, chociaż jest to teoretycznie możliwe. Dobrym przykładem jest Unicode. Nazwy znaków są wyciągane z plików tekstowych udostepnianych przez konsorcium Unicode. Aby z nich skorzystać, musiałem utworzyć konwerter tekstu z tych plików na pliki JS zawierające funkcję wypełniającą jakąś tabelę. Sam konwerter też już mam w JavaScript, ale on nie potrafi zaczytać i zapisać pliku, tylko do jednego pol wkleja się tekst z pliku TXT, a skonwertowany tekst trafia do drugiego pola.

Mam też aplikację emulującą mikrokomputer oparty na Z80. W C++ czy C# to nie problem. Nieraz myślałem, żeby przerobić to na JavaScript, aby móc uruchomić w telefonie i zapomnieć o wersji w C++, ale obawiam się, że wydajnościowo nie dorównam (będzie dużo gorzej), a dodatkowo musiałbym całkowicie inaczej podejść do plików konfiguracyjnych.

Co ciekawe, kiedyś były próby uruchamiania aplikacji destkopowych przeglądarkach. Czytałem o GTK+ w HTML5, ale na zapowiedziach się kończyło. Do Javy istnieje AjaxSwing, którego kiedyś instalowałm i całkiem nieźle działał z wcześniej napisaną desktopową aplikacją w Javie, ale na szerszą skalę takie rozwiązanie jakoś nie przyjęło się. A jest to o tyle super, bo ma się jeden kod źródłowy i ten sam program może funkcjonować i w desktopie i w webie w zależności od potrzeby.

2
scibi_92 napisał(a):

W jaki sposób jest to zbyt kosztowne? Znaczna częśc systemów ma backend w którym jest zawarta pewna logika + persystencja stanu. Przykładowo, robiąć przelew musi być odpowiednia walidacja środków na koncie itp która musi być zrobiona na serwerach banku ze względu na bezpieczeństwo oraz to że w aplikacji desktopowej nie obsłużysz chociażby sensownie Kafki.

Ale co ma web (jako warstwa prezentacji) do backendu? To aplikacja desktopowa nie może gadać z serwerem?

1

@katakrowa: bo patrzysz przez pryzmat tego, czego ty używasz. A nie np przez pryzmat pracy tego, ile zleceń jest realizowanych na aplikacje desktopowe, a ile na webowe. Desktop to jest obecnie nisza. Zastosowania naprawdę profesjonalne jak IDE dla wąskiej grupy użytkowników, antywirusy i jakieś programy narzędziowe instalowane na PC. Tylko ile tego powstaje, a ile powstaje aplikacji webowych na zlecenie? Na co jest więcej ofert pracy i dlaczego?

Co do gier, to pc też coraz bardziej marginalizowany na rzecz konsol i usług chmurowych jak Stadia.

1

To aplikacja desktopowa nie może gadać z serwerem?

Może, tak samo jak ktoś może używać Excela do zarządzania projektami - tylko sensu tu na ogół nie widzę. Instalowanie, problem z wymuszaniem aktualizacji z powodu chociażby łatek bezpieczeństwa.

@katakrowa:

To, że coraz więcej ludzi używa komputera jedynie do przeglądania Internetu i YT nie oznacza, że ilość używanych aplikacji typu desktop zmalała.

xD Nie wiem czy to tak celowo czy nie, ale to brzmi jakby przeglądarka i oprogramowania w niej odpalone służyła tylko do oglądania śmiesznych filimików z kotami. A taki program do przeglądania zdjęć na komputerze to popierdółka w porównaniu do Wolfram Alpha która odpala się w przeglądarce. To jakby porównać równanie kwadratowe do całej podwójnych.

gry ;

Z tego co się orientuję to pisze się zupełnie inaczej niż inne aplikacje desktopowe, więc tutaj bym ich nie mieszał :P

środowiska IDE ;

I ile tych IDE potrzeba i w praktyce jest używanych? Pewnie kilkanaście maks tak naprawdę powszechnie używanych

kompilatory

?? Co kompilatory z aplikacjami desktopowymi mają do czynienia?

komunikatory ;
edytory tekstów ;
excele itp...

Komunikatory mam albo webówkowe albo jako aplikacje mobilne, jako edytory tesktów i arkusze są wykorzystywane aplikacje webowe/mobilne (ale głownie to pierwsze) Googli.

systemy raportowe do baz danych ;

Nie wiem co przez to masz na myśli, ale np. jakieś logi z Elastica (jakby nie było tez forma GUI dla bazy danych) oglądam w Kibanie czyli aplikacji przeglądarkowej, podobnie z logami od Kafki.

No i znaczna część aplikacji z której ludzie korzystają to tylko klienci większych systemów, których esencją są tak naprawde złożone systemy backendowe. Jak inwestujesz na giełdzie i masz alerty o zmianach cen akcji, to ten klient to jest pierdoła w porównaniu do tego co dzieje się na backendzie, wiec tak czy owak webówka króluje, bo często aplikacje kliencie to 5 czy 10% softu który jest potrzebny.

A czego by miało dowodzić? Po prostu uważam, że rynek aplikacji Desktop to wciąż bardzo ważny rynek, który przez najbliższe 30 lat na 100% nie zniknie jak niektórzy wieszczą.

Tego że aplikacje desktopowe całkowicie umrą to nikt nie suguruje, po prostu chodzi o to że mają o wiele mniejszy udzial w rynku obecnie. Mobilne jako tako się bardziej bronią, ale to trochę co innego

2

Ach nie było by tej dyskusji gdyby był 1 system operacyjny. Albo wiele na których działa aplikacja napisana raz. Niestety.
W 2022 to nie ma co się zastanawiać web mobile vs desktop . Raczej crossplatform+web vs web.

0
kamil kowalski napisał(a):

Albo wiele na których działa aplikacja napisana raz. Niestety.

No jak napisana raz a działa wszędzie, to musi to być Java. Nie będzie inaczej.

3
andrzejlisek napisał(a):

Jednak tworzenie takiej aplikacji przypomina trochę programowanie dla DOS, czylu pusty ekran tekstowy lub graficzny bez żadnego menedżera interfejsu. W przypadku aplikacji desktopowej, system operacyjny zapewnia okienka, kontrolki w określonym stylu kolorystycznym.

W HTMLu też masz zestaw kontrolek. A jak chcesz mieć coś customowego to możesz zrobić własne komponenty z użyciem jakiegoś Reacta (albo nawet i bez niego). Plus jest masę bibliotek, które zapewniają ci już customowe widżety. Więc nie rozumiem tego argumentu.

Jeżeli ma się pomysł, żeby aplikacja miała wiele okien wyświetlanych obok siebie, to w aplikacji desktopowej nie ma żadnego problemu, natomiast w przeglądarkowej takiego czegoś nie ma, da się zrobić wyskakujące okienka w DIV, ale co aplikacja to trzeba to tworzyć od początku, oprogramować przeciąganie myszki, pasek tytułu. Można to też rozłożyć na kilka zakładek lub okien samej preglądarki, ale to też trzeba to samemu obsłużyć.

chodzi ci o tiling? To też ktoś coś takiego zrobił w React: https://github.com/nomcopter/react-mosaic

Standardowe czcionki i style są po prostu brzydkie

można ściągnąć z Google Fonts fajniejsze.

W przypadku layoutu to trzeba się pomęczyć z div. Często szybciej i łatwiej użyć table/tr/td, ale jest to uważane za nieprawidłowy sposób, pomimo, że pozwala uzyskać zamierzony efekt.

Trzeba po prostu poznać inne sposoby układania layoutu. był już layout na tabelkach, później była moda na float: left i inne haki, a teraz mamy flex i grid (swoją drogą grid to trochę jak tabelki, tylko dostosowane pod robienie layoutu). Jest lepiej, a nie gorzej.

współczesne IDE potrafią same wyświetlić metody dostępne dla danej zmiennej, które zależą od typu. W aplikacji przeglądarkowej jest tak naprawdę używany jeden język, jakim jest JavaScript. On jest niestety dynamicznie typowany, czyli ta sama zmienna raz może być liczbą, a raz napisem,

Ludzie, którym się to nie podoba, używają TypeScriptu.

również deklarowanie zmiennej nie jest obowiązkowe, a możliwe jest wielokrotne deklarowanie, to prowadzi do trudnych do wychwycenia błędów.

Mówisz o var, którego w nowym kodzie się zwykle nie używa, a używa się const i let, które rzucają błędem, jak ponownie zadeklarujesz. Poza tym można korzystać z linterów, jak chce się mieć większą kontrolę nad "trudnymi do wychwycenia błędami".

Kolejna sprawa jest taka, że JavaScript ma tylko jeden typ liczbowy i to zmiennoprzecinkowy.

Niby Number to podstawowy typ liczbowy i w większości tego się używa, jednak teraz wszedł jeszcze BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt
plus można korzystać z typowanych tablic i one też trzymają dane o określonym typie liczbowym.

Dodatkowo, z powodu dynamiczności typów, nie ma możliwości, żeby IDE do JavaScript po napisaniu zmiennej umiał podać, jaki to jest typ zmiennej i jakie ma metody lub pola, bo nie wiadomo, czy w danym momencie będzie to tekst, czy taki obiekt, czy inny obiekt.

Dlatego dużo ludzi pisze w TypeScripcie. Poza tym o jakim IDE mówisz? WebStorm, VSCode? Przecież one i tak dość sprytne są. Ew. kiedyś było coś takiego jak Tern, co ci dawał takie info.

Jakiś czas temu napisałem w C++ aplikację wyświetlającą spectrogram w czasie rzeczywistym. Później napisałem identyczną aplikację w HTML5/JavaScript i wydajnościowo nie udało mi się dorównać wersji w C++, Udało się uzyskać może góra 30% wydajności.

To normalne, że rozwiązanie w JavaScript będzie wolniejsze niż wersja natywna w C++. Tym niemniej w jaki sposób pisałeś wersję w JS? Ogólnie zasada jest taka, że jak chcesz mieć szybką grafikę w JS, to używa się do tego WebGL(w przyszłości WebGPU).

Kolejną sprawą jest obsługa plików binarnych. W desktopie nie ma z tym żadnego problemu, natomiast w JavaScript trzeba się namęczyc. Można plik jakoś zaczytać do bloba, wyciągnąć bajty, ale one będą albo jako napis (tekst), albo jako ciąg liczb, więc abo dane będą nieprawidłowe, albo wydajność będzie słaba.

Nie wiem, czy do końca rozumiem, o co ci chodzi, ale z moich doświadczeń w JS wkurza mnie, że nie mogę sobie zdefiniować "schema" dla pliku binarnego i zaciągnąć od razu semantycznie (tak jak w C++ da się zdefiniować struktury, a potem załadować dane z dysku od razu do pamięci i działać na strukturach), tylko zabawa z przetwarzaniem pojedynczych bajtów.

Nawet z plikami tekstowymi też jest trochę zachodu, choćby zwykłe zaczytanie pliku .txt do zmiennej tekstowej, albo odczyt tekstu linia po linii. W C# to nie problem, a w JS trzeba się gimnastykować, chociaż jest to teoretycznie możliwe.

nie rozumiem, w czym problem.
Żeby podzielić tekst na linie można zrobić np. tak:
text.split('\n')

Sam konwerter też już mam w JavaScript, ale on nie potrafi zaczytać i zapisać pliku, tylko do jednego pol wkleja się tekst z pliku TXT, a skonwertowany tekst trafia do drugiego pola.

Też nie do końca rozumiem problem. Albo masz po prostu nieaktualną wiedzę z JS.
Jeśli chodzi o pliki z dysku, to wczytujesz za pomocą inputa: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file
No i pamiętam, że jakoś się dało wygenerować plik po stronie frontendu do ściągnięcia (chyba za pomocą bloba?).
Plus jest coś takiego jak WebShare API, przydatne na komórkach.

Więc da się, ale faktycznie, nie jest jest to specjalnie wygodne. Więc jak coś potrzebuje mocno korzystać z dysku, to można to opakować w Electrona i zrobić webową aplikację desktopową (nie będzie to idealne, apki na Electronie są często krytykowane za słabą wydajność i zżeranie zasobów).

Mam też aplikację emulującą mikrokomputer oparty na Z80. W C++ czy C# to nie problem. Nieraz myślałem, żeby przerobić to na JavaScript, aby móc uruchomić w telefonie i zapomnieć o wersji w C++, ale obawiam się, że wydajnościowo nie dorównam (będzie dużo gorzej), a dodatkowo musiałbym całkowicie inaczej podejść do plików konfiguracyjnych.

Pamiętaj, że przeglądarka zapewnia dzisiaj coś takiego jak WebAssembly, do którego można kompilować kod w różnych językach (między innymi w C++). Ludzie korzystają z tego do portowania apek C++ do przeglądarki.

TL;DR mam wrażenie, że masz nieaktualną wiedzę z JS i siejesz FUDy.

4
piotrpo napisał(a):
  • Znacznie wydajniejsze narzędzia do tworzenia UI. Przeciągnięcie kontrolki z palety do jakiegoś tam layoutu jest prostsze i szybsze niż klepanie DIV'ów w WWW.

No jakieś 15 lat temu to jeszcze była prawda, teraz może próg wejścia jest nieco większy, ale później już jest szybciej.

  • Można (zwykle) utrzymywać wspólny stack technologiczny dla frontu i backendu. Np. Swing na froncie ze Spring na backend, albo C# w .NET

To zaleta tylko dla fullstacków.

katakrowa napisał(a):

To, że coraz więcej ludzi używa komputera jedynie do przeglądania Internetu i YT nie oznacza, że ilość używanych aplikacji typu desktop zmalała.

Nie, teraz coraz mniej ludzi używa do tego komputera. Smartfon wystarcza.

18

Jestem tak stary, że pisałem jeszcze desktopy.
Zasadniczo desktopowe aplikacje 22 lata temu (np. w Swing) pisało się nadal o wiele wygodniej niż webowe obecnie :-)
I nie dlatego, że java i Swing były jakieś cudowne, choć taki Netbeans + Swing był dużo lepiej przemyślany niż uwielbiane wtedy Delphi (które było zajebiste).

Dodatkowo były inne zalety np. klient i serwer w jednym języku - mamy współdzielenie kodu (dane, walidacje itp).
Najważniejsze było jednak to, że nie pracujemy w czymś co jest totalnym rakiem, jakim jest web development.

Web development to rak, bo powstał przez serię przypadków i nadużyć.
Na samym początku mamy HTML, który służył do prezentacji statycznych dokumentów, nie do aplikacji.
Potem mamy protokół HTTP, który miał pracować w trybie jeden Request - jeden Response z całym dokumentem (full page reload), a nie jako protokół komunikacji między aplikacjami.
Do tego dochodzi język JavaSkrypt, który w założeniu miał zapewniać małe dynamiczne dodatki do stron HTML, więc to że jest totalnie zrypany (jako język) niewiele przeszkadzało.
Z tym związany jest jeszcze DOM, który również nie powstał po to, żeby manipulować dziesiątkami elementów na stronie.
Z całej hałastry jedynie CSS działa jak powinien, zupełnie niezrozumiale, ale przynajmniej jest używany do tego mniej więcej do czego został stworzony.

3

@jarekr000000: kientów oprogramowania ani managmentu produktów nie obchodzi to czy Ty sobie uważasz że developowanie webówki to rak. Klientów obchodzi to że nie muszą instalowac klienta każdego banku z usług jakiego korzystają czy klienta każdego sklepu internetowego. Dodatkowo przy urządzeniach mobilnych trzeba byłoby mieć po dwie aplikacje jeżeli coś chce sobie dodać produkt korzystając ze smarphone'a.

Mam wrażenie, że ludzie, którzy pieją z zachwytu nad współczesnym web dev'em zwyczajnie nie mają porównania z tym jak prosto robiło się GUI w narzędziach typu RAD i podobnie zresztą jeśli chodzi o programowanie w językach ogólnego zastosowania.

Ja "pieję z zachwytem" z powodów które wymieniłem na początku tego posta

5

@scibi_92:
Z ciekawostek: kiedyś robiłem aplikację Web, która była instalowana lokalnie, ponieważ na samym początku wyszło, że na niektórych lotniskach co prawda mają komputery, które uciągną naszą grubą JSową Single Page application, ale o tym, żeby te tony JS przeciągnąć przez sieć podłączoną do dżungli to już nie ma mowy. Gorzej - napisaliśmy nawet update/instalatora - do aplikacji Web 🤦
To było oparte o jakieś rozszerzenia do firefox, dawno temu - obecnie na takie cuda jest offline support.

1

Ja nie "pieję z zachwytu" nad programowaniem pod web. Mało tego, mam nadzieję że nie będę musiał się tym zajmować. Ale nie oszukujmy się - z punktu widzenia użytkownika końcowego aplikacja webowa prawie zawsze jest wygodniejsza.

1

Przyszłość to aplikacje a nie programy instalowane z pliku .exe

Chodzi o model sprzedaży typu SaaS o którym napisałem artykuł - w skrócie SaaS jest bardziej dochodowy a SaaSa najłatwiej zrealizować poprzez WEB

0

Ale aplikacje exe też mogą działać w web
Aplikacje mobilne też można uruchamiać w przeglądarce.
Tworząc stronę internetową po prostu zrobię sobie prosto najpierw exe aplikację.
Można po prostu udostępnić po sieci aplikację exe i będzie się uruchamiać. Po prostu stworzyć skrót na komputerze klienta do lokalizacji sieciowej z plikiem exe.
Jak to było w 2020 to co dopiero jest teraz. Jeszcze lepsze nażędzia.
Google play miało mieć możliwość uruchamiania aplikacji bez pobierania ich. Jak strony internetowe.

0

@kamil kowalski:

przecież to jest RDP? czy nie?

1

Wszystko zależy czym jest dany produkt i jakich ma adresatów.
1.ogólna kolaboracja - trello, Google docs, komunikatory itp. zalecany web
2.narzędzia dla ludu - edytory zdjęć, tworzenie jakiś wykresów, konwertery plików itp. zalecany web
3.narzędzia i programy używane do pracy- wszelkie aplikacje które są narzędziem do wykonywania przez kogoś pracy etatowej typu edytory zdjęć dla grafików, programy sprzedażowe w sklepach stacjonarnych, excel dla działu analiz itp. zalecany desktop
4. programy integrujące sprzęt lub komunikujące się z jakimiś urządzeniami lokalnie- tylko desktop
5. Ogólny model sprzedaży bezpośredni/pośredni czyli to kto się zajmuje ewentualnym serwisem twórca czy przedstawiciel- mam tu na myśli głównie systemy ERP bo to że np. Comarch zrobiłby wszystko w web nie rozwiąże problemów ze szkoleniem użytkowników i helpdeskiem a często przedstawiciele odpowiadają też za infrastrukturę u klienta. Czyli klient do wyboru miałby system lokalny, ale i tak kupuje to jako całość z komputerami i serwisem vs kupienie dostępu do web, ale infrastrukturę sobie sam ogarniasz.

Z punktem 3 pewnie się wielu nie zgodzi, ale chciałbym zauważyć że pojęcie wysokiej dostępności usługi tyczy się gównie usługi a nie tego czy klient będzie miał stabilny internet a wykrzaczyć dzisiejsze aplikacje nawet te działające „pseudo lokalnie” za pomocą losowego gubienia internetu jest dość łatwo.

1

@kamil kowalski:
przecież to jest remote desktop znane tyle lat że hej. chyba nie rozumiesz co przytaczasz. Już ci tłumaczył spoglądamy w dokumentacje. Ja mam taki jeden przemysłowy projekt na vnc + panel który ma dostęp przez serwer www. to są rozwiązania znane od dekad.

5

Mylicie 2 sprawy:

  • Łatwość tworzenia GUI pod desktopy.
  • Użyteczność dla użytkownika.

Zrobienie desktopowego UI było i jest bez porównania prostsze niż zrobienie tego samego w jakimś tam Angularze, czy innym React. Facebook nigdy by nie został tym czy jest, gdyby trzeba było zainstalować sobie jakąś aplikację, żeby z niego korzystać. Mając do wyboru bieda wersję Word'a w Google docs i zainstalowanego Worda, wybieram google Docs, bo to co tam wystarcza mi w nadmiarze, a fakt, że mam dostęp do tego dokumentu z każdej możliwej lokalizacji, mogę go 3 kliknięciami udostępnić, albo dać komuś do recenzji jest zaletą przebijającą wszystkie funkcje Word'a, o których nie wiem.

0
LukeJL napisał(a):
andrzejlisek napisał(a):

Jednak tworzenie takiej aplikacji przypomina trochę programowanie dla DOS, czylu pusty ekran tekstowy lub graficzny bez żadnego menedżera interfejsu. W przypadku aplikacji desktopowej, system operacyjny zapewnia okienka, kontrolki w określonym stylu kolorystycznym.

W HTMLu też masz zestaw kontrolek. A jak chcesz mieć coś customowego to możesz zrobić własne komponenty z użyciem jakiegoś Reacta (albo nawet i bez niego). Plus jest masę bibliotek, które zapewniają ci już customowe widżety. Więc nie rozumiem tego argumentu.

Jeżeli ma się pomysł, żeby aplikacja miała wiele okien wyświetlanych obok siebie, to w aplikacji desktopowej nie ma żadnego problemu, natomiast w przeglądarkowej takiego czegoś nie ma, da się zrobić wyskakujące okienka w DIV, ale co aplikacja to trzeba to tworzyć od początku, oprogramować przeciąganie myszki, pasek tytułu. Można to też rozłożyć na kilka zakładek lub okien samej preglądarki, ale to też trzeba to samemu obsłużyć.

chodzi ci o tiling? To też ktoś coś takiego zrobił w React: https://github.com/nomcopter/react-mosaic

Chodzi bardziej o coś w tym rodzaju, pomijam, że to jest MDI, czyli wszystkie okna wewnątrz jednego. Jak widać, jest wiele okien, na którym są jakieś informacje, użytkownik może je otwierać, zamykać, przemieszczać i zmieniać rozmiar, jak mu się podoba. W tym przypadku to OS to umożliwia. W HTML takiego czegoś nie ma, spotyka się czasem aplikacje z takim okienkiem (najczęściej okienko komunikatu). W takim razie chcąc przerobić taką aplikację exe na HTML+JS aby działała tak samo, to jest więcej zachodu, chociaż jest to możliwe.

również deklarowanie zmiennej nie jest obowiązkowe, a możliwe jest wielokrotne deklarowanie, to prowadzi do trudnych do wychwycenia błędów.

Mówisz o var, którego w nowym kodzie się zwykle nie używa, a używa się const i let, które rzucają błędem, jak ponownie zadeklarujesz. Poza tym można korzystać z linterów, jak chce się mieć większą kontrolę nad "trudnymi do wychwycenia błędami".

Tak, mówię o var.

Dodatkowo, z powodu dynamiczności typów, nie ma możliwości, żeby IDE do JavaScript po napisaniu zmiennej umiał podać, jaki to jest typ zmiennej i jakie ma metody lub pola, bo nie wiadomo, czy w danym momencie będzie to tekst, czy taki obiekt, czy inny obiekt.

Dlatego dużo ludzi pisze w TypeScripcie. Poza tym o jakim IDE mówisz? WebStorm, VSCode? Przecież one i tak dość sprytne są. Ew. kiedyś było coś takiego jak Tern, co ci dawał takie info.

Póki co nie używałem prawdziwego IDE, tylko różnych notatników z kolorowaniem składni. Rozumiem, że te dwa wymienione przez Ciebie potrafią w locie przeanalizować kod i podać, jaki tym mają w danym miejscu.

Jakiś czas temu napisałem w C++ aplikację wyświetlającą spectrogram w czasie rzeczywistym. Później napisałem identyczną aplikację w HTML5/JavaScript i wydajnościowo nie udało mi się dorównać wersji w C++, Udało się uzyskać może góra 30% wydajności.

To normalne, że rozwiązanie w JavaScript będzie wolniejsze niż wersja natywna w C++. Tym niemniej w jaki sposób pisałeś wersję w JS? Ogólnie zasada jest taka, że jak chcesz mieć szybką grafikę w JS, to używa się do tego WebGL(w przyszłości WebGPU).

Grafika to nie problem, bardziej chodzi o obliczenia i pracę na tablicach. Użyłem canvas i na nim malowałem pikselami. Tam jest coś .createImageData i można manipulować pikselami.

Kolejną sprawą jest obsługa plików binarnych. W desktopie nie ma z tym żadnego problemu, natomiast w JavaScript trzeba się namęczyc. Można plik jakoś zaczytać do bloba, wyciągnąć bajty, ale one będą albo jako napis (tekst), albo jako ciąg liczb, więc abo dane będą nieprawidłowe, albo wydajność będzie słaba.

Nie wiem, czy do końca rozumiem, o co ci chodzi, ale z moich doświadczeń w JS wkurza mnie, że nie mogę sobie zdefiniować "schema" dla pliku binarnego i zaciągnąć od razu semantycznie (tak jak w C++ da się zdefiniować struktury, a potem załadować dane z dysku od razu do pamięci i działać na strukturach), tylko zabawa z przetwarzaniem pojedynczych bajtów.

Chodzi o zaczytanie pliku do tablicy bajtowej (liczbowej), gdzie jedna pozycja to jeden bajt i odwrotnie, czyli jest tablica liczbowa i chodzi o zapisanie do pliku tak, jak jest. Jest coś takiego, jak blob ale to trochę okrężna droga.

Nawet z plikami tekstowymi też jest trochę zachodu, choćby zwykłe zaczytanie pliku .txt do zmiennej tekstowej, albo odczyt tekstu linia po linii. W C# to nie problem, a w JS trzeba się gimnastykować, chociaż jest to teoretycznie możliwe.

nie rozumiem, w czym problem.
Żeby podzielić tekst na linie można zrobić np. tak:
text.split('\n')

Na serwerze w katalogu z plikiem HTML i plikami JS jest jeszcze plik TXT. Chodzi o otwarcie pliku, wczytanie tekstu z niego i zamknięcie pliku. Można to zrobić za pomocą XMLHttpRequest działa asynchonicznie, co utrudnia przerobienie istniejącego kodu z C++ na JS. Mi chodziło o tę czynność synchronicznie, tak samo jak w C++.

Sam konwerter też już mam w JavaScript, ale on nie potrafi zaczytać i zapisać pliku, tylko do jednego pol wkleja się tekst z pliku TXT, a skonwertowany tekst trafia do drugiego pola.

Też nie do końca rozumiem problem. Albo masz po prostu nieaktualną wiedzę z JS.
Jeśli chodzi o pliki z dysku, to wczytujesz za pomocą inputa: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file
No i pamiętam, że jakoś się dało wygenerować plik po stronie frontendu do ściągnięcia (chyba za pomocą bloba?).
Plus jest coś takiego jak WebShare API, przydatne na komórkach.

Wskazany Input spełnia swoją rolę, ale jest jeden haczyk. Przy użytkowaniu produkcyjnym to nie problem, ale przy testowaniu, jak wielokrotnie uruchamiasz aplikację z tym samym plikiem, to za każdym razem trzeba wskazać ten plik. Podobno jest to tak specjalnie zrobione ze względów bezpieczeństwa. Podobnie, jak nie ma możliwości, żeby użytkownik wskazał plik, zapamiętać w LocalStorage nazwę pliku, a przy następnym otwarciu lub odświeżeniu apki zaczytał się ten sam plik. Podobnie sprawa się ma z zapisem do pliku. Na przykład jest aplikacja w C++, która generuje 20 plików o kolejnych numerach we wskazanym katalogu. Chce zrobić identyczną w HTML+JS i na użytek testów zhardkodować nazwę katalogu i niech aplikacja generuje tam te pliki. Jedyny efekt, to zażądanie pobrania 20 plików, nic więcej. Ewentualnie można w przeglądarce ustawić katalog do automatycznego pobierania, ale to nie to samo, co katalog wskazywany w aplikacji.

2

Dla mnie aplikacje dekstop dalej mają sens, ale nie do wszystkiego. Aplikacje, które często używam, chętnie instaluję lokalnie. Przykładowo, mam na laptopie slacka i spotify, a przecież obie apki maja wersję web. Z innych aplikacji korzystam w formie online. Nie mam żadnego pakietu biurowego, wolę korzystać z odpowiedników od Googla, bo mi to w zupełności wystarczy.

Osobną kwestią pozostaje jak aplikacje desktop są tworzone. Jak widzę coś napisanego na JVM, to raczej nie instaluję bo spodziewam się kupy w UI. Nie mogę zdzierżyć jak wyglądają IDE oparte na InteliJ, bo być może nie są brzydkie i nawet HiDPI w końcu nauczyły się obsługiwać, ale mnie odrzucają. Nigdy nie potrafiłem zrobić ładnej aplikacji w swingu, ale zaznaczam, że mówię o doświadczeniu studenckim z przed 15 lat, być może teraz coś się w tej materii zmieniło. Bardzo miło też wspominam moje pradawne doświadczenie z Windows Forms, ale już MFC i WinAPI to była tragedia.

Z kolei VS code nie razi mnie tak w oczy, a to przecież w dużej mierze TypeScript. Już w 2008 słyszałem o opisywaniu UI aplikacji desktopowych na takiej samej zasadzie jak robi się to w web. Ta tendencja nie znikła. Wydaje mi się, że znacznie większa liczba deweloperów frontu, w porównaniu z osobami, które piszą natywne aplikacje UI, sprawi, iż zobaczymy więcej frameworków pozwalających na tworzenie aplikacji desktopowocyh przy pomocy TSa, CSSa i htmla. Chciałbym tylko albo WYSIWYG dorównał temu co oferowało kiedyś choćby takie delphi.

Podsumowując, myślę, że zapotrzebowanie na aplikacje desktop będzie się tylko zmmniejszać, a trendem pozostanie ściąganie technologii webowych na desktopy.

1 użytkowników online, w tym zalogowanych: 0, gości: 1