Zaloguj się aby uzyskać dostęp do dodatkowych opcji [zamknij]

Dlaczego nie: MySQL, Symfony, CakePHP, Smarty, jQuery, Bootstrap, itp

Data: 2014-02-20
Zdzisław Zawada

Zdzisław Zawada

Celem tego artykułu nie jest bezpośrednio szukanie wad czy zalet konkretnych rozwiązań technologicznych i programowych. Jego celem jest nakreślenie filozofii doboru takich, a nie innych rozwiązań, którą kierują się twórcy skryptów Quick.Cms i Quick.Cart.

Tekst ten skierowany jest raczej do osób, które posiadają przynajmniej podstawową wiedzę z zakresu tworzenia stron czy sklepów internetowych. Jeśli jesteś osobą, która chce stworzyć stronę lub sklep dla siebie, dla swojej firmy, a może dla znajomych, warto zapoznać się z poniższą treścią.

Nasze "NIE" dla MySQL

Brak bazy danych MySQL to jedna z cech charakterystycznych naszych skryptów. Zauważyć należy, że nie jesteśmy przeciwnikami tej technologii, choć faktycznie jeszcze kilka lat temu nasz entuzjazm był większy.

Nasze skrypty oparte są o bazę plikową (Quick.Cart i starsze wersje Quick.Cms) lub SQLite (Quick.Cms od wersji 6.0), aby ułatwić ich obsługę. Nie wymagają przez to serwera bazy danych, dzięki czemu mogą działać na większej ilości serwerów, nawet tych gdzie MySQL jest niedostępny.

Nie jest wymagana instalacja i konfiguracja bazy danych, ponieważ jest ona umieszczona w plikach na serwerze razem ze skryptem i wystarczy z reguły skopiowanie całego skryptu na serwer i gotowe.

Brak bazy w technologii SQL jest także swego rodzaju zabezpieczeniem przed popularnymi atakami typu SQL injection, na które skrypt mógłby być podatny w przypadku nieumiejętnych modyfikacji przez osoby trzecie.

Ostatnim argumentem jest wydajność, brak bazy MySQL oszczędza czas potrzebny na połączenie się z nią i wykonywanie zapytań. W przypadku plików bazodanowych stosowanych w Quick.Cms i Quick.Cart są one umieszczone lokalnie na serwerze i dostęp do nich jest dużo szybszy.

Decyzję o skorzystaniu z SQLite w najnowszych wersjach Quick.Cms podjęliśmy po wielu badaniach. Pozwala ona jednak na połączenie zalet przechowywania bazy w pliku wraz ze skryptem, z zaletami wynikającymi z relacyjnej bazy danych i zapytań SQL.

Przykład połączenia z bazą danych Przykład połączenia z bazą danych

Nasze "NIE" dla frameworków (Zend, Symfony, itp.)

W miarę rozwoju programowania aplikacji internetowych w języku PHP pojawiły się różnego rodzaju frameworki, które w sposób automatyczny pomagają rozwiązać najczęstsze problemy z obsługą kodu, baz danych, itp. Wśród najpopularniejszych wymienić należy Zend Framework, Symfony, CakePHP, Kohana, CodeIgniter. Trzeba pamiętać także, że są frameworki rozwijane tylko na potrzeby danej firmy czy projektu. Takie frameworki to często bardzo przydatne narzędzia, w większości darmowe, ale rozwijane aktywnie i posiadające dobre wsparcie. Mają także swoje wady i to nie małe.

Potrzeba dużej ilości czasu, aby opanować wybrany framework. Zwykle najpopularniejsze frameworki mają wbudowane już swoje mechanizmy i funkcje, które ułatwiają rozpoczęcie pracy i nie wymagają pisania obsługi wszystkich elementów od zera. Jednak to powoduje, że są one często bardzo skomplikowane w budowie i wymagają poświęcenia sporej ilości czasu na ich opanowanie. O ile osoba tworząca co chwilę nowe aplikacje może sobie (a nawet powinna) na to pozwolić, o tyle przy jednorazowych projektach czy mniejszej wiedzy z zakresu programowania nie zawsze jest to opłacalne. Niestety, pomimo wielu podobieństw opanowanie jednego frameworka wcale nie oznacza, że łatwo będzie przejść na inny. Każdy z nich posiada swoją filozofię działania. Czasem na wstępie może przeszkodzić nam trudna konfiguracja wybranego frameworka, a prawda jest taka, że aby wybrać coś dla siebie trzeba wypróbować i poznać przynajmniej kilka.

I te rozmiary! Wystarczy pobrać kilka frameworków, aby przekonać się, że w podstawowej wersji są to już dosyć duże skrypty (od kilku do kilkunastu MB). Niestety, duża ilość plików i kodu powoduje, że w niewielkich projektach wygląda to jak wyjście "z armatą na muchę". Do tego dochodzi wydajność, która choć powinna być podstawą działania frameworków, niestety nie zawsze jest.

Na koniec należy wspomnieć, że takie narzędzia są przydatne osobom, które wykonują różnorodne aplikacje internetowe, ponieważ są one zwykle fundamentem, a nie gotowym oprogramowaniem. Jeśli wykonujesz strony internetowe, lepiej skorzystać z gotowego systemu CMS, który jest już przygotowany w tym celu.

Przykładowy kod z frameworka Symfony Przykładowy kod z frameworka Symfony

Nasze "NIE" dla szablonów (Smarty, Twig, itp.)

Nie chodzi tutaj o szablony w rozumieniu skórek czyli wyłącznie grafiki. Smarty to prawdopodobnie najpopularniejszy system szablonów. Są również inne bardziej lub mniej rozbudowane jak np.: Twig, Plates czy PHPTAL. Podobnie jak z frameworkami, często powstają małe projekty rozwijające swój system szablonów. Zazwyczaj bywa tak, że ich żywot nie trwa zbyt długo.

Idea szablonów to oddzielenie warstwy programowej od warstwy prezentacyjnej. Dlatego strona internetowa oparta o szablony teoretycznie daje możliwość zmiany struktury HTML bez znajomości kodu PHP. Brzmi cudnie, ale i to ma swoje wady. Niestety, do kodu HTML w ramach szablonów potrzebne jest np. dołączanie treści wczytywanych z bazy, czasem potrzebne jest tworzenie znanej z programowania pętli (np. przy wyświetlaniu listy). Oznacza to, że osoba która chce pracować z szablonami musi poznać ich zasadę działania przypominającą programowanie. Upraszczając można stwierdzić, że korzystanie np. ze Smarty zmusza do nauczenia się kolejnego języka, którym one się posługują. To samo można zrobić w samym PHP i o ile np. w przypadku dużych projektów korzystanie z szablonów jest wygodne i czasem konieczne, o tyle przy tych mniejszych często nie ma sensu dodawanie dodatkowej biblioteki (która też nie jest mała) i komplikowanie struktury projektu.

Powyższe wady powodują, że coraz więcej programistów odchodzi od idei szablonów na rzecz pisania kodu w czystym PHP. Tą tendencję widać nawet w systemach szablonów. Powstało już kilka, które bardziej przypominają czyste PHP niż to co znamy np. ze Smarty.

Quick.Cms i Quick.Cart dawniej także korzystały z autorskiego systemu szablonów. Jednak na pewnym etapie zrezygnowaliśmy z niego, aby zwiększyć wydajność oraz aby nie stawiać kolejnych barier osobom poznającym nasze skrypty po raz pierwszy. Osoby te nie muszą uczyć się zasady działania szablonów, wystarczy znajomość podstaw HTML/PHP.

Kod w czystym PHP i jego odpowiednik w szablonie Smarty Kod w czystym PHP i jego odpowiednik w szablonie Smarty

Nasze "NIE" dla Bootstrap

Kolejny ciekawy framework, ale dotyczący tylko warstwy Front-End. Posiada on sporo gotowych komponentów do budowy strony internetowej widzianej po stronie przeglądarki, m. in.: formularze, menu, tabele, itp. Pozwala także np. na przygotowanie responsywnej wersji strony.

Bardzo ciekawe rozwiązanie, ale niestety niosące za sobą sporą ilość nadmiarowego kodu, który nie zawsze jest potrzebny, jeśli tworzymy niewielki serwis. Z kolei jego okrajanie też nie do końca ma sens, ponieważ skoro już korzystamy z biblioteki to po co ograniczać jej możliwości. Aby korzystać z Bootstrap, nawet w wersji podstawowej, musimy dodać ponad 100 KB jego kodu (i to już w wersji zminimalizowanej) nie licząc ew. czcionek, czy wymaganego jQuery. Porównując nawet z rozbudowanym skryptem Quick.Cart.Ext to kod JavaScript i CSS, potrzebny do działania części widocznej przez klienta, zajmuje ok 40 KB. Oczywiście nie można powiedzieć, że jest to równoważne funkcjonalnie. Jednak należy zadać sobie pytanie, czy potrzebujemy aż tyle funkcji jeśli z nich nie korzystamy. Zawsze należy pamiętać, że przeładowanie strony skryptami zwiększa kod potrzebny do pobrania strony, co przedłuża czas załadowania strony.

Przykładowe komponenty w Bootstrap Przykładowe komponenty w Bootstrap

"TAK" czy "NIE" dla jQuery?

jQuery to biblioteka dla programistów JavaScript. Pozwala na szybsze pisanie efektownych skryptów, upraszcza kod i sama w sobie oferuje sporo gotowych funkcji. Jednak jak zwykle "coś za coś". Sama biblioteka rozrasta się. Pomimo bardzo dobrej optymalizacji i kompresji kodu, jQuery zwiększa rozmiar kodu strony o ok 90 KB (pierwsze wersje zajmowały tylko kilkanaście KB). Dodatkowo często, aby korzystać z jakichś bardziej zaawansowanych funkcji, wymagane są jeszcze dodatkowe pluginy rozszerzające działanie biblioteki. Dlatego więc jQuery z różnymi dodatkowymi skryptami często znacznie powiększa rozmiar strony. W przypadku kiedy dużo korzystamy z funkcjonalności tej biblioteki, jak najbardziej ma to sens, natomiast często można poradzić sobie bez niej, pisząc własny kod w JavaScript. Taki kod będzie dodatkowo bardziej wydajny (jeśli został dobrze napisany) i w przypadku niedużej ilości funkcji mniejszy niż sama biblioteka.

Tak właśnie na tą chwilę jest w Quick.Cart. W podstawowej wersji nie korzysta on z jQuery, ponieważ wystarczają dedykowane funkcje JS. Jednak jQuery jest coraz częściej wymagane i dołączane wraz z dodatkami. Widoczny jest także w internecie trend tworzenia interaktywnych elementów już po stronie przeglądarki.

Od wersji 6.0 Quick.Cms zdecydowaliśmy się na dołączenie jQuery w standardzie. W tej wersji nasz Quick.Cms został mocno przebudowany. Większość funkcji i bibliotek oparliśmy o jQuery. Oczywiście wielkość skryptu zwiększyła się o rozmiar biblioteki jQuery, jednak dzięki niej byliśmy w stanie zmniejszyć pozostałe skrypty co "zamortyzowało" trochę ich sumaryczny rozmiar.

Przykład kodu jQuery Przykład kodu jQuery

Podsumowanie

Odwiedzający Twoją stronę zapewne nie zauważą jakie technologie się za nią kryją. Dla odwiedzającego jest to tylko kolejna strona jaką ogląda w sieci. Najważniejsze jest osiągnięcie celu, dla którego dana osoba znalazła się na Twojej stronie. Niestety przeszkodzić jej może w tym zbyt duża ilość kodu do załadowania lub zbyt długi czas wczytywania strony z powodu konieczności obsługi przez serwer czy przeglądarkę nadmiarowego kodu, którego może nawet nie wykorzystujesz. Przede wszystkim też dla Ciebie jako właściciela strony internetowej ważne jest, aby zarządzanie nią było proste i przyjemne, a nie wymagało przebrnięcia przez gąszcz skomplikowanych technologii i skryptów, których opanowanie zajmuje czas jaki mógłbyś lepiej wykorzystać.

Sam możesz się przekonać, jaką robi to różnicę zapoznając się z testami wydajności naszych skryptów ».

Wydajność naszych skryptów Wydajność naszych skryptów
 
regulamin o nas kontakt