Web vs desktop

0

Pyodide ma port na webassembly i ja tylko czekam na jakiś fajny framework do Pythona takiego typu jak React, i żeby było wsparcie tagów jakieś jak w JSX.

1
andrzejlisek napisał(a):

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.

Też już ktoś coś takiego zrobił: https://nextapps-de.github.io/winbox/
Ale nawet jakby nie było czegoś takiego, to przecież mógłbyś zrobić sobie samemu taki menedżer okien, a potem go używać w projektach.

WebStorm, VSCode

Z tego co wiem, to te dwa (ja używam VSCode) to najlepsze edytory do JS, jeśli chodzi o rozumienie kodu. No chyba, że się coś nowego pojawiło.

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.

Jak ci zależy na szybkości, to takie rzeczy możesz zrobić w WebGL. I manipulować pikselami we fragment shaderze. Choć czysty WebGL ma swoją barierę wejścia. No ale można by też użyć jakiejś biblioteki typu Pixi i tam zaimplementować tylko swój shader... oczywiście mierzyć cały czas wydajność, czy faktycznie jest szybciej.

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++.

Szukasz na siłę problemów.
Tym niemniej używając fetch zamiast XMLHttpRequest możesz działać na async/await, więc masz kod, który wygląda na synchroniczny.

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.

Możesz użyć też drag'n'drop, wtedy zamiast wybierania plików, wystarczy, że użytkownik przeciągnie plik.

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.

Bo to trzeba inaczej podejść. Np. napisać aplikację w Node.js. która by odpalała lokalnie serwer, wtedy backend mógłby robić operacje na plikach, a frontend służyłby jako GUI. Albo opakować aplikację w Electron.

Albo, jeśli w dalszym ciągu miałaby to być apka czysto webowa, bez konieczności instalacji niczego, można byłoby zrobić możliwość działania na jakimś dysku w chmurze. Wtedy użytkownik wgrałby sobie pliki do chmury i apka by na nich pracowała.

Albo, jeśli miałoby to koniecznie działać na plikach lokalnych, to można by przyjmować od użytkownika cały zzipowany katalog, odzipowywać go, działać na plikach w nim, a potem znowu zrobić zipa do pobrania. Chociaż owszem, będzie to dalej niewygodne. Jednak powinno być wykonalne.

Na przykład jest aplikacja w C++, która generuje 20 plików o kolejnych numerach we wskazanym katalogu

Tego rodzaju apka w ogóle nie musiałaby mieć GUI, tylko mogłaby być zwykłym narzędziem konsolowym. Wtedy w Node.js zgrabnie można było napisać coś takiego (o ile odbiorcami narzędzia są osoby techniczne, które są przyzwyczajone do narzędzi CLI).

0

W biznesie i w 80% przypadków web bardzo dobrze się nadaje, szczególnie do aplikacji korzystających z internetu lub sieci lokalnej. Np. system ERP może być jako web. Zalety są oczywiste, nic nie potrzeba instalować i działa "na wszystkim", czyli i na komputerze i na telefonie. Może też być aplikacją offline, wystarczy w komputerze lub w telefonie zapisać plik HTML i niego uruchamiać.

Natomiast zauważyłem, że w przypadku telefonów, programiści bardzo chętnie tworzą natywną apkę. Takie proste biznesowe sprawy, jak promocje w marketach, Groupon, Allegro, OLX, aplikacje dla taksówek, aplikacje magazynowe dla firm, na pewno można zrobić jako web. A tak, to jest nie tylko podwójna robota (bo Iphone i Andorid), ale jeszcze przedzieranie się przez procedury umieszczania apki w Google Play i AppStore. W przestrzeniu publicznej widuje się QR kody pobierające aplikacje z Google play i AppStore. Czy to jest naprawdę potrzebne? Wystarczyłaby jedna odpowiednia aplikacja webowa i ma się z głowy wszystkie telefony za jednym zamachem. Powiadomienia push, pomiar z akcelerometrów i kompasu również jest możliwy poprzez JavaScript.

5
andrzejlisek napisał(a):

Natomiast zauważyłem, że w przypadku telefonów, programiści bardzo chętnie tworzą natywną apkę. Takie proste biznesowe sprawy, jak promocje w marketach, Groupon, Allegro, OLX, aplikacje dla taksówek, aplikacje magazynowe dla firm, na pewno można zrobić jako web.

To nie kwestia programiści chętnie tworzą. Trochę się to już uspokoiło, ale parę lat temu, jak jeszcze trwała "rewolucja mobilna", to wszystkie działy marketingu na świecie miały w swoich korpo golach "wypuścić aplikację mobilną", bo wyczytali to w jakimś komiksie dla marketingowców. W rynek został zalany masą szajsu nie mającego żadnego sensu, bo były to instalowalne na telefonie strony www, a nawet te strony nie miały sensu.

Przykłady extreme:
Gruby projekt aplikacji do obsługi konferencji dla handlowców. W ujjjjjj dziwnych rzeczy, backendy, mapy, rozbudowana analityka. Jako że miałem dostęp do tej analityki, to podejrzałem dane po całym, tym evencie. 5 logowań, na 2 systemach (Android, iOS). Nie wiem ile to kosztowało, ale na 100% powyżej 100k USD

Jeszcze grubszy projekt, z modelami 3D, 2 platformami, backendem, customowym systemem lokalizacji urządzenia (w salonach miały stać roboty, które sobie pogwizdują w ultradźwiękach, a urządzenie to rozpoznawało), oczywiście reklamy i obowiązkowy splashscreen dodany na sam koniec, więc niczego nie przykrywał, a jedynie wkurzał użytkownika dłuższym o 5 sekund startem aplikacji. Najbardziej interesującą funkcją tej apki dla użytkownika była możliwość kazania robotowi zatańczyć...

Ogólnie to, w pierwszych 10 latach istnienia Androida/iOS powstało nie tyle, że mnóstwo aplikacji które mogłyby być stronami WWW, a raczej mnóstwo aplikacji, które nie powinny być nawet stronami www.

1

Takie proste biznesowe sprawy, jak promocje w marketach, Groupon, Allegro, OLX, aplikacje dla taksówek, aplikacje magazynowe dla firm, na pewno można zrobić jako web.

Aplikacje dla taksówek? xD W tym z tymi wszystkymi mapami, obsługa lokalizacji? xD

3

Jak patrzę na Fusion 360, to mam wrażenie, ze dużo im do przejścia na WWW nie zostało

Znaczy oni już są online, także w sumie już są WWW. Tylko, że nikt kto płaci nie używa tego przez web do faktycznej pracy. O użytkownikach CADów myślcie jak o programistach używających IDE. No niby są IDE online, ale jaki odsetek programistów używa ich do pracy z której mają chleb? Poza tym, CADów nie używa się tylko w klasycznych biurach tak jak się to prezentuje na grafikach ze stocka, są one też używane przez kontraktorów i wykonawców w terenie i to wcale nie są to niszowe zastosowania. Uzależnienie działania od prędkości internetu to poważna wada.

0

@several: Kwestia czasu. Webowe IDE to nowość, w dodatku, jeżeli pominiemy takie popierdółki jak VSCode, to są ogromne aplikacje. Myślę, że to będzie się zmieniać, bo potencjalnie jest o co walczyć. Wymaganie bycia on-line to oczywiście duża wada, ale coraz mniejsza - Internet zaczyna być wszędzie.

0

W web najbardziej mi przeszkadza html css. Te wszystkie node.js,react, itd. Jak zobaczyłem że graficznie można wszystko wy klikać metodą drag and drop to się od razu na to przesiadłem. Niby są jakieś strony na których można tak zrobić kod a potem skopiować ale strasznie to kiepskie w porównaniu z takim edytorem w android studio do aplikacji natywnych. Skróciło by to czas nauki o jakieś 50%.

5

Internet zaczyna być wszędzie.

Jeżeli cały czas mówimy o CADach, wydaje mi się, że nie znasz spektrum działań w jakim te aplikacje są używane. CAD przy którym pracuje jest wyspecjalizowany w inżynierii środowiskowej i był używany przez kontaktorów w tunelach (nie przez 100% czasu oczywiście), gdzie na etapie budowy nigdy nie ma zasięgu z niczym i najwygodniej komunikować się przez krótkofalówkę. Wiem o takich aplikacjach używanych na antarktydzie i lasach tropikalnych. To są zazwyczaj dobrze płacący klienci. Ogólnie trend jest taki że producenci próbujący wymusić zmianę używając argumentu o wszechobecności internetu tracą klientów. Tak jak autodesk stracił klientów merdżując Eagle'a z Fusion360, jest tam jakaś starsza wersja dostępna osobno, ale to tylko dlatego, że niektórzy klienci byli w stanie to wymusić bazując na jakiś zapisach w umowie. A Eagle to nawet nie jest coś co użyłbyś poza środowiskiem biurowym. W moim przypadku, już sam wymóg ciągłego podłączenia do internetu np. na potrzeby sprawdzania licencji równałoby się z ubiciem produktu, bywali tacy klienci, którzy życzyli sobie by przynajmniej jeden z kilku dni szkoleń odbył się na maszynie będącej całkowicie offline. O przejściu całkowicie na web wolę w ogóle nie myśleć.

Wydaje mi się, że mając do dyspozycji WASMa i WebGL, technologicznie jesteśmy gotowi na przejście z CADami do webu, ale pomijając już dodatkowy narzut developmentu nie jest to coś czego rynek potrzebuje i za co zapłaci. Są w stanie zapłacić, za jakieś dodatkowe ficzery jeśli akurat mają dostęp do internetu, np. za możliwość zrobienia backupu online, albo nawet cały system do dzielenia się projektem w zespole z przydzielaniem uprawnień itd. ale za samego CADa online nikt nie chce płacić.

0

@several: Nie znam się na CAD (poza jakimiś krótkimi i przypadkowymi zabawami). Wydaje mi się, że rynek mógłby chcieć zapłacić np. za CAD'a działającego jak Minecraft - ileś tam osób jednocześnie zmienia ten sam projekt, bez ryzyka, że część tej pracy pójdzie do kosza, bo konflikt, sztucznego dzielenia projektu na kawałki, żeby tych konfliktów nie było itp.

Ze swojego podwórka, mam w projekcie aplikację desktopową, bo pracuje ona w środowisku w którym nie zawsze jest Internet, czasami ze względów technicznych, czasami ze względu na przepisy, albo koszty przesyłania danych. Rolą aplikacji jest przechować dane do momentu uzyskania tego dostępu i to jest właściwie jedyny powód, dla którego jest ona instalowana na urządzeniu. Aktualnie, odsetek sytuacji, w których należało wykonać krytyczną biznesowo operację, ale się nie dało, bo zabrakło łączności, to 2%. Nie jest to dużo, ale wciąż jest to bariera. Jeżeli uda się zwiększyć dostępność sieci w krytycznych momentach cyklu biznesowego, albo je "odkrytycznić", to nie będzie problemu z przejściem na WWW. Jeżeli to się uda, to spodziewam się pocałunków na stopach ze strony administratorów, bo nagle, kompletnie odpadnie im problem aktualizacji apolikacji na kilkuset urządzeniach, które czasami są w sieci, czasami ich nie ma, jak są to też nie wiadomo, czy akurat nie robią czegoś istotnego.

--edit
Jest jedna ogromna przewaga WWW z punktu widzenia inżynierii oprogramowania. Czas od wprowadzenia zmiany, do momentu w której użytkownik może jej zacząć używać.

1
scibi_92 napisał(a):

Takie proste biznesowe sprawy, jak promocje w marketach, Groupon, Allegro, OLX, aplikacje dla taksówek, aplikacje magazynowe dla firm, na pewno można zrobić jako web.

Aplikacje dla taksówek? xD W tym z tymi wszystkymi mapami, obsługa lokalizacji? xD

Tak. Już jakiś czas temu taksówkarze przestali używać tradycyjnej radiostacji na rzecz tabletu lub telefonu z apką. HTML/JS może pobrać lokalizację (przy pierwszym pobraniu pyta się, czy podać lokalizację). Mapę to można wziąć od Google. Do tego jakaś lista numerów taksówkarzy będących wolnych lub zajętych, przycisk przyjmujący zlecenie na przewóz i parę innych rzeczy. Teraz to jest w postaci natywnej apki, ale chyba nie ma w niej czegoś, czego nie da się zrobić w HTML5+CSS+JS, chyba, że mają coś, co jest potrzebne do pracy, a ja nie wiem. Łaczność bezpośrednia też jest możliwa, przecież pełno jest webowych "apek" pracujących jako chat, a nawet połączenia głosowe i video.

piotrpo napisał(a):

@several: Nie znam się na CAD (poza jakimiś krótkimi i przypadkowymi zabawami). Wydaje mi się, że rynek mógłby chcieć zapłacić np. za CAD'a działającego jak Minecraft - ileś tam osób jednocześnie zmienia ten sam projekt, bez ryzyka, że część tej pracy pójdzie do kosza, bo konflikt, sztucznego dzielenia projektu na kawałki, żeby tych konfliktów nie było itp.

Ze swojego podwórka, mam w projekcie aplikację desktopową, bo pracuje ona w środowisku w którym nie zawsze jest Internet, czasami ze względów technicznych, czasami ze względu na przepisy, albo koszty przesyłania danych. Rolą aplikacji jest przechować dane do momentu uzyskania tego dostępu i to jest właściwie jedyny powód, dla którego jest ona instalowana na urządzeniu.

W szerszym znaczeniu i to można ogarnąć webem. Wystarczy, ze jedna i ta sama aplikacja jest zarówno hostowana, jak i do pobrania w pliku ZIP zawierającym pliki HTML, CSS, JS (coś w tym stylu, jak zapisana strona HTML jako kompletna). Jakby się uprzeć, to na 90% da się zawrzeć wszystko w jednym pliku HTML, chociaż jest to trudniejsze w edytowaniu. Sama apka (skrypt) może przechowywać swoje dane w local storage lub IndexedDB lub Web SQL, ewentualnie poprzez import i eksport w postaci tekstowej, bądź wskazywanie i pobieranie pliku. Jeżeli taki plik HTML pobierze się na dysk i uruchomi, to internet nie jest w ogóle potrzebny do pracy z apką. Oczywiście może mieć funkcję "wyślij na serwer" lub "pobierz z serwera", które potrzebują internetu.

1

Wydaje mi się, że rynek mógłby chcieć zapłacić np. za CAD'a działającego jak Minecraft - ileś tam osób jednocześnie zmienia ten sam projekt, bez ryzyka, że część tej pracy pójdzie do kosza, bo konflikt

Dzielenie się projektem i jednoczesna praca w jednym projekcie już jest w wielu CADach, nawet my ją mamy plus kilka innych webowych zabawek jak podglądy rysunków i takie tam i faktycznie rynek jest w stanie za to zapłacić. Tylko, że to są dodatkowe, opcjonalne ficzery, które nie zmieniają obecnej rzeczywistości, która przedstawia się następująco - domeny w których operują CADy są na tyle trudne, że dodatkowe kopanie się z webowym stackiem jest nieopłacalne, a nawet jeśli by się udało to ograniczasz się tylko do biur projektowych ze światłowodem, które wbrew powszechnemu mniemaniu są tylko częścią potencjalnego rynku i prawie całkowicie odcinasz się od kontraktorów i wykonawców.

W efekcie wydasz więcej na development, ale za to zarobisz mniej.

Jest też taka kwestia, że biura projektowe nie działają w próżni i jak jest duża inwestycja to wychodzą przed szereg, żeby dogodzić wykonawcy i sami obserwujemy sytuacje w której architekci przerzucają się na nasz produkt bo wykonawca go już używa. Dla takich nowych klientów mamy dodatkowy smaczek w postaci webowego systemu do dzielenie się projektem żeby osłodzić im przesiadkę, ale na pewno nie jest to powód dla którego kontraktor wybrał nasz produkt.

Opisałem Wam jak wygląda rzeczywistość. Zróbcie z tym co chcecie. Desktop to nisza, a CAD to nisza w niszy, ale dopóki ta nisza w niszy generuje miliony przychodów i webowy stack nadal będzie tak skopany jak jest obecnie to wszelkie próby przerzucenia CADa do webu skończą się na etapie ciekawego prototypu.

2
kamil kowalski napisał(a):

W web najbardziej mi przeszkadza html css. Te wszystkie node.js,react, itd. Jak zobaczyłem że graficznie można wszystko wy klikać metodą drag and drop to się od razu na to przesiadłem. Niby są jakieś strony na których można tak zrobić kod a potem skopiować ale strasznie to kiepskie w porównaniu z takim edytorem w android studio do aplikacji natywnych. Skróciło by to czas nauki o jakieś 50%.

Ciekawy aspekt podniosłeś.
Jak obserwuję GUI, to w każdym z języków to "schyłkowe" / "barokowe" podejście siłuje się z designem wizualnym na sposób webowy.
Java Swing vs FX, C# WinForms vs WPF, Qt klasyka vs QML (ten nowy język z sąsiedneigo wątku).

Dla mnie to ślepa uliczka. Gdzies kiedyś klient został umieszczony w pozycji, że ma miec soft wybajerowany wizualnie, nikt nie pyta o jakoś merytoryczną (webowa rządówka, styronki korporacyjne) - Po stronie destopa jak siadłem do wykonań "młodziezowych" programów (playery itd), to nie umiałem tego użyć.

Co do edycji formatek biznesowych dla weba, chyba były jakies kroki, czy to w kręgu JSF, Vaadin, Wicket (zasłyszane przez ramię), czy ASPX u małomiękkiego
Działało to jak działało , sporo tak, trochę nie - dawało ... o zgrozo ... powtarzalny wygląd aplikacji
Rzecz w tym, ze cały ten biznes został postawiony na głowie: "nasza the most zajebista apka" na być wizualnie totalnie odjazdowa od reszty rynku (a klient jest szczęśliwy, że za to przepłaca)

jarekr000000 napisał(a):

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.

W pełni sie zgadzam.

Najpierw (jako branża) robimy widgety windowsowe, wydajne, oszczędnie co do RAM - a potem to mamy w du... i emulujemy je w programie pt przeglądarka internetowa (zwróćcie uwagą na nazwę: przeglądarka - to potwierdza wizję @jarekr000000 )
Zamiast apki która startuje w 0.3s i zużywa straszną ilość 4MB (no dobra, 20MB) RAM, mamy kobyłę która zabiera 1GB (rozgrzana przeglądarka z większą apką), którą trzeba zabić po 3h bo tekst przyjmuje jak animacja teleksu, i restartować

Ja się zgadzam co do oceny historyczno-funkcjonalnej, że duet HTTP/HTML nie był do tego przeznaczony, do czego jest używany.
Pytanie głownie do @jarekr000000 czy którąś z historycznych technologii do chudego klienta uważasz za najbliższą wizji "zróbmy zdalne programy dobrze" ?

1a2b3c4d5e napisał(a):

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

+1

Tak, wiem, web ma zalety w postaci bezproblemowej dystrybucji
... ale czy na pewno ... tu ktoś obok się martwił o nie chodzenie czegoś w IE. (serio: jest wielki, wielki postęp, z 10-15 lat temu to była jazda z przegladarkami)

1

W wickecie było jakieś podejście do klikania formatek z idę? Kurde. 13 lat w wickecie, ale może mnie coś ominęło ;-) albo źle zrozumiałem :-P — opiszon 1 minuta temu

Do wicketa była mało udana i zarzucona wtyczka do NB ??? Eslipse ???
Nie był to żadne Delhi, ale przynajmniej próbowało utrzymać zgodność HTMLa z kodem pod względem wicket:id *)
Wiem, że miałem kompleks do prezentacji Vaadina, te prezentacje wyglądały znacznie lepiej. JSF tez coś miało.

Zakładamy klub wickeciarzy ?

*) rzecz ciekawa: chcieliśmy kiedyś jako branża narzędzi, który utrzymywały zgodność przynajmniej pól backend-fronend. Dziś to mamy w czarnej ...

0

Teraz to jest w postaci natywnej apki, ale chyba nie ma w niej czegoś, czego nie da się zrobić w HTML5+CSS+JS, chyba, że mają coś, co jest potrzebne do pracy, a ja nie wiem. Łaczność bezpośrednia też jest możliwa, przecież pełno jest webowych "apek" pracujących jako chat, a nawet połączenia głosowe i video.

Być może tak jest, ale nadal podejrzewam że stworzenie natywnej apki może byc bardziej wygodne. Dodatkowo, w przypadku natywnej apki masz cały ekran dla aplikacji dla niej, a to jest tez sporą wygodą w przypadku małych ekranów.

@several: Kwestia czasu. Webowe IDE to nowość, w dodatku, jeżeli pominiemy takie popierdółki jak VSCode, to są ogromne aplikacje. Myślę, że to będzie się zmieniać, bo potencjalnie jest o co walczyć. Wymaganie bycia on-line to oczywiście duża wada, ale coraz mniejsza - Internet zaczyna być wszędzie.

@piotrpo: z jednej strony masz rację, ale z drugiej sądze że nadal cała masa aplikacji korzystających z internetu bedzie o wiele bardziej sensowna na desktopie. Przykładem jest chociażby Spotify z cachowaniem danych. Ja słucham bardzo wielu różnych albumów muzycznych, i możliwość cachowania danych jest ekstremalnie przydatna, zwłaszcza w przypadku słuchania z telefonu.

0

Znalazłem narzędzia które ponoć pobierają stronę i dzięki czemu może strona działać offline. Czy słyszeliście o czymś podobnym ? albo używaliście?. Jaś wtyczka do chrome? Albo program wieloplatformowy. Który to automatyzuje.?

1
kamil kowalski napisał(a):

Znalazłem narzędzia które ponoć pobierają stronę i dzięki czemu może strona działać offline. Czy słyszeliście o czymś podobnym ? albo używaliście?. Jaś wtyczka do chrome? Albo program wieloplatformowy. Który to automatyzuje.?

Pobierajka programowanej, czyli dynamicznej strony ??? Chyba urban legends.

a) można pobrac stronę zawierajać informacje, dla tej informacji (wykorzystanej jednorazowo)
b) webowcy (frontowcy) mogą napisać apliakcję prawie-desktopową, która by aktywnie działała offline - ale to musi na to być determiancja projektowa. Generalnie jakaś szemrana libka JS ściąga z kosmosu API do dodawania liczb, typówka JS nie jest do przestawienia do offline

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