Przygotowujemy cotygodniowe przeglądy już od ponad roku i dlatego najwyższa pora przyjrzeć się najważniejszym trendom i wydarzeniom z tego okresu. Łapcie kubek gorącej kawy i zapraszamy do lektury!
To już 52 edycja naszego frontendowca przeglądu, a to oznacza, że przygotowujemy dla Was nasze podsumowania już od ponad roku! Aby uczcić to doniosłe wydarzenie postanowiliśmy wybrać 11, naszym zdaniem, najciekawszych trendów i wydarzeń minionego roku (kolejność dobrana losowo). Na starcie ostrzegam: przygotujcie sobie spory kubek z kawą, bo to nie będzie krótka lektura (ale za to jaka ciekawa!) ☕️
1. React 17 i React Server Components
W październiku 2020 powitaliśmy kolejną dużą wersję Reacta. Pomimo dużego numerka (17), wydanie nie zawierało nowych funkcjonalności i skupiało się na ułatwieniu bardziej granularnych aktualizacji w przyszłości (zamiast migrować całą aplikację za jednym razem, możliwe ma być migrowanie jej po kawałku i współistnienie kilku wersji Reacta w jednej aplikacji).
Kiedy już utwierdziłem się w przekonaniu, że React popadł w stagnację, tuż przed świętami Bożego Narodzenia z tego przeświadczenia wybudził mnie Dan Abramov przedstawiając React Server Components. Koncepcja ta to wariancja Server Side Renderingu, która pozwala renderować część komponentów po stronie klienta, a część po stronie serwera. Podejście to minimalizuje ilość kodu wysyłanego do przeglądarki (biblioteki importowane przez komponenty renderowane na serwerze nie są pobierane przez klienta) i daje dostęp do typowo serwerowych interfejsów z poziomu Reacta (bazy danych, system plików). Oczywiście rozwiązanie ma też swoje ograniczenia: komponenty renderowane na serwerze nie mogą przechowywać stanu i obsługiwać interaktywnych akcji. Nie wiadomo, kiedy i czy React Server Components osiągną status produkcyjny, ale zdecydowanie pomysł ten był jednym z największych w ostatnich miesiącach powiewów świeżości we Frontendowym Świecie.
Jeśli jesteśmy już w kontekście React, to warto wspomnieć również o powstaniu React Working Group, które to ma być przestrzenią do komunikacji między społecznością, a ludźmi stojącymi za implementacją nowych funkcjonalności. Grupa ta powstała przy okazji ogłoszenia alfy Reacta 18, która w odróżnieniu od wersji 17, zawierać będzie całą masę nowych interesujących funkcji (między innymi wsparcie dla Suspense w Server Side Renderingu i lepsze batchowanie renderów). Pozostaje tylko cierpliwie czekać na wersję beta i oficjalną wydanie.
Przeczytaj więcej:
https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html
https://reactjs.org/blog/2021/06/08/the-plan-for-react-18.html
Odkryj więcej treści IT dopasowanych do Ciebie
W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Angular 11, Angular 12… nudy!
Na przestrzeni ostatnich 12 miesięcy dostaliśmy dwie nowe wersje Angulara, i szczerze mówiąc, były to dwa wydania nudne jak flaki z olejem. W ramach wersji 11 w życie wdrożona została “Operacja Byelog”, w ramach której otagowany został cały backlog błędów i feature requests zgłoszonych przez społeczność (udało się nawet wdrożyć w życie kilka z nich). Oprócz tego doszło automatyczne inlineowanie czcionek, upiększone logi i przyśpieszone buildy. Wersja 12 w porównaniu z 11 wygląda odrobinę ciekawiej. Dostaliśmy w niej pełne wsparcie dla Webpack 5, deprekacje View Engine i Protractora oraz kilka drobnych usprawnień. Reasumując Angular rozwija się stabilnie, a na horyzoncie jak na razie brak większych rewolucji (chyba jedyną, która przychodzi mi do głowy jest rozpoczęcie prac nad opcjonalnymi modułami, ale nie wiadomo jednak, kiedy ma to szansę trafić w nasze ręce).
Przeczytaj więcej:
https://blog.vived.io/frontend-thursday-vol-32/
https://github.com/angular/protractor/issues/5502
3. Vue 3.0
Spośród trzech największych frontendowych frameworków zdecydowanie najwięcej działo się w obozie Vue. Po prawie dwóch latach developmentu i trzech miesiącach otwartej bety, trzecia wersja Vue doczekała się oficjalnego releasu wersji 3.0. Framework otrzymał wiele od dawna wyczekiwanych usprawnień. Virtual DOM został przepisany w celu poprawy wydajności i lepszej obsługi TypeScriptu. Dodane zostało nowe Composition API, które wielu uważa za reactowe hooki zrobione dobrze. Oprócz tego w nowej wersji znajdziemy Conditional Suspend Rendering, nierenderowane w HTML fragmenty czy natywne wsparcie dla portali (i musicie przyznać, że widać tutaj wiele inspiracji z ekosystemu Reacta).
Vue 3.1 dostarczył narzędzie ułatwiające migrację z wersji 2, a Vue 3.2 dalsze ulepszenia w kierunku wsparcia WebComponentów oraz Server Side Renderingu. Warto wspomnieć również, że Vuex, czyli najpopularniejszej w tym środowisku biblioteki do zarządzania stanem, również wspiera już Vue w wersji 3,0. No i oficjalnym narzędziem do budowaniu Vue jest niezwykle szybki Vite, który to również niedawno doczekał się kolejnej dużej wersji.
Przeczytaj więcej:
https://blog.vuejs.org/posts/vue-3-one-piece.html
https://blog.ninja-squad.com/2021/06/07/what-is-new-vue-3.1/
https://blog.vuejs.org/posts/vue-3.2.html
4. Duże pieniądze, nowo powstające firmy i upadek Babela
Pieniądze rządzą światem i nie inaczej jest w przypadku naszego małego frontendowego światka. A jeśli chodzi o finanse, to mam wrażenie, że w minionych 52 tygodniach naprawdę sporo się działo. Na początek weźmy na tapetę trend, jakim było powstanie firm wokół otwarto źródłowych projektów, czyli Rome i Deno. Oprócz uruchomienia działalności, obu tym projektom udało się zgromadzić od inwestorów odpowiednio 5 i 4.5 miliona dolarów i zatrudnić co najmniej kilku deweloperów w pełnym wymiarze czasowym. W przypadku Deno można już mówi o pozytywnych efektach tego działania: nowe wersje środowiska uruchomieniowego pojawiają się regularnie, i co do zasady zawierają przynajmniej jedną nową ciekawą funkcjonalność. Abstrahując od konkretnych przypadków tych firm: dobrze widzieć, że są na rynku ludzie i organizacje gotowe zainwestować w otwarto źródłowe projekty. Pozostaje tylko mieć nadzieję, że Deno i Rome odniosą sukces i przetrą drogę dla podobnych inwestycji w przyszłości.
Nie dla wszystkich ten rok był jednak równie kolorowy. Na blogu Babela opublikowana została notatka informująca, że osobom odpowiedzialnym za utrzymanie i rozwój narzędzia zaczyna brakować pieniędzy. Jeśli interesują Was twarde dane, to Babel do gromadzenia środków korzysta z OpenCollective, a dane o budżecie są publicznie dostępne. W momencie publikacji artykułu Babel dysponował około 15 tysiącami dolarów miesięcznego budżetu, co nie starczało na opłacenie trzech pracujących nad nim deweloperów. Zaoszczędzone w lepszych czasach pieniądze miały wystarczyć na utrzymanie zatrudnienia do końca 2021 roku, ale warto nadmienić, że Babel oryginalnie aspirował do zatrudnienia aż 4 deweloperów.
Jak to się stało, że narzędzie używane przez większość JavaScript developerów prawie zbankrutowało? Babel w ostatnich latach, dzięki coraz prostszej konfiguracji środowisk deweloperskich stał się dla większości programistów przeźroczysty. Mogłoby się wydawać, że ogłoszenie tak dramatycznych informacji skłoni do refleksji i szybko znajdą się majętni sponsorzy chcący wesprzeć projekt. Jak się jednak okazało, za notatką nie popłynął strumień monet, a w internecie zawrzało. Zapytacie, dlaczego? Otóż do tej pory aż 10 tysięcy dolarów z miesięcznego budżetu wpływało na konto jednego dewelopera i nie była to wcale osoba z największą liczbą kontrybucji. Na Twitterze rozgorzała dysputa na temat odpowiedzialności osoby utrzymującej projekt Open Source, w której głos zabrały nawet takie tuzy jak Evan You (twórca Vue), czy Sebastian McKenzie (twórca Rome). Z jednej strony jasnym jest, że zbieranie funduszy, pisanie notatek o nowych funkcjonalnościach i ogólnie pojęta promocja, to również praca, za którą należy się wynagrodzenie, a z drugiej stawiane jest pytanie o granicę między dostarczaniem nowych funkcji, a czasem poświęconym na inne aktywności. Atmosferę podgrzewał jeszcze dysonans między zarobkami Hernego (głównego maintenera Babela) i pozostałych deweloperów (10000$ vs 2000$). Co prawda, wraz z publikacją wspomnianej wyżej notatki, ogłoszono również wyrównanie zarobków wszystkich osób zaangażowanych w projekt, ale wielu zarzuca, że to właśnie niesprawiedliwy podział budżetu doprowadził do obecnej sytuacji.
Od publikacji wspomnianego artykułu minęło już kilka miesięcy i wydaje się, że Babel przeszedł przez ten kryzys wizerunkowy bez szwanku. Obecnie z OpenCollective wynika, że projekt miesięcznie gromadzi około 20000$, a to w zupełności wystarcza na opłacenie trzech deweloperów.
Przeczytaj więcej:
https://techcrunch.com/2021/06/23/vercel-raises-102m-series-c-for-its-next-js-based-front-end-development-platform/
https://deno.com/blog/the-deno-company
https://rome.tools/blog/announcing-rome-tools-inc/
https://babeljs.io/blog/2021/05/10/funding-update.html
https://news.ycombinator.com/item?id=27116357
5. Kontrowersje wokół FLoC i Supercookies
Temat Supercookies i FLoC to chyba najbardziej burzogenny temat ostatnich miesięcy. Pierwsze z tych tajemniczych określeń zostało ukute początkiem roku przez Firefoxa i jest synonimem na cały zbiór sprytnych rozwiązań mających na celu śledzenie interakcji użytkownika pomiędzy witrynami, zazwyczaj w celu lepszej personalizacji reklam (jako przykład Mozilla podała wykorzystanie do tego cache’u przeglądarki). Na tym etapie wszystkie przeglądarki, poza Chrome, chwalą się specjalnym wsparcie dla blokowania Supercookies. Dlaczego Google zwleka z wprowadzeniem takiej funkcjonalności? No cóż, jeśli jednym z Waszych głównych źródeł dochodu byłyby targetowane reklamy, to prawdopodobnie też kręcilibyście nosem na takie rozwiązanie…
Google zdaje sobie jednak sprawę z trendu dbania o prywatność w sieci i dlatego zaproponował swoją alternatywę dla Supercookies, czyli FLoC (Federated Learning of Cohorts). Algorytm ten po stronie klienta analizuje historię przeglądania i przypisuje użytkownika do odpowiedniej kohorty. W ten sposób dane o aktywności użytkownika nigdy nie opuszczają jego przeglądarki, a reklamodawcy nie tracą możliwości dobrego targetowania swoich reklam. Na papierze plan brzmi całkiem nieźle, ale jeśli zagłębić się w szczegóły, to okazuje się, że nie jest już tak optymistycznie. Do tej pory, jeśli dana strona chciała jednoznacznie zidentyfikować użytkownika, to prawdopodobnie musiała przeanalizować kilka milionów rekordów. Po wdrożeniu nowego rozwiązania liczba ta zmniejszy się do kilku tysięcy, bo strony będą mogły odczytać id kohorty i w ten sposób mocno zawęzić obszar poszukiwań. Ponadto, jeśli na stronie logujemy się za pomocą maila, to natychmiast będzie ona w stanie powiązać nas z naszymi zainteresowaniami, a nawet zapisać je u siebie na serwerze. FLoC domyślnie analizuje również wszystkie strony na jakie wchodzimy (w tym te rządowe czy powiązane z naszymi danymi zdrowotnymi), a nie tak jak to miało miejsce do tej pory, gdzie śledzeni byliśmy tylko na stronach do których załączono odpowiedni skrypt of Google’a albo Facebooka.
Swój publiczny sprzeciw przeciwko FLoC wyraziło sporo firm zajmujących się prywatnością (między innymi Brave i DuckDuckGo), a presja ze strony użytkowników zmusiła Google do odroczenia globalnego wdrożenia algorytmu do swojej przeglądarki do 2023 roku. Dodatkowy czas firma z Mountain View zamierza wykorzystać na rozpoczęciu publicznych dyskusji dotyczących prywatności w kontekście personalizacji reklam, jak i negocjacjach z innymi dużymi graczami w świecie przeglądarek i e-commerce.
Przeczytaj więcej:
https://brave.com/why-brave-disables-floc/
https://www.eff.org/deeplinks/2021/03/googles-floc-terrible-idea
https://arstechnica.com/gadgets/2021/06/google-delays-floc-rollout-until-2023/
6. Hermes działa na iOS
W minionych dwunastu miesiącach otrzymaliśmy dwie nowe nowe wersje React Native (0.64 i 0.65), ale ciężko doszukiwać się w nich rewolucji. Większość zmian dotyczyła usprawnień wydajności, accessibility, czy kompatybilności z procesorami M1. W tym szarym łez padole znalazła się jednak jedna funkcja, która wzbudziła sporo zamieszania: wsparcie dla silnika Hermes na urządzeniach z systemem iOS.
Jeśli żyjecie poza bańką React Native i nie kojarzycie Hermesa, to jest to silnik JavaScriptu od samego Facebooka, który ma redukować Time to Interactive, być przystosowanym do urządzeń mobilnych i tworzony jest od początku z myślą o dobrym wsparciu dla React Native. Jako przykładowe usprawnienie niech posłuży nam dodany w ostatnim releasie Garbage Collector (o pasującej do konwencji nazwie Hades), który skraca fazę stop-the-world nawet 30 krotnie i zmniejsza zużycie procesora nawet o 50%.
Dlaczego jest to ważne wydarzenie? Otóż Apple od lat narzuca wszystkim rozwijany przez siebie silnik JavaScriptCore. Od tej reguły do tej pory nie było wyjątków i nawet Chrome na mobilnych urządzeniach z jabłuszkiem pod spodem, używał silnika Safari. To co umożliwiło powstanie Hermesa na urządzenia z iOS, to drobna zmiana w regulaminie AppStore mówiąca, że ograniczenie dotyczy tylko interpretowanego kodu (Hermes pakowany jest do plików binarnych). Niestety nie oznacza to, że szybko zobaczymy na iPhonach Chrome z v8 (z drugiej strony może to i dobrze, bo Safari jest ostatnią przystanią powstrzymującą dominację v8 na rynku).
Przeczytaj więcej:
https://reactnative.dev/blog/2021/03/12/version-0.64
https://www.reddit.com/r/reactnative/comments/j8gzjz/hermes_is_coming_to_ios/
https://reactnative.dev/blog/2021/08/17/version-065
https://hermesengine.dev/docs/hades/
7. Internet Explorer 11 w końcu umiera
Projekty ogłaszające koniec wsparcia dla Internet Explorera 11 wyrastały w tym roku, jak grzyby po deszczu. Angular oznaczył wsparcie dla IE 11 jako deprecated i usunie je całkowicie wraz z pojawieniem się Angulara 13. Vue ogłosiło usunięcie ze swojej roadmapy dla wersji 3 implementację kompatybilności z IE 11. Przed kilkoma tygodniami AWS ogłosił koniec wsparcia dla IE 11 przez Amazon Web Services. Listę zamyka sama firma matka przeglądarki, która oprócz ogłoszenia końca wsparcia dla IE 11 w produktach Microsoft 365, ogłosiła również, że 15 czerwca 2022 roku przestanie wspierać IE 11 w wersji dla systemu Windows 10. Niestety w przypadku pozostałych wersji nie jest już tak kolorowo, bo na Windows 7 i 8 IE 11 będzie wspierany do 1 października 2023, a na wersji serwerowej i IoT aż do 1 września 2029 (auć!).
Jeśli pracujecie w organizacji, która wykorzystuje aplikacje działające tylko na IE 11 ( z wyliczeń Microsoftu wynika, że na jeden biznes przypada 1,678 takich aplikacji) to nie musicie szykować się na koniec świata. Silnik stojący za pradziadkiem współczesnych przeglądarek nadal będzie utrzymywany, a wraz z nim tryb kompatybilności wstecznej dla Edge. Jeśli chodzi natomiast o ciekawostki, o których wszyscy oprócz mnie słyszeli, to Internet Explorer oferuje opcję wyświetlenia banera zachęcającego do migracji na nowszą przeglądarkę i umożliwia łatwe przeniesienia historii, ciasteczek i haseł.
Przeczytaj więcej:
https://blogs.windows.com/windowsexperience/2021/05/19/the-future-of-internet-explorer-on-windows-10-is-in-microsoft-edge/
https://github.com/vuejs/rfcs/discussions/296
https://github.com/angular/angular/issues/41840
https://aws.amazon.com/blogs/aws/heads-up-aws-support-for-internet-explorer-11-is-ending/
9. Node.js w przeglądarce, czyli WebContainers
Jak dziś pamiętam, jaką falę zainteresowania w sieci wzbudziło ogłoszenie na Google I/O przez StackBlitz WebContainers. Czym jest ta tajemnicza technologia? Otóż jest to środowiska uruchomieniowe Node.js, działające całkowicie w przeglądarce i oparte głównie na WebAssembly. Do pełnego szczęścia potrzebne są jeszcze integracje z systemem operacyjny i na tym polu nie jest idealnie, ale ludziom ze StackBlitz udało się dowieść całkiem sporo (np. emulacja fs jest możliwa dzięki wykorzystaniu File System Access API). W architekturę rozwiązania uwikłany jest też ServiceWorker, który przechwytuje odpowiednie requesty i przekierowuje je do naszego WebContainer (dzięki jego obecności całe rozwiązanie działa również offline).
W tej beczce miodu jest też niestety łyżka dziegciu (a nawet kilka!). Z poziomu WebContainers nie połączymy się z bazą danych, bo przeglądarki nie mogą komunikować się za pomocą niestandardowych protokołów (tutaj zespół StackBlitz liczy na pojawienie się w przyszłości w przeglądarkach Native Sockets). Ponadto na ten moment WebContainers działają tylko w silnikach opartych na Chromium, więc nie uświadczymy ich chociażby na mobilnych urządzeniach z jabłuszkiem czy w Firefox (co może boleć podwójnie, bo to właśnie Mozilla utrzymuje, zdaniem wielu, najlepszy silnik WASM). Oprócz tego lista wspieranych frameworków jest raczej krótka, aczkolwiek trzeba przyznać, że zawiera chyba wszystkie najpopularniejsze opcje (Express.js, Koa, NestJS, Next.js, Nuxt) Jeśli WebContainers aspirują do zostania w pełni funkcjonalnym środowiskiem deweloperskim, to przed nimi jeszcze długa droga, ale jak na wersję beta to jest naprawdę nieźle.
Przeczytaj więcej:
https://blog.stackblitz.com/posts/introducing-webcontainers/
https://twitter.com/stackblitz/status/1395409316270772224
9. Tailwind 2.0 i kompilator JIT dla Tailwinda
Zdaniem wielu podejście utilty-first idealnie pasuje do współczesnych frontendowych frameworków i prawdopodobnie właśnie z tego powodu jego popularność nieustannie rośnie Jak wynika z State of CSS 2020, jest to framework generujący największe zainteresowanie w swojej kategorii. Ponadto względem 2019 roku zaliczył on wzrost o 20 punktów procentowych, jeśli chodzi o wdrożenie na produkcję. Na tym etapie możemy już mówić o tym, że zastąpił on na tronie cssowych frameworków Bootstrapa.
W listopadzie 2020 doczekaliśmy się Tailwinda w wersji 2.0, a wraz z nią między innymi rozszerzoną paletę kolorów, nowy breakpoint dla największych ekranów i wsparcie dla dark-mode. Na najciekawsze nowości musieliśmy jednak poczekać do marca 2021 roku, kiedy to ukazał się kompilator Just-In-Time dla Tailwinda. Przy wykorzystaniu zwykłego kompilatora do przeglądarki dostarczany był pokaźny plik zawierający całego Tailwinda (czasami mającego nawet 10MB!). W trybie produkcyjnym natomiast standardem było odchudzanie paczki przy pomocy PurgeCSS. Nowy Kompilator zupełnie zmienia to zachowanie i teraz zarówno w trybie produkcyjnym, jak i deweloperskim wraz z dodaniem kolejnej klasy do elementu, dynamicznie pojawiać się ona będzie w wynikowych plikach styli. Nie wpłynie to znacząco na rozmiar bundla, ale za to poprawi developer experience – w trakcie developmentu przeglądarka będzie musiała obsługiwać o rząd wielkości mniejszy plik CSS. Nie są to (niestety) jedyne zmiany, jakie wprowadza nowy kompilator. Nowy sposób generowania klas umożliwia specyfikację jednostek w pikselach i kolorów w postaci hexa. Jest to rozwiązanie niezwykle wygodne, ale wydaje się również niepokojąco zbliżone do inline styles. No cóż, z wielką mocą idzie wielka odpowiedzialność – zobaczymy, czy programiści sprostają temu wyzwaniu.
Przeczytaj więcej:
https://blog.tailwindcss.com/just-in-time-the-next-generation-of-tailwind-css
https://blog.tailwindcss.com/tailwindcss-v2
10. Webpack 5
Webpack od dawna jest branżowym standardem i pomimo rosnącej konkurencji (a szczególnie ciekawie wygląda zwłaszcza ta oparta o esbuild) na razie nic nie zapowiada jego schyłku. Prawie równo rok temu ukazała się długo oczekiwana wersja 5 tego narzędzia do pakowania aplikacji i gdybyśmy mieli tutaj przyjrzeć się wszystkim nowościom, jakie wprowadzono, to cóż, prawdopodobnie musielibyśmy dwukrotnie wydłużyć ten artykuł . W związku z tym wspomnę tylko o jednej funkcjonalności, o której na przestrzeni ostatniego roku było najgłośniej, a jest nią Module Federation. Funkcjonalność ta ma umożliwiać dynamiczne doczytanie innej aplikacji i współdzielenie zależności. Jeśli coś Wam to przypomina to dobrze kombinujecie: Module Federation to feature zaprojektowany, aby wspierać mikrofrontendy (które swoją drogą zasługują chyba na tytuł najgorętszego catch phrase zeszłego roku).
Warto napomknąć również, że rynek szybko postanowił nadgonić standard i narzędzia dające wsparcie dla Webpacka 5 wyrastały jak grzyby po deszczy (wspomnijmy chociażby Angulara czy Nexta). No i nie było chyba takiej notatki o wsparciu dla Webpacka 5, w której nie wspomniano by o Module Federation i mikrofrontendach.
Przeczytaj więcej:
https://webpack.js.org/blog/2020-10-10-webpack-5-release/
https://webpack.js.org/concepts/module-federation/
https://scriptedalchemy.medium.com/webpack-5-module-federation-stitching-two-simple-bundles-together-fe4e6a069716
https://nextjs.org/docs/messages/webpack5
Odkryj więcej treści IT dopasowanych do Ciebie
W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!
Zainstaluj teraz i czytaj tylko dobre teksty!
11. MDN Web Docs umiera, powstaje Open Web Docs
Nie jest tajemnicą, że Mozlilla w ostatnim okresie nie najlepiej radzi sobie, jeśli chodzi o kwestie finansowe. Skutkiem zaistniałej sytuacji były cięcia kosztów, redukcje etatów i przerzuceniem ludzi do rozwoju potencjalnie dochodowych produktów (takich jak na przykład niedawno opublikowany VPN wbudowany w Firefox). Na restrukturyzacji firmy ucierpiał niestety zespół odpowiedzialny za MDN Web Docs – dokumentacji, z którą do czynienia miał chyba każdy deweloper.
Świat nienawidzi jednak próżni i niedługo po ogłoszeniu redukcji etatów w Mozilli, światło dzienne ujrzało Open Web Docs. Nie dajcie się zmylić nazwie – to nie jest kolejna innowacyjna biblioteka, a organizacja, która za zadanie wzięła sobie wspieranie otwartych dokumentacji weba (w tym wspomnianego wcześniej MDN Web Docs). Open Web Docs do tej pory otrzymało już spory zastrzyk gotówki, bo oprócz indywidualnych deweloperów, finansowo wsparły ją Google, Microsoft i Facebook wpłacając po 250 tysięcy dolarów. Pozostaje tylko trzymać kciuki za dalsze wsparcie od największych graczy i czekać na rezultaty pracy – w końcu dobrej dokumentacji nigdy za wiele.
Przeczytaj więcej:
Odkryj więcej świetnych treści!
- Rozsądna ilość treści
- Tylko wysoka jakość
- Pełne dopasowanie do Twoich potrzeb!
