Warning: Redis::get(): php_network_getaddresses: getaddrinfo for localhost failed: No address associated with hostname in /home/klient.dhosting.pl/michalko/webroad.pl/public_html/wp-content/plugins/litespeed-cache/src/object-cache.cls.php on line 665

Warning: Cannot modify header information - headers already sent by (output started at /home/klient.dhosting.pl/michalko/webroad.pl/public_html/wp-content/plugins/litespeed-cache/src/object-cache.cls.php:665) in /home/klient.dhosting.pl/michalko/webroad.pl/public_html/wp-content/plugins/dw-question-answer/inc/Posts/Base.php on line 20

Warning: Cannot modify header information - headers already sent by (output started at /home/klient.dhosting.pl/michalko/webroad.pl/public_html/wp-content/plugins/litespeed-cache/src/object-cache.cls.php:665) in /home/klient.dhosting.pl/michalko/webroad.pl/public_html/wp-includes/feed-rss2-comments.php on line 8
Komentarze do: Progressive Enhancement – zapomniany fundament https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament blog dla webmasterów, na którym piszemy o HTML5, CSS3, JavaScript, webdesign, UX, CMS Sat, 26 Sep 2020 15:48:42 +0000 hourly 1 https://wordpress.org/?v=6.9.4 Autor: Eduweb.pl – frontendowy bootcamp — WebKrytyk.pl https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2606 Sun, 06 Nov 2016 12:04:35 +0000 https://webroad.pl/?p=3722#comment-2606 […] – choćby przy pomocy takich „super trendy” frameworków jak next.js, w których PE jest wciąż żywe. W sumie to bardzo smutne, że obecnie generowanie strony na serwerze to jedno z […]

]]>
Autor: Szablon Starbis — WebKrytyk.pl https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2604 Mon, 31 Oct 2016 15:21:23 +0000 https://webroad.pl/?p=3722#comment-2604 […] Nagle jest wysyp stylów inline, które łamią zasady CSP i przy okazji zasadę podziału warstw aplikacji. […]

]]>
Autor: Szablon Intense — WebKrytyk.pl https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2522 Sun, 08 May 2016 19:52:29 +0000 https://webroad.pl/?p=3722#comment-2522 […] niedziałania JS, że newralgiczne elementy strony wręcz nie mogą zależeć od jego obecności! Filozofia PE nie powstała bez […]

]]>
Autor: Tanio-strony-internetowe.pl — WebKrytyk.pl https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2452 Mon, 29 Feb 2016 22:10:48 +0000 https://webroad.pl/?p=3722#comment-2452 […] Ja wiem, że to wtyczka, ale takie praktyki są wręcz naganne. Wystarczy, że serwer AddThis padnie i dzielenie się nie zadziała. Gdyby te linki zostały wstawione tradycyjnie, wówczas działałyby zawsze, dla wszystkich. Stąd PE jest wciąż ważne. […]

]]>
Autor: Wideokursy #2: Kurs PHP Mirosława Zelenta — WebKrytyk.pl https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2372 Thu, 31 Dec 2015 19:04:29 +0000 https://webroad.pl/?p=3722#comment-2372 […] niemieszanie wartsw jest całkowicie fundamentalną praktyką, opisałem w swoim artykule o Progressive Enhancement. Co prawda dotyka on sfery frontendu, lecz dokładnie te same zasady obowiązują też w backendzie […]

]]>
Autor: Witold Wrotek, „Javascript i jQuery. 131 praktycznych skryptów” – przykładowy rozdział — WebKrytyk.pl https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2143 Thu, 01 Jan 2015 21:48:49 +0000 https://webroad.pl/?p=3722#comment-2143 […] już wcześniej, ale tutaj jeszcze trochę dopowiem. Oprócz już wymienionych powodów, ten zapis miesza warstwy aplikacji i wymusza obniżenie bezpieczeństwa strony, gdyż zaprzecza zasadom Content Security Policy […]

]]>
Autor: ZapewniamyEnergie.pl — WebKrytyk.pl https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2139 Wed, 31 Dec 2014 21:41:59 +0000 https://webroad.pl/?p=3722#comment-2139 […] Menu jest ukryte przez display: none. Oczywiście o PE nie ma mowy. […]

]]>
Autor: Moja prawda o Angular.js — WebKrytyk.pl https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2111 Fri, 12 Dec 2014 19:39:16 +0000 https://webroad.pl/?p=3722#comment-2111 […] PE jest zapomnianym fundamentem i bez niego nie mogę nawet patrzeć na Angulara – łamie on wszystkie zasady, w które wierzę. […]

]]>
Autor: My truth about Angular.js — WebKrytyk.pl https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2107 Sun, 07 Dec 2014 22:23:20 +0000 https://webroad.pl/?p=3722#comment-2107 […] PE is the forgotten foundation (in Polish) and without it I can’t even look into Angular.js’s direction – it breaks all principles I believe in. […]

]]>
Autor: Comandeer https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2070 Tue, 11 Nov 2014 17:31:00 +0000 https://webroad.pl/?p=3722#comment-2070 Ale GMail bez JS może działać. Bezsensem jest jedynie to, że wersja bez JS jest osobna, bo prościej byłoby na wersję bez JS po prostu ten JS nałożyć. Po prostu ktoś w tym 2005 roku nie pomyślał.
Tak, ludzie z JS to wybrańcy bogów – inaczej Zakas nigdy nie mówiłby o PE 2.0 i nie dzielił JS na „JS”, „nice JS” i „OMG JS”.
Jak już wspominałem mało jest aplikacji webowych, które koniecznie muszą mieć JS. De facto są to aplikacje, które nie potrzebują serwera do niczego innego oprócz incjalnego wczytania plików. Co się do tego zalicza? Fotoszopy online, komunikatory (ale znów – wysłanie/odebranie wiadomości można zrobić bez JS jako podstawową funkcjonalność dla każdego; patrz: Wiadomości na FB), mapy… Mało jest przykładów rzeczy „JS-only”. I Google o tym wie, wciąż utrzymując prehistoryczną wersję GMaila i umożliwiając wyszukiwanie info na Google.com nawet ludziom z Lynxem (nikt mi nie wmówi, że wpisanie zapytania do wyszukiwarki wymaga JS).
Hasło „aplikacje webowe” jest doskonałą wymówką, żeby wyrzucić w pizdu dostępność i tak podstawowe zasady, jak podział warstw aplikacji. Ba, nawet aplikacje JS-only są w stanie dużo zyskać, jeśli ich HTML, CSS i JS będą całkowicie od siebie niezależne (nikt nie lubi zmieniać jednej rzeczy w 3 miejscach). A 98% tych aplikacji naprawdę skorzystałoby z PE. Może i początkowo jest to więcej pracy do zrobienia (chociaż – czy ja wiem?) i trwa ciut dłużej, ale dla rozwoju aplikacji taki trójpodział warstw jest de facto kluczowy. Nie sądzę, żeby wydłużyło to tworzenie MVP (osobiście szybciej pisze mi się coś PE niźli coś, co nie dzieli aplikacji na warstwy).
Tak, CSP powinno być wykorzystywane wszędzie, bo podnosi diametralnie bezpieczeństwo a w przypadku wielu produktów jest to czynnik kluczowy (nawet Polymer ostatnio, przez Vulcanizera, dochrapał się wsparcia dla CSP!). A jeśli aplikacja jest podzielona na warstwy, CSP po prostu działa. Ot, poboczna korzyść.
A RESTful API całkowicie wykorzystywane w JS to IMO po prostu żart. Po to utrzymuję serwer, żeby każdy, kto chce dane, mógł je pobrać. Nie obchodzi mnie czy to jest klient łączący się przez Web Sockets i budujący stronę w React.js z wizualizacją w WebGL czy po prostu bot w cURL, który bierze czystego JSON-a i wkłada go do pliku. Po to mam ten serwer, żeby każdy miał dostęp do danych. Owszem, można tworzyć aplikacje JS-only przy użyciu architektury REST, ale czemu mam wykluczać część userów, skoro przy pomocy tej samej architektury mogę obsłużyć wszystkich? REST to URIs, więc wręcz naturalne jest takie jego wykorzystanie. Można to podrasować w JS (History API), lecz podstawowa funkcjonalność jest wbudowana w HTML (i nawet Angular nie jest na tyle nienormalny, żeby nie korzystać z HTML-owych formularzy czy linków) – i to jest właśnie PE. Rozbudowywanie rozwiązania od najprostszych składników aż do stworzenia całkowitego, kompleksowego rozwiązania, które jest skalowalne i łatwe w modyfikacji. PE dla frontendu jest mniej więcej tym samym, co MVC dla backendu (M – HTML, V – CSS, C – JS). Owszem, można wszytko wcisnąć do controllera, ale wszyscy wiemy, że nie jest to najlepsze rozwiązanie.
Nie sądzę, że PE jest jedynym rozwiązaniem – sam siedzę w aplikacjach JS-only, gdzie po prostu nie ma żadnego sensownego sposobu, żeby zapewnić wsparcie bez JS. Ale to, że strona zawiera edytor grafiki, nie oznacza równocześnie, że user bez JS nie może się na niej zarejestrować. Bo to bez sensu – tylko edytor wymaga JS, ale dla zasady zablokujmy całą stronę dla tych bez JS. To trochę tak, jakbyśmy niepiśmiennych zamykali w izolowanych pomieszczeniach, bo przecież nie zasługują, żeby obcować z resztą społeczeństwa. Można – tylko po co?

P.S. Polskie startupy faktycznie mają bardzo duże problemy ze stworzeniem działających usług… ;) http://www.vintom.com/ – wg Business Link to jeden z TOP10 polskich startupów. 30 minut w ST (ok, godzinka – w końcu trza wliczyć pociągnięcia łyków coli :D) i mam analogiczną usługę. Kiedyś słowo „startup” coś znaczyło – dzisiaj nie znaczy absolutnie nic (tak, jak HTML5).

]]>
Autor: Michał Załęcki https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2067 Tue, 11 Nov 2014 16:47:00 +0000 https://webroad.pl/?p=3722#comment-2067 Ja z kolei mam wrażenie, ze dla Ciebie zawsze jest tylko jedno rozwiązanie CSP/PE – z takim podejściem 90% startupów by nie wystartowało bo przez rok tworzyli by MVP. Sponsorzy pozostałych 10% by się może nie pokapowali. Mówisz, że PE proste i przyjemne, a przykład to rozwiązanie GMail – klasa enterprise – największy klient poczty stworzony przez największego giganta branży.

]]>
Autor: Comandeer https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2066 Tue, 11 Nov 2014 16:45:00 +0000 https://webroad.pl/?p=3722#comment-2066 Przepraszam Cię bardzo – gdzie jest tutaj porównanie Angulara i Polymera i udowadnianie wyższości jednego nad drugim? Napisałem tylko tyle, że Google przykłada większą wagę do Polymera. Dowodów na to stwierdzenie nie trzeba szukać daleko, bo połowa środowiska JS i ludzie związani z Google mówią to otwarcie. Nie porównuję Polymera do Angulara, bo jeden jest prolifillem dla Web Components a drugi frameworkiem JS.

Co do RESTful APIs wykorzystywanych przez nielicznych: polecam czytać wraz z kontekstem i *DOKŁADNIE*, bo napisałem coś całkowicie innego.

Co do budowania SPA jako dwóch osobnych stron – to nie jest PE. PE polega na *ULEPSZANIU* podstawowej funkcjonalności, co padło w artykule kilka razy, wraz z podanym przykładem takiego rozwiązania. Ba, wspominałem o tym także w kontekście GMaila… I tak, dla strony wizytówki nie robię SPA. Tylko to nie ma nic do rzeczy, skoro kontekstem rozmowy są aplikacje internetowe… które także można stworzyć w sposób dostępny i użyteczny, przy małym nakładzie pracy i środków. A Angular nijak temu nie służy.

To nie jest konserwatyzm – to po prostu nie jest bycie chujem i wspieranie każdego użytkownika a nie wybrańca bogów.

Nie przekręcaj moich słów i nie wkładaj mi w usta czegoś, czego nigdy nie powiedziałem. Bo jeśli nasze dyskusje mają się toczyć na takim poziomie, to faktycznie – lepiej spasować. Bo plucie jadem i ironią bez uważnego czytania tego, co napisałem, zamiast merytorycznych argumentów jest po prostu nieprofesjonalne.

]]>
Autor: Michał Załęcki https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2065 Tue, 11 Nov 2014 16:34:00 +0000 https://webroad.pl/?p=3722#comment-2065 Porównywanie AngularJS i Polymer z udowadnianiem wyższości jednego nad drugim. RESTful APIs wykorzystywane tylko przez nielicznych – to ja tu chyba spasuję.

]]>
Autor: Comandeer https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2064 Tue, 11 Nov 2014 16:26:00 +0000 https://webroad.pl/?p=3722#comment-2064 >Jakieś zdezaktualizowane info masz. AngularJS 2.0 będzie blisko Polymera.
Nie mam ;) Angular 2.0 będzie korzystał z Polymera – to jest fakt. Co nie zmienia faktu, że będzie z niego korzystał właśnie dlatego, że Google kładzie bardzo duży nacisk na wczesną i szybką adopcję Web Components. Inaczej Angular byłby całkowicie osobnym frameworkiem, tak, jak jest to obecnie.

>Tak też mówiono o Node.js – „rak który zniszczy mózgi developerom”
Problem w tym, że to był całkowity hejt, bez żadnych racjonalnych argumentów (który już nawet zniknął z Sieci). Jeśli chcesz podyskutować o Angularze, jestem w stanie uzasadnić moją opinię.

>To twoje zdanie.
Nie tylko moje. http://ponyfoo.com/articles/stop-breaking-the-web czy https://medium.com/este-js-framework/whats-wrong-with-angular-js-97b0a787f903 + bardzo wielu developerów, którzy pracowali np z Backbone.js. Angular miesza HTML z JS i de facto z powrotem cofa nas do ery wszędobylskich atrybutów [on…] (co Polymer niestety też robi) – a tego raczej nikt sobie nie życzy.

>I JSX ma zadziałać z wyłączonym JS?
Nie zadziała – bo dlaczego ma działać? Ale to, że React działa tylko z JS, nie wyklucza, że można go użyć zgodnie z duchem PE. React jest przecież warstwą zachowania – tylko i wyłącznie. Jeśli JS jest dostępne na kliencie, to dostajemy React jako system szablonów. Jeśli JS na kliencie nie ma, serwer renderuje strony.

>API to API, a nie od razu backend, który wyśle do nas plik html.
Polecam zapoznać się z hasłem izomorficznych aplikacji internetowych i np koncepcją Zakasa odnośnie node.js jako nowego frontendu: http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/

>Dla mnie SPA bez JS brzmi na obecną chwile jak utopia.
Jeszcze raz przytoczę GMaila: jeśli klienta ma JS, wówczas dostajemy pełnoprawne SPA. Jeśli klient nie ma JS, dostajemy klienta poczty z podstawową funkcjonalnością. Da się stworzyć działającą aplikację internetową, która nie musi mieć JS, dostarczając podstawowe UI i UX userowi. Tak, bez JS nie będzie to SPA, ale user *COŚ* dostanie a nie wypierdolimy go oknem, bo nie spełnia naszych wymagań.

>Chcesz nowoczesnego webu – włącz JS.
Zawsze, gdy komentujesz, mam wrażenie, że nie czytasz dokładnie moich artykułów… Podałem bowiem bardzo ważne statystyki, które pokazują, że JS może nie być i to u każdego, nawet u Ciebie. I to nie dlatego, że sobie wyłączysz – po prostu będzie błąd. Tak, nowoczesny web opiera się na JS, co nie oznacza, że dla tych, którzy nie mają JS, należy przygotować czarną dziurę. Bo to jest po prostu bycie wielkim *. Nie wspominając już o tym, że de facto nikt z ludzi, którzy tworzą „nowoczesny web”, nie przejmuje się potrzebami np ludzi niepełnosprawnych. RESTful APIs powstały po to, żeby móc dostarczać potrzebnych informacji *każdemu*. Dziwnym trafem używa się ich po to, żeby dostarczać informacji nielicznym.

]]>
Autor: Michał Załęcki https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2063 Tue, 11 Nov 2014 16:08:00 +0000 https://webroad.pl/?p=3722#comment-2063 > AngularJS nigdy nie będzie od tego szybszy, zwłaszcza, że jego założenia
są po prostu z gruntu niewłaściwe. Zresztą Google nie błogosławi
Angularowi – ich oczkiem w głowie jest Polymer
Jakieś zdezaktualizowane info masz. AngularJS 2.0 będzie blisko Polymera.

> jest w stanie zepsuć Sieć jeszcze bardziej
Tak też mówiono o Node.js – „rak który zniszczy mózgi developerom”

> To przykład domu, na który spadła bomba atomowa ;)
To twoje zdanie.

> React.js to po prostu bardzo wydajny system szablonów – nie wiem czego od niego chcesz ;)
I JSX ma zadziałać z wyłączonym JS?

> Jeśli ktoś pisze RESTful API, niedziałające bez JS, to tak naprawdę nie wie co to RESTful API. Kropka.
Spokojnie. API działa na serwerze, wiec chyba się nie rozumiemy – wysyła np. JSON, przyjmuje requesty i tylko to. API to API, a nie od razu backend, który wyśle do nas plik html. Dla mnie SPA bez JS brzmi na obecną chwile jak utopia.

]]>
Autor: Comandeer https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2061 Tue, 11 Nov 2014 13:49:00 +0000 https://webroad.pl/?p=3722#comment-2061 >A tym czasem do drzwi perfekcyjnego domu backendowca zapukał AngularJS/React – będą robić SPA z jakimś RESTful API :P
AngularJS IMO to najgorzej obecnie zaprojektowany framework JS, jaki istnieje. Z HTML robi siekę i de facto nie wnosi nic ciekawego do sposobu, w jaki piszemy JS (serio każda dyrektywa jest przepuszczana przez wrapper dla eval, który ma kilka tysięcy linijek kodu?). Twitter kiedyś też się napalił do rozwiązania typu AngularJS – i co? I z podkulonym ogonem wrócił do renderowania strony na serwerze przy 1. loadzie. AngularJS nigdy nie będzie od tego szybszy, zwłaszcza, że jego założenia są po prostu z gruntu niewłaściwe. Zresztą Google nie błogosławi Angularowi – ich oczkiem w głowie jest Polymer. Angular był tylko i wyłącznie eksperymentem, który wyrwał się spod kontroli i stał się niesamowicie popularny. Nowy jQuery – z tym, że on niesie o wiele większe niebezpieczeństwa i jest w stanie zepsuć Sieć jeszcze bardziej.
React.js to po prostu bardzo wydajny system szablonów – nie wiem czego od niego chcesz ;) Bardzo ładnie można go wykorzystać zgodnie z duchem PE. A SPA z RESTful API równie dobrze może działać bez JS (bo RESTful API to… żądania do serwera – przecież nie trzeba ich wykonywać z poziomu JS). Jeśli ktoś pisze RESTful API, niedziałające bez JS, to tak naprawdę nie wie co to RESTful API. Kropka.

>No ale może jest to przykład domu zawieszonego na linie
To przykład domu, na który spadła bomba atomowa ;)

>Prototype, MooTools czy jakaś abstrakcja na potrzeby własne/przykładu?
Abstrakcja. Chociaż w gruncie rzeczy prawdopodobnie byłoby lepiej, gdybym użył tutaj Fetch API ;)

]]>
Autor: Michał Załęcki https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament#comment-2058 Mon, 10 Nov 2014 23:57:00 +0000 https://webroad.pl/?p=3722#comment-2058 > JS powinien jedynie zmieniać stan elementów strony
> Założenia PE są proste i nietrudne do spełnienia
> PE po prostu się opłaca
A tym czasem do drzwi perfekcyjnego domu backendowca zapukał AngularJS/React – będą robić SPA z jakimś RESTful API :P Tym sposobem opłacalność i prostotę szlak trafił. No ale może jest to przykład domu zawieszonego na linie :)

> new Request…
Prototype, MooTools czy jakaś abstrakcja na potrzeby własne/przykładu? :)

]]>