🚀 go-pugleaf

Dnia Fri, 3 Aug 2018 14:32:48 +0200, Roman Tyczka napisał(a):

> Potrzebuję biblioteki hashującej, teraz akurat SHA512. Widzę, że popularna
> jest/była CryptoJS, ale to chyba martwy projekt i strach w to wbijać.
> Znalazłem jeszcze jsSHA, ale nie wiem czy dobre.

Masz to w przeglądarce:
https://developer.mozilla.org/en-US/docs/Web/API/Window/crypto

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On Fri, 3 Aug 2018 15:33:52 +0200, Borys Pogoreło wrote:

> Dnia Fri, 3 Aug 2018 14:32:48 +0200, Roman Tyczka napisał(a):
> 
>> Potrzebuję biblioteki hashującej, teraz akurat SHA512. Widzę, że popularna
>> jest/była CryptoJS, ale to chyba martwy projekt i strach w to wbijać.
>> Znalazłem jeszcze jsSHA, ale nie wiem czy dobre.
> 
> Masz to w przeglądarce:
> https://developer.mozilla.org/en-US/docs/Web/API/Window/crypto

O proszę, chociaż jedno miłe zaskoczenie. Nawet przez sekundę wcześniej
pomyślałem, że tak powszechnie potrzebny drobiazg jak funkcja skrótu
powinna być w standardzie bez dodatków, ale zaraz odepchnąłem myśl, bo może
za dużo bym chciał ;-)

Jeszcze tylko dopytam, przy IE piszą, że od wersji 11 (czyli to co jest w
Win10), co z Win7, 8 i Vistą? 

-- 
pozdrawiam
Roman Tyczka

On Fri, 3 Aug 2018 15:45:08 +0200, Roman Tyczka wrote:

>> Masz to w przeglądarce:
>> https://developer.mozilla.org/en-US/docs/Web/API/Window/crypto

Przy okazji... w CryptoJS miałem funkcje do kodowania base64, tu nie mogę
znaleźć. Z kolej sam JS ma niby atob() i btoa() (btw genialne nazwy!) ale
zwracają inny wynik niż to co CryptoJS oraz inne biblioteki jakich używam. 

Co zatem używać do base64?

-- 
pozdrawiam
Roman Tyczka

Dnia Fri, 3 Aug 2018 15:45:08 +0200, Roman Tyczka napisał(a):

> Jeszcze tylko dopytam, przy IE piszą, że od wersji 11 (czyli to co jest w
> Win10), co z Win7, 8 i Vistą?

IE11 chyba jest też na W7, na W8 na pewno.

Jeszcze znalazłem coś takiego:
https://github.com/vibornoff/webcrypto-shim

Co do base64, to witamy w świecie javascriptu, gdzie zaczyna się cyrk, gdy
w grę wchodzą dane binarne:
https://developer.mozilla.org/en-US/docs/Web/API/WindowBase64/Base64_encoding_and_decoding#The_Unicode_Problem

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On Fri, 3 Aug 2018 19:57:30 +0200, Borys Pogoreło wrote:

>> Jeszcze tylko dopytam, przy IE piszą, że od wersji 11 (czyli to co jest w
>> Win10), co z Win7, 8 i Vistą?
> 
> IE11 chyba jest też na W7, na W8 na pewno.
> 
> Jeszcze znalazłem coś takiego:
> https://github.com/vibornoff/webcrypto-shim
> 
> Co do base64, to witamy w świecie javascriptu, gdzie zaczyna się cyrk, gdy
> w grę wchodzą dane binarne:
> https://developer.mozilla.org/en-US/docs/Web/API/WindowBase64/Base64_encoding_and_decoding#The_Unicode_Problem


Nim jeszcze dotarłem do base64 już się odbiłem od crypto.

Zrobiłem sobie metodę:

	SHA512 : function (str) {
		var buffer = new TextEncoder("utf-8").encode(str);
		var hash = crypto.subtle.digest("SHA-512", buffer);
		return Array.from(new Uint8Array(hash));
	},

i ona po prostu nie działa, zwraca pustą tablicę.
W ostatniej linii konwertuje na tablicę bajtów obiekt jaki zwraca metoda
digest(). Ale z nim coś jest nie teges, debuger pokazuje, że ma dwa
propertysy PromiseStatus: pending i PromiseValue : undefined.
Wyczytałem, że to jakieś proxy dla wartości wyliczanej asynchronicznie.
Skoro pending to coś się nie skończyło. Ale nie mam pojęcia jak z tego
wybrnąć.

Co robię nie tak?

ps. znalazłem jeszcze taki przykład:

https://gist.github.com/chrisveness/e5a07769d06ed02a2587df16742d3fdd

i w komentarzach ktoś napisał, że dostęp do crypto api jest ograniczony do
"secure origins". Czy to znaczy, że jeśli odpalam w przeglądarce stronę bez
SSLa (bo nie mam lokalnie żadnego certyfikatu) to może być przyczyną
niedziałania crypto api? Czy da się to obejść?

-- 
pozdrawiam
Roman Tyczka

On Mon, 6 Aug 2018 14:41:04 +0200, Roman Tyczka wrote:

> i w komentarzach ktoś napisał, że dostęp do crypto api jest ograniczony do
> "secure origins". Czy to znaczy, że jeśli odpalam w przeglądarce stronę bez
> SSLa (bo nie mam lokalnie żadnego certyfikatu) to może być przyczyną
> niedziałania crypto api? Czy da się to obejść?

Odpaliłem tę moją funkcję na https://js.do czyli spod HTTPS, nadal nie
działa. Chyba wrócę do CryptoJS.

-- 
pozdrawiam
Roman Tyczka

Dnia Mon, 6 Aug 2018 14:41:04 +0200, Roman Tyczka napisał(a):

> Wyczytałem, że to jakieś proxy dla wartości wyliczanej asynchronicznie.
> Skoro pending to coś się nie skończyło. Ale nie mam pojęcia jak z tego
> wybrnąć.
> 
> Co robię nie tak?

Nie czekasz na wynik Promise.

Jeśli możesz użyć nowej składni, to możesz sobie ułatwić życie:

async function(str) {
    // ...
    var hash = await crypto...
    return ..
}

W przeciwnym razie powinieneś jawnie poczekać na rozwiązanie sie Promise.

> i w komentarzach ktoś napisał, że dostęp do crypto api jest ograniczony do
> "secure origins". Czy to znaczy, że jeśli odpalam w przeglądarce stronę bez
> SSLa (bo nie mam lokalnie żadnego certyfikatu) to może być przyczyną
> niedziałania crypto api? Czy da się to obejść?

Nie, localhost też jest secure origin.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On Wed, 8 Aug 2018 22:34:10 +0200, Borys Pogoreło wrote:

>> Co robię nie tak?
> 
> Nie czekasz na wynik Promise.
> 
> Jeśli możesz użyć nowej składni, to możesz sobie ułatwić życie:
> 
> async function(str) {
>     // ...
>     var hash = await crypto...
>     return ..
> }

Robię tak i zonk:

async function sha512(str) {
	var buffer = new TextEncoder("utf-8").encode(str);
	var hash_promise = await window.crypto.subtle.digest("SHA-512", buffer)
	.then(function (buff) {
              var bytes = new Uint8Array(buff);
              var res = '';
              for (var i = 0; i < bytes.length; i++) {
                var byte = bytes[i].toString(16);
                byte = (byte.length < 2) ? ('0' + byte) : byte;
                res += byte;}
              return res;
              });
	return hash_promise;
}

let result = sha512('raz dwa trzy');

tutaj result ciągle jest niepoliczony, ma obiekt typu Promise ze stanem
Pending :-(

 
> W przeciwnym razie powinieneś jawnie poczekać na rozwiązanie sie Promise.

Tylko to niestety jest dla mnie nie do ogarnięcia, z przerwami tkwie już w
tym 3ci dzie i nie potrafię tego ogarnąć, mój stary mózg jest chyba zbyt
sztywny na te wielokrotnie zagłębione anonymousy.

-- 
pozdrawiam
Roman Tyczka

Dnia Thu, 9 Aug 2018 11:04:50 +0200, Roman Tyczka napisał(a):

> let result = sha512('raz dwa trzy');
> 
> tutaj result ciągle jest niepoliczony, ma obiekt typu Promise ze stanem
> Pending :-(

Bo teraz wymieszałeś async i then(). Jeśli korzystasz z async, to życie
staje się dużo prostsze, bo piszesz sekwencyjnie:

var buff = await window.crypto.subtle.digest("SHA-512", buffer);
var bytes = new Uint8Array(buff);
... itd.

Trzeba zadbać tylko o jakąś obsługę wyjątków.

> Tylko to niestety jest dla mnie nie do ogarnięcia, z przerwami tkwie już w
> tym 3ci dzie i nie potrafię tego ogarnąć, mój stary mózg jest chyba zbyt
> sztywny na te wielokrotnie zagłębione anonymousy.

Ogarniesz. Trzeba po prostu zmienić sposób myślenia.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On Fri, 10 Aug 2018 11:49:53 +0200, Borys Pogoreło wrote:

>> let result = sha512('raz dwa trzy');
>> 
>> tutaj result ciągle jest niepoliczony, ma obiekt typu Promise ze stanem
>> Pending :-(
> 
> Bo teraz wymieszałeś async i then(). Jeśli korzystasz z async, to życie
> staje się dużo prostsze, bo piszesz sekwencyjnie:
> 
> var buff = await window.crypto.subtle.digest("SHA-512", buffer);
> var bytes = new Uint8Array(buff);
> ... itd.
> 
> Trzeba zadbać tylko o jakąś obsługę wyjątków.

Sprawdzę to potem jeszcze raz, bo to naprawdę ułatwia, choć już z Promisami
troszkę poszedłem do przodu i nawet działa. 
Ale jeśli chodzi o async/await to wg dokumentacji IE tego nie wspiera,
czyli klops :/
Co prawda M$ się już wypiął na IE ale chyba nadal sporo ludzi go używa,
jakie masz na ten temat zdanie?
 
>> Tylko to niestety jest dla mnie nie do ogarnięcia, z przerwami tkwie już w
>> tym 3ci dzie i nie potrafię tego ogarnąć, mój stary mózg jest chyba zbyt
>> sztywny na te wielokrotnie zagłębione anonymousy.
> 
> Ogarniesz. Trzeba po prostu zmienić sposób myślenia.

O tak, mózg zapiekły na klasycznym, ładnym, obiektowym i sekwencyjnym
kodzie (mimo częstego i szerokiego korzystania z wątków) ma spory problem,
żeby tę magię przytulić i się pogodzić z tym jak to działa. Co krok to
niespodzianka :-)

-- 
pozdrawiam
Roman Tyczka

On Fri, 3 Aug 2018 19:57:30 +0200, Borys Pogoreło wrote:

>> Jeszcze tylko dopytam, przy IE piszą, że od wersji 11 (czyli to co jest w
>> Win10), co z Win7, 8 i Vistą?
> 
> IE11 chyba jest też na W7, na W8 na pewno.
> 
> Jeszcze znalazłem coś takiego:
> https://github.com/vibornoff/webcrypto-shim

No, a to nie tyle można, co wręcz trzeba używać, bo się okazuje, że
podzbiór Crypto czyli Crypto.subtle - obiekt gdzie ukryte są te hasze i
inne zabawki jest co prawda wspierany w IE11, ale: "User must explicitly
enable this feature". Czyli pozamiatane, bo trudno zakładać, że ktoś to
włączy.

Od lat pracuję na Windows i na Windows piszę soft, ale dopiero teraz
wyraźnie odczuwam jak ta firma jest na bakier ze światem, standardami i
user experiencem, którym sobie gębę wycierają w co drugim zdaniu :/

-- 
pozdrawiam
Roman Tyczka

Dnia Fri, 10 Aug 2018 12:41:31 +0200, Roman Tyczka napisał(a):

> Sprawdzę to potem jeszcze raz, bo to naprawdę ułatwia, choć już z Promisami
> troszkę poszedłem do przodu i nawet działa. 
> Ale jeśli chodzi o async/await to wg dokumentacji IE tego nie wspiera,
> czyli klops :/

To nie jest jedyny problem z IE jaki Cię czeka. Czas się przywitać z
Babelem, który przekształca kod do starszej wersji JS. Do async/await
istnieje wtyczka:
http://babeljs.io/docs/en/babel-plugin-transform-async-to-generator/
ale nie wiem jak jest z jej zgodnością z IE. Chyba tam nawet generatorów
jeszcze nie ma, ale może są jakieś polyfille.

> O tak, mózg zapiekły na klasycznym, ładnym, obiektowym i sekwencyjnym
> kodzie (mimo częstego i szerokiego korzystania z wątków) ma spory problem,
> żeby tę magię przytulić i się pogodzić z tym jak to działa. Co krok to
> niespodzianka :-)

Tu przynajmniej nie masz problemów związanych ze współbieżnością, chociaż
tyle.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

Dnia Fri, 10 Aug 2018 12:47:55 +0200, Roman Tyczka napisał(a):

> Od lat pracuję na Windows i na Windows piszę soft, ale dopiero teraz
> wyraźnie odczuwam jak ta firma jest na bakier ze światem, standardami i
> user experiencem, którym sobie gębę wycierają w co drugim zdaniu :/

Ciesz się, że ominęły Cię czasy IE6-IE8. W przypadku WinAPI miałeś łatwo,
bo to MS był autorem. A technologie webowe chcieli zagarnąć dla siebie i to
był dopiero bałagan. W tamtych czasach niczym niezwykłym był kod, gdzie
sporą częścią były wyjątki na IE (inna obsługa eventów, inny AJAX, itd.).
Dlatego też m.in. jQuery i mu podobne biblioteki zyskały taką popularność -
dawały ujednolicone API, ukrywając te setki wyjątków i przypadków
brzegowych.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On Fri, 10 Aug 2018 22:34:42 +0200, Borys Pogoreło wrote:

>> Od lat pracuję na Windows i na Windows piszę soft, ale dopiero teraz
>> wyraźnie odczuwam jak ta firma jest na bakier ze światem, standardami i
>> user experiencem, którym sobie gębę wycierają w co drugim zdaniu :/
> 
> Ciesz się, że ominęły Cię czasy IE6-IE8. W przypadku WinAPI miałeś łatwo,
> bo to MS był autorem. A technologie webowe chcieli zagarnąć dla siebie i to
> był dopiero bałagan. 

No wiem, wiem, pamiętam, choć obserwowałem to z boku i osobiście nie czułem
tego bólu :-)

A teraz popatrz jaki m$ do przodu:
https://www.dobreprogramy.pl/Najlepsza-przegladarka-na-smartfony-to-nie-Chrome.-Wyzsze-oceny-zbiera-Microsoft-Edge,News,89799.html

> W tamtych czasach niczym niezwykłym był kod, gdzie
> sporą częścią były wyjątki na IE (inna obsługa eventów, inny AJAX, itd.).
> Dlatego też m.in. jQuery i mu podobne biblioteki zyskały taką popularność -
> dawały ujednolicone API, ukrywając te setki wyjątków i przypadków
> brzegowych.

Przy okazji powiedz mi czy jQuery nadal jest używane w nowych projektach
czy to już nisza i są inne tego typu narzędzia?

-- 
pozdrawiam
Roman Tyczka

On 13/08/2018 12:02, Roman Tyczka wrote:
> On Fri, 10 Aug 2018 22:34:42 +0200, Borys Pogoreło wrote:
> 
>>> Od lat pracuję na Windows i na Windows piszę soft, ale dopiero teraz
>>> wyraźnie odczuwam jak ta firma jest na bakier ze światem, standardami i
>>> user experiencem, którym sobie gębę wycierają w co drugim zdaniu :/
>>
>> Ciesz się, że ominęły Cię czasy IE6-IE8. W przypadku WinAPI miałeś łatwo,
>> bo to MS był autorem. A technologie webowe chcieli zagarnąć dla siebie i to
>> był dopiero bałagan.
> 
> No wiem, wiem, pamiętam, choć obserwowałem to z boku i osobiście nie czułem
> tego bólu :-)
> 
> A teraz popatrz jaki m$ do przodu:
> https://www.dobreprogramy.pl/Najlepsza-przegladarka-na-smartfony-to-nie-Chrome.-Wyzsze-oceny-zbiera-Microsoft-Edge,News,89799.html

btw mobilnych urządzeń, to na nich korzystam z Brave Browser: 
https://brave.com/

>> W tamtych czasach niczym niezwykłym był kod, gdzie
>> sporą częścią były wyjątki na IE (inna obsługa eventów, inny AJAX, itd.).
>> Dlatego też m.in. jQuery i mu podobne biblioteki zyskały taką popularność -
>> dawały ujednolicone API, ukrywając te setki wyjątków i przypadków
>> brzegowych.
> 
> Przy okazji powiedz mi czy jQuery nadal jest używane w nowych projektach
> czy to już nisza i są inne tego typu narzędzia?
> 

Osobiście nie korzystam z jQuery od wielu lat. Nie ma takiej już 
potrzeby, według mnie.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/
https://www.aslint.org/ - Accessibility Lint Validator

Dnia Mon, 13 Aug 2018 12:02:46 +0200, Roman Tyczka napisał(a):

> A teraz popatrz jaki m$ do przodu:
> https://www.dobreprogramy.pl/Najlepsza-przegladarka-na-smartfony-to-nie-Chrome.-Wyzsze-oceny-zbiera-Microsoft-Edge,News,89799.html

I dobrze, niech w końcu trzymają się standardów.

> Przy okazji powiedz mi czy jQuery nadal jest używane w nowych projektach
> czy to już nisza i są inne tego typu narzędzia?

Powoli wymiera. Wsparcie dla selektorów CSS w przeglądarkach jest
praktycznie identyczne, a na manipulację DOM są teraz lepsze i
wydajniejsze rozwiązania. Zostaje AJAX, dla którego masz dziesiątki innych
bibliotek. I parę przydatnych funkcji typu $.extend, które jednak masz
również w innych bibliotekach typu Lodash.

Zostają proste i szybkie projekty, użycie z przyzwyczajenia, konieczność
zachowania zgodności wstecz lub wykorzystywanie kodu, który opiera się w
jakimś stopniu na jQuery.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On Sun, 19 Aug 2018 21:40:04 +0200, Borys Pogoreło wrote:

>> A teraz popatrz jaki m$ do przodu:
>> https://www.dobreprogramy.pl/Najlepsza-przegladarka-na-smartfony-to-nie-Chrome.-Wyzsze-oceny-zbiera-Microsoft-Edge,News,89799.html
> 
> I dobrze, niech w końcu trzymają się standardów.
> 
>> Przy okazji powiedz mi czy jQuery nadal jest używane w nowych projektach
>> czy to już nisza i są inne tego typu narzędzia?

Po przerwie wracam do JS, będę znowu dręczył pytaniami ;-)
 
> Powoli wymiera. 

No właśnie takie mam wrażenie, a projekcik jaki teraz robię był zaczęty
dawno temu przez kogoś innego i używa jQuery. jQuery zaczynam się uczyć,
ale wygląda na to, że to ślepa uliczka. Z kolei gdy go teraz wywalę to
wszystko co mam muszę przeorać, choć dużo tego nie ma. Co radzisz? Porzycić
jQuery? ...a mam chyba ze 3 książki do niego kupione :/

> Wsparcie dla selektorów CSS w przeglądarkach jest
> praktycznie identyczne, a na manipulację DOM są teraz lepsze i
> wydajniejsze rozwiązania. 

Czyli jak konkretnie zastąpić $('#pnl1') lub $('div[id=^pnl]) bez jQuery?
Jakiś przykład?

> Zostaje AJAX, dla którego masz dziesiątki innych
> bibliotek. 

Jaką polecasz?

> I parę przydatnych funkcji typu $.extend, które jednak masz
> również w innych bibliotekach typu Lodash.

Tak, Lodash obczaiłem z grubsza, wydaje się paczką lukru składniowego, choć
przydatny bo upraszcza kod. Niemniej boję się takich bibliotek, bo się
człek do składni przyzwyczai a potem biblioteka zdechnie i tyłek boli. W
Delphi buduję swoje pakiety tego rodzaju, a pod maską korzystają one z
innych bilbiotek. Gdy jakaś padnie, to podmieniam tylko pod maską, a
zewnętrze czyli mój interfejs dostępowy pozostaje bez zmian i mam pewność,
że zawsze będę go miał.
 
> Zostają proste i szybkie projekty, użycie z przyzwyczajenia, konieczność
> zachowania zgodności wstecz lub wykorzystywanie kodu, który opiera się w
> jakimś stopniu na jQuery.

Czyli uciekać z jQuery... 

btw dlaczego jQuery umiera? Co jest głównym powodem?

-- 
pozdrawiam
Roman Tyczka

> btw dlaczego jQuery umiera? Co jest głównym powodem?
> 

Bo IE umarł?

On Tue, 4 Sep 2018 09:45:16 +0200, Tomek wrote:

>> btw dlaczego jQuery umiera? Co jest głównym powodem?
>> 
> Bo IE umarł?

Może i umarł, ale zombie jeszcze funkcjonuje. 
Tak z ciekawości spytam, bo mam wrażenie, że Borys też IE traktuje jako
nieistotny, pytanie do wszystkich:

- czy powszechne jest uznanie wśród web developerów, że wsparcie dla IE
jest już niepotrzebne?

-- 
pozdrawiam
Roman Tyczka

On 2018-09-04, Roman Tyczka <noemail@because.no> wrote:

[...]

> - czy powszechne jest uznanie wśród web developerów, że wsparcie dla IE
> jest już niepotrzebne?

Nie. Powszechnym jest uznanie faktu, że ostatnie wersje IE (Edge wszczególności)
są już na tyle ustandaryzowane, że nie ma potrzeby się z tym babrać, ani przejmować
"na jakiej przeglądarce to pójdzie".

Są też różnego rodzaju nakładki/transpilery w rodzaju babela oraz frameworki/biblioteki
w rodzaju axios, react, angular, że problem niekompatybilności gdzieś tam pod spodem
przestał po prostu istnieć, bo wszystko pilnuje by działał spójny kod.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

On Tue, 4 Sep 2018 14:30:24 +0200, Wojciech Bancer wrote:

>> - czy powszechne jest uznanie wśród web developerów, że wsparcie dla IE
>> jest już niepotrzebne?
> 
> Nie. Powszechnym jest uznanie faktu, że ostatnie wersje IE (Edge wszczególności)
> są już na tyle ustandaryzowane, że nie ma potrzeby się z tym babrać, ani przejmować
> "na jakiej przeglądarce to pójdzie".
> 
> Są też różnego rodzaju nakładki/transpilery w rodzaju babela oraz frameworki/biblioteki
> w rodzaju axios, react, angular, że problem niekompatybilności gdzieś tam pod spodem
> przestał po prostu istnieć, bo wszystko pilnuje by działał spójny kod.

Z tego wypływa wniosek, że bez frameworków/bibliotek nie podchodź... goły
JS to za mało, bo w IE brakuje async/CryptoAPI/FetchAPI/itd.

Z kolei każdy framework to serial z setką sezonów... nie do opanowania na
szybko. Gdzie się nie odwrócić to ściana.

Pozostaje zatem czekać aż IE zdechnie do końca (liczę ze dwa lata), a
tymczasem używać jQuery (bo się okazało, że Bootstrap którego też używam
wymaga jQuery do działania).

To na chwilę obecną nieco upraszcza sprawę, choć świadoność brnięcia w
umierającą technologię nieco uwiera. Ale może ten czas pozwoli się lepiej
odnaleźć w nowym świecie i potem będzie łatwiej.

Dzięki za opinię.

-- 
pozdrawiam
Roman Tyczka

On 2018-09-04, Roman Tyczka <noemail@because.no> wrote:
> On Tue, 4 Sep 2018 14:30:24 +0200, Wojciech Bancer wrote:
>
>>> - czy powszechne jest uznanie wśród web developerów, że wsparcie dla IE
>>> jest już niepotrzebne?
>> 
>> Nie. Powszechnym jest uznanie faktu, że ostatnie wersje IE (Edge wszczególności)
>> są już na tyle ustandaryzowane, że nie ma potrzeby się z tym babrać, ani przejmować
>> "na jakiej przeglądarce to pójdzie".
>> 
>> Są też różnego rodzaju nakładki/transpilery w rodzaju babela oraz frameworki/biblioteki
>> w rodzaju axios, react, angular, że problem niekompatybilności gdzieś tam pod spodem
>> przestał po prostu istnieć, bo wszystko pilnuje by działał spójny kod.
>
> Z tego wypływa wniosek, że bez frameworków/bibliotek nie podchodź... goły
> JS to za mało, bo w IE brakuje async/CryptoAPI/FetchAPI/itd.

W IE brakuje, ale w Edge nie:
https://caniuse.com/#feat=fetch
https://caniuse.com/#feat=async-functions
https://caniuse.com/#feat=cryptography

> Pozostaje zatem czekać aż IE zdechnie do końca (liczę ze dwa lata), a
> tymczasem używać jQuery (bo się okazało, że Bootstrap którego też używam
> wymaga jQuery do działania).

IE już zdechł. Trzyma się jeszcze w niektórych korporacjach, ale spora część
już przeszła na Chrome. A Edge nie odstaje.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

On 2018-09-04, Wojciech Bancer <wojciech.bancer@gmail.com> wrote:

[...]

>> Z tego wypływa wniosek, że bez frameworków/bibliotek nie podchodź... goły
>> JS to za mało, bo w IE brakuje async/CryptoAPI/FetchAPI/itd.

Dodatkowo myślę, że cyt. "bez frameworków/bibliotek" to się do żadnego
języka w dzisiejszych czasach nie podchodzi. Bo i po co wymyślać koło?

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

On 04/09/2018 10:59, Roman Tyczka wrote:
> On Tue, 4 Sep 2018 09:45:16 +0200, Tomek wrote:
> 
>>> btw dlaczego jQuery umiera? Co jest głównym powodem?
>>>
>> Bo IE umarł?
> 
> Może i umarł, ale zombie jeszcze funkcjonuje.
> Tak z ciekawości spytam, bo mam wrażenie, że Borys też IE traktuje jako
> nieistotny, pytanie do wszystkich:
> 
> - czy powszechne jest uznanie wśród web developerów, że wsparcie dla IE
> jest już niepotrzebne?


Potrzebne, ale na tyle minimalnie, jak to możliwe ;-)

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/
https://www.aslint.org/

On 04/09/2018 15:17, Roman Tyczka wrote:
> On Tue, 4 Sep 2018 14:30:24 +0200, Wojciech Bancer wrote:
> 
>>> - czy powszechne jest uznanie wśród web developerów, że wsparcie dla IE
>>> jest już niepotrzebne?
>>
>> Nie. Powszechnym jest uznanie faktu, że ostatnie wersje IE (Edge wszczególności)
>> są już na tyle ustandaryzowane, że nie ma potrzeby się z tym babrać, ani przejmować
>> "na jakiej przeglądarce to pójdzie".
>>
>> Są też różnego rodzaju nakładki/transpilery w rodzaju babela oraz frameworki/biblioteki
>> w rodzaju axios, react, angular, że problem niekompatybilności gdzieś tam pod spodem
>> przestał po prostu istnieć, bo wszystko pilnuje by działał spójny kod.
> 
> Z tego wypływa wniosek, że bez frameworków/bibliotek nie podchodź... goły
> JS to za mało, bo w IE brakuje async/CryptoAPI/FetchAPI/itd.

Wcale nie. Poza kilkoma polyfillami da się wszystko dobrze zrobić w 
samym JavaScripcie. Niemniej jednak sam korzystam z TypeScriptu teraz.

> Z kolei każdy framework to serial z setką sezonów... nie do opanowania na
> szybko. Gdzie się nie odwrócić to ściana.
> 
> Pozostaje zatem czekać aż IE zdechnie do końca (liczę ze dwa lata), a
> tymczasem używać jQuery (bo się okazało, że Bootstrap którego też używam
> wymaga jQuery do działania).

IE tak szybko nie zdechnie, bo siedzi mocno w korporacjach. A tam już są 
zupełnie inne zasady, niż na rynku zwykłego konsumenta.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/
https://www.aslint.org/

Dnia Tue, 4 Sep 2018 14:30:24 +0200, Wojciech Bancer napisał(a):

> Nie. Powszechnym jest uznanie faktu, że ostatnie wersje IE (Edge wszczególności)
> są już na tyle ustandaryzowane, że nie ma potrzeby się z tym babrać, ani przejmować
> "na jakiej przeglądarce to pójdzie".

Tak dobrze to jeszcze nie ma. Jeśli Twój kod będzie uruchamiany w korpo, to
IE11 jeszcze potrafi ugryźć (przykładowo strasznie zabugowany flexbox).
Tego nie obejdziesz inaczej jak sztuczkami w stylu min-width, jawnym
definiowaniem flex-basis, itd.

> Są też różnego rodzaju nakładki/transpilery w rodzaju babela oraz frameworki/biblioteki
> w rodzaju axios, react, angular, że problem niekompatybilności gdzieś tam pod spodem
> przestał po prostu istnieć, bo wszystko pilnuje by działał spójny kod.

Taka była też rola jQuery ;) Tylko na niższym poziomie, poszczególnych
funkcji biblioteki.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

Dnia Tue, 4 Sep 2018 09:30:32 +0200, Roman Tyczka napisał(a):

> No właśnie takie mam wrażenie, a projekcik jaki teraz robię był zaczęty
> dawno temu przez kogoś innego i używa jQuery. jQuery zaczynam się uczyć,
> ale wygląda na to, że to ślepa uliczka. Z kolei gdy go teraz wywalę to
> wszystko co mam muszę przeorać, choć dużo tego nie ma. Co radzisz? Porzycić
> jQuery? ...a mam chyba ze 3 książki do niego kupione :/

Od jQuery tak łatwo nie uciekniesz, także warto je znać. Wraz z
zamiennikami w bardziej nowoczesnym JS.

> Czyli jak konkretnie zastąpić $('#pnl1') lub $('div[id=^pnl]) bez jQuery?
> Jakiś przykład?

https://developer.mozilla.org/pl/docs/Web/API/Document/querySelector

>> Zostaje AJAX, dla którego masz dziesiątki innych
>> bibliotek. 
> 
> Jaką polecasz?

Np. axios. Choć jak dla mnie ten w jQuery nie jest najgorszy. I już od
dawna jest oparty o Promises, czego choćby nie można powiedzieć o kliencie
http w node.js.

> Tak, Lodash obczaiłem z grubsza, wydaje się paczką lukru składniowego, choć
> przydatny bo upraszcza kod. Niemniej boję się takich bibliotek, bo się
> człek do składni przyzwyczai a potem biblioteka zdechnie i tyłek boli. 

Wątpię, by tak się stało. To jest zbyt wygodne i popularne, a JS ma zbyt
duże braki składniowe. A nawet między konkurującymi bibliotekami różnice w
składni pokrywających się funkcji są niewielkie.

> btw dlaczego jQuery umiera? Co jest głównym powodem?

Tak jak pisałem - zarówno przeglądarki jak i sam JS rozwinęły i
ustandaryzowały się na tyle, że jQuery przestał pełnić swoją głowną funkcję
uniwersalnej biblioteki łatającej braki. Choć nadal bywa przydatny, bo
przykładowo bez bibliotek łatwo nie zrobisz choćby bezpiecznego sklonowania
obiektu. A jeśli masz pod ręką jQuery, to masz też $.extend.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On 2018-09-06, Borys Pogoreło <borys@pl.edu.leszno> wrote:

[...]

>> są już na tyle ustandaryzowane, że nie ma potrzeby się z tym babrać, ani przejmować
>> "na jakiej przeglądarce to pójdzie".
>
> Tak dobrze to jeszcze nie ma. Jeśli Twój kod będzie uruchamiany w korpo, to
> IE11 jeszcze potrafi ugryźć (przykładowo strasznie zabugowany flexbox).
> Tego nie obejdziesz inaczej jak sztuczkami w stylu min-width, jawnym
> definiowaniem flex-basis, itd.

Nie wszystkie korpo są takie złe. W niektórych korpo dominuje już chrome. :)
Na chyba 4 z którymi mam "internal" kontakt, w 3 jest Chrome, w jednej 
tylko IE.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

Dnia Thu, 6 Sep 2018 23:13:23 +0200, Wojciech Bancer napisał(a):

> Nie wszystkie korpo są takie złe. W niektórych korpo dominuje już chrome. :)
> Na chyba 4 z którymi mam "internal" kontakt, w 3 jest Chrome, w jednej 
> tylko IE.

Zazdraszczam. Ja mam właśnie zgłoszenie, że w jednej aplikacji coś gdzieś
się nie rozwija w IE, juz się cieszę na szukanie tego.

Ale są jeszcze obszary, gdzie wymagana jest zgodność z IE8, przynajmniej w
zakresie czytelnego wyświetlania treści. To jest dopiero hardkor, polyfille
nawet na media queries są potrzebne. I to w 2018...

-- 
Borys Pogoreło
borys(#)leszno,edu,pl