🚀 go-pugleaf

W dniu czwartek, 21 listopada 2019 22:01:09 UTC+1 użytkownik J-23 napisał:
> Witam,
> Długi czas bolączką Lazarus było brak możliwości pisania pod Web. Ta 
> biblioteka to zmienia http://www.raudus.com/ fajnie że idzie to do 
> przodu choć w ślimaczym tępię
> 
> Pozdrawiam
> J-23

Szczerze? Kiepsko to wygląda. W tym wypadku Delphi+uniGUI jednak bije to cóś na głowę.
Poza tym (albo nie doczytałem do końca, bo godzina późna) z jednej strony opensource a z drugiej 99$/year na programistę? Zresztą - nieważne - na razie to nie jest do użytku.

pozdrawiam,
Przemek O.

W dniu 22.11.2019 o 00:02, immo pisze:
> W dniu czwartek, 21 listopada 2019 22:01:09 UTC+1 użytkownik J-23 napisał:
>> Witam,
>> Długi czas bolączką Lazarus było brak możliwości pisania pod Web. Ta
>> biblioteka to zmienia http://www.raudus.com/ fajnie że idzie to do
>> przodu choć w ślimaczym tępię
>>
>> Pozdrawiam
>> J-23
> 
> Szczerze? Kiepsko to wygląda. W tym wypadku Delphi+uniGUI jednak bije to cóś na głowę.

Mnie osobiście cieszy kierunek w którym to zmierza bo jeszcze niedawno 
panowało zdanie że jeszcze daleka droga do Web.

Co do uniGUI to tylko czekać aż ktoś weźmie ciekawego frameworka kto wie 
może to będzie nawet ExtJS bo o ile pamięć mnie nie myli na tym bazuje 
uniGUI i zbuduje coś podobnego.

> Poza tym (albo nie doczytałem do końca, bo godzina późna) z jednej strony opensource a z drugiej 99$/year na programistę? Zresztą - nieważne - na razie to nie jest do użytku.

Testować tego nie testowałem. Ta cena wygląda też trochę dziwnie ale jak 
będę potrzebował tego wtedy będę to zgłębiał :)

Pozdrawiam
J-23

On Thu, 21 Nov 2019 22:01:04 +0100, J-23 wrote:

> Witam,
> Długi czas bolączką Lazarus było brak możliwości pisania pod Web. Ta 
> biblioteka to zmienia http://www.raudus.com/ fajnie że idzie to do 
> przodu choć w ślimaczym tępię
> 
> Pozdrawiam
> J-23

No, już są na etapie stron gdzieś tak z 95-98 roku. Jeszcze z 200 lat i
będą koło 2010.

Po co używać takich potworków skoro są potężne i elastyczne narzędzia
oparte o JS/Node? I miliony bibliotek do wszystkiego.

To tak jakby w świecie pełnym darmowych golarek golić się tulipankiem z
butelki i mówić "jest super, już prawie się da ogolić i tylko trochę
ryzyko, że można poderżnąć sobie gardło, ale jak się uprzesz to udowodnisz,
że się da". Jak ktoś lubi... spoko.

Delphi nie było, nie jest i nigdy nie będzię nadawało się do weba w stopniu
nawet o kilometr zbliżonym do normalnych, dedykowanych temu narzędzi.
Lazarus też nie.
Co innego strona serwerowa, ale nie generująca HTML tylko dostarczająca
logiki biznesowej.

-- 
pozdrawiam
Roman Tyczka

W dniu 22.11.2019 o 19:34, Roman Tyczka pisze:
> On Thu, 21 Nov 2019 22:01:04 +0100, J-23 wrote:
> 
>> Witam,
>> Długi czas bolączką Lazarus było brak możliwości pisania pod Web. Ta
>> biblioteka to zmienia http://www.raudus.com/ fajnie że idzie to do
>> przodu choć w ślimaczym tępię
>>
>> Pozdrawiam
>> J-23
> 
> No, już są na etapie stron gdzieś tak z 95-98 roku. Jeszcze z 200 lat i
> będą koło 2010.
> 
> Po co używać takich potworków skoro są potężne i elastyczne narzędzia
> oparte o JS/Node? I miliony bibliotek do wszystkiego.

Web nigdy nie składał się z jednej technologii zawsze jest to zbiór kilku.

Z tymi potężnymi i elastycznymi to bym dyskutował ale ok niech ci będzie 
że są

> 
> To tak jakby w świecie pełnym darmowych golarek golić się tulipankiem z
> butelki i mówić "jest super, już prawie się da ogolić i tylko trochę
> ryzyko, że można poderżnąć sobie gardło, ale jak się uprzesz to udowodnisz,
> że się da". Jak ktoś lubi... spoko.
> 
> Delphi nie było, nie jest i nigdy nie będzię nadawało się do weba w stopniu
> nawet o kilometr zbliżonym do normalnych, dedykowanych temu narzędzi.
> Lazarus też nie.
> Co innego strona serwerowa, ale nie generująca HTML tylko dostarczająca
> logiki biznesowej.
> 
Tutaj też od strony klienta używasz JS + co tam sobie dobierzesz Pascal 
jest tylko od strony serwera

Jest jednak możliwość zrobienia tego w jednym kodzie i to akurat jest fajne.

podobnie jak w Pythonie lub innym tworze

Pozdrawiam
J-23

On Sat, 23 Nov 2019 00:42:46 +0100, J-23 wrote:

>>> Długi czas bolączką Lazarus było brak możliwości pisania pod Web. Ta
>>> biblioteka to zmienia http://www.raudus.com/ fajnie że idzie to do
>>> przodu choć w ślimaczym tępię
>>>
>>> Pozdrawiam
>>> J-23
>> 
>> No, już są na etapie stron gdzieś tak z 95-98 roku. Jeszcze z 200 lat i
>> będą koło 2010.
>> 
>> Po co używać takich potworków skoro są potężne i elastyczne narzędzia
>> oparte o JS/Node? I miliony bibliotek do wszystkiego.
> 
> Web nigdy nie składał się z jednej technologii zawsze jest to zbiór kilku.
> 
> Z tymi potężnymi i elastycznymi to bym dyskutował ale ok niech ci będzie 
> że są

W porównaniu do tego co oferuje Delphi/Lazarus? Są przeolbrzymie o
przepotężnych możliwościach.
 
>> To tak jakby w świecie pełnym darmowych golarek golić się tulipankiem z
>> butelki i mówić "jest super, już prawie się da ogolić i tylko trochę
>> ryzyko, że można poderżnąć sobie gardło, ale jak się uprzesz to udowodnisz,
>> że się da". Jak ktoś lubi... spoko.
>> 
>> Delphi nie było, nie jest i nigdy nie będzię nadawało się do weba w stopniu
>> nawet o kilometr zbliżonym do normalnych, dedykowanych temu narzędzi.
>> Lazarus też nie.
>> Co innego strona serwerowa, ale nie generująca HTML tylko dostarczająca
>> logiki biznesowej.
>> 
> Tutaj też od strony klienta używasz JS + co tam sobie dobierzesz Pascal 
> jest tylko od strony serwera
> 
> Jest jednak możliwość zrobienia tego w jednym kodzie i to akurat jest fajne.

To jest fundamentalny błąd w produkcji softu. Próba naginania
rzeczywistości do oczekiwać i lenistwa. Próba używania młotka do wkręcania
wkrętów, heblowania i gwintowania. Nie da się, nawet olbrzymim nakładem
chęci i czasu. Zmyślny programista dobiera narzędzia do problemu, weba robi
za pomocą technologii webowych, mobila za pomocą mobilnych, itd. Tak jest
prościej, szybciej i w dalszej perspektywnie taniej. Delphi jest fajne do
desktopowych, windowsowych okienek i baz danych. Choć nawet kwestia ORMa to
już w jego wymiarze problem, który w innych technologiach nie istnieje od
dekad.
btw okienka zaś umierają, czy to się komuś podoba czy nie, jeszcze parę lat
i zostanie garstka użytkowników, jak w latach dwutysięcznych użytkownicy
softu dosowego. Reszta będzie siedzieć na aplikacjach napędzanych JS i
innymi tego typu narzędziami. Może Emba podepnie się pod nurt WebAssembly,
bo to ciekawa technologia i chyba dałoby się ją spiąć z Delphi, ale poza
tym to czarno widzę przyszłość pascala i trzymanie się go kurczowo będzie
bardzo bolesne.
 
> podobnie jak w Pythonie lub innym tworze

Python też korzysta z bibliotek pisanych w innych językach, gdy oczekuje
się od niego wydajności, bo sam jest koszmarnie wolny. Choć akurat w jego
przypadku te biblioteki są, w świecie Delphi ich nie ma zazwyczaj lub jest
niedorobiona i porzucona jedna.

-- 
pozdrawiam
Roman Tyczka

W dniu 23.11.2019 o 13:18, Roman Tyczka pisze:
> On Sat, 23 Nov 2019 00:42:46 +0100, J-23 wrote:
> 
>>>> Długi czas bolączką Lazarus było brak możliwości pisania pod Web. Ta
>>>> biblioteka to zmienia http://www.raudus.com/ fajnie że idzie to do
>>>> przodu choć w ślimaczym tępię
>>>>
>>>> Pozdrawiam
>>>> J-23
>>>
>>> No, już są na etapie stron gdzieś tak z 95-98 roku. Jeszcze z 200 lat i
>>> będą koło 2010.
>>>
>>> Po co używać takich potworków skoro są potężne i elastyczne narzędzia
>>> oparte o JS/Node? I miliony bibliotek do wszystkiego.
>>
>> Web nigdy nie składał się z jednej technologii zawsze jest to zbiór kilku.
>>
>> Z tymi potężnymi i elastycznymi to bym dyskutował ale ok niech ci będzie
>> że są
> 
> W porównaniu do tego co oferuje Delphi/Lazarus? Są przeolbrzymie o
> przepotężnych możliwościach.

Aż się ciśnie na usta gdzie są te potężne możliwości? NodeJS bez 
dodatkowych bibliotek jest tylko swoistym środowiskiem uruchomieniowym 
pozwalającym korzystać z JS poza przeglądarką tyle i aż tyle.
>   
to są inne technologie jak do tej pory Delphi nie działało na Web i nie 
będzie działać na dużą skale, np dla mnie byłby Delphi/Lazarus dziwnym 
wyborem gdyby celem była sama strona www. Natomiast dodatkowa 
funkcjonalność w postaci weba do istniejącego softu ma jak najbardziej sens.
>>> To tak jakby w świecie pełnym darmowych golarek golić się tulipankiem z
>>> butelki i mówić "jest super, już prawie się da ogolić i tylko trochę
>>> ryzyko, że można poderżnąć sobie gardło, ale jak się uprzesz to udowodnisz,
>>> że się da". Jak ktoś lubi... spoko.
>>>
>>> Delphi nie było, nie jest i nigdy nie będzię nadawało się do weba w stopniu
>>> nawet o kilometr zbliżonym do normalnych, dedykowanych temu narzędzi.
>>> Lazarus też nie.
>>> Co innego strona serwerowa, ale nie generująca HTML tylko dostarczająca
>>> logiki biznesowej.
>>>
>> Tutaj też od strony klienta używasz JS + co tam sobie dobierzesz Pascal
>> jest tylko od strony serwera
>>
>> Jest jednak możliwość zrobienia tego w jednym kodzie i to akurat jest fajne.
> 
> To jest fundamentalny błąd w produkcji softu.
Z tym błędem fundamentalnym to się do końca nie zgodzę. Do weba musimy 
mieć co najmniej dwie technologie coś co działa po stronie klienta tutaj 
najczęściej jest JS + coś dodatkowego i po stronie serwera o ile po 
stronie klienta JS jest raczej stałym dodatkiem to po stronie serwera 
mamy już wolną amerykankę może być to Node/Java/PHP/Python i dołączył do 
nich powoli Pascal więc zapytam serio czego naginania że po stronie 
serwera pojawił się Pascal?
  Próba naginania
> rzeczywistości do oczekiwać i lenistwa. Próba używania młotka do wkręcania
> wkrętów, heblowania i gwintowania. Nie da się, nawet olbrzymim nakładem
> chęci i czasu. Zmyślny programista dobiera narzędzia do problemu, weba robi
> za pomocą technologii webowych, mobila za pomocą mobilnych, itd. Tak jest
> prościej, szybciej i w dalszej perspektywnie taniej. Delphi jest fajne do
> desktopowych, windowsowych okienek i baz danych. Choć nawet kwestia ORMa to
> już w jego wymiarze problem, który w innych technologiach nie istnieje od
> dekad.
> btw okienka zaś umierają, czy to się komuś podoba czy nie, jeszcze parę lat
> i zostanie garstka użytkowników, jak w latach dwutysięcznych użytkownicy
> softu dosowego. Reszta będzie siedzieć na aplikacjach napędzanych JS i
> innymi tego typu narzędziami. Może Emba podepnie się pod nurt WebAssembly,
> bo to ciekawa technologia i chyba dałoby się ją spiąć z Delphi, ale poza
> tym to czarno widzę przyszłość pascala i trzymanie się go kurczowo będzie
> bardzo bolesne.

Demonizujesz JS pojawia się coraz częściej nie tylko w aplikacjach web 
ale i desktop. Po co a dlatego że te technologie da się łatwo 
modyfikować. To że pokazałem Raudus to jest tylko jedna z możliwości ja 
takie rzeczy jak potrafi Raudus budowałem np za pomocą Noda czy 
Electrona jest to tylko jedna z możliwości

Ciekawym przykładem wykorzystania JS jest np Visual Studio Code które 
wykorzystuje JS w aplikacji desktop.
>   
>> podobnie jak w Pythonie lub innym tworze
> 
> Python też korzysta z bibliotek pisanych w innych językach, gdy oczekuje
> się od niego wydajności, bo sam jest koszmarnie wolny. Choć akurat w jego
> przypadku te biblioteki są, w świecie Delphi ich nie ma zazwyczaj lub jest
> niedorobiona i porzucona jedna.

a to dobre Python szybszy z dodatkowymi bibliotekami jak bez:P? Od 
kiedy? Python jest językiem skryptowym a jak wiemy każdy język skryptowy 
jest wolniejszy od kompilowanego

Pozdrawiam
J-23

W dniu sobota, 23 listopada 2019 13:18:30 UTC+1 użytkownik Roman Tyczka napisał:
> > Jest jednak możliwość zrobienia tego w jednym kodzie i to akurat jest fajne.
> To jest fundamentalny błąd w produkcji softu. Próba naginania
> rzeczywistości do oczekiwać i lenistwa. Próba używania młotka do wkręcania
> wkrętów, heblowania i gwintowania. Nie da się, nawet olbrzymim nakładem
> chęci i czasu. Zmyślny programista dobiera narzędzia do problemu, weba robi

Ciach... Swego czasu byłem "zmyślnym programistom" i dobierałem narzędzia do problemu. Efekt - może było to i fajne i ciekawe na etapie - "uczę się". Na etapie - "zarabiam" nie sprawdza się i wybieram opcję "najłatwiej i najefektywniej". I wybacz, ale w firmie w której używa się Delphi, najłatwiej i najefektywniej jest wybrać np. UniGUI niż szkolić ludzi w technologiach "webowych" (co by to nie miało znaczyć). 
A chciałem zauważyć, że w takich przypadkach nie chodzi o "stronkę z reklamą firmy Mietka" a najczęściej o rozszerzenie o kolejne możliwości już istniejącego systemu pisanego w Delphi.

> za pomocą technologii webowych, mobila za pomocą mobilnych, itd. Tak jest
> prościej, szybciej i w dalszej perspektywnie taniej. 

Także powyższe farmazony są prawdziwe dla studentów i tych szukających drogi. Lub ewentualnie na tyle bogatych żeby tracić czas i pieniądze na poszukiwanie "właściwej" drogi lub zatrudnianie ludzi pod konkretne zadania.

>Delphi jest fajne do
> desktopowych, windowsowych okienek i baz danych. Choć nawet kwestia ORMa to
> już w jego wymiarze problem, który w innych technologiach nie istnieje od
> dekad.
> btw okienka zaś umierają, czy to się komuś podoba czy nie, jeszcze parę lat
> i zostanie garstka użytkowników, jak w latach dwutysięcznych użytkownicy
>

Ahhh... Umieranie okienek jest tak mityczne jak zastępowanie Windowsa linuksem. Od ilu to ja już lat słysze? Od 20? Co najmniej. Zresztą prawda jest taka, że po pierwszym "szale" weba, gdy nagle okazało się że jednak apki webowe są mniej wygodne od desktopa, firmy rozwijają aplikację standardowo dając do tego możliwość podpięcia GUI webowego. Nie na odwrót.
I tak, wiem że technologie weba zmieniły się przez ten czas i jak ktoś potrafi/chce/ma czas, może zrobić apkę web z userExperience podobnym jak deskopowej, jednak jest to trudniejsze i bardziej czasochłonne. Poza tym problemem jest gdy np. taka apka musi się komunikować ze sprzętem. 

Swoją drogą bardzo pesymistycznie widzisz Delphi :) W szczególności w okresie gdy tak naprawdę do pakietu można mieć jedno jedyne zastrzeżenie - dziwną politykę licencyjno-cenową, bo reszt idzie w ciekawym kierunku (jak nigdy wcześniej).

pozdrawiam,
Przemek O.

On Mon, 25 Nov 2019 02:23:35 -0800 (PST), immo wrote:

>>> Jest jednak możliwość zrobienia tego w jednym kodzie i to akurat jest fajne.
>> To jest fundamentalny błąd w produkcji softu. Próba naginania
>> rzeczywistości do oczekiwać i lenistwa. Próba używania młotka do wkręcania
>> wkrętów, heblowania i gwintowania. Nie da się, nawet olbrzymim nakładem
>> chęci i czasu. Zmyślny programista dobiera narzędzia do problemu, weba robi
> 
> Ciach... Swego czasu byłem "zmyślnym programistom" i dobierałem
> narzędzia do problemu. Efekt - może było to i fajne i ciekawe na etapie
> - "uczę się". Na etapie - "zarabiam" nie sprawdza się i wybieram opcję
> "najłatwiej i najefektywniej". I wybacz, ale w firmie w której używa się
> Delphi, najłatwiej i najefektywniej jest wybrać np. UniGUI niż szkolić
> ludzi w technologiach "webowych" (co by to nie miało znaczyć). A
> chciałem zauważyć, że w takich przypadkach nie chodzi o "stronkę z
> reklamą firmy Mietka" a najczęściej o rozszerzenie o kolejne możliwości
> już istniejącego systemu pisanego w Delphi.

Skoro chcesz robić weba w Delphi to i tak:
a) musisz nauczyć się HTMLa
b) musisz nauczyć się CSS
c) musisz zrozumieć HTTP

to powyżej, żeby zrobić dobrze i żeby nie wyglądało jak website z lat '90
zajmie z 70% czasu nauki.

Zostaje JS/TS, którego imho postokroć lepiej się nauczyć i go używać niż
pałować się z delphi i konwerterami do JS z wielu powodów. Zwłaszcza, że TS
jest po prostu zwykłym, typowanym językiem programowania, przy tym o niebo
wygodniejszym od Delphi w przypadku weba. Już samo durne obsługiwanie JSONa
w JS to łatwizna, przypisujesz stringa z JSONem do zmiennej i zmienna staje
się obiektem JS, malutka linijka w kodzie. W Delphi pałowania z parsowaniem
i pustego kodowania co niemiara.

Mało tego, gdy na produkcji coś nie będzie działać tak jak powinno to
znająć te technologie wraz z JS jesteś w stanie szybko rozkminić co jest
problemem, pisząc zaś w Delphi i używając kodu JS generowanego przez
automat jesteś w d...
 
>> za pomocą technologii webowych, mobila za pomocą mobilnych, itd. Tak jest
>> prościej, szybciej i w dalszej perspektywnie taniej. 
> 
> Także powyższe farmazony są prawdziwe dla studentów i tych szukających
> drogi. Lub ewentualnie na tyle bogatych żeby tracić czas i pieniądze na
> poszukiwanie "właściwej" drogi lub zatrudnianie ludzi pod konkretne
> zadania.

Masz prawo do swojej opinii. Nawet jeśli przez takie decyzje rośnie w tle
dług technologiczny. Bo nie oszukujmy się, Delphi jest na równi pochyłej,
możesz zaklinać rzeczywistość, ale trend jest spadkowy a nie wzrostowy.
Pewnego pięknego poranka odpalisz kompa i przeczytasz, że emba zwolniła już
wszystkich developerów Delphi i zamknęła tę gałąź swojej produkcji, zajmuje
się innymi rzeczami. A Tobie zostaje otrzeć łzę i przepisać powoli wszystko
na inną technologię.

>>Delphi jest fajne do
>> desktopowych, windowsowych okienek i baz danych. Choć nawet kwestia ORMa to
>> już w jego wymiarze problem, który w innych technologiach nie istnieje od
>> dekad.
>> btw okienka zaś umierają, czy to się komuś podoba czy nie, jeszcze parę lat
>> i zostanie garstka użytkowników, jak w latach dwutysięcznych użytkownicy
> 
> Ahhh... Umieranie okienek jest tak mityczne jak zastępowanie Windowsa linuksem. Od ilu to ja już lat słysze? Od 20? Co najmniej.

Ja 20 lat temu nie słuszałem takich twierdzeń, może poza światem Linuksa,
który co roku ogłasza rok Linuksa (czyt. pokonanie Windowsa), ale nie o tym
tu mowa. Mowa o nowym paradygmacie, o aplikacjach chmurowo-webowych, to nie
są stare technologie, dopiero się rozwijają i dynamicznie zjadają rynek
desktopowy. Zobacz na dzieciaki, one już pecetów nie używają, smartfon i
przeglądarka to ich żywioł. A one za chwilę będą głównym targetem
softwarowych firm.

> Zresztą prawda jest taka, że po pierwszym "szale" weba, gdy nagle okazało
> się że jednak apki webowe są mniej wygodne od desktopa, firmy rozwijają
> aplikację standardowo dając do tego możliwość podpięcia GUI webowego.

Czy GUI desktopowe jest wygodniejsze czy nie to kwestia upodobań.

> Nie na odwrót. I tak, wiem że technologie weba zmieniły się przez ten
> czas i jak ktoś potrafi/chce/ma czas, może zrobić apkę web z
> userExperience podobnym jak deskopowej, jednak jest to trudniejsze i
> bardziej czasochłonne. Poza tym problemem jest gdy np. taka apka musi
> się komunikować ze sprzętem. 

Nie widzę problemu, instalujesz bridge, z którym aplikacja webowa
komunikuje się lokalnie po HTTP, efekt prawie taki sam jak driver
systemowy.

> Swoją drogą bardzo pesymistycznie widzisz Delphi :) W szczególności w
> okresie gdy tak naprawdę do pakietu można mieć jedno jedyne zastrzeżenie
> - dziwną politykę licencyjno-cenową, bo reszt idzie w ciekawym kierunku
> (jak nigdy wcześniej). 

Oraz jest TAK STRASZLIWIE zabugowane jak nigdy wcześniej - dziękuję, mam
dość. Zresztą obecnie w Embie moc idzie w marketing, w R&D zostali już
chyba tylko studenci i niezmordowany Dmitry od AnyDACa. Tak się nie da.

-- 
pozdrawiam
Roman Tyczka

W dniu poniedziałek, 25 listopada 2019 13:57:49 UTC+1 użytkownik Roman Tyczka napisał:

> Skoro chcesz robić weba w Delphi to i tak:
> a) musisz nauczyć się HTMLa
> b) musisz nauczyć się CSS
> c) musisz zrozumieć HTTP
> 
> to powyżej, żeby zrobić dobrze i żeby nie wyglądało jak website z lat '90
> zajmie z 70% czasu nauki.

Apka webowa != website. Chyba mówimy o różnych sprawach, albo nigdy nie używałeś / nie sprawdzałeś jak pracuje się z np. UniGUI. 

> 
> Zostaje JS/TS, którego imho postokroć lepiej się nauczyć i go używać niż
> pałować się z delphi i konwerterami do JS z wielu powodów. Zwłaszcza, że TS
> jest po prostu zwykłym, typowanym językiem programowania, przy tym o niebo
> wygodniejszym od Delphi w przypadku weba. Już samo durne obsługiwanie JSONa
> w JS to łatwizna, przypisujesz stringa z JSONem do zmiennej i zmienna staje
> się obiektem JS, malutka linijka w kodzie. W Delphi pałowania z parsowaniem
> i pustego kodowania co niemiara.
> 
> Mało tego, gdy na produkcji coś nie będzie działać tak jak powinno to
> znająć te technologie wraz z JS jesteś w stanie szybko rozkminić co jest
> problemem, pisząc zaś w Delphi i używając kodu JS generowanego przez
> automat jesteś w d...

Tak, teraz jestem pewien. Nie wiesz o czym piszesz. Ja w przeciwieństwie do Ciebie zrobiłem już kilka webApek w UniGUI.

> Masz prawo do swojej opinii. Nawet jeśli przez takie decyzje rośnie w tle
> dług technologiczny. Bo nie oszukujmy się, Delphi jest na równi pochyłej,
> możesz zaklinać rzeczywistość, ale trend jest spadkowy a nie wzrostowy.
> Pewnego pięknego poranka odpalisz kompa i przeczytasz, że emba zwolniła już
> wszystkich developerów Delphi i zamknęła tę gałąź swojej produkcji, zajmuje
> się innymi rzeczami. A Tobie zostaje otrzeć łzę i przepisać powoli wszystko
> na inną technologię.

Opis jest prawdziwy dla dowolnej technologii :/


> > Ahhh... Umieranie okienek jest tak mityczne jak zastępowanie Windowsa linuksem. Od ilu to ja już lat słysze? Od 20? Co najmniej.
> 
> Ja 20 lat temu nie słuszałem takich twierdzeń, może poza światem Linuksa,
> który co roku ogłasza rok Linuksa (czyt. pokonanie Windowsa), ale nie o tym
> tu mowa. Mowa o nowym paradygmacie, o aplikacjach chmurowo-webowych, to nie
> są stare technologie, dopiero się rozwijają i dynamicznie zjadają rynek
> desktopowy. Zobacz na dzieciaki, one już pecetów nie używają, smartfon i
> przeglądarka to ich żywioł. A one za chwilę będą głównym targetem
> softwarowych firm.

Już widzę planowanie produkcji lub księgowość na smartfonie. :/ Wydaje mi sie że obecną przestarzałą technologią jednak doczekam emerytury. Żeby stało się tak jak mówisz musi zaistnieć rewolucja w tym co oferują dostawcy sprzętu. A na razie się na to nie zanosi. Oczywiście głowy nie dam uciąć bo rewolucja ma to do siebie ze pojawia się niespodziewanie.

> Czy GUI desktopowe jest wygodniejsze czy nie to kwestia upodobań.

Jakich upodobań? To jest akurat mierzalne i jeśli ktoś delikatnie bardziej wejdzie w zagadnienia UX to jest to w stanie zbadać i podać jednoznaczne wyniki.

> Nie widzę problemu, instalujesz bridge, z którym aplikacja webowa
> komunikuje się lokalnie po HTTP, efekt prawie taki sam jak driver
> systemowy.

A ja widzę, bo to już jest kombinowane rozwiązanie a nie natywne. W tym przypadku brak już zalet aplikacji webowej.

> Oraz jest TAK STRASZLIWIE zabugowane jak nigdy wcześniej - dziękuję, mam
> dość. Zresztą obecnie w Embie moc idzie w marketing, w R&D zostali już
> chyba tylko studenci i niezmordowany Dmitry od AnyDACa. Tak się nie da.

Każdy ma prawo do swojego zdania, jednak ja uważam że o ile mnie można zarzucić przesadny optymizm w kwestii Delphi (pomimo że sam produkcyjnie już od dawana Delphi nie używam jako pierwszego wyboru, bo właśnie polityka cenowo-licencyjna jest super odstraszaczem) to Ty jednak przesadzasz w drugą stronę.  A AnyDaca/FireDACa nie używam od czasu jak wykupiło go EMB, bo słusznie wtedy zaprorokowałem że jego cena wzrośnie a dostępność będzie dużo gorsza. Przesiadłem się na rozwiązania DevArta i w testach nawet okazało się że jest szybszy od FireDACa :) Ale to tak na marginesie.

pozdrawiam,
Przemek O.

On Tue, 26 Nov 2019 01:26:47 -0800 (PST), immo wrote:

>> Skoro chcesz robić weba w Delphi to i tak:
>> a) musisz nauczyć się HTMLa
>> b) musisz nauczyć się CSS
>> c) musisz zrozumieć HTTP
>> 
>> to powyżej, żeby zrobić dobrze i żeby nie wyglądało jak website z lat '90
>> zajmie z 70% czasu nauki.
> 
> Apka webowa != website. Chyba mówimy o różnych sprawach, albo nigdy nie używałeś / nie sprawdzałeś jak pracuje się z np. UniGUI. 

Owszem, nie używałem UniGUI, czytałem tylko opis ze strony i ogłądałem
dema, nic mi nie urwało.
 
>> Zostaje JS/TS, którego imho postokroć lepiej się nauczyć i go używać niż
>> pałować się z delphi i konwerterami do JS z wielu powodów. Zwłaszcza, że TS
>> jest po prostu zwykłym, typowanym językiem programowania, przy tym o niebo
>> wygodniejszym od Delphi w przypadku weba. Już samo durne obsługiwanie JSONa
>> w JS to łatwizna, przypisujesz stringa z JSONem do zmiennej i zmienna staje
>> się obiektem JS, malutka linijka w kodzie. W Delphi pałowania z parsowaniem
>> i pustego kodowania co niemiara.
>> 
>> Mało tego, gdy na produkcji coś nie będzie działać tak jak powinno to
>> znająć te technologie wraz z JS jesteś w stanie szybko rozkminić co jest
>> problemem, pisząc zaś w Delphi i używając kodu JS generowanego przez
>> automat jesteś w d...
> 
> Tak, teraz jestem pewien. Nie wiesz o czym piszesz. Ja w przeciwieństwie do Ciebie zrobiłem już kilka webApek w UniGUI.

PWA, bo o tym piszesz, tym różni się od strony internetowej, że jest
...inaczej nazwane :-) Są oczywiście drobne wymagania, typu praca offline,
co zostało załatwione service workerami, ale 95% apki webowej to ten sam
kod co kod strony + kilka drobnych dodatków.
 
>> Masz prawo do swojej opinii. Nawet jeśli przez takie decyzje rośnie w tle
>> dług technologiczny. Bo nie oszukujmy się, Delphi jest na równi pochyłej,
>> możesz zaklinać rzeczywistość, ale trend jest spadkowy a nie wzrostowy.
>> Pewnego pięknego poranka odpalisz kompa i przeczytasz, że emba zwolniła już
>> wszystkich developerów Delphi i zamknęła tę gałąź swojej produkcji, zajmuje
>> się innymi rzeczami. A Tobie zostaje otrzeć łzę i przepisać powoli wszystko
>> na inną technologię.
> 
> Opis jest prawdziwy dla dowolnej technologii :/

Dla natywnych technologii webowych? Nie sądzę. Owsze,m frameworki umierają
i rodzą się nowe, ale póki co background czyli JS i CSS od lat swietnie się
rozwija.
 
>>> Ahhh... Umieranie okienek jest tak mityczne jak zastępowanie Windowsa linuksem. Od ilu to ja już lat słysze? Od 20? Co najmniej.
>> 
>> Ja 20 lat temu nie słuszałem takich twierdzeń, może poza światem Linuksa,
>> który co roku ogłasza rok Linuksa (czyt. pokonanie Windowsa), ale nie o tym
>> tu mowa. Mowa o nowym paradygmacie, o aplikacjach chmurowo-webowych, to nie
>> są stare technologie, dopiero się rozwijają i dynamicznie zjadają rynek
>> desktopowy. Zobacz na dzieciaki, one już pecetów nie używają, smartfon i
>> przeglądarka to ich żywioł. A one za chwilę będą głównym targetem
>> softwarowych firm.
> 
> Już widzę planowanie produkcji lub księgowość na smartfonie. :/ Wydaje
> mi sie że obecną przestarzałą technologią jednak doczekam emerytury.
> Żeby stało się tak jak mówisz musi zaistnieć rewolucja w tym co oferują
> dostawcy sprzętu. A na razie się na to nie zanosi. Oczywiście głowy nie
> dam uciąć bo rewolucja ma to do siebie ze pojawia się niespodziewanie.

Jeszcze kilka ruchów takich jak JPK i księgowość będzie prawie w pełni
zautomatyzowana. A planowanie produkcji pewnie nie ogarniesz smartfonem,
nie wiem, nie znam się, ale na tablecie już nie widzę problemu. Można też
bezprzewodowo przesłać obraz na choćby tv czy projektor a sterowanie mieć
na milion innych sposobów niż myszka, a nawet głosowe.
Zresztą ile % softwaru to produkcja? Ćwierć promila? Pewnie mniej. Nisza
desktopowa oczywiście zostanie, tak jak nisze w wielu innych branżach.
 
>> Czy GUI desktopowe jest wygodniejsze czy nie to kwestia upodobań.
> 
> Jakich upodobań? To jest akurat mierzalne i jeśli ktoś delikatnie
> bardziej wejdzie w zagadnienia UX to jest to w stanie zbadać i podać
> jednoznaczne wyniki.

No to czekam na wyniki, bo jak na razie kontrolki w apkach mobilnych wydają
mi się przyjaźniejsze w użyciu. Owszem, gdy apka desktopowa ma dobrze
zrobione skróty klawiaturowe i user się tego nauczy to będzie
niedościgniony, ale interfejsy klikane zależą od umiejętności
projektującego, i zarówno desktopowy jak i mobilny może być dobry lub zły.
 
>> Nie widzę problemu, instalujesz bridge, z którym aplikacja webowa
>> komunikuje się lokalnie po HTTP, efekt prawie taki sam jak driver
>> systemowy.
> 
> A ja widzę, bo to już jest kombinowane rozwiązanie a nie natywne. W tym przypadku brak już zalet aplikacji webowej.

A instalacja drivera czym jest jeśli nie kombinowanym rozwiązaniem? Niczym
się to nie różni.
 
>> Oraz jest TAK STRASZLIWIE zabugowane jak nigdy wcześniej - dziękuję, mam
>> dość. Zresztą obecnie w Embie moc idzie w marketing, w R&D zostali już
>> chyba tylko studenci i niezmordowany Dmitry od AnyDACa. Tak się nie da.
> 
> Każdy ma prawo do swojego zdania, jednak ja uważam że o ile mnie można
> zarzucić przesadny optymizm w kwestii Delphi (pomimo że sam produkcyjnie
> już od dawana Delphi nie używam jako pierwszego wyboru, bo właśnie
> polityka cenowo-licencyjna jest super odstraszaczem) to Ty jednak
> przesadzasz w drugą stronę.  

Zapewne tak, ale dla mnie oczywiste jest, że Delphi już dziś praktycznie
nie liczy się w świecie produkcji softu, w ofertach pracy, w dostępności
narzędzi itd. A Emba tylko uparcie kopie gębszy dołek, zarówno bandycką
polityką licencyjonowania jak i zamykaniem się na open source. Już nawet M$
poszedł po rozum do głowy w tym zakresie.

> A AnyDaca/FireDACa nie używam od czasu jak
> wykupiło go EMB, bo słusznie wtedy zaprorokowałem że jego cena wzrośnie
> a dostępność będzie dużo gorsza. Przesiadłem się na rozwiązania DevArta
> i w testach nawet okazało się że jest szybszy od FireDACa :) Ale to tak
> na marginesie. 

O, to ciekawe, przyjrzę się, bo używam FD, ale dlatego, że nic lepszego nie
było.
A jak ze wsparciem DevArtu? Reakcja na zgłoszenia problemu jest taka jak
KIEDYŚ była u Dmitryego (szybka) czy jak dziś u Emby (często żadna)?

-- 
pozdrawiam
Roman Tyczka

W dniu wtorek, 26 listopada 2019 14:16:01 UTC+1 użytkownik Roman Tyczka napisał:

> No to czekam na wyniki, bo jak na razie kontrolki w apkach mobilnych wydają
> mi się przyjaźniejsze w użyciu. Owszem, gdy apka desktopowa ma dobrze
> zrobione skróty klawiaturowe i user się tego nauczy to będzie
> niedościgniony, ale interfejsy klikane zależą od umiejętności
> projektującego, i zarówno desktopowy jak i mobilny może być dobry lub zły.

No ale o tym pisze. Teraz zobacz jaki jest nakład na zrobienie dobrego klikanego GUI na Webie a jaki dla desktopa. O tej różnicy mówię.

> A instalacja drivera czym jest jeśli nie kombinowanym rozwiązaniem? Niczym
> się to nie różni.

Tak, ale w tym momencie tracisz to w czym web jest lepszy od desktopa. Brakiem konieczności zarządzania wersjami na maszynie lokalnej. Instalacja czegokolwiek lokalnie automatycznie powoduje brak możliwości uniezależnienia się od widzimisię użytkownika/administratora. I w tym momencie nie widze sensu pchania się w takie webapki, bo nie są ani szybsze/wydajniejsze, ani bardziej ergonomiczne czy produktywne. Nie uruchomisz już jej gdziekolwiek (bo wymagana jest instalacja).

> Zapewne tak, ale dla mnie oczywiste jest, że Delphi już dziś praktycznie
> nie liczy się w świecie produkcji softu, w ofertach pracy, w dostępności
> narzędzi itd. A Emba tylko uparcie kopie gębszy dołek, zarówno bandycką
> polityką licencyjonowania jak i zamykaniem się na open source. Już nawet M$
> poszedł po rozum do głowy w tym zakresie.

Ja tam nie wiem. Zależy jak patrzeć na rynek. Na naszym krajowym jest kilka wielkich firm które nadal rozwijają oprogramowanie w Delphi. Jest kilka które tworzą nowe oprogramowanie. Dla rynku niemieckiego tandem Delphi+Oracle nadal jest bardzo rozpowszechniony. Są dziedziny w których Delphi nadal jest głównym graczem. Choćby HealthCare. Spowodowane to jest dużą ilością istniejących bibliotek i już działającego oprogramowania. Odwrót widać bardziej na młodych firmach które zaczynają. Pytanie tylko czy jest to powodowane słabością Delphi czy raczej bezsensowną polityką licencyjno/cenową. 

> O, to ciekawe, przyjrzę się, bo używam FD, ale dlatego, że nic lepszego nie
> było.
> A jak ze wsparciem DevArtu? Reakcja na zgłoszenia problemu jest taka jak
> KIEDYŚ była u Dmitryego (szybka) czy jak dziś u Emby (często żadna)?

Przeniosłem się na DevArt w momencie gdy EMB zakupiło AnyDACa i stało się to o czym mówiłem. Nowa wersja AD/FD tylko z nowym Delphi.
Support w moim przypadku był potrzebny dwa razy na samym początku. Reakcja poniżej 24h (w pierwszym przypadku w około godzinę), patch dla mnie + nowa wersja w jakimś tam czasie. Wydaje mi się że było ok.
Poźniej miałem kilka zgłoszeń do dbForge które też przy okazji zacząłem używać. Tutaj było gorzej :) Bo czekać trzeba było kilka dni, ale koniec końców problemy i tak zostały rozwiązane.
Inna sprawa że od tego czasu firma się rozrosła :) Teraz może nie być tak kolorowo. Pomijając że w nowych wersjach nie widzę bugów, tym bardziej że teraz to bardziej ewolucja niż rewolucja.

pozdrawiam,
Przemek O.

On Wed, 27 Nov 2019 05:09:47 -0800 (PST), immo wrote:

>> No to czekam na wyniki, bo jak na razie kontrolki w apkach mobilnych wydają
>> mi się przyjaźniejsze w użyciu. Owszem, gdy apka desktopowa ma dobrze
>> zrobione skróty klawiaturowe i user się tego nauczy to będzie
>> niedościgniony, ale interfejsy klikane zależą od umiejętności
>> projektującego, i zarówno desktopowy jak i mobilny może być dobry lub zły.
> 
> No ale o tym pisze. Teraz zobacz jaki jest nakład na zrobienie dobrego
> klikanego GUI na Webie a jaki dla desktopa. O tej różnicy mówię. 

Ale po pierwsze GUI to tylko kilka % apki, miód kryje się pod spodem. Po
drugie apka webowa/mobilna ma jednak tę przewagę, że odpalisz ją zawsze i
wszędzie i na wszystkim, a nie tylko siedząc za biurkiem przed desktopem z
windows, czasem to kluczowa funkcja. Dlatego nie możesz tu jednoznacznie
stwierdzić, że robienie na desktopie jest bezwarunkowo lepsze, bo
szybsze/tańsze.
 
>> A instalacja drivera czym jest jeśli nie kombinowanym rozwiązaniem? Niczym
>> się to nie różni.
> 
> Tak, ale w tym momencie tracisz to w czym web jest lepszy od desktopa.
> Brakiem konieczności zarządzania wersjami na maszynie lokalnej.

Nieprawda, apka się rozwija niezależnie od "drajwera", który może być
stały, jeśli obsługuje poprawnie ten potrzebny sprzęt i nie ma konieczności
aktualizacji.

> Instalacja czegokolwiek lokalnie automatycznie powoduje brak możliwości
> uniezależnienia się od widzimisię użytkownika/administratora. 

I to właśnie domena apek desktopowycxh.

> I w tym momencie nie widze sensu pchania się w takie webapki, bo nie są
> ani szybsze/wydajniejsze, ani bardziej ergonomiczne czy produktywne. Nie
> uruchomisz już jej gdziekolwiek (bo wymagana jest instalacja).

Nie, wymagana jest instalacja webdrajwera do czegoś tam, a nie apki.
A drajwer jest dla jakiejś jednej czy kilku funkcji, a nie dla całości.
Reszta działa bez drajwera. W przeciwieństwie do apki desktopowej, która
zawsze i wszędzie wymaga instalacji, upgradów, uprawnień, itd.
Poza tym ile tych urządzeń sprzętowych jest potrzebnych i jak często? I dla
ilu apek? 5%? 
 
>> Zapewne tak, ale dla mnie oczywiste jest, że Delphi już dziś praktycznie
>> nie liczy się w świecie produkcji softu, w ofertach pracy, w dostępności
>> narzędzi itd. A Emba tylko uparcie kopie gębszy dołek, zarówno bandycką
>> polityką licencyjonowania jak i zamykaniem się na open source. Już nawet M$
>> poszedł po rozum do głowy w tym zakresie.
> 
> Ja tam nie wiem. Zależy jak patrzeć na rynek. Na naszym krajowym jest
> kilka wielkich firm które nadal rozwijają oprogramowanie w Delphi. Jest
> kilka które tworzą nowe oprogramowanie. Dla rynku niemieckiego tandem
> Delphi+Oracle nadal jest bardzo rozpowszechniony. Są dziedziny w których
> Delphi nadal jest głównym graczem. Choćby HealthCare. Spowodowane to
> jest dużą ilością istniejących bibliotek i już działającego
> oprogramowania. Odwrót widać bardziej na młodych firmach które
> zaczynają. Pytanie tylko czy jest to powodowane słabością Delphi czy
> raczej bezsensowną polityką licencyjno/cenową. 

Legacy systemy znajdziesz w każdej technologii, głównie w umierających lub
już martwych. Tylko co to oznacza? Że Delphi ma przyszłość? Niektórzy
jeżdżą Fiatem 126p.
 
>> O, to ciekawe, przyjrzę się, bo używam FD, ale dlatego, że nic lepszego nie
>> było.
>> A jak ze wsparciem DevArtu? Reakcja na zgłoszenia problemu jest taka jak
>> KIEDYŚ była u Dmitryego (szybka) czy jak dziś u Emby (często żadna)?
> 
> Przeniosłem się na DevArt w momencie gdy EMB zakupiło AnyDACa i stało
> się to o czym mówiłem. Nowa wersja AD/FD tylko z nowym Delphi. Support w
> moim przypadku był potrzebny dwa razy na samym początku. Reakcja poniżej
> 24h (w pierwszym przypadku w około godzinę), patch dla mnie + nowa
> wersja w jakimś tam czasie. Wydaje mi się że było ok. Poźniej miałem
> kilka zgłoszeń do dbForge które też przy okazji zacząłem używać. Tutaj
> było gorzej :) Bo czekać trzeba było kilka dni, ale koniec końców
> problemy i tak zostały rozwiązane. Inna sprawa że od tego czasu firma
> się rozrosła :) Teraz może nie być tak kolorowo. Pomijając że w nowych
> wersjach nie widzę bugów, tym bardziej że teraz to bardziej ewolucja niż
> rewolucja. 
 
Dzięki, poobserwuję temat.

-- 
pozdrawiam
Roman Tyczka