Front-end Frameworks: rozwiązania czy nadęte problemy?

Nowoczesne frameworki front-end wymagają pobrania środowiska programistycznego wraz z zależnościami i skompilowania kodu, zanim jeszcze spróbujesz wyświetlić go w przeglądarce. Czy to dobra rzecz? Czy problemem jest to, że budujemy bardziej złożone witryny, czy też same frameworki są złożone, wprowadzając niepotrzebny poziom złożoności?

Dzisiejsze tworzenie stron internetowych bardzo ewoluowało od lat 90.; jesteśmy w stanie tworzyć całe doświadczenia, które są bardzo zbliżone do tego, co może zrobić każda natywna aplikacja, a proces rozwoju również się zmienił. Dawno minęły czasy, kiedy bycie front-endowym programistą internetowym polegało na otwarciu Notatnika, wpisaniu kilku linijek kodu, sprawdzeniu go w przeglądarce i przesłaniu do folderu FTP.

Front-endowy rozwój sieci Web z przeszłości

Muszę zacząć od stwierdzenia oczywistego: świat nie jest taki, jak 10 lat temu. (Szokujące, wiem.) Jedyne, co pozostaje niezmienne, to zmiana. Kiedyś mieliśmy bardzo mało przeglądarek, ale było wiele problemów ze zgodnością. Dzisiaj nie widzisz zbyt wiele rzeczy takich jak „najlepiej oglądane w przeglądarce Chrome 43.4.1”, ale wtedy było to dość powszechne. Mamy teraz więcej przeglądarek, ale mniej problemów ze zgodnością. Czemu? Z powodu jQuery . jQuery zaspokoiło potrzebę posiadania standardowej, wspólnej biblioteki, która pozwalała pisać kod JavaScript, który manipuluje DOM bez martwienia się o to, jak będzie działał w każdej przeglądarce i w każdej wersji każdej przeglądarki — prawdziwy koszmar w latach 2000. .

Nowoczesne przeglądarki mogą standardowo manipulować DOM, więc zapotrzebowanie na taką bibliotekę znacznie zmalało w ostatnich latach. jQuery nie jest już potrzebne , ale wciąż możemy znaleźć wiele niezwykle przydatnych wtyczek, które od niego zależą. Innymi słowy, frameworki internetowe mogą nie być konieczne, ale nadal są wystarczająco przydatne, aby być popularne i szeroko stosowane. Jest to cecha wspólna dla większości popularnych frameworków internetowych, od React, Angular, Vue i Ember po modele stylizacji i formatowania, takie jak Bootstrap.

Dlaczego ludzie używają frameworków

W tworzeniu stron internetowych, tak jak w życiu, szybkie rozwiązanie jest zawsze przydatne. Czy kiedykolwiek robiłeś router w JavaScript? Po co przechodzić przez bolesny proces uczenia się, skoro można zainstalować npm framework front-end, aby rozwiązać ten problem? Czas to luksus, gdy klient chce, żeby coś zostało zrobione wczoraj , albo dziedziczysz kod od innego programisty zaprojektowany pod konkretny framework, albo integrujesz się z zespołem, który już korzysta z danego frameworka. Spójrzmy prawdzie w oczy – ramy istnieją nie bez powodu. Gdyby nie było dla nich korzyści, nikt by ich nie używał.

Więc jakie są niektóre z korzyści i unikalnych właściwości korzystania z frameworka do tworzenia stron internetowych?

Czas to pieniądz. Kiedy tworzysz projekt, a klient nie dba o to, jakiego frameworka używasz — a nawet prawdopodobnie nie jest nawet świadomy tego, czego używasz — zależy mu tylko na uzyskaniu wyników, a im szybciej, tym lepiej. Ugruntowane frameworki pozwalają stworzyć natychmiastowe poczucie postępu od samego początku, którego klient pragnie od pierwszego dnia. Dodatkowo im szybciej się rozwijasz, tym więcej zarabiasz, ponieważ czas uwolniony przez framework może zostać przeniesiony na więcej projektowanie.

Chodzi o społeczność. Przy wyborze frameworka jest to bardzo ważna kwestia — kto pomoże ci, gdy utkniesz w jakimś problemie? Ty i ja wiemy, że to się kiedyś wydarzy. Dojdziesz do miejsca, w którym będziesz musiał zrobić coś, do czego framework nie był przeznaczony lub do czego framework nigdy nie został zaprojektowany, aby zapewnić ci dostęp, więc posiadanie wspierającej Cię społeczności jest niezbędne. Programowanie — zwłaszcza freelancer — może być trudne, ponieważ zanurzasz się w wirtualnym świecie, a jeśli jesteś jedynym programistą front-endowym w zespole, oznacza to, że tylko Ty masz doświadczenie i wiedzę, aby znaleźć rozwiązanie. Ale jeśli front-end, którego używasz, ma solidne wsparcie, po drugiej stronie świata znajdzie się ktoś, kto zmierzy się z tym samym problemem i może być w stanie Ci pomóc.

Standardy są piękne. Czy zauważyłeś, że kiedy zajrzysz do starego kawałka własnego kodu, możesz łatwo się po nim poruszać? A przynajmniej łatwiej niż kawałek kodu napisany przez kogoś innego? Myślisz w określony sposób i masz swój własny sposób nazywania rzeczy i organizowania kodu. To jest standard. Wszyscy za nimi podążamy, nawet jeśli są tylko dla nas. Podobne rzeczy jemy na śniadanie, budzimy się o określonej godzinie i codziennie kładziemy klucze w tym samym miejscu. I rzeczywiście, gdybyśmy codziennie zmieniali nasze nawyki, życie byłoby o wiele trudniejsze tylko z powodu wymyślania różnych rzeczy. Czy kiedykolwiek zgubiłeś klucze, ponieważ umieściłeś je w innym miejscu niż zwykle? Normy ułatwiają życie. Pracując w zespole lub społeczności programistów stają się absolutnie niezastąpieni.

Frameworki zapewniają standard od momentu ich zainstalowania, prowadząc Cię do myślenia i kodowania w określony sposób. Nie musisz tracić czasu na tworzenie standardu ze swoim zespołem; możesz po prostu śledzić, jak rzeczy są robione w ramach. Ułatwia to wspólną pracę. Łatwiej jest szukać funkcji, gdy wiesz, że funkcja musi znajdować się w określonym pliku, ponieważ jest ona zbudowana w celu dodania trasy w SPA, a w Twojej strukturze wszystkie trasy są umieszczane w pliku o tej nazwie. Osoby o różnych poziomach umiejętności mogą ze sobą współpracować, jeśli masz taki poziom standaryzacji, ponieważ podczas gdy zaawansowani programiści wiedzą, dlaczego coś się robi w ten sposób, nawet młodsi programiści mogą przestrzegać samego standardu.

Kiedy frameworki zawodzą

Kilka lat temu powiedzenie czegoś w stylu „Nie używam frameworków — nie widzę z nich żadnych realnych korzyści” przyciągnęłoby do twoich drzwi ludzi z pochodniami i widłami. Ale dzisiaj coraz więcej osób zadaje sobie pytanie: „Dlaczego w ogóle powinienem używać frameworka? Czy naprawdę ich potrzebuję? Czy tak trudno jest bez nich kodować?

Z pewnością jestem jednym z nich — nigdy nie byłem fanem żadnego konkretnego frameworka i kodowałem bez nich przez całą swoją karierę. Jeśli mam wybór w tej sprawie, moim wyborem jest zawsze „Nie, dziękuję”. Od lat zajmuję się JavaScriptem, a wcześniej w ActionScript. Programowałem we Flashu, kiedy większość ludzi uważała go już za martwy. (Wiem, wiem… ale robiłem wiele animacji, a animacja w zwykłym HTML jest trudna.) Więc jeśli jesteś jednym z wielu, którzy nigdy nie myślą o kodowaniu bez frameworków, pokażę ci kilka powodów, dla których możesz walczyć.

„Jeden rozmiar dla wszystkich” to kłamstwo. Czy możesz sobie wyobrazić napisanie pojedynczego oprogramowania, które może zrobić wszystko, co osiągnąłeś w swojej karierze? To jeden z głównych problemów z frameworkami do tworzenia stron internetowych. Twój projekt ma bardzo specyficzne potrzeby, które zwykle rozwiązujemy dodając biblioteki, wtyczki lub dodatki rozszerzające zakres frameworka. Żaden framework nie oferuje 100% tego, czego potrzebujesz, i żaden framework nie składa się w 100% z rzeczy, które uznasz za przydatne.

Zbyt duża ilość kodu, którego nie używasz, może powodować opóźnienia w wczytywaniu witryny, co staje się coraz ważniejsze z każdym dodatkowym użytkownikiem. Inną kwestią jest to, że sposób myślenia „jeden rozmiar dla wszystkich” skutkuje niewydajnym kodem. Weźmy na przykład $('sku-product').html('SKU 909090'); , czyli kod jQuery, który ostatecznie, jak wszyscy wiemy, zostanie przetłumaczony na coś takiego jak document.getElementById('sku-product').innerHTML = 'SKU 909090'; .

Taka różnica w jednym wierszu może wydawać się nieistotna, ale zmiana treści konkretnego elementu strony jest właśnie zaletą Reacta. Teraz React przechodzi przez proces tworzenia reprezentacji DOM i analizowania różnic w tym, co próbujesz renderować. Czy nie byłoby łatwiej od samego początku kierować treści, które chcesz zmienić?

Ta plątanina chwastów, przez którą idziesz, to ciernie. Czy kiedykolwiek byłeś w sytuacji, w której używasz swojego frameworka i próbujesz dodać do niego bibliotekę, tylko po to, by zdać sobie sprawę, że potrzebna wersja biblioteki nie działa dobrze z wersją, której używasz? Czasami potrzeba więcej wysiłku, aby dwa fragmenty kodu działały razem, niż samo napisanie kodu. A ponieważ frameworki i biblioteki, których używasz, są często zbudowane na innych frameworkach i bibliotekach, które mogą mieć ukryte niezgodności, których nawet nie możesz przewidzieć, problem może stać się wykładniczo bardziej złożony, osiągając punkt, w którym nie da się nimi zarządzać, jeśli chcesz, aby projekt się rozwijał.

Nadążanie za Jonesami to rzecz. Czy kiedykolwiek pracowałeś nad projektem w AngularJS tylko po to, aby dowiedzieć się, że potrzebujesz czegoś, co nie pojawiło się przed wydaniem Angular 4? Czy w ogóle wiedziałeś, że Angular 5 został wydany? To kolejny ogromny problem; nawet jeśli trzymasz się jednego frameworka front-end, kiedy pojawi się nowe główne wydanie, wszystko może się zmienić tak bardzo, że kod, nad którym tak ciężko pracowałeś, nie będzie nawet działał w nowej wersji. Może to skutkować wszystkim, od irytujących drobnych zmian, które należy wprowadzić w wielu plikach, po całkowite przepisanie kodu.

Nadążanie za najnowszymi kompilacjami frameworka jest trudne, ale z tego samego powodu inne frameworki cierpią, gdy aktualizacje całkowicie się zatrzymują i nie mogą nadążyć za resztą technologii. W 2010 roku po raz pierwszy zostały wydane zarówno AngularJS, jak i Backbone. Dzisiaj Angular jest w piątej głównej wersji, a Backbone jest całkowicie poza centrum uwagi. Siedem lat wydaje się długim okresem. Jeśli tworzysz strony internetowe, prawdopodobnie zmieniły się one całkowicie pod względem estetyki i funkcji. Jeśli tworzysz aplikację, obstawianie niewłaściwej struktury może później postawić firmę w trudnej – i kosztownej – sytuacji, gdy trzeba będzie coś napisać od nowa.

Kiedy masz tylko młotek, wszystko wygląda jak gwóźdź. Jeśli często korzystałeś z frameworków do tworzenia stron internetowych, to prawdopodobnie Ci się przydarzyło, gdzie pojedyncza baza kodu definiuje kształt kodu, którego będziesz używać w przyszłości, nawet jeśli jest to tylko peryferyjnie powiązane. Powiedzmy, że zamierzasz zbudować platformę taką jak YouTube i chcesz użyć Framework X. Może nadejść moment, w którym, nawet jeśli brzmi to niedorzecznie w dzisiejszych czasach, zdecydujesz się użyć Flasha do filmów, ponieważ to jest to, co się dzieje wbudowany w ramy.

Struktury mają opinie i są silne; React na przykład wymusza korzystanie z JSX w określony sposób. Wszędzie widać, że kod jest używany w ten sposób. Czy istnieje alternatywa? TAk. Ale kto go używa? Nie zawsze jest to złe, ale jeśli potrzebujesz wykonać złożone animacje, możesz potrzebować tylko frameworka do animacji, a nie całego Reacta. Widziałem, jak ludzie robią szalone rzeczy, takie jak dodawanie jQuery do strony, aby dołączyć węzeł do elementu, coś, co można osiągnąć w waniliowym JS za pomocą document.getElementById('id_of_node').appendChild(node); .

Eval jest zły, ale .innerHTML jest makiaweliczny

Chcę poświęcić trochę czasu na zbadanie tego punktu osobno, ponieważ myślę, że jest to jeden z powodów, dla których więcej ludzi nie koduje bez frameworków. Kiedy zobaczysz, jak działa większość kodu podczas próby dodania czegoś do DOM, znajdziesz garść kodu HTML wstrzykniętego przez właściwość .innerHTML . Wydaje się, że wszyscy zgadzamy się, że eval jest zły do ​​uruchamiania kodu JavaScript, ale chcę tutaj umieścić .innerHTML w centrum uwagi. Kiedy wstrzykujesz kod HTML jako zwykły ciąg, tracisz wszelkie odniesienia, które mogłeś mieć do dowolnego z utworzonych węzłów. Prawdą jest, że możesz je odzyskać, używając getElementsByClassName lub przypisując im id , ale jest to mało praktyczne. Próbując zmienić wartość jednego z węzłów, zauważysz, że ponownie renderujesz cały kod HTML.

To jest dobre, gdy zaczynasz kodować. Możesz łatwo zrobić wiele prostych rzeczy bez większego doświadczenia. Problem występuje ze złożonością nowoczesnych stron internetowych, które zwykle przypominają aplikacje — oznacza to, że musimy stale zmieniać wartości naszych węzłów, co jest operacją kosztowną, jeśli robisz to przez ponowne dołączenie całej struktury przez .innerHTML . React skutecznie rozwiązuje ten problem poprzez cień DOM, a Angular rozwiązuje go, używając powiązania jako łatwego sposobu na modyfikację wartości wyświetlanej na stronie. Jednak można to również dość łatwo rozwiązać, śledząc utworzone węzły i zapisując te, które zostaną ponownie użyte lub zaktualizowane w zmiennych. Istnieją również inne powody, aby ogólnie trzymać się z daleka od .innerHTML .

Największe mity na temat kodowania bez frameworków

Czas to pieniądz. Tak, przywracam tę koncepcję z wcześniejszej wersji. Wiele osób ma wrażenie, że jeśli przestaną używać popularnego frameworka internetowego, natychmiast przeniesiemy się do Internetu lat 90., kiedy <marquee> był ulubionym tagiem wszystkich, obracające się GIF-y na stronie Geocities były modne i awanturnicze, Alta Vista była do wyszukiwania w sieci, a liczniki trafień były wszechobecne.

W przypadku frameworków internetowych Twoje pierwsze wiersze kodu wydają się przynosić dużo oszczędności czasu, ale w pewnym momencie zyski zamieniają się w straty. Spędzasz czas czytając o tym, jak sprawić, by framework robił rzeczy, do których nie jest stworzony, jak zintegrować biblioteki i sprawić, by dobrze się z nim bawiły, i dowiadujesz się, że kod, który zbudowałeś zgodnie ze standardami frameworka, nie działa w ogóle działać, a teraz musisz to przepisać. Kiedy robisz rzeczy bez ram, zaczynasz wolniej, ale robisz stałe postępy. W końcu chodzi o to, gdzie chcesz, aby była łatwa. Całkowity czas nie będzie miał większego znaczenia.

Mój kod będzie dłuższy niż Wielki Mur. Pisanie bez ram jest jak kupowanie filmu zamiast subskrybowania usługi przesyłania strumieniowego. Nie masz natychmiastowego dostępu do setek filmów, które chcesz obejrzeć, ale także nie musisz wydawać pieniędzy na tysiące innych filmów, których pobranie ze sklepu nigdy nawet byś nie rozważał. Możesz po prostu napisać, czego potrzebujesz.

Czy pośrednik jest przydatny? Pewny. Ale zwykle nie jest to konieczne . Każda linijka kodu, którą piszesz, ma większe znaczenie, ponieważ nie musisz dostosowywać się do wymagań frameworka. Może się wydawać, że piszesz więcej kodu za pomocą czystego JavaScriptu, ponieważ sposób tworzenia elementów DOM zajmuje linie do utworzenia elementu, dołączenia go do DOM i być może dodania klasy do stylizacji, w przeciwieństwie do wywoływania pojedynczej linii kod w JSX. Ale jeśli porównasz kod przy użyciu biblioteki takiej jak jQuery lub React, waniliowy JS może mieć podobną długość. Czasem jest dłuższy, ale czasem też krótszy.

Nie ma potrzeby odkrywania koła na nowo. Mantra profesorów informatyki na całym świecie. I to prawda — po prostu nie musi to oznaczać konkretnie frameworków. Wysłanie żądania Ajax w celu załadowania lub zapisania danych jest wymogiem na przykład w prawie każdej aplikacji internetowej, ale brak frameworka nie oznacza, że ​​musisz za każdym razem pisać kod od nowa. Możesz stworzyć własną bibliotekę lub bazę kodu, lub możesz wyodrębnić kod od innych. Im jest mniejszy, tym łatwiej jest go modyfikować lub dostosowywać w razie potrzeby, więc przydaje się, gdy potrzebujesz czegoś specyficznego dla projektu. Łatwiej jest zmodyfikować 100-200 wierszy kodu niż przeszukiwać górę plików, które może zawierać biblioteka lub platforma innej firmy.

Będzie działać tylko dla małych projektów. To bardzo powszechny mit, ale wcale nie jest prawdziwy; obecnie pracuję nad całym systemem do zarządzania wszystkimi aspektami firmy online w jednym miejscu, łącznie z modułem, który jest czymś w rodzaju Dysku Google. Niezależnie od tego, czy z frameworkami, czy bez nich, przechodzę przez bardzo podobne kroki i napotykam bardzo podobne problemy. Różnica jest znikoma. Jednak bez frameworków cały mój kod jest mniejszy i łatwiejszy w zarządzaniu.

CHCĘ DOWODU

Dobra. Przestańmy mówić o teorii i przejdźmy do rzeczywistego przykładu. Kilka dni temu musiałem pokazać listę marek z logo sklepu. Początkowy kod używał jQuery, ale miał problem, gdy podczas ładowania w Mozilli wyświetlał ikonę uszkodzonego obrazu dla marek, które nie miały jeszcze wgranych logo. Nie możemy sprawić, by sklep wyglądał na niedokończony tylko dlatego, że firma X nie zakończyła jeszcze pracy, ale funkcja musiała zostać uruchomiona.

Poniższy kod używa odpowiednika .innerHTML w jQuery:

 var list_brand_names = ['amazon', 'apple', 'nokia']; var img_out = ''; for (i=0;i<list_brand_names.length;i++) { var brandName = list_brand_names[i].toLowerCase(); img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' /></a>"; } jQuery("#brand-images").html(img_out);

Nie zagłębiając się zbytnio w zalety i wady jQuery, problem polega na tym, że nie mamy żadnego odniesienia do obrazów, które stworzyliśmy. Chociaż istnieją rozwiązania, które nie wymagają zmiany kodu, skorzystajmy z okazji, aby zobaczyć, jak można to zrobić bez żadnej biblioteki:

 var brands = ['amazon', 'apple', 'nokia']; var brand_images = document.getElementById("brand-images"); for (var iBrand = 0; iBrand < brands.length; iBrand++) { var link = document.createElement('a'); link.setAttribute('href', '/pages/' + brands[iBrand]); link.style.display = 'none'; brand_images.appendChild(link); var image = new Image(); image.src = "images/" + brands[iBrand] + "png"; image.onload = function(){ this.parentNode.style.display = ''; } link.appendChild(image); }

Oryginalny kod jQuery miał sześć linii, podczas gdy waniliowe rozwiązanie JS zajmowało dwanaście. Aby rozwiązać problem, ukrywanie każdego obrazu do czasu jego załadowania zajmuje dwa razy więcej czasu na kodowanie. Spójrzmy więc na alternatywę. Czy można to również rozwiązać w jQuery? Sprawdź to:

 img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' onload="showImage(this)"/></a>"; function showImage(image){ image.parentNode.style.display = ""; }

Z kilkoma dodatkowymi linijkami kodu, jest teraz tylko trzyliniowa różnica między jQuery a wanilią, ale w jQuery widać, że linia img_out szybko staje się bardzo złożona, do tego stopnia, że ​​trzeba się zatrzymać i zastanów się dokładnie nad tym, co robisz. Kodowanie DOM bezpośrednio przy użyciu funkcji węzła do dodawania atrybutów, funkcji itp. może być dłuższe, ale każda linia ma jaśniejsze, bardziej precyzyjne znaczenie, co ułatwia czytanie i utrzymanie w przyszłości.

Przyjrzyjmy się Reactowi:

 function BrandLink(props) { var url = "images/" + props.brand + ".png"; return (<a href="{props.brand}"><img src={url}/></a>); } class Brands extends React.Component { constructor() { super(); this.state = {brands: ['amazon', 'apple', 'nokia']}; } render() { const links = this.state.brands.map((step, move) => { return (<BrandLink brand={step} key={step}/>); }); return (<div className="brands">{links}</div>); } } ReactDOM.render(<Brands />, document.getElementById("root"));

Ta wersja jest wyraźnie nieoptymalna. Kod nie jest krótszy niż w wanilii, a my wciąż nie doszliśmy nawet do rozwiązania problemu i ukrycia linków, dopóki obraz w nich się nie załaduje.

Dla każdego przykładu wyniki będą inne. Czasami jQuery będzie krótsze. Czasami wygrywa React. Są chwile, kiedy waniliowy JS może być krótszy niż oba. W każdym razie celem nie było udowodnienie, że jedno jest z natury lepsze od drugiego, ale pokazanie, że nie ma znaczącej różnicy między używaniem vanilla JS a używaniem frameworka, jeśli chodzi o długość kodu.

Wniosek

Podobnie jak w przypadku każdego prawdziwego problemu, nic nie jest czarne ani białe. Kodowanie bez frameworków do tworzenia stron internetowych może być najlepszym rozwiązaniem dla niektórych Twoich projektów, a koszmarem w innych. Tak jak w przypadku każdego narzędzia, kluczem jest nie tylko nauczenie się, jak z niego korzystać, ale także kiedy i jakie mogą być zalety i wady korzystania z niego. Kodowanie w czystym JavaScript jest takie samo, jak w przypadku każdego frameworka — opanowanie go zajmuje trochę czasu, zanim poczujesz się komfortowo z niego korzystać.

Ale kluczowa różnica, przynajmniej dla mnie, polega na tym, że frameworki pojawiają się i znikają, a nawet jeśli framework jest popularny przez długi czas, może radykalnie zmienić się z jednej wersji na drugą. Czysty JavaScript będzie opcją na znacznie dłużej, dopóki nie przestanie być całkowicie istotny i pojawi się jakiś inny język. Nawet wtedy będzie więcej koncepcji i strategii, które można przenieść bezpośrednio z jednego języka do drugiego, niż w przypadku jednego frameworka do innego. Czas i wysiłek są mniej więcej równoważne w przypadku pojedynczego projektu, zmniejszenie amortyzacji wiedzy i lekcje, które możesz zabrać ze sobą do następnego wyzwania, to bardzo ważne czynniki, które należy wziąć pod uwagę.