🚀 go-pugleaf

W dniu 2016-08-23 o 09:21, kameleonsql@gmail.com pisze:
> Witam,
> Jak w temacie, czy polecacie nowe wersje Delphi do tworzenia Aplikacji mobilnych.
Delphi? AFAIK ciągle nie.

 > Zależy mi na jednej wersji kodu (o ile jest to możliwe :)):
Xamarin

> 1. Windows 10
Daruj sobie, znikomy procent i spada

> 2. Android
> 3. iOS
>
> Aplikacje mobile będą głownie "wyciągnięciem" funkcjonalności z ERP'a, baza danych Firebird 3.0.
>
> Jeśli nie Delphi to co polecacie ?
IMO najlepiej dwie natywne aplikacje. Tu nawet nie ma logiki biznesowej, 
więc nie ma co współdzielić.

Ew. Xamarin, jedne kod na obie platformy, tylko nie można ego spieprzyć 
przenosząc fragmenty UI i zachowania z platformy na platformę.

>
> Ps.
> Jestem totalnym ignorantem w tym temacie i raczej nie będziemy tego sami pisali.
 > Zlecę to jakiejś firmie, która się specjalizuje w temacie, ale
> chciałbym temat trochę "od podszewki" poznać.
>

Tak BTW zadbaj żeby API REST tego ERP miało dobra dokumentację, i jakieś 
środowisko testowe.

-- 
Arivald

W dniu wtorek, 23 sierpnia 2016 14:30:03 UTC+2 użytkownik arivald napisał:
> W dniu 2016-08-23 o 09:21, kameleonsql@gmail.com pisze:
> > Witam,
> > Jak w temacie, czy polecacie nowe wersje Delphi do tworzenia Aplikacji mobilnych.
> Delphi? AFAIK ciągle nie.
> 
>  > Zależy mi na jednej wersji kodu (o ile jest to możliwe :)):
> Xamarin
> 
> > 1. Windows 10
> Daruj sobie, znikomy procent i spada
> 
> > 2. Android
> > 3. iOS
> >
> > Aplikacje mobile będą głownie "wyciągnięciem" funkcjonalności z ERP'a, baza danych Firebird 3.0.
> >
> > Jeśli nie Delphi to co polecacie ?
> IMO najlepiej dwie natywne aplikacje. Tu nawet nie ma logiki biznesowej, 
> więc nie ma co współdzielić.
> 
> Ew. Xamarin, jedne kod na obie platformy, tylko nie można ego spieprzyć 
> przenosząc fragmenty UI i zachowania z platformy na platformę.
> 
> >
> > Ps.
> > Jestem totalnym ignorantem w tym temacie i raczej nie będziemy tego sami pisali.
>  > Zlecę to jakiejś firmie, która się specjalizuje w temacie, ale
> > chciałbym temat trochę "od podszewki" poznać.
> >
> 
> Tak BTW zadbaj żeby API REST tego ERP miało dobra dokumentację, i jakieś 
> środowisko testowe.
> 
> -- 
> Arivald

Dzięki Arivald

Nad API REST, właśnie myślę i wygląda na to, że jeszcze trochę pomyślę :)

W dniu 2016-08-23 o 14:30, arivald pisze:
> W dniu 2016-08-23 o 09:21, kameleonsql@gmail.com pisze:
>> Witam,
>> Jak w temacie, czy polecacie nowe wersje Delphi do tworzenia Aplikacji
>> mobilnych.
> Delphi? AFAIK ciągle nie.
To zależy; do tego co Roman opisał da radę.
Ale problemy mogą być nieprzewidywalne ;-)
Osobiście wycofałem się z pomysłu pisania w Delphi mobile.

>> Zależy mi na jednej wersji kodu (o ile jest to możliwe :)):
> Xamarin
>
>> 1. Windows 10
> Daruj sobie, znikomy procent i spada
>
>> 2. Android
>> 3. iOS
>>
>> Aplikacje mobile będą głownie "wyciągnięciem" funkcjonalności z ERP'a,
>> baza danych Firebird 3.0.
>>
>> Jeśli nie Delphi to co polecacie ?
> IMO najlepiej dwie natywne aplikacje. Tu nawet nie ma logiki biznesowej,
> więc nie ma co współdzielić.
Po co dwie, jak może być jedna?

> Ew. Xamarin, jedne kod na obie platformy, tylko nie można ego spieprzyć
> przenosząc fragmenty UI i zachowania z platformy na platformę.
Zaproponuję inne rozwiązanie.
Serwer aplikacyjny, który serwuje dane, ogarnia logikę itd.
Do tego stosunkowo prosty kod w HTML5 (pierwsza wersja to PHP + JS, 
druga wersja to Pure.JS), który komunikuje się z serwerem.
Aplikacja mobilna to de-facto strona www osadzona w prostym launcherze, 
który ją renderuje w WebView. To podobne rozwiązanie do np. Apache 
Cordova, ale niezupełnie.
Dodatkowy plus taki, że odpala się to w każdej przeglądarce - a to plus 
nie bez znaczenia, imo.

Ja serwer naklepałem w moORMocie, mam jeden i ten sam kod w serwerze i 
aplikacji. I zero logiki w innej aplikacji, tj. mobilnej aplikacji.
Takie podejście pozwoliło mi wykorzystać cuda wianki dostępne w HTML5 
przy jednoczesnej bardzo silnej separacji logiki/danych/prezentacji i 
nie oddałem na zewnątrz swojej logiki.
Nawet bazy danych nie oddałem ;-)

Po problemach początkowych (nosz urwa nie wiedziałem, że PHP + Windows 
to samo zło i po prostu nie robi) działa to bardzo sprawnie.

Można iść trochę inaczej, czyli wykorzystać mORMot MVC. Przy takim 
zastosowaniu będzie to działać bardzo, ale to bardzo sprawnie.
Tak czy siak, wywalenie PHP na zbity pysk, pozwoli mi na prościutki 
deploment tego rozwiązania - bo serwer REST i HTTP to de-facto te sam 
serwer napisany w Delphi (a więc korzysta z mojego "starego" kodu), a 
sama aplikacja mobilna jest zrobiona wg SPA (Single Page Application).
Jak do tego dodamy obsługę np. WebSocket lub innego MQTT, to mamy w 
pełni reaktywną i responsywną aplikację mobilną.

Oczywiście bez serwera to w ogóle nie działa - ale dla mnie to duży plus 
i żaden minus.

>> Ps.
>> Jestem totalnym ignorantem w tym temacie i raczej nie będziemy tego
>> sami pisali.
Dlatego też zrobiłem tak, jak opisałem. Nie chciałem oddać logiki na 
zewnątrz i nie chciałem też tego klepać, bo się na tym nie znam.
Natomiast sam znam się znacznie lepiej na modelu dziedziny, a więc samo 
ustalenie założeń było o rząd wielkości prostsze.

>> Zlecę to jakiejś firmie, która się specjalizuje w temacie, ale
>> chciałbym temat trochę "od podszewki" poznać.
>>
> Tak BTW zadbaj żeby API REST tego ERP miało dobra dokumentację, i jakieś
> środowisko testowe.
I testy jednostkowe do serwera :P

-- 
wloochacz

W dniu 2016-08-23 o 14:51, kameleonsql@gmail.com pisze:
/ciach/

> Nad API REST, właśnie myślę i wygląda na to, że jeszcze trochę pomyślę :)
To jest prostsze niż Ci się wydaje.
Spójrz:
http://synopse.info/files/html/Synopse%20mORMot%20Framework%20SAD%201.18.html#TITL_63
oraz
http://synopse.info/files/html/Synopse%20mORMot%20Framework%20SAD%201.18.html#TITL_68


-- 
wloochacz

Użytkownik "wloochacz" <wloochacz@no.spam.gmail.com> napisał w wiadomości 
news:57bca64b$0$15209$65785112@news.neostrada.pl...
...

Nie myślałeś o tym aby ze swojego bełkotu wydać kasowy kryminał?

-- 
marfi 

W dniu wtorek, 23 sierpnia 2016 21:38:52 UTC+2 użytkownik wloochacz napisał:
> W dniu 2016-08-23 o 14:30, arivald pisze:
> > W dniu 2016-08-23 o 09:21, kameleonsql@gmail.com pisze:
> >> Witam,
> >> Jak w temacie, czy polecacie nowe wersje Delphi do tworzenia Aplikacji
> >> mobilnych.
> > Delphi? AFAIK ciągle nie.
> To zależy; do tego co Roman opisał da radę.
> Ale problemy mogą być nieprzewidywalne ;-)
> Osobiście wycofałem się z pomysłu pisania w Delphi mobile.
> 
> >> Zależy mi na jednej wersji kodu (o ile jest to możliwe :)):
> > Xamarin
> >
> >> 1. Windows 10
> > Daruj sobie, znikomy procent i spada
> >
> >> 2. Android
> >> 3. iOS
> >>
> >> Aplikacje mobile będą głownie "wyciągnięciem" funkcjonalności z ERP'a,
> >> baza danych Firebird 3.0.
> >>
> >> Jeśli nie Delphi to co polecacie ?
> > IMO najlepiej dwie natywne aplikacje. Tu nawet nie ma logiki biznesowej,
> > więc nie ma co współdzielić.
> Po co dwie, jak może być jedna?
> 
> > Ew. Xamarin, jedne kod na obie platformy, tylko nie można ego spieprzyć
> > przenosząc fragmenty UI i zachowania z platformy na platformę.
> Zaproponuję inne rozwiązanie.
> Serwer aplikacyjny, który serwuje dane, ogarnia logikę itd.
> Do tego stosunkowo prosty kod w HTML5 (pierwsza wersja to PHP + JS, 
> druga wersja to Pure.JS), który komunikuje się z serwerem.
> Aplikacja mobilna to de-facto strona www osadzona w prostym launcherze, 
> który ją renderuje w WebView. To podobne rozwiązanie do np. Apache 
> Cordova, ale niezupełnie.
> Dodatkowy plus taki, że odpala się to w każdej przeglądarce - a to plus 
> nie bez znaczenia, imo.
> 
> Ja serwer naklepałem w moORMocie, mam jeden i ten sam kod w serwerze i 
> aplikacji. I zero logiki w innej aplikacji, tj. mobilnej aplikacji.
> Takie podejście pozwoliło mi wykorzystać cuda wianki dostępne w HTML5 
> przy jednoczesnej bardzo silnej separacji logiki/danych/prezentacji i 
> nie oddałem na zewnątrz swojej logiki.
> Nawet bazy danych nie oddałem ;-)
> 
> Po problemach początkowych (nosz urwa nie wiedziałem, że PHP + Windows 
> to samo zło i po prostu nie robi) działa to bardzo sprawnie.
> 
> Można iść trochę inaczej, czyli wykorzystać mORMot MVC. Przy takim 
> zastosowaniu będzie to działać bardzo, ale to bardzo sprawnie.
> Tak czy siak, wywalenie PHP na zbity pysk, pozwoli mi na prościutki 
> deploment tego rozwiązania - bo serwer REST i HTTP to de-facto te sam 
> serwer napisany w Delphi (a więc korzysta z mojego "starego" kodu), a 
> sama aplikacja mobilna jest zrobiona wg SPA (Single Page Application).
> Jak do tego dodamy obsługę np. WebSocket lub innego MQTT, to mamy w 
> pełni reaktywną i responsywną aplikację mobilną.
> 
> Oczywiście bez serwera to w ogóle nie działa - ale dla mnie to duży plus 
> i żaden minus.
> 
> >> Ps.
> >> Jestem totalnym ignorantem w tym temacie i raczej nie będziemy tego
> >> sami pisali.
> Dlatego też zrobiłem tak, jak opisałem. Nie chciałem oddać logiki na 
> zewnątrz i nie chciałem też tego klepać, bo się na tym nie znam.
> Natomiast sam znam się znacznie lepiej na modelu dziedziny, a więc samo 
> ustalenie założeń było o rząd wielkości prostsze.
> 
> >> Zlecę to jakiejś firmie, która się specjalizuje w temacie, ale
> >> chciałbym temat trochę "od podszewki" poznać.
> >>
> > Tak BTW zadbaj żeby API REST tego ERP miało dobra dokumentację, i jakieś
> > środowisko testowe.
> I testy jednostkowe do serwera :P
> 
> -- 
> wloochacz

Serwus,

Dzięki "wloochacz" za wypowiedź, Twoje zdanie jest jak zawsze "odmiennym spojrzeniem" (nie pisze tego złośliwie) na temat, ale jak mam tak samo :) 
Obecnie myślę nad tym, jak najsprytniej temat mobilny "ugryź" i każda opinia forumowicza jest dla mnie cenna. 

Pozdrawiam

W dniu środa, 24 sierpnia 2016 10:20:19 UTC+2 użytkownik kamel...@gmail.com napisał:

> Obecnie myślę nad tym, jak najsprytniej temat mobilny "ugryź" i każda opinia forumowicza jest dla mnie cenna. 

Technologią, która aktualnie działa w najszerszym zakresie klientów (mobilne, web i desktop) jest JavaScript. Jeśli potrzebujesz szybko zrobić aplikację na wiele platform i nie zależy Ci na 'native experience' każdej z nich, napisz appkę w Angularze2 (na przykład - to świetny framework, ale jest tu ogromny wybór) i zapakuj ją używając Cordovy lub innego tego typu narzędzia. Jeśli masz alergię na JS, użyj TypeScriptu (na przykład, możliwości jest wiele). Do backendu wrzuć REST lub MQTT (w zależności od preferencji i potrzeb), to pozwala kompletnie odseparować obie warstwy - możesz potem API rozwijać w Delphi, Javie, .NET'cie czy choćby w nodejs'ie. Przyjmij radę: nie rób ŻADNEJ warstwy w PHP ;-)

Jeśli aplikacja się będzie rozrastać i kasę zarabiać, prędzej czy później zajdzie potrzeba przepisania jej na natywne technologie każdej z platform. Przykład z życia wzięty: https://www.engadget.com/2012/12/18/wunderlist-2-debuts/ To też pokazuje, że im mniej logiki w aplikacji mobilnej, tym lepiej ;-)

> Pozdrawiam

Takoż,
Virion

W dniu czwartek, 25 sierpnia 2016 12:03:39 UTC+2 użytkownik Mikołaj 'Virion' Milewski napisał:
> W dniu środa, 24 sierpnia 2016 10:20:19 UTC+2 użytkownik kamel...@gmail.com napisał:
> 
> > Obecnie myślę nad tym, jak najsprytniej temat mobilny "ugryź" i każda opinia forumowicza jest dla mnie cenna. 
> 
> Technologią, która aktualnie działa w najszerszym zakresie klientów (mobilne, web i desktop) jest JavaScript. Jeśli potrzebujesz szybko zrobić aplikację na wiele platform i nie zależy Ci na 'native experience' każdej z nich, napisz appkę w Angularze2 (na przykład - to świetny framework, ale jest tu ogromny wybór) i zapakuj ją używając Cordovy lub innego tego typu narzędzia. Jeśli masz alergię na JS, użyj TypeScriptu (na przykład, możliwości jest wiele). Do backendu wrzuć REST lub MQTT (w zależności od preferencji i potrzeb), to pozwala kompletnie odseparować obie warstwy - możesz potem API rozwijać w Delphi, Javie, .NET'cie czy choćby w nodejs'ie. Przyjmij radę: nie rób ŻADNEJ warstwy w PHP ;-)
> 
> Jeśli aplikacja się będzie rozrastać i kasę zarabiać, prędzej czy później zajdzie potrzeba przepisania jej na natywne technologie każdej z platform. Przykład z życia wzięty: https://www.engadget.com/2012/12/18/wunderlist-2-debuts/ To też pokazuje, że im mniej logiki w aplikacji mobilnej, tym lepiej ;-)
> 
> > Pozdrawiam
> 
> Takoż,
> Virion

JavaScript odpada u mnie z definicji :)
1. Jest za wolna 
2. Iluzja wieloplatformowości (ilość warunków jakie muszą być spełnione by to działało na różnych platformach, zawsze przyprawiała mnie o zawrót głowy i nerwowe bicie serca :))
3. Za droga w utrzymaniu

Dzięki Viron za wypowiedź.

W dniu czwartek, 25 sierpnia 2016 22:54:14 UTC+2 użytkownik kamel...@gmail.com napisał:

> JavaScript odpada u mnie z definicji :)
> 1. Jest za wolna 

Wolna czy za wolna? ;-) Firefox, Thunderbird i szereg aplikacji systemowych Windowsa 8/10 jest napisane w JS. Coraz więcej softu codziennego użytku ma front lub wszystko w JS (Slack, Wunderlist do pewnego momentu, HipChat, Atom, VisualStudio Code, Spotify - to tylko z tych, których codziennie używam) i użytkownik nie zauważa różnicy.

> 2. Iluzja wieloplatformowości (ilość warunków jakie muszą być spełnione by to działało na różnych platformach, zawsze przyprawiała mnie o zawrót głowy i nerwowe bicie serca :))

Życzę powodzenia z utrzymaniem i rozwijaniem wieloplatformowych aplikacji mobilnych w Delphi lub Xamarinie... ale ostrożnie - może dojść do palpitacji :-)

> 3. Za droga w utrzymaniu

A tego to nie rozumiem. Delphi jest drogie, programiści już prawie wyginęli - a JS ma bardzo duży wybór darmowych tooli i jest bodaj najszybciej rozwijającym się ekosystemem językowym w historii (wystarczy spojrzeć na ilość unikalnych paczek na npm w porównaniu do JAKICHKOLWIEK innych repozytoriów), więc i programistów rzesza...

> Dzięki Viron za wypowiedź.

A proszę bardzo,
Virion.
VirIon.
Vir-I-on.

W dniu 2016-08-26 o 17:36, Mikołaj 'Virion' Milewski pisze:
> W dniu czwartek, 25 sierpnia 2016 22:54:14 UTC+2 użytkownik kamel...@gmail.com napisał:
>
>> JavaScript odpada u mnie z definicji :)
>> 1. Jest za wolna
>
> Wolna czy za wolna? ;-) Firefox, Thunderbird i szereg aplikacji systemowych Windowsa
> 8/10 jest napisane w JS.

Eeee... nie całkiem. Firefox, Thunderbird i inne aplikacje na Gecko są 
napisane głównie w C++, a JavaScript jet rodzajem kleju pomiędzy 
komponentami. Tak, sporo logiki biznesowej jest w JS. Szacuję że 
aplikacja spędza nie więcej niż 5% czasu w JS, resztę w natywnych binarkach.

I JS jest jednym z powodów dlaczego Firefox czy Thunderbird jak się 
zawiesi to wszystkie okna na raz ... brak wielowątkowości w JS.

A najbardziej wkurza jak skrypt na stronie WWW zawiesza całą aplikację...


>> 3. Za droga w utrzymaniu
>
> A tego to nie rozumiem. Delphi jest drogie, programiści już prawie wyginęli -
> a JS ma bardzo duży wybór darmowych tooli i jest bodaj najszybciej rozwijającym
> się ekosystemem językowym w historii (wystarczy spojrzeć na ilość unikalnych
> paczek na npm w porównaniu do JAKICHKOLWIEK innych repozytoriów), więc i
> programistów rzesza...
>

E, chyba miałeś na myśli Javę, nie JavaScript ;-)

-- 
Arivald

W dniu 2016-08-26 o 18:24, arivald pisze:
> W dniu 2016-08-26 o 17:36, Mikołaj 'Virion' Milewski pisze:
>> W dniu czwartek, 25 sierpnia 2016 22:54:14 UTC+2 użytkownik
>> kamel...@gmail.com napisał:
>>
>>> JavaScript odpada u mnie z definicji :)
>>> 1. Jest za wolna
>>
>> Wolna czy za wolna? ;-) Firefox, Thunderbird i szereg aplikacji
>> systemowych Windowsa
>> 8/10 jest napisane w JS.
>
> Eeee... nie całkiem. Firefox, Thunderbird i inne aplikacje na Gecko są
> napisane głównie w C++, a JavaScript jet rodzajem kleju pomiędzy
> komponentami. Tak, sporo logiki biznesowej jest w JS. Szacuję że
> aplikacja spędza nie więcej niż 5% czasu w JS, resztę w natywnych
> binarkach.
No widzisz, stąd wniosek że JS do tego typu zastosowań jest 
wystarczająco szybka, mimo tego że wolna.

> I JS jest jednym z powodów dlaczego Firefox czy Thunderbird jak się
> zawiesi to wszystkie okna na raz ... brak wielowątkowości w JS.
Brak jej w JS czy w maszynie JS od Gecko?
Czy nie dlatego niektórzy nazywają FireFoxa FireSzmatą ;-)

> A najbardziej wkurza jak skrypt na stronie WWW zawiesza całą aplikację...
Zaraz, chwila - czy Ty aby nie piszesz o ekosystemie FireFox a nie o JS 
sensu stricte?

>>> 3. Za droga w utrzymaniu
>>
>> A tego to nie rozumiem. Delphi jest drogie, programiści już prawie
>> wyginęli -
>> a JS ma bardzo duży wybór darmowych tooli i jest bodaj najszybciej
>> rozwijającym
>> się ekosystemem językowym w historii (wystarczy spojrzeć na ilość
>> unikalnych
>> paczek na npm w porównaniu do JAKICHKOLWIEK innych repozytoriów), więc i
>> programistów rzesza...
>>
>
> E, chyba miałeś na myśli Javę, nie JavaScript ;-)
Odpowiem za Kolegę - nie, na pewno miał na myśli JavaScript.
I to co napisał, zgadzam się z tym obiema ręcyma i nogyma.

BTW - ja jestem daleko od ekosystemu JS, ale również za namową Kolegi 
Viriona przyjrzałem się temu bliżej. Jakbym miał pisać na dzień 
dzisiejszy cokolwiek w JS, to na pewno byłby to TypeScript.
Różnice są dla mnie... porażające (konkretnie chodzi mi o zakres 
zmiennej) i pewnie dlatego, że wychowany jestem na np. językach z silnym 
typowaniem.
Tak czy siak, JS/EcmaScript to zdecydowanie przyszłościowa platforma.
Na pewno bardziej, niż taki FMX w szczególe czy Delphi w ogóle.

-- 
wloochacz

W dniu piątek, 26 sierpnia 2016 17:36:30 UTC+2 użytkownik Mikołaj 'Virion' 
> > Dzięki Viron za wypowiedź.
> 
> A proszę bardzo,
> Virion.
> VirIon.
> Vir-I-on.

Jak już pisałem jestem "dyletantem" w tym temacie i dlatego szukam wiedzy i staram się czerpań doświadczenie innych ... Moje stanowisko w sprawie JavaScript obecnie ewoluuje :)

Wielkie dzięki 
Vir-I-on

W dniu piątek, 26 sierpnia 2016 19:54:06 UTC+2 użytkownik wloochacz napisał:
> W dniu 2016-08-26 o 18:24, arivald pisze:
> > W dniu 2016-08-26 o 17:36, Mikołaj 'Virion' Milewski pisze:
> >> W dniu czwartek, 25 sierpnia 2016 22:54:14 UTC+2 użytkownik
> >> kamel...@gmail.com napisał:
> >>
> >>> JavaScript odpada u mnie z definicji :)
> >>> 1. Jest za wolna
> >>
> >> Wolna czy za wolna? ;-) Firefox, Thunderbird i szereg aplikacji
> >> systemowych Windowsa
> >> 8/10 jest napisane w JS.
> >
> > Eeee... nie całkiem. Firefox, Thunderbird i inne aplikacje na Gecko są
> > napisane głównie w C++, a JavaScript jet rodzajem kleju pomiędzy
> > komponentami. Tak, sporo logiki biznesowej jest w JS. Szacuję że
> > aplikacja spędza nie więcej niż 5% czasu w JS, resztę w natywnych
> > binarkach.
> No widzisz, stąd wniosek że JS do tego typu zastosowań jest 
> wystarczająco szybka, mimo tego że wolna.
> 
> > I JS jest jednym z powodów dlaczego Firefox czy Thunderbird jak się
> > zawiesi to wszystkie okna na raz ... brak wielowątkowości w JS.
> Brak jej w JS czy w maszynie JS od Gecko?
> Czy nie dlatego niektórzy nazywają FireFoxa FireSzmatą ;-)
> 
> > A najbardziej wkurza jak skrypt na stronie WWW zawiesza całą aplikację...
> Zaraz, chwila - czy Ty aby nie piszesz o ekosystemie FireFox a nie o JS 
> sensu stricte?
> 
> >>> 3. Za droga w utrzymaniu
> >>
> >> A tego to nie rozumiem. Delphi jest drogie, programiści już prawie
> >> wyginęli -
> >> a JS ma bardzo duży wybór darmowych tooli i jest bodaj najszybciej
> >> rozwijającym
> >> się ekosystemem językowym w historii (wystarczy spojrzeć na ilość
> >> unikalnych
> >> paczek na npm w porównaniu do JAKICHKOLWIEK innych repozytoriów), więc i
> >> programistów rzesza...
> >>
> >
> > E, chyba miałeś na myśli Javę, nie JavaScript ;-)
> Odpowiem za Kolegę - nie, na pewno miał na myśli JavaScript.
> I to co napisał, zgadzam się z tym obiema ręcyma i nogyma.
> 
> BTW - ja jestem daleko od ekosystemu JS, ale również za namową Kolegi 
> Viriona przyjrzałem się temu bliżej. Jakbym miał pisać na dzień 
> dzisiejszy cokolwiek w JS, to na pewno byłby to TypeScript.
> Różnice są dla mnie... porażające (konkretnie chodzi mi o zakres 
> zmiennej) i pewnie dlatego, że wychowany jestem na np. językach z silnym 
> typowaniem.
> Tak czy siak, JS/EcmaScript to zdecydowanie przyszłościowa platforma.
> Na pewno bardziej, niż taki FMX w szczególe czy Delphi w ogóle.
> 
> -- 
> wloochacz

Jedno widzę jest pewne, tak na zimo czytając co piszecie. Delphi się nie nadaje nawet do tego co ja planuje. Jeszcze może ktoś mi tak łopatologicznie wyjaśni dlaczego tak w czambuł stare i "dobre" PHP z definicji dyskwalifikujecie. Mam całe B2B oparte na Kohana + Bootstrap, całość w MVC i to daje rade. Co prawda cały IBASE jest napisany przez nas + baza na Firebird (daje rade :)), ale nie ma z tym problemów i całość śmiga już jakieś 5 lat ?

Pozdrawiam

Lektura do poduszki, na dobry początek:

https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

A teraz garść własnych doświadczeń:

Znam PHP całkiem nieźle. Używałem kilku różnych frameworków, bywają lepsze i gorsze. Mogę polecić Yii, szczególnie w drugiej wersji - kawał dobrego kodu, pisany z dużą świadomością platformy i dojrzałością. Niemniej, po kilku latach pracy i rozwijaniu różnych systemów - jak i rozszerzaniu frameworków pod siebie - wyewoluowałem :-) Mianowicie, lubię hierarchiczne wzorce - z MVC zawsze robiłem mniej lub bardziej HMVC, AJAX-aware oczywiście. To, oraz generalnie specyfika weba zawsze prowadziły do tego, że część logiki widoku jak i biznesowej musiała powstawać w JS, po stronie frontu - nie mówiąc już o kodzie "frameworkowym", potrzebnym do łatania abstrakcji HMVC, żeniacego server side i front side... Teraz uważam, że na froncie musi być aplikacja. Czy użyjesz Angulara, Reacta, czy sam coś wyrzeźbisz - nie jest aż tak istotne jak to, żeby to była APLIKACJA, a nie zbiór skrypcików pisanych ad hoc, bo framework server-side już tu nie sięga. Aplikacja backendowa naturalnie przechodzi wtedy w API - REST czy jakie tam chcesz. A ponieważ logikę już masz w Delphi (tak zrozumiałem), to po co pośrednik w postaci PHP? API można zresztą napisać w czymkolwiek lepszym od PHP.

Prócz tego, PHP nie nadaje się do wdrożeń na Windows. Ma zakodowane, żeby co 500 requestów się scrashować - bo tak, żeby pamięć nie ciekła. Na Linuksie jest FPM, który ogarnia tą kuwetę, na Windowsie nie. Można i to przewalczyć (mi pomogło napisanie wrappera na PHP.exe w WinAPI), ale to ciągle rzeźba w... brązie. Zresztą, chyba wszystko jest od PHP szybsze.

-- 
Pozdrawiam,
Virion

W dniu 2016-08-26 o 19:53, wloochacz pisze:
> W dniu 2016-08-26 o 18:24, arivald pisze:
>> I JS jest jednym z powodów dlaczego Firefox czy Thunderbird jak się
>> zawiesi to wszystkie okna na raz ... brak wielowątkowości w JS.
> Brak jej w JS czy w maszynie JS od Gecko?
> Czy nie dlatego niektórzy nazywają FireFoxa FireSzmatą ;-)
>
>> A najbardziej wkurza jak skrypt na stronie WWW zawiesza całą aplikację...
> Zaraz, chwila - czy Ty aby nie piszesz o ekosystemie FireFox a nie o JS
> sensu stricte?
>

Generalnie ta implementacja JS jest chyba najgorsza pod tym względem.

Ale ogólnie w standardzie ECMA praktycznie nie ma wielowątkowości, nie 
ma współdzielenia danych, nie ma synchronizacji. Jest tylko 'webworker', 
ale to się opiera na kompletnie odseparowanych od głównego wątku 
silnikach, każdy ma swoje odseparowane dane, które owszem chodzą w 
osobnych watkach, ale cała komunikacja z nimi jest tylko poprzez 
komunikaty.

IMO upierdliwe w użyciu.

W  ES6 dodali mechanizm Promise, który służy do synchronizacji, 
asynchronicznych zadań, chociaż większość przykładów użycia zapewnia 
asynchroniczność na timerach czy asynchronicznych API, nie na webworkerach.


>>>> 3. Za droga w utrzymaniu
>>>
>>> A tego to nie rozumiem. Delphi jest drogie, programiści już prawie
>>> wyginęli -
>>> a JS ma bardzo duży wybór darmowych tooli i jest bodaj najszybciej
>>> rozwijającym
>>> się ekosystemem językowym w historii (wystarczy spojrzeć na ilość
>>> unikalnych
>>> paczek na npm w porównaniu do JAKICHKOLWIEK innych repozytoriów), więc i
>>> programistów rzesza...
>>>
>>
>> E, chyba miałeś na myśli Javę, nie JavaScript ;-)
> Odpowiem za Kolegę - nie, na pewno miał na myśli JavaScript.
> I to co napisał, zgadzam się z tym obiema ręcyma i nogyma.

Ok, ok, nie mówię że nie.
Ale jak poczytałem to: 
http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
Biblioteka realizująca funkcję która powinna być w standardzie... eh..


> BTW - ja jestem daleko od ekosystemu JS, ale również za namową Kolegi
> Viriona przyjrzałem się temu bliżej. Jakbym miał pisać na dzień
> dzisiejszy cokolwiek w JS, to na pewno byłby to TypeScript.
> Różnice są dla mnie... porażające (konkretnie chodzi mi o zakres
> zmiennej) i pewnie dlatego, że wychowany jestem na np. językach z silnym
> typowaniem.

Hmmm TypeScript wygląda ciekawie. Chociaż fraza "kompiluje do 
JavaScriptu" powoduje mieszane uczucia ;-)

A propos kompilacji do JS, to jest też asm.js. Kompiluje kod C++ (a w 
zasadzie pośredni kod LLVM) do JS, unikając wszelkich powolnych 
konstrukcji JSa (np.alokacji pamięci i GC), dzięki czemu działa około 2x 
wolniej niż natywny program w C++. Wszystkie popularne przeglądarki mają 
już optymalizacje dla asm.js.
Tylko jak się spojrzy w wygenerowany JS...


> Tak czy siak, JS/EcmaScript to zdecydowanie przyszłościowa platforma.
> Na pewno bardziej, niż taki FMX w szczególe czy Delphi w ogóle.
>

No tu akurat trudno się nie zgodzić.

-- 
Arivald

W dniu piątek, 26 sierpnia 2016 18:24:55 UTC+2 użytkownik arivald napisał:
> W dniu 2016-08-26 o 17:36, Mikołaj 'Virion' Milewski pisze:
> > W dniu czwartek, 25 sierpnia 2016 22:54:14 UTC+2 użytkownik kamel...@gmail.com napisał:
> >
> >> JavaScript odpada u mnie z definicji :)
> >> 1. Jest za wolna
> >
> > Wolna czy za wolna? ;-) Firefox, Thunderbird i szereg aplikacji systemowych Windowsa
> > 8/10 jest napisane w JS.
> 
> Eeee... nie całkiem. Firefox, Thunderbird i inne aplikacje na Gecko są 
> napisane głównie w C++, a JavaScript jet rodzajem kleju pomiędzy 
> komponentami. Tak, sporo logiki biznesowej jest w JS. Szacuję że 
> aplikacja spędza nie więcej niż 5% czasu w JS, resztę w natywnych binarkach.
> 
> I JS jest jednym z powodów dlaczego Firefox czy Thunderbird jak się 
> zawiesi to wszystkie okna na raz ... brak wielowątkowości w JS.
> 
> A najbardziej wkurza jak skrypt na stronie WWW zawiesza całą aplikację...
> 
> 
> >> 3. Za droga w utrzymaniu
> >
> > A tego to nie rozumiem. Delphi jest drogie, programiści już prawie wyginęli -
> > a JS ma bardzo duży wybór darmowych tooli i jest bodaj najszybciej rozwijającym
> > się ekosystemem językowym w historii (wystarczy spojrzeć na ilość unikalnych
> > paczek na npm w porównaniu do JAKICHKOLWIEK innych repozytoriów), więc i
> > programistów rzesza...
> >
> 
> E, chyba miałeś na myśli Javę, nie JavaScript ;-)
> 
> -- 
> Arivald

Widać że nie używasz JS. Wielowątkowość jest w tym języku i to bardzo ładnie opakowana bez kombinacji jak np w Delphi. Wielowątkowość tqorzy się sama. Trzeba mieć tego świadomość. Na przykład (pseudokod):

pobieram obrazek
coś z nim robię

^ powyższy kod jest błędny bo pobieranie obrazka nie zakończy się a już wywoływana będzie instrukcja "coś z nim zrobię".

Powinno być w "pobieram obrazek":

obrazek.onLoad=function{
  coś z nim robię  //zostanie wywołane dopiero po pobraniu obrazka
}


Kolejna kwestia to szybkość działania JS. Od zawsze mówiło się o tym że języki interpretowane są wolniejsze od kompilowanych. 
Teraz przeglądarka po wczytaniu strony dokonuje kompilacji JS i kod działa jak należy.

Co do Javy- nie używam. Bo nie działa natywnie w przeglądarce :P

Paweł

W dniu piątek, 26 sierpnia 2016 21:28:13 UTC+2 użytkownik kamel...@gmail.com napisał:
> W dniu piątek, 26 sierpnia 2016 17:36:30 UTC+2 użytkownik Mikołaj 'Virion' 
> > > Dzięki Viron za wypowiedź.
> > 
> > A proszę bardzo,
> > Virion.
> > VirIon.
> > Vir-I-on.
> 
> Jak już pisałem jestem "dyletantem" w tym temacie i dlatego szukam wiedzy i staram się czerpań doświadczenie innych ... Moje stanowisko w sprawie JavaScript obecnie ewoluuje :)
> 
> Wielkie dzięki 
> Vir-I-on

JS to świetny dynamicznie rozwijający się język. Do tego masz cacy debugger w samym Firefoksie. Jeżeli chcesz mieć po stronie serwera PHP, co czasami jest koniecznością z tego powodu że hostingodawca narzuca Ci taki model, wówczas zainstaluj sobie WampSerwer na komputerze lokalnym z Windowsem na którym pracujesz. Świetny do debugowania, za jednym odpaleniem masz lokalny Apache, PHP i debugowanie w jednym.

Paweł

W dniu 2016-08-27 o 08:46, zpksoft pisze:
> W dniu piątek, 26 sierpnia 2016 18:24:55 UTC+2 użytkownik arivald napisał:
>> W dniu 2016-08-26 o 17:36, Mikołaj 'Virion' Milewski pisze:
>>> W dniu czwartek, 25 sierpnia 2016 22:54:14 UTC+2 użytkownik kamel...@gmail.com napisał:
>>>
>>>> JavaScript odpada u mnie z definicji :)
>>>> 1. Jest za wolna
>>>
>>> Wolna czy za wolna? ;-) Firefox, Thunderbird i szereg aplikacji systemowych Windowsa
>>> 8/10 jest napisane w JS.
>>
>> Eeee... nie całkiem. Firefox, Thunderbird i inne aplikacje na Gecko są
>> napisane głównie w C++, a JavaScript jet rodzajem kleju pomiędzy
>> komponentami. Tak, sporo logiki biznesowej jest w JS. Szacuję że
>> aplikacja spędza nie więcej niż 5% czasu w JS, resztę w natywnych binarkach.
>>
>> I JS jest jednym z powodów dlaczego Firefox czy Thunderbird jak się
>> zawiesi to wszystkie okna na raz ... brak wielowątkowości w JS.
>>
>> A najbardziej wkurza jak skrypt na stronie WWW zawiesza całą aplikację...
>>
>
> Widać że nie używasz JS. Wielowątkowość jest w tym języku i to bardzo ładnie opakowana
> bez kombinacji jak np w Delphi. Wielowątkowość tqorzy się sama. Trzeba mieć tego
> świadomość. Na przykład (pseudokod):
>
> pobieram obrazek
> coś z nim robię
>
> ^ powyższy kod jest błędny bo pobieranie obrazka nie zakończy się a już wywoływana
>  będzie instrukcja "coś z nim zrobię".
>
> Powinno być w "pobieram obrazek":
>
> obrazek.onLoad=function{
>   coś z nim robię  //zostanie wywołane dopiero po pobraniu obrazka
> }

Ale tu mówisz nie o wielowątkowym kodzie JS. Mówisz o asynchronicznym 
API używanym przez JS. A to ogromna różnica.
Sam JS nie ma żadnego wpływu na to jak i kiedy i czy w ogóle obrazek się 
załaduje. To jest domena nawet nie silnika JS, a przeglądarki.

Podobnie ze wszytkimi asynchronicznymi API, jak np. XmlHttpRequest.

> Kolejna kwestia to szybkość działania JS. Od zawsze mówiło się o tym że języki
>  interpretowane są wolniejsze od kompilowanych.
> Teraz przeglądarka po wczytaniu strony dokonuje kompilacji JS i kod działa jak należy.
>
> Co do Javy- nie używam. Bo nie działa natywnie w przeglądarce :P
>
> Paweł
>

-- 
Arivald

>
> Jedno widzę jest pewne, tak na zimo czytając co piszecie. Delphi się nie nadaje nawet do tego co ja planuje. Jeszcze może ktoś mi tak łopatologicznie wyjaśni dlaczego tak w czambuł stare i "dobre" PHP z definicji dyskwalifikujecie. Mam całe B2B oparte na Kohana + Bootstrap, całość w MVC i to daje rade. Co prawda cały IBASE jest napisany przez nas + baza na Firebird (daje rade :)), ale nie ma z tym problemów i całość śmiga już jakieś 5 lat ?
>


Też kilka lat temu napisaliśmy coś w stylu B2B w PHP, działa do dzić ale 
bardzo szybko okazało się że in większe tym więcej problemów
skuteczny przyrost funkcjonalności nie dość że niższy niż w Delphi,
ale to można wytłumaczyć małym doświadczeniem,
to wraz ze wzrostem skomplikowania systemu malejący. Przyczyny są pewnie
wielorakie : brak silnego typowania, słaba obiektowość, duża
zależność od środowiska itd.

Teraz pytanie do Ciebie co planujesz. Na PC  wszyscy mówią że należy
dobierać język do zadania, ale przy smartfonach jakoś wszyscy nakłaniają
do pisania aplikacji natywnych odrębnie na każdą platformę. Oczywiście
w pewnym obszarze jest to właściwe: gdy ma się milion klientów a appka
jest wielkości komunikatora.  Oczywiście można tak samo zrobić z ERP: 
wybrać kilka funkcji i zaimplementować je w dowolnym narzędziu: 
zamówienia, kontakty podgląd raportów. Jeżeli to wystarczy ?

Systemy ERP są składową wielu tysięcy
okien i funkcjonalności i to determinuje rozwiązanie. Każde, które 
wymaga odrębnego kodu powoduje klikukrotny wzrost kosztów utrzymania,
pytanie czy obecna baza klientów zaakceptuje to.

W kwestii przenoścności to obecnie nie jest problemem sama niezgodność
implementacji (JS, HTML czy chociażb FMX) na poszczególne platformy,
szybkość też jest do zaakceptowania (o ile się to dobrze zoptymalizuje)
największym wyzwaniem jest opracowanie zupełnie nowego interfejsu
na urządzenia o innych rozmiarach, rozdzielczościach i interfejsach 
wskazujących (mysz, dotyk). Systemy klasy ERP z okienkami zawierającymi
setki pól zupełnie nie przystają do ekranu smartfonu.

--
Darek

W dniu sobota, 27 sierpnia 2016 08:40:57 UTC+2 użytkownik arivald napisał:

> Ale ogólnie w standardzie ECMA praktycznie nie ma wielowątkowości, nie 
> ma współdzielenia danych, nie ma synchronizacji. Jest tylko 'webworker', 
> ale to się opiera na kompletnie odseparowanych od głównego wątku 
> silnikach, każdy ma swoje odseparowane dane, które owszem chodzą w 
> osobnych watkach, ale cała komunikacja z nimi jest tylko poprzez 
> komunikaty.
> 
> IMO upierdliwe w użyciu.

Skoro async/await robią furorę w C#, to chyba programowanie asynchroniczne jest generalnie lepiej przyjmowane od sekwencyjnego - i nie bez powodu. Ja tam wolę użyć narzędzi typu RabbitMQ / MQTT / Rx.js / Promise (i filozofii przepływu danych i kontroli, którą wprowadzają) niż rzeźbić na event handlerach / delegatach / callbackach. To się po prostu sprawdza. Pierwszy raz na większą skalę użyłem komunikatów (jeszcze synchronicznie) właśnie w Delphi - spytaj Wloochacza, jaki jest przepływ danych w kontrolce do wizualizacji Gantta u niego ;-) Systemy reaktywne są sexy, bo stosunkowo łatwo je zrozumieć, łatwo się skalują i taka architektura sprawdza się na wielu poziomach - i na serwerze, i na kliencie. Upierdliwe? A może po prostu inne, niż przywykłeś? ;-)

> Arivald

-- 
Pozdrawiam,
Vireactive

W dniu sobota, 27 sierpnia 2016 09:06:04 UTC+2 użytkownik arivald napisał:
> W dniu 2016-08-27 o 08:46, zpksoft pisze:
> > W dniu piątek, 26 sierpnia 2016 18:24:55 UTC+2 użytkownik arivald napisał:
> >> W dniu 2016-08-26 o 17:36, Mikołaj 'Virion' Milewski pisze:
> >>> W dniu czwartek, 25 sierpnia 2016 22:54:14 UTC+2 użytkownik kamel...@gmail.com napisał:
> >>>
> >>>> JavaScript odpada u mnie z definicji :)
> >>>> 1. Jest za wolna
> >>>
> >>> Wolna czy za wolna? ;-) Firefox, Thunderbird i szereg aplikacji systemowych Windowsa
> >>> 8/10 jest napisane w JS.
> >>
> >> Eeee... nie całkiem. Firefox, Thunderbird i inne aplikacje na Gecko są
> >> napisane głównie w C++, a JavaScript jet rodzajem kleju pomiędzy
> >> komponentami. Tak, sporo logiki biznesowej jest w JS. Szacuję że
> >> aplikacja spędza nie więcej niż 5% czasu w JS, resztę w natywnych binarkach.
> >>
> >> I JS jest jednym z powodów dlaczego Firefox czy Thunderbird jak się
> >> zawiesi to wszystkie okna na raz ... brak wielowątkowości w JS.
> >>
> >> A najbardziej wkurza jak skrypt na stronie WWW zawiesza całą aplikację...
> >>
> >
> > Widać że nie używasz JS. Wielowątkowość jest w tym języku i to bardzo ładnie opakowana
> > bez kombinacji jak np w Delphi. Wielowątkowość tqorzy się sama. Trzeba mieć tego
> > świadomość. Na przykład (pseudokod):
> >
> > pobieram obrazek
> > coś z nim robię
> >
> > ^ powyższy kod jest błędny bo pobieranie obrazka nie zakończy się a już wywoływana
> >  będzie instrukcja "coś z nim zrobię".
> >
> > Powinno być w "pobieram obrazek":
> >
> > obrazek.onLoad=function{
> >   coś z nim robię  //zostanie wywołane dopiero po pobraniu obrazka
> > }
> 
> Ale tu mówisz nie o wielowątkowym kodzie JS. Mówisz o asynchronicznym 
> API używanym przez JS. A to ogromna różnica.
> Sam JS nie ma żadnego wpływu na to jak i kiedy i czy w ogóle obrazek się 
> załaduje. To jest domena nawet nie silnika JS, a przeglądarki.
> 
> Podobnie ze wszytkimi asynchronicznymi API, jak np. XmlHttpRequest.
> 
> > Kolejna kwestia to szybkość działania JS. Od zawsze mówiło się o tym że języki
> >  interpretowane są wolniejsze od kompilowanych.
> > Teraz przeglądarka po wczytaniu strony dokonuje kompilacji JS i kod działa jak należy.
> >
> > Co do Javy- nie używam. Bo nie działa natywnie w przeglądarce :P
> >
> > Paweł
> >
> 
> -- 
> Arivald

Albo ja Ciebie nie rozumiem albo Ty mnie. Piszesz że JS nie ma kontroli nad tym czy obrazek się załaduje. Właśnie podałem przykład na to że ma. I jest to typowe w programowaniu w JS. Jeżeli się tego nie uwzględnia to aplikacja działa tak jak napisał to bodajże wloochacz "roszypuje się i blokuje przeglądarkę". 
Ale tak się dzieje tylko wtedy gdy nie rozumie się wielowątkowości JS. Możesz to nazwać "asynchronicznym API" ale na jedno wychodzi: kilka czynności jest wykonywanych w tym samym czasie niezależnie.
To w Delphi musimy stosować się do odpowiednich zabiegów żeby stwierdzić czy dany wątek zakończył się. W JS jest to proste i naturalne.

I żeby nie było że dołuję Delphi. Nie. Programuję równocześnie w obu językach (i nie tylko tych). Każdy ma swoje miejsce i cechy.

Paweł

W dniu sobota, 27 sierpnia 2016 09:06:04 UTC+2 użytkownik arivald napisał:
.....> Podobnie ze wszytkimi asynchronicznymi API, jak np. XmlHttpRequest.
> -- 
> Arivald

Ach, może i o tym.. MxmHttpRequest. Przecież mamy tu pełną kontrolę nad tym, czy odpowiedź z serwera dotarła i co ona zawiera. Jest to podstawa Ajaxa. 

Paweł

W dniu 2016-08-27 o 15:54, zpksoft pisze:
> W dniu sobota, 27 sierpnia 2016 09:06:04 UTC+2 użytkownik arivald napisał:
>> W dniu 2016-08-27 o 08:46, zpksoft pisze:
>>> W dniu piątek, 26 sierpnia 2016 18:24:55 UTC+2 użytkownik arivald napisał:
>>>> W dniu 2016-08-26 o 17:36, Mikołaj 'Virion' Milewski pisze:
>>>>> W dniu czwartek, 25 sierpnia 2016 22:54:14 UTC+2 użytkownik kamel...@gmail.com napisał:
>>>>>
>>>>>> JavaScript odpada u mnie z definicji :)
>>>>>> 1. Jest za wolna
>>>>>
>>>>> Wolna czy za wolna? ;-) Firefox, Thunderbird i szereg aplikacji systemowych Windowsa
>>>>> 8/10 jest napisane w JS.
>>>>
>>>> Eeee... nie całkiem. Firefox, Thunderbird i inne aplikacje na Gecko są
>>>> napisane głównie w C++, a JavaScript jet rodzajem kleju pomiędzy
>>>> komponentami. Tak, sporo logiki biznesowej jest w JS. Szacuję że
>>>> aplikacja spędza nie więcej niż 5% czasu w JS, resztę w natywnych binarkach.
>>>>
>>>> I JS jest jednym z powodów dlaczego Firefox czy Thunderbird jak się
>>>> zawiesi to wszystkie okna na raz ... brak wielowątkowości w JS.
>>>>
>>>> A najbardziej wkurza jak skrypt na stronie WWW zawiesza całą aplikację...
>>>>
>>>
>>> Widać że nie używasz JS. Wielowątkowość jest w tym języku i to bardzo ładnie opakowana
>>> bez kombinacji jak np w Delphi. Wielowątkowość tqorzy się sama. Trzeba mieć tego
>>> świadomość. Na przykład (pseudokod):
>>>
>>> pobieram obrazek
>>> coś z nim robię
>>>
>>> ^ powyższy kod jest błędny bo pobieranie obrazka nie zakończy się a już wywoływana
>>>  będzie instrukcja "coś z nim zrobię".
>>>
>>> Powinno być w "pobieram obrazek":
>>>
>>> obrazek.onLoad=function{
>>>   coś z nim robię  //zostanie wywołane dopiero po pobraniu obrazka
>>> }
>>
>> Ale tu mówisz nie o wielowątkowym kodzie JS. Mówisz o asynchronicznym
>> API używanym przez JS. A to ogromna różnica.
>> Sam JS nie ma żadnego wpływu na to jak i kiedy i czy w ogóle obrazek się
>> załaduje. To jest domena nawet nie silnika JS, a przeglądarki.
>>
>> Podobnie ze wszytkimi asynchronicznymi API, jak np. XmlHttpRequest.
>>
>>> Kolejna kwestia to szybkość działania JS. Od zawsze mówiło się o tym że języki
>>>  interpretowane są wolniejsze od kompilowanych.
>>> Teraz przeglądarka po wczytaniu strony dokonuje kompilacji JS i kod działa jak należy.
>>>
>>> Co do Javy- nie używam. Bo nie działa natywnie w przeglądarce :P
>>>
>>> Paweł
>>>
>>
>> --
>> Arivald
>
> Albo ja Ciebie nie rozumiem albo Ty mnie. Piszesz że JS nie ma kontroli nad tym czy obrazek się załaduje. Właśnie podałem przykład na to że ma. I jest to typowe w programowaniu w JS. Jeżeli się tego nie uwzględnia to aplikacja działa tak jak napisał to bodajże wloochacz "roszypuje się i blokuje przeglądarkę".

Formalnie rzecz biorąc to nie jest wielowątkowość.  To że przeglądarka 
ma kilka warstw i np rendering dzieje się równolegle do wykonywania 
skryptu JS to znaczy że przeglądarka jest wielowątkowa a nie samo JS.
Generalnie program w JS to w zasadzie zbiór skryptów (upraszczając mocno 
sprawę), które są wywoływane w przypadku wystąpienia określonych 
zdarzeń. Pomijając webworkery w danym momencie wykonywany jest tylko 
jeden skrypt.

> Ale tak się dzieje tylko wtedy gdy nie rozumie się wielowątkowości JS. Możesz to nazwać "asynchronicznym API" ale na jedno wychodzi: kilka czynności jest wykonywanych w tym samym czasie niezależnie.

Przeglądarka je wykonuje, i wywołuje w określonych momentach wskazane 
funkcje JS, ale zawsze jednocześnie tylko jedną.
Faktem jest że problemem może być nieokreslona kolejność nadejścia 
zdarzeń (podobnie jak w wielowątkowości) i np. będzie wywołany
wielokrotny rendering strony lub inne powtórzenia działań.
Tak czy inaczej głowną przyczyną złego działania jest zazwyczaj zła 
struktura programu a nie słaba wydajność JS.


> To w Delphi musimy stosować się do odpowiednich zabiegów żeby stwierdzić czy dany wątek zakończył się. W JS jest to proste i naturalne.
Pytanie do czego potrzebujesz wątki. Jak do obliczeń równoległych to w 
JS musisz się trochę bardziej nastarać niż w Delphi. Komunikacja z 
użytkownikiem w Windows jest dokonywana w oparciu o kolejkę komunikatów
co też jest asynchronicznym API.

--
Darek

W dniu 2016-08-27 o 15:26, Mikołaj 'Virion' Milewski pisze:
> W dniu sobota, 27 sierpnia 2016 08:40:57 UTC+2 użytkownik arivald napisał:
>
>> Ale ogólnie w standardzie ECMA praktycznie nie ma wielowątkowości, nie
>> ma współdzielenia danych, nie ma synchronizacji. Jest tylko 'webworker',
>> ale to się opiera na kompletnie odseparowanych od głównego wątku
>> silnikach, każdy ma swoje odseparowane dane, które owszem chodzą w
>> osobnych watkach, ale cała komunikacja z nimi jest tylko poprzez
>> komunikaty.
>>
>> IMO upierdliwe w użyciu.
>
> Skoro async/await robią furorę w C#, to chyba programowanie asynchroniczne
>  jest generalnie lepiej przyjmowane od sekwencyjnego - i nie bez powodu.
> Ja tam wolę użyć narzędzi typu RabbitMQ / MQTT / Rx.js / Promise (i
>  filozofii przepływu danych i kontroli, którą wprowadzają) niż rzeźbić na
>  event handlerach / delegatach / callbackach. To się po prostu sprawdza.
>  Pierwszy raz na większą skalę użyłem komunikatów (jeszcze synchronicznie)
>  właśnie w Delphi - spytaj Wloochacza, jaki jest przepływ danych w
>  kontrolce do wizualizacji Gantta u niego ;-) Systemy reaktywne są sexy,
>  bo stosunkowo łatwo je zrozumieć, łatwo się skalują i taka architektura
>  sprawdza się na wielu poziomach - i na serwerze, i na kliencie.
>  Upierdliwe? A może po prostu inne, niż przywykłeś? ;-)

Komunikatów używałem i używam, i nie to jest upierdliwe (no czasem 
jest). Event handlery / delegaty / callbacki (czyli to samo w różnych 
smakach) to oczywiście podstawa.

Upierdliwe jest odseparowanie maszyn JS w wątkach, wszystko co się 
przesyła komunikatem musi być co najmniej dwa razy skopiowane, a akurat 
zarządzanie pamięcią w JS nie jest najszybsze. A pamięci w telefonach 
nigdy za dużo.

Także serwisy ładowane do workera będą kopiami, kolejne alokacje.

Utrzymanie spójności danych globalnych to też problem - po każdej 
zmianie trzeba by wysyłać message do każdego workera który tej danej używa.


W większości języków z wielowątkowością wątki mają wspólną pamięć, to 
program dba o synchronizację. Zmienne globalne, serwisy, cache, etc bez 
duplikatów.
Przesyłać pomiędzy wątkami można wydajnie, po prostu wskaźnikami czy 
referencjami.

-- 
Arivald

W dniu 2016-08-27 o 15:54, zpksoft pisze:
> W dniu sobota, 27 sierpnia 2016 09:06:04 UTC+2 użytkownik arivald napisał:
>> W dniu 2016-08-27 o 08:46, zpksoft pisze:
>>> W dniu piątek, 26 sierpnia 2016 18:24:55 UTC+2 użytkownik arivald napisał:
>>>> A najbardziej wkurza jak skrypt na stronie WWW zawiesza całą aplikację...
>>>>
>>>
>>> Widać że nie używasz JS. Wielowątkowość jest w tym języku i to bardzo ładnie opakowana
>>> bez kombinacji jak np w Delphi. Wielowątkowość tqorzy się sama. Trzeba mieć tego
>>> świadomość. Na przykład (pseudokod):
>>>
>>> pobieram obrazek
>>> coś z nim robię
>>>
>>> ^ powyższy kod jest błędny bo pobieranie obrazka nie zakończy się a już wywoływana
>>>  będzie instrukcja "coś z nim zrobię".
>>>
>>> Powinno być w "pobieram obrazek":
>>>
>>> obrazek.onLoad=function{
>>>   coś z nim robię  //zostanie wywołane dopiero po pobraniu obrazka
>>> }
>>
>> Ale tu mówisz nie o wielowątkowym kodzie JS. Mówisz o asynchronicznym
>> API używanym przez JS. A to ogromna różnica.
>> Sam JS nie ma żadnego wpływu na to jak i kiedy i czy w ogóle obrazek się
>> załaduje. To jest domena nawet nie silnika JS, a przeglądarki.
>>
>> Podobnie ze wszytkimi asynchronicznymi API, jak np. XmlHttpRequest.
>>
>>> Kolejna kwestia to szybkość działania JS. Od zawsze mówiło się o tym że języki
>>>  interpretowane są wolniejsze od kompilowanych.
>>> Teraz przeglądarka po wczytaniu strony dokonuje kompilacji JS i kod działa jak należy.
>>>
>>> Co do Javy- nie używam. Bo nie działa natywnie w przeglądarce :P
>>>
>>> Paweł
>>>
>>
>> --
>> Arivald
>
> Albo ja Ciebie nie rozumiem albo Ty mnie. Piszesz że JS nie ma kontroli nad tym
> czy obrazek się załaduje. Właśnie podałem przykład na to że ma.

Kwestia tego co rozumiesz poprzez "ma kontrolę". W Twoim przykładzie JS 
zleca załadowania obrazka, czym dalej zajmuje się kod natywny, który 
może używać wątków (i pewnie to robi), i jak kod natywny skończy to 
informuje czy obrazek się załadował czy nie (event onload / onerror). I 
sam JS na ten proces nie ma wpływu, on jedynie zleca, i czeka na event. 
Nic więcej. A co przeglądarka naprawdę zrobi żeby załadować ten obrazek 
jest już daleko poza zasięgiem JS.

A że JS jest jednowątkowy, to tak naprawdę nie ma gwarancji kiedy JS 
obsłuży event wysłany przez przeglądarkę. Eventy, tak jak i timery JS są 
uruchamiane dopiero jak silnik JS skończy robić to co robił. Coś jak 
kolejka komunikatów w Windows. Tak samo się blokuje jak coś dłuższego 
uruchomisz.


> I jest to typowe w programowaniu w JS. Jeżeli się tego nie uwzględnia to aplikacja
> działa tak jak napisał to bodajże wloochacz "roszypuje się i blokuje przeglądarkę".
> Ale tak się dzieje tylko wtedy gdy nie rozumie się wielowątkowości JS. Możesz to
> nazwać "asynchronicznym API" ale na jedno wychodzi: kilka czynności jest wykonywanych
> w tym samym czasie niezależnie.

Co nie zmienia faktu że nie przez JavaScript, a przez kod natywny w 
przeglądarce. JS dalej pozostaje jednowątkowy. Nie rozumiem 
"wielowątkowości JS" bo nic takiego nie istnieje. Jeśli już to jest to 
multitasking, w wersji cooperative.


> To w Delphi musimy stosować się do odpowiednich zabiegów żeby stwierdzić czy
> dany wątek zakończył się. W JS jest to proste i naturalne.

Oczywiście że proste, jest tylko jeden watek, jego zakończenie to śmierć 
aplikacji ;-)

>
> I żeby nie było że dołuję Delphi. Nie. Programuję równocześnie w obu językach
>  (i nie tylko tych). Każdy ma swoje miejsce i cechy.
>
> Paweł
>

-- 
Arivald

W dniu sobota, 27 sierpnia 2016 20:17:27 UTC+2 użytkownik arivald napisał:

> Utrzymanie spójności danych globalnych to też problem - po każdej 
> zmianie trzeba by wysyłać message do każdego workera który tej danej używa.
> 
> 
> W większości języków z wielowątkowością wątki mają wspólną pamięć, to 
> program dba o synchronizację. Zmienne globalne, serwisy, cache, etc bez 
> duplikatów.
> Przesyłać pomiędzy wątkami można wydajnie, po prostu wskaźnikami czy 
> referencjami.

No i spójrzmy, do czego to prowadzi:
1. Globalne zmienne / globalny stan aplikacji - antywzorzec, który nader ciężko wybić z głowy sobie / pracownikom
2. Konieczność jawnej synchronizacji każdego współdzielenia danych między wątkami - deadlocki, bottlenecki i wszystkie tej maści ścierwa, które każdemu z nas niejedną godzinę z życia zeżarły, bo debugowanie tego to koszmar
3. Organiczny wzrost couplingu (zna ktoś jakiś zgrabny polski odpowiednik?), bo przecież łatwo i się da, to czemu nie

Myślę, że asynchroniczne podejście JSa promuje budowę software'u bardziej na zasadzie mikroserwisów, niż złożonych struktur. Separując developera od problemów, które 'starzy natywni wyjadacze' zwykli bohatersko rozwiązywać, w gruncie rzeczy ułatwia pracę. Sam w to kiedyś nie do końca wierzyłem, ale czy gdyby tak nie było, to czy ten ekosystem uzyskał by takie momentum? A swoją drogą: czy przypadkiem garbage collecting w .NETcie nie budził podobnych emocji kiedyś, gdy arytmetyka wskaźników była chlebem powszednim programistów (nie tylko jądra i sterowników)?

Żeby nie być gołosłownym, zajrzyj tutaj:

https://webtask.io

To narzędzie oferujące nic więcej ponad mikroserwisy w JS jest bazą, na której zbudowane są wszystkie usługi tej firmy - Auth0:

https://auth0.com

Ciekaw jestem, ilu programistów tej firmy w życiu użyło muteksa =)

> Arivald

-- 
Pozdrawiam,
Virion

W dniu 27.08.2016 o 08:46, zpksoft pisze:
> Co do Javy- nie używam. Bo nie działa natywnie w przeglądarce :P

Spróbuj użyć GWT lub jego odmian po szczegóły odsyłam do Google.

Ponadto przeczytałem odnogę gdzie dyskutujecie z Arivaldem i powiem 
szczerze... jestem zdziwiony... bo od kiedy można mówić o wątkach i JS 
razem... JS jest w asynchroniczne tłumacząc to łopatologiczne to jest 
pobawione wątków. Oczywiście są różne AJAXy i inne cuda na kiju ale o 
typowych wątkach jakie znamy np z Delphi trzeba zapomnieć.

Sam pamiętam swoje początki z JS i trudno mi się było przestawić z tym 
że to działa odmienie jak w językach kompilowanych

A szybkość? hm i tu kieruje słowa do autora wątku by napisał dokładnie 
co chce zrobić. Bo nie wydaje mi się by JS było za wolne jeśli tak jest 
w jego przypadku to stawiam na nie zrozumienie tematu.

Pozdrawiam

W dniu sobota, 27 sierpnia 2016 21:19:04 UTC+2 użytkownik Mikołaj 'Virion' Milewski napisał:
...> No i spójrzmy, do czego to prowadzi:
> 1. Globalne zmienne / globalny stan aplikacji - antywzorzec, który nader ciężko wybić z głowy sobie / pracownikom
...> -- 
> Pozdrawiam,
> Virion

No niekoniecznie. Jeżeli nie zna się dostatecznie JS to budujemy sobie śmietnik ze zmiennych globalnych.

W JS każdy obiekt jest tablicą i w każdej chwili możesz dodać mu nową własność, np:

jakisObiekt['nowa własność']=1234;

Jest to świetne, znakomicie upraszcza kod.

Paweł

W dniu sobota, 27 sierpnia 2016 20:33:55 UTC+2 użytkownik arivald napisał:
...> Kwestia tego co rozumiesz poprzez "ma kontrolę". W Twoim przykładzie JS 
> zleca załadowania obrazka, czym dalej zajmuje się kod natywny, który 
> może używać wątków (i pewnie to robi), i jak kod natywny skończy to 
> informuje czy obrazek się załadował czy nie (event onload / onerror). I 
> sam JS na ten proces nie ma wpływu, on jedynie zleca, i czeka na event. 
> Nic więcej. A co przeglądarka naprawdę zrobi żeby załadować ten obrazek 
> jest już daleko poza zasięgiem JS.

A po co Ci wiedzieć co robi przeglądarka ładując grafikę? Pewnie ściąga bajt po bajcie :)
To jak z API Windows. Nie wnikasz w niskopoziomowe mechanizmy bo i po co.

> 
> A że JS jest jednowątkowy, to tak naprawdę nie ma gwarancji kiedy JS 
> obsłuży event wysłany przez przeglądarkę. Eventy, tak jak i timery JS są 
> uruchamiane dopiero jak silnik JS skończy robić to co robił. Coś jak 
> kolejka komunikatów w Windows. Tak samo się blokuje jak coś dłuższego 
> uruchomisz.
> 

eee... to nie jest tak. Przeglądarka ściąga obrazek a w tym czasie kod JS wykonuje coś innego. W momencie załadowania obrazka inna część kodu JS może to zdarzenie niezależnie obsłużyć. Nic się wzajemnie nie blokuje. No, chyb, że źle to napiszesz :)

....> 
> 
> > To w Delphi musimy stosować się do odpowiednich zabiegów żeby stwierdzić czy
> > dany wątek zakończył się. W JS jest to proste i naturalne.
> 
> Oczywiście że proste, jest tylko jeden watek, jego zakończenie to śmierć 
> aplikacji ;-)

Czyżby? Jeżeli masz na myśli wątek główny to w  Delphi jest podobnie :)

> -- 
> Arivald

Paweł

W dniu sobota, 27 sierpnia 2016 23:07:40 UTC+2 użytkownik J-23 napisał:
> W dniu 27.08.2016 o 08:46, zpksoft pisze:
> > Co do Javy- nie używam. Bo nie działa natywnie w przeglądarce :P
> 
> Spróbuj użyć GWT lub jego odmian po szczegóły odsyłam do Google.

Zerknę w wolnej chwili, choć kojarzy mi się to z wczesną wersją Javy. Oczywiście teraz może to oznaczać coś innego.

> 
> Ponadto przeczytałem odnogę gdzie dyskutujecie z Arivaldem i powiem 
> szczerze... jestem zdziwiony... bo od kiedy można mówić o wątkach i JS 
> razem... JS jest w asynchroniczne tłumacząc to łopatologiczne to jest 
> pobawione wątków. Oczywiście są różne AJAXy i inne cuda na kiju ale o 
> typowych wątkach jakie znamy np z Delphi trzeba zapomnieć.
> 

Nie twierdzę że w JS mamy do czynienia z wątkami w tej funkcjonalności jaką mamy w Delphi ale podstawy są. I to tam gdzie są potrzebne. Mam na myśli czasochłonne operacje typu ładowanie obrazka. W tym czasie inny kod JS może robić coś innego więc mamy do czynienia z dwoma wątkami (w tym przypadku).


> Sam pamiętam swoje początki z JS i trudno mi się było przestawić z tym 
> że to działa odmienie jak w językach kompilowanych
> 
> A szybkość? hm i tu kieruje słowa do autora wątku by napisał dokładnie 
> co chce zrobić. Bo nie wydaje mi się by JS było za wolne jeśli tak jest 
> w jego przypadku to stawiam na nie zrozumienie tematu.
> 
> Pozdrawiam

Paweł

W dniu 2016-08-27 o 21:19, Mikołaj 'Virion' Milewski pisze:
> W dniu sobota, 27 sierpnia 2016 20:17:27 UTC+2 użytkownik arivald napisał:
>
>> Utrzymanie spójności danych globalnych to też problem - po każdej
>> zmianie trzeba by wysyłać message do każdego workera który tej danej używa.
>>
>>
>> W większości języków z wielowątkowością wątki mają wspólną pamięć, to
>> program dba o synchronizację. Zmienne globalne, serwisy, cache, etc bez
>> duplikatów.
>> Przesyłać pomiędzy wątkami można wydajnie, po prostu wskaźnikami czy
>> referencjami.
>
> No i spójrzmy, do czego to prowadzi:
> 1. Globalne zmienne / globalny stan aplikacji - antywzorzec, który nader
> ciężko wybić z głowy sobie / pracownikom

Antywzorzec, ale niezbędny. I nie mówię tu o zmiennych w globalnej 
przestrzeni nazw, globalnym scope, bo np. statyczne pola i metody w 
klasach takze są globalami.

Nadużywanie zmiennych globalnych to jest dopiero problem.


> 2. Konieczność jawnej synchronizacji każdego współdzielenia danych między
> wątkami - deadlocki, bottlenecki i wszystkie tej maści ścierwa, które
> każdemu z nas niejedną godzinę z życia zeżarły, bo debugowanie tego to koszmar

E, jaki tam koszmar. Wystarczy parę zasad (dane są albo stałe, każdy 
wątek może czytać, albo dane należą do danego wątku i tylko on może je 
czytać i zmieniać, używać odpowiednich mechanizmów do przesyłania danych 
z wątku do wątku), i problemy znikają.


> 3. Organiczny wzrost couplingu (zna ktoś jakiś zgrabny polski odpowiednik?),
> bo przecież łatwo i się da, to czemu nie

IMO sprzęganie.

Naprawdę nie widzę czemu akurat wielowątkowość ma na to jakiś wpływ.
To raczej zależy od zadań i architektury aplikacji. Wystarczy zastosować 
pośrednika, np kontener IOC, do komunikacji jakiś szyna komunikatów albo 
slot-signal, etc., żeby osiągnąć luźne sprzeganie komponentów.


> Myślę, że asynchroniczne podejście JSa promuje budowę software'u bardziej
> na zasadzie mikroserwisów, niż złożonych struktur.

Owo "asynchroniczne podejście JSa" jest wymuszone przez jego 
jednowątkowość. I nie jest to tyle podejście JS co podejście API których 
z JS się używa, żeby zapewnić w płynne działanie aplikacji.

Dokładnie tak samo da się sterować aplikacją w każdym języku.
Np kolejka komunikatów w Windows (i w wielu innych) jest bardzo podobnym 
rozwiązaniem, zamiast eventów JS są komunikaty.


> Separując developera od
> problemów, które 'starzy natywni wyjadacze' zwykli bohatersko rozwiązywać,
> w gruncie rzeczy ułatwia pracę. Sam w to kiedyś nie do końca wierzyłem,
> ale czy gdyby tak nie było, to czy ten ekosystem uzyskał by takie momentum?

IMO to jest związane raczej z rosnącym znaczeniem, ilością i 
skomplikowaniem aplikacji przeglądarkowych.
JS ma swoje nisze i zastosowania, ale nie jest to język na którym 
bazował bym aplikację.

-- 
Arivald

W dniu 2016-08-28 o 09:29, zpksoft pisze:
 > W dniu sobota, 27 sierpnia 2016 20:33:55 UTC+2 użytkownik arivald 
napisał:
 > ...> Kwestia tego co rozumiesz poprzez "ma kontrolę". W Twoim 
przykładzie JS
 >> zleca załadowania obrazka, czym dalej zajmuje się kod natywny, który
 >> może używać wątków (i pewnie to robi), i jak kod natywny skończy to
 >> informuje czy obrazek się załadował czy nie (event onload / onerror). I
 >> sam JS na ten proces nie ma wpływu, on jedynie zleca, i czeka na event.
 >> Nic więcej. A co przeglądarka naprawdę zrobi żeby załadować ten obrazek
 >> jest już daleko poza zasięgiem JS.
 >
 > A po co Ci wiedzieć co robi przeglądarka ładując grafikę? Pewnie ściąga
 > bajt po bajcie :)
 > To jak z API Windows. Nie wnikasz w niskopoziomowe mechanizmy bo i po co.
 >
 >>
 >> A że JS jest jednowątkowy, to tak naprawdę nie ma gwarancji kiedy JS
 >> obsłuży event wysłany przez przeglądarkę. Eventy, tak jak i timery 
JS są
 >> uruchamiane dopiero jak silnik JS skończy robić to co robił. Coś jak
 >> kolejka komunikatów w Windows. Tak samo się blokuje jak coś dłuższego
 >> uruchomisz.
 >>
 >
 > eee... to nie jest tak. Przeglądarka ściąga obrazek a w tym czasie kod
 > JS wykonuje coś innego.

Dokładnie. Dokładnie tak jak opisałem.
Co nie znaczy że JS jest wielowątkowy bo "w tym czasie kod JS wykonuje 
coś innego". To przeglądarka jest wielowątkowa.


 > W momencie załadowania obrazka inna część kodu
 > JS może to zdarzenie niezależnie obsłużyć. Nic się wzajemnie nie 
blokuje.
 > No, chyb, że źle to napiszesz :)
 >
 > ....>
 >>
 >>> To w Delphi musimy stosować się do odpowiednich zabiegów żeby 
stwierdzić czy
 >>> dany wątek zakończył się. W JS jest to proste i naturalne.
 >>
 >> Oczywiście że proste, jest tylko jeden watek, jego zakończenie to 
śmierć
 >> aplikacji ;-)
 >
 > Czyżby? Jeżeli masz na myśli wątek główny to w  Delphi jest podobnie :)

O, to ci się wydaje.
Aplikacja może spokojnie przetrwać zabicie wątku głównego. Szczególnie 
aplikacja bez VCLowego UI, pompę komunikatów można w dowolnym wątku 
uruchomić.
To VCL, i ogólnie RTL Delphi zakłada że UI będzie działać w wątku 
głównym, i owszem, obsługa UI bez tego wątku jest kłopotliwa.

-- 
Arivald

Zgadza się, ale taki śmietnik robi każdy newbie w każdym języku. Mi chodziło raczej o brak stanów globalnych przy przetwarzaniu równoległym - bo tego Arivald broni. Gdyby zawsze robić "klasyczne" wątki polegające na stanach globalnych, map/reduce by nie powstało... Takie podejście się po prostu nie daje łatwo skalować.

-- 
Pozdrawiam,
Virion

W dniu niedziela, 28 sierpnia 2016 13:37:35 UTC+2 użytkownik arivald napisał:
> W dniu 2016-08-28 o 09:29, zpksoft pisze:
>  >
>  > eee... to nie jest tak. Przeglądarka ściąga obrazek a w tym czasie kod
>  > JS wykonuje coś innego.
> 
> Dokładnie. Dokładnie tak jak opisałem.
> Co nie znaczy że JS jest wielowątkowy bo "w tym czasie kod JS wykonuje 
> coś innego". To przeglądarka jest wielowątkowa.
> 
> -- 
> Arivald

I co to zmienia? Fakt jest faktem: wątki są ;)

Paweł

W dniu niedziela, 28 sierpnia 2016 13:25:47 UTC+2 użytkownik arivald napisał:

> Antywzorzec, ale niezbędny. I nie mówię tu o zmiennych w globalnej 
> przestrzeni nazw, globalnym scope, bo np. statyczne pola i metody w 
> klasach takze są globalami.
> 
> Nadużywanie zmiennych globalnych to jest dopiero problem.

W aplikacji powinna być jeden obiekt globalny: główny kontener IoC. Inne stany globalne są czasem nie do uniknięcia, zwykle z powodu "kodu trzeciego", ale zawsze jakiś kotek ginie, gdy wprowadzasz nową zmienną globalną... ;-)

> E, jaki tam koszmar. Wystarczy parę zasad (dane są albo stałe, każdy 
> wątek może czytać, albo dane należą do danego wątku i tylko on może je 
> czytać i zmieniać, używać odpowiednich mechanizmów do przesyłania danych 
> z wątku do wątku), i problemy znikają.

Kto nigdy nie miał deadlocka, niech rzuci kamieniem.

Rzecz jest jeszcze taka, że przyswojenie sobie tych zasad i ich dobre zrozumienie zajmuje zwykle parę lat - lat, w których młody programista JS jest już bardziej produktywny.

> IMO sprzęganie.

Dzięki :-)

> Naprawdę nie widzę czemu akurat wielowątkowość ma na to jakiś wpływ.
> To raczej zależy od zadań i architektury aplikacji. Wystarczy zastosować 
> pośrednika, np kontener IOC, do komunikacji jakiś szyna komunikatów albo 
> slot-signal, etc., żeby osiągnąć luźne sprzeganie komponentów.

I znów - trzeba to sobie przyswoić, bo platforma zezwala na znaczne nadużycia.

> Owo "asynchroniczne podejście JSa" jest wymuszone przez jego 
> jednowątkowość. I nie jest to tyle podejście JS co podejście API których 
> z JS się używa, żeby zapewnić w płynne działanie aplikacji.
> 
> Dokładnie tak samo da się sterować aplikacją w każdym języku.
> Np kolejka komunikatów w Windows (i w wielu innych) jest bardzo podobnym 
> rozwiązaniem, zamiast eventów JS są komunikaty.

Jasne. Ale, czy widziałeś kod reaktywny w Delphi? Da się wszystko, ale platforma zachęca lub zniechęca. Wyszedłszy od jednowątkowych skryptów dla weba, rynek doszedł do szerokiego rozpropagowania programowania asynchronicznego i reaktywnego. Język jest paskudny (moja opinia), ale ekosystem robi wrażenie i jestem pewien, że jeszcze nie raz pozytywnie zaskoczy.

> IMO to jest związane raczej z rosnącym znaczeniem, ilością i 
> skomplikowaniem aplikacji przeglądarkowych.
> JS ma swoje nisze i zastosowania, ale nie jest to język na którym 
> bazował bym aplikację.

Ja też nie, dlatego dzięki niech będą Hejlsbergowi za TypeScripta!

> Arivald

-- 
Pozdrawiam,
Virion

W dniu 28.08.2016 o 09:35, zpksoft pisze:
> W dniu sobota, 27 sierpnia 2016 23:07:40 UTC+2 użytkownik J-23 napisał:
>> W dniu 27.08.2016 o 08:46, zpksoft pisze:
>>> Co do Javy- nie używam. Bo nie działa natywnie w przeglądarce :P
>>
>> Spróbuj użyć GWT lub jego odmian po szczegóły odsyłam do Google.
>
> Zerknę w wolnej chwili, choć kojarzy mi się to z wczesną wersją Javy. Oczywiście teraz może to oznaczać coś innego.
>
>>
>> Ponadto przeczytałem odnogę gdzie dyskutujecie z Arivaldem i powiem
>> szczerze... jestem zdziwiony... bo od kiedy można mówić o wątkach i JS
>> razem... JS jest w asynchroniczne tłumacząc to łopatologiczne to jest
>> pobawione wątków. Oczywiście są różne AJAXy i inne cuda na kiju ale o
>> typowych wątkach jakie znamy np z Delphi trzeba zapomnieć.
>>
>
> Nie twierdzę że w JS mamy do czynienia z wątkami w tej funkcjonalności jaką mamy w Delphi ale podstawy są. I to tam gdzie są potrzebne. Mam na myśli czasochłonne operacje typu ładowanie obrazka. W tym czasie inny kod JS może robić coś innego więc mamy do czynienia z dwoma wątkami (w tym przypadku).
>
>

Może uporządkujmy to co masz w JS nazwijmy stroną Klienta czyli wszystko 
to co masz już w przeglądarce w postaci JS

To co pobiera obrazek jest stroną Serwera tutaj moża stosować wątki 
łączyć się z bazą itp. Ale zauważ że to nie ma nic wspólnego z JS


- obrazek za nim zostanie wyświetlony po stronie JS musi po stronie 
serwera zostać pobrany.

To co opisujesz nie jest wielowątkowością. Zapytania asynchroniczne 
owszem możesz wysłać kilka ale nie masz pewności które się przetworzy 
pierwsze. TO NIE MA NIC WSPÓLNEGO Z WĄTKAMI. (A przynajmniej nie tak jak 
ty to widzisz)

Można oczywiście się bawić w kolejkę takich zapytań asynchronicznych by 
się to wykonywało jedno po drugim ale w 99% jest to zła droga

Pozdrawiam

W dniu niedziela, 28 sierpnia 2016 17:08:52 UTC+2 użytkownik J-23 napisał:
> W dniu 28.08.2016 o 09:35, zpksoft pisze:
> > W dniu sobota, 27 sierpnia 2016 23:07:40 UTC+2 użytkownik J-23 napisał:
> >> W dniu 27.08.2016 o 08:46, zpksoft pisze:
> >>> Co do Javy- nie używam. Bo nie działa natywnie w przeglądarce :P
> >>
> >> Spróbuj użyć GWT lub jego odmian po szczegóły odsyłam do Google.
> >
> > Zerknę w wolnej chwili, choć kojarzy mi się to z wczesną wersją Javy. Oczywiście teraz może to oznaczać coś innego.
> >
> >>
> >> Ponadto przeczytałem odnogę gdzie dyskutujecie z Arivaldem i powiem
> >> szczerze... jestem zdziwiony... bo od kiedy można mówić o wątkach i JS
> >> razem... JS jest w asynchroniczne tłumacząc to łopatologiczne to jest
> >> pobawione wątków. Oczywiście są różne AJAXy i inne cuda na kiju ale o
> >> typowych wątkach jakie znamy np z Delphi trzeba zapomnieć.
> >>
> >
> > Nie twierdzę że w JS mamy do czynienia z wątkami w tej funkcjonalności jaką mamy w Delphi ale podstawy są. I to tam gdzie są potrzebne. Mam na myśli czasochłonne operacje typu ładowanie obrazka. W tym czasie inny kod JS może robić coś innego więc mamy do czynienia z dwoma wątkami (w tym przypadku).
> >
> >
> 
> Może uporządkujmy to co masz w JS nazwijmy stroną Klienta czyli wszystko 
> to co masz już w przeglądarce w postaci JS
> 
> To co pobiera obrazek jest stroną Serwera tutaj moża stosować wątki 
> łączyć się z bazą itp. Ale zauważ że to nie ma nic wspólnego z JS
> 

Pobranie obrazka podałem jako przykład operacji przebiegającej współbieżnie z innym kodem (jeśli tak zaprogramujemy). Mogą to być inne operacje niekoniecznie odwołujące się do serwera.

> 
> - obrazek za nim zostanie wyświetlony po stronie JS musi po stronie 
> serwera zostać pobrany.
> 

No. Genialne. A jeśli nie pochodzi z serwera tylko został utworzony po stronie przeglądarki?

> To co opisujesz nie jest wielowątkowością. Zapytania asynchroniczne 
> owszem możesz wysłać kilka ale nie masz pewności które się przetworzy 
> pierwsze. TO NIE MA NIC WSPÓLNEGO Z WĄTKAMI. (A przynajmniej nie tak jak 
> ty to widzisz)
> 

Pewności do tego co będzie pierwsze nie mam. Ale wiem kiedy się zakończy. Mogę też kontrolować cały proces ale to ma znikomy sens. 
Wielowątkowość ma to do siebie, że procesy przetwarzania danych przebiegają równolegle więc w wątkach obsługiwanych w Delphi jeżeli je uruchomisz samopas, bez kontroli przebiegu, również nie możesz na pewno stwierdzić w jakiej kolejności się zakończą. Mam wrażenie że sam sobie zaprzeczasz.

> Można oczywiście się bawić w kolejkę takich zapytań asynchronicznych by 
> się to wykonywało jedno po drugim ale w 99% jest to zła droga
> 

A po co ta kolejka? Nikt tu o niej nie wspominał więc nie wytykaj że jest to zła droga.

> Pozdrawiam

Paweł

W dniu 28.08.2016 o 21:12, zpksoft pisze:
> W dniu niedziela, 28 sierpnia 2016 17:08:52 UTC+2 użytkownik J-23 napisał:
>> W dniu 28.08.2016 o 09:35, zpksoft pisze:
>>> W dniu sobota, 27 sierpnia 2016 23:07:40 UTC+2 użytkownik J-23 napisał:
>>>> W dniu 27.08.2016 o 08:46, zpksoft pisze:
>>>>> Co do Javy- nie używam. Bo nie działa natywnie w przeglądarce :P
>>>>
>>>> Spróbuj użyć GWT lub jego odmian po szczegóły odsyłam do Google.
>>>
>>> Zerknę w wolnej chwili, choć kojarzy mi się to z wczesną wersją Javy. Oczywiście teraz może to oznaczać coś innego.
>>>
>>>>
>>>> Ponadto przeczytałem odnogę gdzie dyskutujecie z Arivaldem i powiem
>>>> szczerze... jestem zdziwiony... bo od kiedy można mówić o wątkach i JS
>>>> razem... JS jest w asynchroniczne tłumacząc to łopatologiczne to jest
>>>> pobawione wątków. Oczywiście są różne AJAXy i inne cuda na kiju ale o
>>>> typowych wątkach jakie znamy np z Delphi trzeba zapomnieć.
>>>>
>>>
>>> Nie twierdzę że w JS mamy do czynienia z wątkami w tej funkcjonalności jaką mamy w Delphi ale podstawy są. I to tam gdzie są potrzebne. Mam na myśli czasochłonne operacje typu ładowanie obrazka. W tym czasie inny kod JS może robić coś innego więc mamy do czynienia z dwoma wątkami (w tym przypadku).
>>>
>>>
>>
>> Może uporządkujmy to co masz w JS nazwijmy stroną Klienta czyli wszystko
>> to co masz już w przeglądarce w postaci JS
>>
>> To co pobiera obrazek jest stroną Serwera tutaj moża stosować wątki
>> łączyć się z bazą itp. Ale zauważ że to nie ma nic wspólnego z JS
>>
>
> Pobranie obrazka podałem jako przykład operacji przebiegającej współbieżnie z innym kodem (jeśli tak zaprogramujemy). Mogą to być inne operacje niekoniecznie odwołujące się do serwera.
>

OK, ja tylko skomentowałem twój przykład...

>>
>> - obrazek za nim zostanie wyświetlony po stronie JS musi po stronie
>> serwera zostać pobrany.
>>
>
> No. Genialne. A jeśli nie pochodzi z serwera tylko został utworzony po stronie przeglądarki?
>

To nadal jest jednowątkowe. W Delphi też można odpalić kilka rzeczy w 
jędnym wątku.


>> To co opisujesz nie jest wielowątkowością. Zapytania asynchroniczne
>> owszem możesz wysłać kilka ale nie masz pewności które się przetworzy
>> pierwsze. TO NIE MA NIC WSPÓLNEGO Z WĄTKAMI. (A przynajmniej nie tak jak
>> ty to widzisz)
>>
>
> Pewności do tego co będzie pierwsze nie mam. Ale wiem kiedy się zakończy. Mogę też kontrolować cały proces ale to ma znikomy sens.
> Wielowątkowość ma to do siebie, że procesy przetwarzania danych przebiegają równolegle więc w wątkach obsługiwanych w Delphi jeżeli je uruchomisz samopas, bez kontroli przebiegu, również nie możesz na pewno stwierdzić w jakiej kolejności się zakończą. Mam wrażenie że sam sobie zaprzeczasz.
>
Dokładnie tak jak to napisałeś "równolegle" problem w JS jest tego typu 
że tego się nie da zrobić jeśli puścisz x zapytań asynchronicznych to 
zawsze będzie różnica w czasie ich startu. Powód jeszcze nie wymyślili 
przeglądarek wielowątkowych o tym pisał Ci też Arivald ale ty uparcie 
stoisz przy swoim. Ja by nie być jednostrpnym poproszę Cię o znalezienie 
informacji że JS działa w wątkach.

>> Można oczywiście się bawić w kolejkę takich zapytań asynchronicznych by
>> się to wykonywało jedno po drugim ale w 99% jest to zła droga
>>
>
> A po co ta kolejka? Nikt tu o niej nie wspominał więc nie wytykaj że jest to zła droga.
>

Wspomniałem o kolejce bo taką kolejkę się robi by zasymilować 
wielowątkowość jednak jak wspomniałem jest to zła droga.

A wspomniałem dlatego że widziałem ja wielokrotnie w JS
Właśnie ap-ropo pseudo wątków


Pozdrawiam

W dniu niedziela, 28 sierpnia 2016 23:24:24 UTC+2 użytkownik J-23 napisał:
.....
> W Delphi też można odpalić kilka rzeczy w 
> jędnym wątku.
>

Tak? ciekawe. Bardzo proszę o prosty przykład.
 
> Dokładnie tak jak to napisałeś "równolegle" problem w JS jest tego typu 
> że tego się nie da zrobić jeśli puścisz x zapytań asynchronicznych to 
> zawsze będzie różnica w czasie ich startu. Powód jeszcze nie wymyślili 
> przeglądarek wielowątkowych o tym pisał Ci też Arivald ale ty uparcie 
> stoisz przy swoim. Ja by nie być jednostrpnym poproszę Cię o znalezienie 
> informacji że JS działa w wątkach.
> 

Mam świadomość różnic. Ale funkcjonalnie dla mnie nie ma żadnego znaczenia czy inny kod działa w odrębnym wątku czy "równolegle" (cokolwiek by to oznaczało). Ważne jest dla mnie że różne operacje są wykonywane w tym samym czasie. I w tym znaczeniu JS jest dla mnie wielowątkowe.
Bardzo prosto możemy tworzyć własne zdarzenia i je odpalać. A jak będą realizować swój kod to w tym samym czasie możemy realizować inny kod.
Poczytaj sobie: https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Creating_and_triggering_events

.....> 
> 
> Pozdrawiam

Paweł

W dniu 29.08.2016 o 07:58, zpksoft pisze:
> W dniu niedziela, 28 sierpnia 2016 23:24:24 UTC+2 użytkownik J-23 napisał:
> .....
>> W Delphi też można odpalić kilka rzeczy w
>> jędnym wątku.
>>
>
> Tak? ciekawe. Bardzo proszę o prosty przykład.
>

puść sobie dwie pętle for... (Prostszego zadania nie ma) i one to że są 
dwie nie znaczy że funkcjonują w osobnych wątkach.

>> Dokładnie tak jak to napisałeś "równolegle" problem w JS jest tego typu
>> że tego się nie da zrobić jeśli puścisz x zapytań asynchronicznych to
>> zawsze będzie różnica w czasie ich startu. Powód jeszcze nie wymyślili
>> przeglądarek wielowątkowych o tym pisał Ci też Arivald ale ty uparcie
>> stoisz przy swoim. Ja by nie być jednostrpnym poproszę Cię o znalezienie
>> informacji że JS działa w wątkach.
>>
>
> Mam świadomość różnic. Ale funkcjonalnie dla mnie nie ma żadnego znaczenia czy inny kod działa w odrębnym wątku czy "równolegle" (cokolwiek by to oznaczało). Ważne jest dla mnie że różne operacje są wykonywane w tym samym czasie. I w tym znaczeniu JS jest dla mnie wielowątkowe.
> Bardzo prosto możemy tworzyć własne zdarzenia i je odpalać. A jak będą realizować swój kod to w tym samym czasie możemy realizować inny kod.
> Poczytaj sobie: https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Creating_and_triggering_events
>

To jest zupełnie co innego i nie ma nic wspólnego z wątkami. Tobie to 
wystarcza i OK ale to nie są wątki. Nie myl pojęć.

Chcesz wątki w JS spróbuj tego.
https://html.spec.whatwg.org/multipage/workers.html#workers

Osobiście nie miałem potrzeby używania tego.

Pomimo linka którego Ci podałem nie zmienia to faktu że JS natywnie jest 
jednowątkowa.

Pozdrawiam

W dniu poniedziałek, 29 sierpnia 2016 12:17:07 UTC+2 użytkownik J-23 napisał:
> W dniu 29.08.2016 o 07:58, zpksoft pisze:
> > W dniu niedziela, 28 sierpnia 2016 23:24:24 UTC+2 użytkownik J-23 napisał:
> > .....
> >> W Delphi też można odpalić kilka rzeczy w
> >> jędnym wątku.
> >>
> >
> > Tak? ciekawe. Bardzo proszę o prosty przykład.
> >
> 
> puść sobie dwie pętle for... (Prostszego zadania nie ma) i one to że są 
> dwie nie znaczy że funkcjonują w osobnych wątkach.

No ale gdzie tu jest współbieżność?
Pytam serio. Jeśli masz wiedzę na ten temat to podziel się nią i nie wstawiaj mi kitu. 

...>
> Pozdrawiam

Paweł

W dniu poniedziałek, 29 sierpnia 2016 12:17:07 UTC+2 użytkownik J-23 napisał:
......> 
> To jest zupełnie co innego i nie ma nic wspólnego z wątkami. Tobie to 
> wystarcza i OK ale to nie są wątki. Nie myl pojęć.
> 
> Chcesz wątki w JS spróbuj tego.
> https://html.spec.whatwg.org/multipage/workers.html#workers
> 
> Osobiście nie miałem potrzeby używania tego.
> 
...> 
> Pozdrawiam

OK, rzuciłem na to okiem. To jest artykuł o gadaniu okien między sobą a nie wielowątkowości [w tym samym oknie].

Paweł

W dniu 29.08.2016 o 17:10, zpksoft pisze:
> W dniu poniedziałek, 29 sierpnia 2016 12:17:07 UTC+2 użytkownik J-23 napisał:
> ......>
>> To jest zupełnie co innego i nie ma nic wspólnego z wątkami. Tobie to
>> wystarcza i OK ale to nie są wątki. Nie myl pojęć.
>>
>> Chcesz wątki w JS spróbuj tego.
>> https://html.spec.whatwg.org/multipage/workers.html#workers
>>
>> Osobiście nie miałem potrzeby używania tego.
>>
> ...>
>> Pozdrawiam
>
> OK, rzuciłem na to okiem. To jest artykuł o gadaniu okien między sobą a nie wielowątkowości [w tym samym oknie].
>

Nawet Ci się nie chciało zrozumieć o co chodzi, Słowo Kluczowe to Web 
Workers który podobno zapewnia wielowątkowość po stronie JS. Jak to 
działa nie wiem nie używałem ale może warto sprawdzić


https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers

ty masz odrobinę po polsku:
http://blog.kamilbrenk.pl/web-workers-wielowatkowosc-w-javascript/

Co do kodu od Delphi wróć się do tematu wątków jeszcze raz a będziesz 
wiedział co mam na myśli z pętlami.

Pozdrawiam

W dniu poniedziałek, 29 sierpnia 2016 18:08:18 UTC+2 użytkownik J-23 napisał:
> W dniu 29.08.2016 o 17:10, zpksoft pisze:
> > W dniu poniedziałek, 29 sierpnia 2016 12:17:07 UTC+2 użytkownik J-23 napisał:
> > ......>
> >> To jest zupełnie co innego i nie ma nic wspólnego z wątkami. Tobie to
> >> wystarcza i OK ale to nie są wątki. Nie myl pojęć.
> >>
> >> Chcesz wątki w JS spróbuj tego.
> >> https://html.spec.whatwg.org/multipage/workers.html#workers
> >>
> >> Osobiście nie miałem potrzeby używania tego.
> >>
> > ...>
> >> Pozdrawiam
> >
> > OK, rzuciłem na to okiem. To jest artykuł o gadaniu okien między sobą a nie wielowątkowości [w tym samym oknie].
> >
> 
> Nawet Ci się nie chciało zrozumieć o co chodzi, Słowo Kluczowe to Web 
> Workers który podobno zapewnia wielowątkowość po stronie JS. Jak to 
> działa nie wiem nie używałem ale może warto sprawdzić
> 

Ależ rozumiem. Tworzone jest nowe okno z założeniem, że żyje własnym życiem, czyli we własnym wątku. Z tym oknem możemy komunikować się przez postMessage. I tyle magii.


> 
> https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers
> 
> ty masz odrobinę po polsku:
> http://blog.kamilbrenk.pl/web-workers-wielowatkowosc-w-javascript/
> 
> Co do kodu od Delphi wróć się do tematu wątków jeszcze raz a będziesz 
> wiedział co mam na myśli z pętlami.

Jednak nie rozumiem gdzie w modelu "pętla w pętli" lob "pętla obok pętli" jest współbieżność. Poproszę jednak o przykład. Może być pseudokod. 

> 
> Pozdrawiam

Paweł

W dniu 2016-08-29 o 19:37, zpksoft pisze:
> W dniu poniedziałek, 29 sierpnia 2016 18:08:18 UTC+2 użytkownik J-23 napisał:
>> W dniu 29.08.2016 o 17:10, zpksoft pisze:
>>> W dniu poniedziałek, 29 sierpnia 2016 12:17:07 UTC+2 użytkownik J-23 napisał:
>>> ......>
>>>> To jest zupełnie co innego i nie ma nic wspólnego z wątkami. Tobie to
>>>> wystarcza i OK ale to nie są wątki. Nie myl pojęć.
>>>>
>>>> Chcesz wątki w JS spróbuj tego.
>>>> https://html.spec.whatwg.org/multipage/workers.html#workers
>>>>
>>>> Osobiście nie miałem potrzeby używania tego.
>>>>
>>> ...>
>>>> Pozdrawiam
>>>
>>> OK, rzuciłem na to okiem. To jest artykuł o gadaniu okien między sobą
> a nie wielowątkowości [w tym samym oknie].
>>>
>>
>> Nawet Ci się nie chciało zrozumieć o co chodzi, Słowo Kluczowe to Web
>> Workers który podobno zapewnia wielowątkowość po stronie JS. Jak to
>> działa nie wiem nie używałem ale może warto sprawdzić
>>
>
> Ależ rozumiem. Tworzone jest nowe okno z założeniem, że żyje własnym
> życiem, czyli we własnym wątku. Z tym oknem możemy komunikować się
> przez postMessage. I tyle magii.

Wow, to naprawdę zadziwiające, jak bardzo można nie zrozumieć tekstu.

Jakie "nowe okno"?
Nowa kopia silnika JS, bez żadnego okna, działająca w osobnym wątku.
I owszem, komunikacja poprzez messages.

Drugi artykuł z MDN wręcz jawnie mówi że "window" jest niedostępne dla 
kodu w workerze.

-- 
Arivald

W dniu 29.08.2016 o 21:30, arivald pisze:
> W dniu 2016-08-29 o 19:37, zpksoft pisze:
>> W dniu poniedziałek, 29 sierpnia 2016 18:08:18 UTC+2 użytkownik J-23
>> napisał:
>>> W dniu 29.08.2016 o 17:10, zpksoft pisze:
>>>> W dniu poniedziałek, 29 sierpnia 2016 12:17:07 UTC+2 użytkownik J-23
>>>> napisał:
>>>> ......>
>>>>> To jest zupełnie co innego i nie ma nic wspólnego z wątkami. Tobie to
>>>>> wystarcza i OK ale to nie są wątki. Nie myl pojęć.
>>>>>
>>>>> Chcesz wątki w JS spróbuj tego.
>>>>> https://html.spec.whatwg.org/multipage/workers.html#workers
>>>>>
>>>>> Osobiście nie miałem potrzeby używania tego.
>>>>>
>>>> ...>
>>>>> Pozdrawiam
>>>>
>>>> OK, rzuciłem na to okiem. To jest artykuł o gadaniu okien między sobą
>> a nie wielowątkowości [w tym samym oknie].
>>>>
>>>
>>> Nawet Ci się nie chciało zrozumieć o co chodzi, Słowo Kluczowe to Web
>>> Workers który podobno zapewnia wielowątkowość po stronie JS. Jak to
>>> działa nie wiem nie używałem ale może warto sprawdzić
>>>
>>
>> Ależ rozumiem. Tworzone jest nowe okno z założeniem, że żyje własnym
>> życiem, czyli we własnym wątku. Z tym oknem możemy komunikować się
>> przez postMessage. I tyle magii.
>
> Wow, to naprawdę zadziwiające, jak bardzo można nie zrozumieć tekstu.
>
> Jakie "nowe okno"?
> Nowa kopia silnika JS, bez żadnego okna, działająca w osobnym wątku.
> I owszem, komunikacja poprzez messages.
>
> Drugi artykuł z MDN wręcz jawnie mówi że "window" jest niedostępne dla
> kodu w workerze.
>

Arivald też się dziwie, ale cóż zrobić są ludzie i ludzika. Jak widać 
Paweł ma problem z czytaniem. Wcale się nie dziwie że nie zrozumiał 
tekstu skoro w rodzimym języku (a przynajmniej tak zakładam) nie rozumie 
tekstu "JS jest jednowątkowa" to co tu wymagać?

Pozdrawiam

W dniu 29.08.2016 o 12:17, J-23 pisze:
> W dniu 29.08.2016 o 07:58, zpksoft pisze:
>> W dniu niedziela, 28 sierpnia 2016 23:24:24 UTC+2 użytkownik J-23
>> napisał:
>> .....
>>> W Delphi też można odpalić kilka rzeczy w
>>> jędnym wątku.
>>>
>>
>> Tak? ciekawe. Bardzo proszę o prosty przykład.
>>

Specjalnie odpisuje w tej odnodze by udowodnić Ci że czytać ze 
zrozumieniem nie potrafisz. Ja napisałem tylko tyle cytuje "
To nadal jest jednowątkowe. W Delphi też można odpalić kilka rzeczy w 
jednym wątku." (Sprawdź cytaty by nie było że coś zmanipulowałem)

Jak widzisz to zdanie mówi tylko o tym że w jednym wątku da się odpalić 
kilka rzeczy i to jest PRAWDA!!! Nigdzie nie wspomniałem jak zostanie to 
wykonane. Ty błędnie założyłeś że to się wykona razem. Dałem Ci porosty 
przykład z pętlami gdzie nawet nie potrafiłeś pokazać jak to się wykona 
że owszem będzie w jednym wątku, dwie operacje, które się wykonają jedna 
po drugiej.

Widząc Twoją nieporadność odsyłałem Cię do materiału o wątkach.

Na przyszłość czytaj spokojniej, wolniej i przeczytaj dwa razy czy 
rozumiesz co czytasz.

Bo ewidentne po Twoich postach widać że tak nie jest (Nie rozumiesz co 
czytasz) a jak ktoś Ci coś doradza to go ewidentnie nie słuchasz.

Pozdrawiam

W dniu poniedziałek, 29 sierpnia 2016 21:30:44 UTC+2 użytkownik arivald napisał:
> W dniu 2016-08-29 o 19:37, zpksoft pisze:
> > W dniu poniedziałek, 29 sierpnia 2016 18:08:18 UTC+2 użytkownik J-23 napisał:
> >> W dniu 29.08.2016 o 17:10, zpksoft pisze:
> >>> W dniu poniedziałek, 29 sierpnia 2016 12:17:07 UTC+2 użytkownik J-23 napisał:
> >>> ......>
> >>>> To jest zupełnie co innego i nie ma nic wspólnego z wątkami. Tobie to
> >>>> wystarcza i OK ale to nie są wątki. Nie myl pojęć.
> >>>>
> >>>> Chcesz wątki w JS spróbuj tego.
> >>>> https://html.spec.whatwg.org/multipage/workers.html#workers
> >>>>
> >>>> Osobiście nie miałem potrzeby używania tego.
> >>>>
> >>> ...>
> >>>> Pozdrawiam
> >>>
> >>> OK, rzuciłem na to okiem. To jest artykuł o gadaniu okien między sobą
> > a nie wielowątkowości [w tym samym oknie].
> >>>
> >>
> >> Nawet Ci się nie chciało zrozumieć o co chodzi, Słowo Kluczowe to Web
> >> Workers który podobno zapewnia wielowątkowość po stronie JS. Jak to
> >> działa nie wiem nie używałem ale może warto sprawdzić
> >>
> >
> > Ależ rozumiem. Tworzone jest nowe okno z założeniem, że żyje własnym
> > życiem, czyli we własnym wątku. Z tym oknem możemy komunikować się
> > przez postMessage. I tyle magii.
> 
> Wow, to naprawdę zadziwiające, jak bardzo można nie zrozumieć tekstu.
> 
> Jakie "nowe okno"?
> Nowa kopia silnika JS, bez żadnego okna, działająca w osobnym wątku.
> I owszem, komunikacja poprzez messages.
> 
> Drugi artykuł z MDN wręcz jawnie mówi że "window" jest niedostępne dla 
> kodu w workerze.
> 
> -- 
> Arivald

Hehe, bo nie czytałem. Tylko rzuciłem okiem. Stąd jak się okazuje mylne wnioski. Nie interesuje mnie to rozwiązanie więc szkoda mi poświęcać na to czasu.

Paweł

W dniu poniedziałek, 29 sierpnia 2016 23:14:39 UTC+2 użytkownik J-23 napisał:
> W dniu 29.08.2016 o 12:17, J-23 pisze:
> > W dniu 29.08.2016 o 07:58, zpksoft pisze:
> >> W dniu niedziela, 28 sierpnia 2016 23:24:24 UTC+2 użytkownik J-23
> >> napisał:
> >> .....
> >>> W Delphi też można odpalić kilka rzeczy w
> >>> jędnym wątku.
> >>>
> >>
> >> Tak? ciekawe. Bardzo proszę o prosty przykład.
> >>
> 
> Specjalnie odpisuje w tej odnodze by udowodnić Ci że czytać ze 
> zrozumieniem nie potrafisz. Ja napisałem tylko tyle cytuje "
> To nadal jest jednowątkowe. W Delphi też można odpalić kilka rzeczy w 
> jednym wątku." (Sprawdź cytaty by nie było że coś zmanipulowałem)
> 
> Jak widzisz to zdanie mówi tylko o tym że w jednym wątku da się odpalić 
> kilka rzeczy i to jest PRAWDA!!! Nigdzie nie wspomniałem jak zostanie to 
> wykonane. Ty błędnie założyłeś że to się wykona razem. Dałem Ci porosty 
> przykład z pętlami gdzie nawet nie potrafiłeś pokazać jak to się wykona 
> że owszem będzie w jednym wątku, dwie operacje, które się wykonają jedna 
> po drugiej.
> 
> Widząc Twoją nieporadność odsyłałem Cię do materiału o wątkach.
> 
> Na przyszłość czytaj spokojniej, wolniej i przeczytaj dwa razy czy 
> rozumiesz co czytasz.
> 
> Bo ewidentne po Twoich postach widać że tak nie jest (Nie rozumiesz co 
> czytasz) a jak ktoś Ci coś doradza to go ewidentnie nie słuchasz.
> 
> Pozdrawiam

No bez jaj. Odwracasz kota ogonem i to nie pierwszy raz. Mówiliśmy o możliwości odpalenia kilku rzeczy RÓWNOLEGLE w JS. Ja to nazwałem wielowątkowe a Arivald sprostował na "równoległe". Ty natomiast napisałeś Ze w Delphi też tak można w jednym wątku. Spytałem Więc Ciebie o przykład. Okazało się że bajdurzysz i żeby wyjść z twarzą twierdzisz że chodziło Ci o kilka instrukcji które wykonują się jedna po drugiej. Aż chciało by się zapytać NO CO TY, POWAŻNIE?  
Chyba nie mam już dalej ochoty tego ciągnąć. 

Bye!

Paweł

W dniu 2016-08-27 o 08:41, arivald pisze:
> W dniu 2016-08-26 o 19:53, wloochacz pisze:
>> W dniu 2016-08-26 o 18:24, arivald pisze:
>>> I JS jest jednym z powodów dlaczego Firefox czy Thunderbird jak się
>>> zawiesi to wszystkie okna na raz ... brak wielowątkowości w JS.
>> Brak jej w JS czy w maszynie JS od Gecko?
>> Czy nie dlatego niektórzy nazywają FireFoxa FireSzmatą ;-)
>>
>>> A najbardziej wkurza jak skrypt na stronie WWW zawiesza całą
>>> aplikację...
>> Zaraz, chwila - czy Ty aby nie piszesz o ekosystemie FireFox a nie o JS
>> sensu stricte?
>>
>
> Generalnie ta implementacja JS jest chyba najgorsza pod tym względem.
>
> Ale ogólnie w standardzie ECMA praktycznie nie ma wielowątkowości, nie
> ma współdzielenia danych, nie ma synchronizacji. Jest tylko 'webworker',
> ale to się opiera na kompletnie odseparowanych od głównego wątku
> silnikach, każdy ma swoje odseparowane dane, które owszem chodzą w
> osobnych watkach, ale cała komunikacja z nimi jest tylko poprzez
> komunikaty.
>
> IMO upierdliwe w użyciu.
>

Google myśl inaczej, wymyślili Progressive Web Apps, które używają 
wątków (Service Workers), i to działa.

https://developers.google.com/web/progressive-web-apps/

Ciekawy pomysł na szybką aplikację.
W firmie w kilka godzin powstała aplikacja wspierająca wyjazd firmowy.


I przy okazji Googlowy pomysł na ekspansję UI Androidowego do iOS i 
Windows ;-)

-- 
Arivald