Web vs desktop

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

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