Aplikacja webowa - wybór technologii

Opublikowane przez Jarosław Zabiełło Sat, 25 Aug 2007 19:22:00 GMT

Dość często spotykam się z prośbą o to, jaką technologię (i framework) bym polecił do tworzenia aplikacji webowych. Dziedzina aplikacji webowych rozwija się bardzo prężnie i trudno tak naprawdę przewidzieć, co będzie najlepszym wyborem za parę lat. Niniejszy artykuł stanowi krótkie podsumowanie moich doświadczeń w tej dziedzinie na dzień dzisiejszy.

Nie wierzę w przyszłość architektur webowych opartych na językach kompilowanych, statycznie typowanych.

Na ten temat można by dużo dyskutować. Po prostu nie wierzę w przyszłość budowania aplikacji webowych w językach C# czy Java. Każda zmiana kodu wymaga rekompilacji, wymiany dll itp. Mam złe doświadczenia z ASP.NET. Bardzo wolno i mozolnie się tworzy i debuguje kod. Z kolei Java (tzn. aplikacja webowa pisana napisana w tym języku) jest ciężka i skomplikowana. Aplikacje webowe są dosyć specyficzne. Znacznie lepiej sprawdzają się tam języki wysokopoziomowe i interpretowane. Nie trzeba nic restartować, rekompilować, efekty zmian są prawie natychmiastowo dostępne. Myślę, że większość aplikacji webowych, szczególniej małej i średniej klasy złożoności, zostanie opanowana przez języki interpretowane. Po części już to uczynił PHP. Jednakże…

Nie wierzę w przyszłość PHP.

Na temat wszystkich wad PHP mógłbym dużo pisać. W każdym razie nie mogę się nadziwić, dlaczego jego tworcy wciąż inspirują się składnią Perla i Javy zamiast wzorować się na prostocie i elegancji Pythona czy Ruby. PHP nie nadaje się do modularyzacji, tworzenia komponentów. Próbowałem już kiedyś uzyskać efekt komponentów w Smarty. Nie da się. Głównym problemem jest kolizja nazw klas i funkcji. Przestrzeń nazw miała być dodana w PHP5. Nie dodali, bo nie umieli. PHP brnie więc nadal w swoim chaosie wielkiej, wspólnej przestrzeni nazw dla swych wszystkich, chaotycznie nazwanych funkcji o niespójnej kolejności przekazywanych parametrów. Czy w PHP nie da się napisać dobrej aplikacji? Owszem, da. Jak ktoś się uprze to i w Assemblerze taką napisze. Tylko jakim kosztem… Kierunek rozwoju tego języka wygląda na przypadkowy. Sam język jest źle zaprojektowany. Nie wierzę w jego przyszłość tym bardziej, że wyrosła mu poważna konkurencja.

Fenomem Ruby on Rails.

Powodem rosnącej popularności Ruby on Rails, wbrew zazdrosnym opiniom co niektórych, na pewno nie jest tylko efekt dobrego marketingu. To także efekt pewnej, nowej filozofii w podejściu do tematu. Rails mocno postawił na prostotę i elegancję kodu połączoną z kompleksowością rozwiązania. Do tego dobrze dobrane wartości domyślne (ograniczające ilość niezbędnych konfiguracji) plus wygodne generatory kodu prowadzą człowieka dosłownie za rękę. Rails doczekał się też dobrego IDE co powoduje, że w tym frameworku pracuje się dosyć przyjemnie. Jest przejrzysty i czytelnie zorganizowany. Zainspirował i znalazł już wielu naśladowców, ale nigdy nie uzyskają one jego elegancji i prostoty z prostej przyczyny: siłą Rails jest prostota i dynamika języka Ruby. Dynamika większa nawet od Pythona. Sukces Railsów wzmacnia także lawinowo rosnąca ilość książek.

Rails zaczyna się wdzierać do rozwiązań korporacyjnych. Nie zastąpi on z pewnością Javy, ale na pewno lepiej od niej nadaje się do szybkiego stworzenia dynamicznych interfejsów webowych. Z chwilą okrzepnięcia JRuby (javowej implementacji Rubiego), Rails oparty na Javie (ale ze składnią Rubiego) może zrobić jeszcze sporo zamieszania.

Jednakże, jest technologia, może nie aż tak prosta, ale na pewno pod wieloma względami dojrzalsza i szybsza.

Django i Pylons.

Tak jak Rails, Django powstał na bazie aplikacji zastosowywanej komercyjnie. Podobnie też do Rails, stara się podchodzić kompleksowo podając na tacy określony (autorski) ORM, system szablonów i sposób rozwiązywania adresów URL. Django jest szybsze od Railsów. Wynika to dwóch rzeczy. Python (jako język) jest szybszy od Rubiego oraz Django od początku było projektowane z myślą o optymalizacji wydajnościowej. (Rails skupiał się od początku na uzyskaniu funkcjonalności, zrzucając optymalizację na później). O zaletach Django pisałem rok temu. Django pożera też wyraźnie mniej pamięci niż Rails odpalany na mongrelach.

Niestety, można się przyczepić do kilku rzeczy. Główna krytyka Django dotyczy jego zbytniej monolityczności i mniejszej elastyczności. Rails pozwala podpinać się do wielu baz, Django tylko do jednej. Rails posiada migracje do kontrolowania ewolucji struktury bazy. Django nic takiego nie posiada (tzn. jest w fazie rozwojowej gdzieś w bocznych gałęziach repozytorium SVN). Rails posiada świetne helpery do generowania adresów URL. Djangowy system adresów jest znacznie gorszy. Nie ma możliwości zmiany struktury aplikacji i wygenerowania zmienionych linków we wszystkich szablonach. Rails, dzięki helperom to umożliwia. Rails posiada świetne helpery i specjalne szablony uproszczające korzystanie z AJAX’a, Django nic tu nie oferuje.

Wiele z wymienionych wyżej wad nie posiada pythonowy konkurent Django – Pylons. Pisalem o tym ponad roku temu, że Pylons skopiował prawie wszystkie helpery jakie posiada Rails. Rozwiązuje adresy też w podobny sposób umożliwiając bardziej elastyczne modyfikowanie struktury kontrolerów. Wszystkie zależne adresy URL są generowane za pomocą helperów w sposób podobny do Rails. Pylons w zasadzie to taka sklejanka zewnętrznych bibliotek Pythona. Wykorzystując standardowy mechanizm WSGI, Pylons pozwala na wymianę prawie każdego swojego elementu, od ORM, po system szablonów czy resolver adresów URL.

Wiele z elementów, jakie domyślnie oferuje Pylons przewyższa elastycznością i możliwościami to, co dostępne jest w Django. Np. Pylons korzysta domyślnie z SQLAlchemy, który jest potężniejszy od tego w Rails i Django1. Nie tylko bez problemu pozwala podpiąć się do kilku baz, ale także do bardziej skomplikowanych struktur2. Domyślny system szablonów Mako jest najlepszym systemem jaki znam. Oferuje rozbudowaną3 obiektowość, prostą składnię, doskonały cache dowolnego fragmentu i wg dowolnych zasad. Coś, o czym np. Rails może tylko pomarzyć4. No i Pylons udostępnia szybki, wielowątkowy serwer HTTP który można bez problemu używać zarówno do deweloperki jak i produkcyjnie. Ani Django ani Rails nie obsługują wielowątkowości. Pylons obsługuje, dzięki czemu też ma mniejsze zapotrzebowanie na pamięć.

Pylons oferuje więc więcej możliwości, ale kosztem większej złożoności. Django jest trochę prostszy do opanowania. Cała dokumentacja jest w jednym miejscu. Nauka Pylons wymaga sięgnięcia do oddzielnej dokumentacji SQLAlchemy, Mako czy Routes. Sam SQLAlchemy jest też bardzo rozbudowany i trudniejszy do opanowania.

Zope 3 – najwyższa poprzeczka.

Napisany w Pythonie, obiektowy, wielowątkowy serwer aplikacyjny Zope od dawna uchodził za “zabójczą aplikację” Pythona. Powstało do niego tysiące pluginów. Jednym z najsłynniejszych jest Plone CMS (wg mnie najlepszy CMS jaki napisano). Zope 2.x był jednakże krytykowany za zbytnią złożoność i bałagan w API. Nauczenie się Zope wymagało sporo wysiłku także z powodu słabej dokumentacji. Większość lekkich frameworków Pythona powstało trochę na bazie kontestacji Zope. Na szczęście, twórcy wyciągnęli lekcję z Zope 2 i kod dla wersji 3 został napisany od zera. Znacznie uproszczono i uporządkowano API.

Rails, Django czy Pylons są groźną konkurencją przede wszystkim dla popularnego PHP. To jest mniej więcej dziedzina ich zastosowań. Zope zaś to trochę inna filozofia i inna grupa docelowa. Zope ma ambicję aby konkurować z najpoważniejszymi zastosowaniami klasy enterprise opanowanymi głównie przez Javę.

Przede wszystkim Zope to serwer aplikacyjny w pełni obiektowy i o budowie komponentowej. Każdy komponent ma ściśle zdefiniowane interfejsy5. Zope korzysta standardowo z prawdziwej bazy obiektowej. Nie potrzebuje żadnego wspierania się wrapperami ORM. Baza obiektowa zapisuje całe obiekty Pythona w sposób transparentny i stanowi naturalne przedłużenie pisanego kodu. Zope 3 ma oczywiście wbudowane wszystko co potrzebuje typowa aplikacja webowa, dobry cache, wbudowane mechanizmy bezpieczeństwa, przepływu danych, lokalizacji interfejsu (i18n, l10n) itp. Pozwala też na przeładowywanie komponentów bez restartu serwera. Jeśli potrzeba nowej funkcjonalności, wystarczy napisać nowy komponent i podpiąć do serwera. Nie ma znaczenia czy tym komponentem będzie “artykuł”, czy “plik graficzny” czy cały system redakcyjny, bądź CMS.

Te możliwości jednak nie są bez wad. Do największych zaliczyłbym słabą promocję (to w ogóle jakaś przypadłość Pythona i jego aplikacji) oraz wciąż za słabą dokumentację. Na szczęście ta ostatnia rzec się trochę poprawiła. Nawet są już książki dedykowane specjalnie dla Zope 3.3. Zope potrzebuje też znacznie więcej pamięci niż taki Django czy Pylons.

Ku przyszłości.

Dziedzina aplikacji webowych rozwija się bardzo dynamicznie i trudno coś przewidzieć w dalszej przyszłości. W związku z dynamicznym rozwojem procesorów wielordzeniowych, kto wie, czy renesansu nie przeżyje język Erlang (bo doskonale się nadaje do programowania współbieżnego). Być może renesans przeżyją serwery kontynuacyjne, które zapewniają zachowanie stanu dla aplikacji webowej eliminując potrzebę używania sesji. W serwerze kontynuacyjnym, pisanie kodu dla aplikacji webowej, czy desktopowej, prawie niczym się nie różni. Na razie najbardziej znanym serwerem tego typu jest napisany w Smalltalku – Seaside. Duży potencjał ma też Ruby, bo posiada wbudowaną obsługę kontynuacji.

Na pewno obawa co do znalezienia pracy w Rails czy Pythonie raczej nie ma dużego uzasadnienia. Jest wiele firm używających Pythona. Najlepszym przykładem jest Google, który prawie wszystko ma oparte na Pythonie. Od czasu do czasu pojawiają się w Polsce dramatyczne ;) wołania o programistów Pythona, więc choć ofert nie ma tyle co dla Javy i .NET, to można coś wyszukać. Jeśli chodzi o Ruby on Rails, to ofert zaczyna być coraz więcej, jest już trochę więcej niż dla Pythona. Rails pędzi na pełnej szybkości i dzięki dobre promocji wdziera się coraz szerzej do świadomości programistów głównego nurtu. Sam pracuję w firmie gdzie główny system oparty jest na Springu i Hibernate, technologiach Javy. Jednakże do tworzenia aplikacji webowej został wybrany Ruby on Rails.

Podsumowując powiedziałbym, że współczesny programista musi operować kilkoma językami i technologiami. Dzisiaj pracuje się w heterogenicznym środowisku i wykorzystuje mieszane technologie. Kto myśli, że nauczy się tylko jednego, doskonałego języka i tylko jednego frameworka, pewnie mocno się rozczaruje w zderzeniu z rzeczywistością6.

Do lekkich webowych interfejsów z dużą ilością AJAX’a wybrałbym Rails. Także dla osób początkujących, pragnących nabrać dobrych nawyków, wybrałbym Rails7. Tam, gdzie wymagane jest jednak dobre wsparcie dla Unicode oraz gdzie wydajność jest bardziej kluczowa, wybrałbym Pylons8. Z kolei, jeśli chcemy uderzyć w rynek bardziej kompleksowych rozwiązań dla biznesu, Zope 3 będzie raczej trudny do pobicia. I w końcu, tam, gdzie potrzebujemy gotowego, dobrego forum i taniego hostingu najlepiej sprawdzi się PHP (tak, najlepsze, gotowe do użycia forum są napisane w PHP).

Apendix: Jest dostępne kolorowanie składni Mako dla kilku edytorów (TextMate, Emacs, Vim i Komodo). (2007-09-12)


1 Tak w ogóle to kwestia porównania Active Record, SQLAlchemy i Django nie jest taka oczywista. Każdy posiada coś, czego nie posiada drugi. Np. Active Record posiada eleganckie walidatory, których nie ma w SQLAlchemy. Z kolei Django nie umie podpiąć się do wielu baz, ale posiada wygodne, wysokopoziomowe pola w modelu. SQLAlchemy zaś podepnie się do najbardziej pogmatwanej struktury, wielu baz i to wszystko w elegancki, obiektowy sposób, a nie z brutalnymi wstawkami kodu SQL, jak ma miejsce w Active Record. Poza tym SQLAlchemy potrafi optymalizować zapytania tak, aby kilka poleceń wykonać możliwe najmniejszą ilością kwerend i połączeń z bazą.

2 Rails nie ma problemu podpięcia się do wielu baz. Zaś struktury takie jak złożone klucze główne potrafi obsłużyć za pomocą odpowiednich pluginów.

3 Mako pozwala na więcej niż proste dziedziczenie tak jak ma Django. Pozwala na kaskadę dziedziczenia.

4 Rails ma słabe możliwości w zakresie buforowania danych. Np. nie potrafi buforować fragmentów szablonów w oparciu o unikalny klucz (z parametrów adresu URL lub w oparciu o inne kryteria).

5 Sam Python nie posiada wbudowanej składni do tworzenia interfejsów czy klas abstrakcyjnych. Autorzy Zope 3 jednak je częściowo zasymulowali korzystając z tego, co oferuje język.

6 W tym wszystkim za mało padło o znajomości JavaScript. Nie jest to zbyt prosty i intuicyjny język, a ma spore możliwości i jest bardzo dynamiczny. Jego znajomość jest absolutnie niezbędna dla każdej osoby chcącej tworzyć aplikacje internetowe. O CSS i XHTML nie wspominam, bo to oczywiste podstawy.

7 Rozpoczynanie przygody z tworzeniem aplikacji webowych od PHP jest najgorszą rzeczą jaką możemy zrobić. PHP za bardzo zachęca i utrwala złe nawyki programistyczne. To właśnie miał na myśli DHH, twórca Rails, kiedy porównał PHP do… diabła. :)

8 A co z Django? Jeśli mam wybierać między Django a Pylons, to wolę Pylons. Ma większe możliwości i osiągnął wystarczającą dojrzałość aby podważyć dominację i popularność Django w kręgach pythonistas. Jedną z polskich firm, która wdrożyła i używa z sukcesem Pylonsów jest firma, w której spędziłem parę lat i gdzie wdrożyłem kiedyś Pythona – Wydawnictwo Murator. Pozdrowienia dla ekipy. :)

Tagi , , , , ,  | 98 comments

Comments

  1. Avatar [email protected] powiedział about 5 hours later:

    Bardzo ciekawa a jednocześnie nieco przerażająca analiza. Coż z niej wynika? Musimy umieć:

    Ruby Rails Pylons PHP Python Django Zope HTML CSS SQL XML Java JavaScript Składnię szablonów jak rhtml czy haml.

    plus pliki konfiguracyjne wszystkiego co to obsługuje.

    Wychodzi więc na to chyba, że tworzenie serwisów webowych wymaga bardzoooo szerokiej orientacji i niesamowitej wręcz umiejętności przełączania się między technologiami i rozwiązaniami :-). Pozostaje nam tylko wziąć książki i uczyć się, uczyć, uczyć…

  2. Avatar Sebastian Nowak powiedział about 13 hours later:

    Z tą nauką chyba nie jest tak źle. Nawet jeśli już poznasz to wszystko, to nie będziesz zawsze używał wszystkich z tych frameworków/serwerów aplikacyjnych. Chyba nie zawsze jedna osoba odpowiada za wszystko: kod aplikacji, warstwę prezentacji (owszem może zrobić prosty szablon, który coś wyświetli, ale ktoś i tak to będzie poprawiał, czy doprowadzał do stanu tka jak powinno być).

    Tekst oczywiście fajny. Jestem ciekawe co jest Twoim ulubionym rozwiązaniem. Tylko nie pisz ,,zależy” do czego.;-)

  3. Avatar darek powiedział about 13 hours later:

    moim zdaniem zbyt po macoszemu potraktowałeś Django.. skupiłeś się głownie na tym co ma Rails, a czego nie ma Django, a trochę mniej na kwesti co ma Django, czego brakuje railsom, a trochę tego jest…

    czy Pylons (złodzieje z każdej strony coś kradną ;-) jest poważną konkurancją dla Django ? teoretycznie tak, w rzeczywistości nie sądzę aby szybko to się stało, biorąc pod uwagę jego marketing (równie marny jak Django), większą złożoność (trudność dobrego opanowania), bardziej zawiłą i niedostępną dokumentacje.. (zapaleńcy niestety światem nie rządzą ;-)

    Poza tym artykuł dobry, zwłaszcza początek o przyszłości języków kompilowany w zastosowaniach web.. mam podobne zdanie.

    Pozdrawiam.

  4. Avatar http://envp.ovh.org powiedział about 15 hours later:

    Kurcze i znowu – “sukces railsów nie jest to tylko dobry marketing”, tak, a może wyjaśni mi ktoś czemu język programowania (php) porównuje się do frameworka? Na sieci można znaleźć propagandowe filmy rails vs php, którym php ma wszystko poplątane, a rails stoi i zmienia sobie dane w “pułeczkach naśladujących MVC” – i to nie jest kolejne posunięcie marketingowe? No proszę Was, człowiek, który nie wie w czym zacząć zobaczy na sieci taki filmik i wszystko jasne… Nie jestem zwolennikiem php, po dłuższym okresie pisania w tym języku szukam alternatywy, może z ciekawości – nie wiem, ale krew mnie zalewa jak widzę takie poplątanie – ok porównujemy frameworki to porównujmy mojavi vs railsy, czy inne – ale co ma piernik do wiatraka. Railsy prowadzą bardzo dobrą politykę, mają szanse stać się językiem wiodącym w tej kategorii, ale jeszcze długa droga przed nim – brak hostingu dla aplikacji pythonowych czy railsowych…

  5. Avatar pawel_k powiedział about 16 hours later:

    Moim zdaniem popełniasz taki sam błąd jak każdy krzykacz krytykujący php – stawiasz przeciwko językowi frameworki. Nie chcę tutaj krytykować Twoją analizę php (całkowicie się z nią zgadzam), ale wystarczy że do boju z railsami czy django postawisz symfony a sytuacja zaczyna się wyrównywać. A ukazujące się wszędzie, moim (i nie tyko moim) zdaniem bardzo naciągane porównania wydajnościowe (chociażby dlatego że nikt nie stawia serwerów produkcyjnych w takiej konfiguracji jaka jest wybierana do testów) skomentowali sami twórcy symfony – http://www.symfony-project.com/weblog/2007/06/11/is-symfony-too-slow-for-real-world-usage.html

    Nie jest też tak że twórcy php nie wprowadzili jakiś zmian bo nie umieli – nie zapominaj jaka jest przeszłość php i niestety nie można z nią całkowicie zerwać, a wprowadzenie php5 mimo wszystko było dla php tym czym railsy dla rubiego (oczywiście na innym poziomie). Mimo wszystko ja widzę przyszłość php dość jasno. W wersji php6 ma być wprowadzonych kilka poprawek które krytykowałeś (oczywiście dalej to będzie za mało). Również społeczność tego języka wydoroślała – coraz większa liczba osób używa frameworków (symfony, ZF, cake, CI) odchodząc tym samym od pisania kiepskich pseudo bibliotek. Generalnie wszystko idzie w dobrym kierunku, tylko trzeba siedzieć w temacie żeby to zauważyć, a moim zdaniem ciągle u Ciebie widać traktowanie php i jego społeczności z czasów php3/php4, które już dawno odeszły w zapomnienie.

  6. Avatar ehh powiedział about 16 hours later:

    Stronniczy artykul i przesadnie mocno pesymistyczny.

  7. Avatar Jarosław Zabiełło powiedział about 18 hours later:

    Nie mam jednego ulubionego języka ani technologii (choć z języków najbardziej podoba mi się Python i Ruby). Artykuł przedstawia to, co myślę na ten temat.

    Co do PHP, to może napiszę kiedyś więcej. Próbowałem paru frameworków naśladujących Rails. Bardzo daleko im do pierwowzoru. PHP po prostu nie jest aż tak dynamiczny jak Ruby. Nigdy nie uda im się stworzyć tak czytelnego frameworka. Poza tym prawie wszystkie osoby jakie znam, które zetknęły się z Pythonem lub Ruby tracą szybko zainteresowanie PHP.

    Podtrzymuję to, że w rozwój PHP zaangażowali się jacyś niekompetentni ludzie. Świadczy o tym chaos w pehapowym API i brak jasnego kierunku rozwoju. Obiektowość w PHP4 tak spieprzyli, że nie było co ratować. A tym, że nie umieli zaimplementować namespaces było kiedyś w internecie. Ktoś z core team miał jakieś problemy z C.

  8. Avatar Konrad powiedział about 18 hours later:

    Gratuluję świetnego artykułu. Nawet nie chcę sobie wyobrażać ilości czasu, którą zajęło opanowanie wszystkich technologii, które porównujesz. I wielkie dzięki za uświadamianie społeczeństwa, że PHP śmierdzi.

    Co do kontunuacyjnych frameworków: raczej ciężko mi się zgodzić z “dużym potencjałem” ruby’ego na tym polu: pomijając fakt, że jeszcze nie powstał żaden wystarczająco dojrzały framework (jeśli jakiś powstał w ogóle), to jeśli się nie mylę, już w wersji 1.9 języka kontynuacje mają zniknąć (kłócą się głęboko z wątkami w YARVie).

  9. Avatar pawel_k powiedział about 18 hours later:

    @Jarosław Zabiełło próbowałem RoR i szczerze nie zrobił na mnie takiego wrażenia żebym porzucił php, pewnie dlatego że jak go poznałem już rok programowałem w symfony więc nie było tam nic co by mnie zaskoczyło. gdbym wcześniej nie znał symfony to rzeczywiście mógłbym się przestawić na RoR.

    a co do niekompetencji programistów tworzących php – to ja dalej podtrzymuję swoje zdanie odnośnie tego jaki postęp zrobiło php i jego społeczność, a jakie przestarzałe i nieaktualne masz o tym wszystkim pojęcie…

  10. Avatar lopex powiedział about 20 hours later:

    Warto też wspomnieć o http://erlyweb.org/ i http://www.erlang.org/doc/apps/mnesia/index.html

  11. Avatar Tomek powiedział about 23 hours later:

    Ja natomiast niewierze w koniec ery java i .NET. Większość aplikacji webowych wykorzystywanych w dużych firmach jest zrobiona w tych technologiach. Nikt nigdy nie zgodzi się wykorzystywać nowo rozwijanej technologi, bez wsparcia technicznego i biznesowego. No chyba że MS, Oracle, SAP stwierdzą nagle że trzeba się przesiąść na ruby, pythona lub php. Wtedy nie będzie już odwrotu.

  12. Avatar Marian powiedział about 24 hours later:

    Rails, Django czy Pylons są groźną konkurencją przede wszystkim dla popularnego PHP

    Porównujesz język (PHP) do frameworków – to tak jak porównywać mąkę do chleba.

  13. Avatar sprae powiedział 1 day later:

    Porównywanie framework-ów do PHP jest jak porównanie koparki z grupą kopaczy. Moim zdaniem to ma sens.

  14. Avatar Jarosław Zabiełło powiedział 1 day later:

    Tomek: nie twierdzę, że Java czy .NET upadnie. Sądzę tylko, że Rails będzie wypierać Javę tam gdzie jest najmocniejszy, czyli do tworzenia lekkich frontonów webowych współpracujących z relacyjną bazą danych. Sam mam taką sytuację w firmie. Rails świetnie się uzupełnia z Javą.

    Marian: pisałem skrótowo, chodziło mi ogólnie o aplikacje webowe (właczając frameworki) stworzone w PHP (inna sprawa, że większość aplikacji webowych powstaje jako “radosna twórczość” oparta na antywzorcu spaghetti-code). Może PHP6 w końcu doda te przestrzenie nazw. Bez tego to nie jest dla mnie język obiektowy, ale jaką nieudolna jego imitacja. I może dodadzą w końcu też porządny Unicode, bo PHP (jak i Ruby) mają to skopane (Ruby 2.0 ma to już mieć). Tylko Python ma na dziś porządną implementację Unicode (nie mylić ze strumieniem bajtów UTF-8).

  15. Avatar jan powiedział 1 day later:

    Zrobienie czegokolwiek bez korzystania z jakiejkolwiek przygotowanej architektury (wzorce, frameworki) jest zawsze pracochłonne, mało bezpieczne i trudne w modyfikacji czy rozbudowie. Nie ma sensu porównywanie samych języków bo dzisiaj nie ma już sensu pisanie w języku jako takim. Jeżeli nawet nie korzystamy z żadnego z ogólnodostępnych frameworków to sami zawsze piszemy coś co w mniejszym lub większym stopniu jest framewarkiem (w cudzysłowiu frameworkiem bo z definicji takowy ma oddzielać programistę od samego języka w całości udostępniając swoje metody rozwiązujące każdy problem). Może lepszym pytaniem byłoby “czy istnieje język w którym można by zrobić taki framework idealny”. Najgorsze we frameworkach jest to że zawsze w końcu dochodzimy do momentu kiedy trzeba zacząć grzebać w kodzie frameworka lub robić na poziomie języka obejścia umożliwiające nam realizowanie takich potrzeb których framework nie wspiera. Czasami też zdarza się że framework oferuje nam takie narzędzia których akurat potrzebujemy ale zalecany sposób ich użycia jest tak niewygodny bądź zawiły że i tak bardziej opłaca się to zrobić samemu. Brakuje tu często kompleksowości i pragmatyzmu jaki stoi u założeń Javy. Wiem że frameworka idealnego nie da się zrobić w php (sam próbowałem). Php podąża w bardzo dziwną stronę, czerpie z różnych źródeł ale nie trzymając się żadnego konkretnego założenia. Z jednej strony rozwinięto obiektowość z drugiej jednak w wersji 6 zapowiadają dodanie instrukcji goto()... Czasami odnoszę wrażenie że twórcy chcą żeby php był ogólnie “fajny”.

    Tak naprawdę w sposób nieunikniony poruszamy się w stronę całkowitego SOA gdzie nie będzie grzebania w języku ale jedynie obrabianie logiki przez drag-and-drop na diagramach. Do czegoś takiego doszło już mikrokontrolerach gdzie mało kto bawi się w pisanie w języku. Obawiać się można oczywiście o komercjalizację, bo jeżeli przewidujemy dojście do klikalnych rozwiązań ready-to-use to ktoś to musi zrobić i to zrobić solidnie. Czy pojawi się coś darmowego jak tomcat lub php czy może komercyjngo jak bardzo dobry ale drogi serwer coldfusion. Nadzieją na pojawienie się rozwiązania darmowego napawa tylko ogólnie panujący kierunek na freeware i pochodne (patrz aplikacje google, produkty mozilli i wiele innych). Czas pokaże. A my, z tego co mi się wydaje, dalej jesteśmy skazani na używanie czegoś co nie jest wygodne, niezależnie od tego czy sami to sobie napiszemy czy ściągniemy.

  16. Avatar acd powiedział 1 day later:

    W swojej ocenie ASP.NET nie uwzględniłeś stanu aktualnego tej platformy. Wymieniłeś główne wady wersji sprzed lat.

    W ASP.NET 2.0 zmiana w kodzie zrodlowym aplikacji wchodzi w życie automatycznie (przy następnym request’cie).

    Rekompilację wykonuje server w sposób przeźroczysty i jest ona przyrostowa. Dołączanie kodu przez DLL jest opcją, a nie koniecznością.

  17. Avatar Kosu powiedział 1 day later:

    Odnośnie namespace w PHP6 polecam poczytać http://opensource.apress.com/article/193/namespaces-in-php-6

  18. Avatar Pawel Kaminski powiedział 1 day later:

    taki marketingowy dodatek do dyskusji http://www.youtube.com/watch?v=GQXqWkWqnSw :)

  19. Avatar http://blog.dentharg.eu.org powiedział 1 day later:

    Ze strony Django: “Get your database running

    If you plan to use Django’s database API functionality, you’ll need to make sure a database server is running. Django works with PostgreSQL, MySQL, Oracle and SQLite (although SQLite doesn’t require a separate server to be running).”

    czyli więcej niż do 1. Chyba, ze chodzi Ci o możliwość podłączenia się runtime do wielu baz, a nie obsługiwane silniki..

  20. Avatar mroq powiedział 1 day later:

    sprae, porownywanie sztandarowych produktów obu języków ma sens (zend vs. ror) – koparka kontra koparka będzie ciekawe. Natomiast głupio jeśli pan Jarosław przeprowadza rzeź górników maszyną do odwiertów.

  21. Avatar Marian powiedział 1 day later:

    @sprae “Porównywanie framework-ów do PHP jest jak porównanie koparki z grupą kopaczy. Moim zdaniem to ma sens.”

    to dlaczego nie porównuje sie Zend Framework do Pythona albo CakePHP do Ruby??

    Porównujcie Zend Framework do Django, albo inne frameworki pod PHP do frameworkow napisanych pod inne języki!!

    To powinno być oczywiste, a ciągle porównuje się super frameworki z bidnym PHP

  22. Avatar MacRayers powiedział 1 day later:

    “Tomek: nie twierdzę, że Java czy .NET upadnie. Sądzę tylko, że Rails będzie wypierać Javę tam gdzie jest najmocniejszy, czyli do tworzenia lekkich frontonów webowych współpracujących z relacyjną bazą danych. Sam mam taką sytuację w firmie. Rails świetnie się uzupełnia z Javą.”

    Tutaj w pełni zgadzam się z Jarkiem. Co do frameworkow PHP – one naśladują tylko pewne rozwiązania z RoR (niektóre całkiem zresztą dobrze są rozwinięte). Problemem w PHP IMO jest fakt, iż porównując podstawy PHP vs Ruby widać, który język ma większy potencjał. Zbudowanie domu na solidnych podstawach, pozwala z czasem dokładać kolejne piętra – bez utraty skalowalności czy bezpieczeństwa. Postawienie nawet ciekawego wieżowca na słabym gruncie, może skończyć się katastrofą… Przykro mi, gdyż od kilku lat wiodącym językiem w naszej firmie jest PHP, ale gdy zrobiło się ponad 200 różnych wdrożeń, to widać, że język ten zaczyna strasznie ograniczać. Zwykłe porównanie Ruby i PHP spowodowało u mnie uśmiech na twarzy (na korzyść Rubinka)...

    Szkoda PHP. To naprawdę był ciekawy projekt. Zapytacie – dlaczego mówię w czasie przeszłym ? Otóż, IMO dzisiejsza siła PHP opiera się jedynie na masie aktualnie wykorzytujących go programistów. Taka siła inercji, która powoduje, że język ten jest popularny. Z czasem, programiści PHP wykonują coraz większe systemy – zaczynają rozglądać się za jakimiś frameworkami etc. To droga w ślepą uliczkę. Dopóki nie poprawi się podstaw (obiektowość choćby i wiele wymienionych tutaj wad) dopóty język ten w pewnych zastosowaniach będzie nie do końca satysfakcjonujący… a nie poprawi się niestety. Core Team PHP zachowuje się jak Core Team Java – zbyt dużo instalacji wymusza malutkie zmiany. Duże zmiany mogą oznaczać to o czym przekonał się Microsoft zmieniając Visual Basica w ramach .NET Programiści zaczęli odpływać. Za dużo błędów pojawiło się podczas powstawania PHP – nikt zresztą nie przypuszczał, że wyrośnie na taką siłę. Teraz IMO jest za późno, chyba że, powstanie fork (???) PHP napisany od zera. Tylko po co wyważać drzwi, które są otwarte ?

  23. Avatar lenrock powiedział 1 day later:

    Zgadzam sie po pierwsze , ze postawienie rownosci pomiedzy Frameworkami a PHP , to pomylka . Co do ASP.NET , sprawdza sie w biznesowych rozwiazaniach , jest duzo osob ktore uczy sie C# i dzieki temu moga ten sam jezyk wykorzystywac na aplikacje Desktopowe, Pocketowe i ASP. Mozna latwo podlaczac biblioteki stworzone nie tylko pod webaplikacje i ilosc darmowych biliotek szybko rosnie. Co do PHP , to ja wlasnie jestem osoba ktora jak sie dobrze wyuczyla na ASP , to jak wrocilem na PHP (bo na to jest tani hosting) to szukalem rozwiazania podobnego i znalazlem PRADO . Sa tam nawet namespace’y , a przewaga jest taka ze sa podlaczone do tego znane bilbioteki z PHP , jak ActiveRecord, SafeHtml , Geshi . I tu chcialbym dojsc do sedna, w PHP mamy do wyboru od groma darmowych dobrze opracowanych rozwiazan . Im wiecej sie googla , tym aplikacja coraz bardziej przypomina skladanie z klockow Lego :).

    Jeszcze tak na marginesie , sprawa szybkosci debugowania pod ASP to chyba wymysliles tylko aby sie przyczepic , wiem ze duzo osob nie lubi Microsoftu, ale mozna ASP zarzucic bardziej merytoryczne problemy jak np nie pelny MVC .

    Na zakonczenie ,rozumiem ze wszyscy sobie zyczymy aby programisci webaplikacji , tworzyli obiektowe rozwiazania , zgodne z dobrymi architekturami . a programisci tworzacy kod smietnik w php3 i php4 odeszli w zapomnienie.

  24. Avatar Tomek powiedział 1 day later:

    hej

    warto tylko dodać, że PHP wyklucza sie samo poprzez swoja nazwe (Personal Home Page), ale oczywiscie niewielu ludzi o tym pamieta)...

    co do Javy, to nieprawdą jest że trzeba wykonywać rekompilacje i redeploymenty przy każdej zmianie – po pierwsze mechanizm classloaderów pozwala na dynamiczną komplilację i ładowanie nowych klas (albo nowych wersji istniejących, ale to juz jest trudniejsze… ale problem jest wszedzie ten sam, bo trzeba po prostu cos zrobic z istniejacymi instancjami). Pomijam fakt, ze kompilacja jednak jest jakims (wiem ze zazwyczaj niewystarczajacym) sprawdzeniem czy kod jest poprawny i nadaje sie do dalszego testowania.

    Java ma dla mnie inny atut: Google Web Toolkit, który (dla mnie) naprawdę przyspiesza development w porownaniu z innymi frameworkami (przynajmniej javowymi :) bez utraty enterprice’owatosci aplikacji.

    Co do RoR, to wszystko byłoby fajne, gdyby nie to, że Ruby wygląda jak poplątanie Pythona z TCLem, a ten ostatni jak proba zaimplementowania Lispa w skladni podobnej do C/C++... Tak jak kod w pythonie jest super czytelny dla osoby ktora nawet pythona widzi pierwszy raz, tak ruby nie zawsze wygląda tak dobrze.

  25. Avatar Jarosław Zabiełło powiedział 1 day later:

    Tomek: w każdym języku można napisać nieczytelny kod. Ruby pozwala na pisanie piękniejszego kodu niż jakikolwiek znany mi język. Zobacz jak elegancko wyglądają definicje modeli i walidatorów w Rails.

  26. Avatar Tomek powiedział 1 day later:

    Jarku, oczywiscie ze w kazdym, ale sa takie ktore lepiej sie do tego nadaja i ruby zrobilo na mnie takie lekkie wrazenie (moze przez podobienstwo do TCla, ktorego bardzo nie lubie). To oczywiscie moje subiektywne wrazenie, poparte ponad 10-letnia praca zawodowa jako programista :)

    Jesli piekny kod jest dla Ciebie wazny (ja doskonale to rozumiem i popieram), to polecam Ci ANSI Common Lisp – moze nie ma za wielu frameworkow do tworzenia aplikacji webowych, ale w rekach dobrego programisty jest to narzedzenie nie majace sobie rownych….

  27. Avatar Jarosław Zabiełło powiedział 1 day later:

    Tomek: Jakoś nie mogę przekonać się do Lispa. Za dużo nawiasów. :) Inna sprawa, że jako wcześniejszy programista Pythona, Ruby jako język nie robił na mnie wrażenia. Doceniłem go dopiero dzięki Rails.

  28. Avatar Radek powiedział 1 day later:

    A czym wg Ciebie jest “aplikacja webowa”? Strona internetowa, czy aplikacja? Bo to chyba jednak pomieszanie pojec. Wyjasniji co masz na mysli pod pojeciem aplikacji, bo z komentarzy wynika, ze rozmawiamy o stronach. Jesli jednak rozmawiamy o aplikacjach to zapomnial wasc o Adobe Flex do interfejsu i polaczeniu tego z .NET, Java, CF czy (o zgrozo) PHP. Co do server-side. CF ma podobne problemy co PHP – najwiekszym minusem jest brak dobrego srodowiska programistycznego. No i brak oraz niechec tworcow do implementacji pelnej obiektowosci sa przeszkoda w pisaniu duzych, rozproszonych aplikacji. Tak samo bylo z PHP gdy jeszcze go uzywalem. Juz o wiele lepsze zdanie mam na temat perla. Takie moje osobiste zdanie – ja Cie bardzo przepraszam, ale dla mnie pisanie, ze “to postawilbym w tym, a tamto w tamtym” jest poprostu smieszne. Wg mnie tylko korzystanie z jednej, max dwoch technologii pozwala dobrze je poznac, dobrze rozwiazywac problemy i wypracowac prawie idealne techniki pracy z nimi. No bo w koncu co decyduje, ze forum postawisz w PHP, a costam w RoR? Bo w PHP jest juz dobre forum, a RoR jest cool?

  29. Avatar Jarosław Zabiełło powiedział 1 day later:

    Radek: Przyjmuję def. aplikacji webowej tak jak w Wikipedii. Różnica między stroną a aplikacją jest płynna. Flex, Flash, aplety Javy to są tylko RIA.

    Co decyduje o wyborze? Pragmatyzm. Jeśli nie mam czasu ani ochoty aby napisać coś od zera, a mam gotowy produkt, który spełnia moje oczekiwania, to podchodzę pragmatycznie, instaluję taki produkt (np. IPB). Identycznie zrobiłem odnośnie CMS, nie znam potężniejszego i bardziej intuicyjnego niż Plone, więc zainstalowałem Plone. Po prostu nie trzymam się kurczowo jakiejś jednej technologii, nawet jak mi bardziej odpowiada z wielu względów (bo pracuje się przyjemniej, szybciej i kod jest łatwiejszy do utrzymania)

  30. Avatar kazik powiedział 2 days later:

    Autor porównuje język z frameworkiem? Jak można? ;-) Dla ludzi z poczuciem humoru: http://www.railsenvy.com/2007/8/24/rails-vs-php

  31. Avatar Paweł Kondzior powiedział 2 days later:

    Ja Pier… panowie PROGRAMISCI PHP, wezcie przeczytajcie dokladnie artykul, gdzie Jarek porownuje php z rails ? W akapicie o przyszlosci php nie widze ani slowa na temat rails, nawet jednego, natomaist jest jedno o rubym, w konktescie ruby/python.

    Sadze ze autor skupil sie ogolnie na php a nie na zadnym konkretnym frameworkow (bo chyba o tym mial byc artykul) poniewaz php ma ich 2 miliardy osiemset dwanascie i nie ma sensu ich tutaj wymieniac czy przyrownywac, bo kazdy pokolei jakby zostal przyrownany do django, plone, rails, campfire! czy spring’a po prostu by wymiekl na starcie.

    Powinismy zaczac eksportowac na zachod takich jak Wy bo tam juz ich brakuje wszyscy migruja :P.

  32. Avatar rsz powiedział 2 days later:

    “serwery kontynuacyjne, które zapewniają zachowanie stanu dla aplikacji webowej eliminując potrzebę używania sesji”

    nieprawda, nie zawsze można wyeliminować sesje korzystając z kontynuacji.

  33. Avatar rsz powiedział 2 days later:

    Jarek, a co ma obecność przestrzeni nazw do “obiektowości” języka? (ad komentarz #14)

  34. Avatar Jarosław Zabiełło powiedział 2 days later:

    Robert, sesja pewnie i tak musi być używana, ale z pkt. widzenia developera zmienia się sposób pisania kodu. Jeśli nawet są sesje to zdaje się, że są transparentne dla programisty. Trzeba byłoby sprawdzić, jak to działa w Seaside. Co do namespaces, to jakoś tak zawsze kojarzyłem je jako coś to zawsze towarzyszy obiektowości. Ale może to jest inny temat, bo np. wcześniejsze implementacje Smalltalka też chyba nie miały przestrzeni nazw. Odnośnie “porównywania biednego języka PHP z frameworkiem RoR” (choć tego nie czyniłem jak to słusznie podkreślił Paweł (komentarz #31), gdyż porównywałem raczej Rails z Django niż PHP – polecam kolejny odcinek Rails Envy. Faktycznie, po co mam używać naśladowców jak mogę mieć oryginał?

  35. Avatar zet powiedział 2 days later:

    No cóż – autor zdaje się nie mieć za bardo pojęcia o tym co pisze jeśli chodzi o PHPa. Ręce opadają, gdy się czyta teksty typu “bo nie umieją”, czy “gdzieś czytałem”. Stawianie zarzutu PHP4, że skopano w nim obiektowość to tak jakby oburzać się o marne wsparcie dla obiektowości w C. To po prostu nie był język, który powstał w tym celu. Na serio obiektowość w PHP zaczęto traktować dopiero w PHP5. W tej chwili jedyne czego brakuje PHPowi to namespace’y i late static bindy. Obie te rzeczy są już zaimplementowane w PHP6, a być może zostaną nawet backportnięte do PHP 5.3 (można sobie ściągnąć patch do PHP5 implementuący namespace’y).

    Prawdą jest, że PHPowi brakuje elegancji, ale ma za to tą przewagę nad innymi językami, że powstał specjalnie z myślą o sieci i nie potrzebuje nakładek typu Railsy by być całkiem użyteczny.

    Co do Railsów właśnie i ich rzekomego dynamicznego rozwoju to proponuje spojrzeć na tą stronę Do tego jeszcze te słynne problemy ze skalowalnością (a PHP jak dobrze wiadomo skaluje się bez większych przeszkód). Więc póki co wszystko wskazuje na to, że Ruby (On Rails) okazał się jedynie przejściową modą.

    Co innego Python. Co prawda przydałoby się go nastawić nieco bardziej na sieć, bo korystanie z zope’a, czy django często daje zbyt duży “overhead” (web.py jest krokiem w dobrym kierunku), ale i tak wydaje się mieć przed sobą świetlaną przyszłość jako język tworzenia aplikacji webowych (skoro youtube i Google z niego korzystają :))

    Aha, tekst, że frameworki phpowe “nie mają szans” z rails, czy django także ma niewiele wspólnego z rzeczywistością.

  36. Avatar pawel_k powiedział 2 days later:

    @Jarek “Faktycznie, po co mam używać naśladowców jak mogę mieć oryginał?” – chociażby dlatego że po paru latach pisania w php znam go praktycznie na wylot… dlatego wolę pisać w symfony (który równie dobrze mógłby być w tej reklamie jako “najwiekszy fan railsów” ;) ), ponieważ dojście do takiego poziomu na którym jestem obecnie w php zajęło by mi (w zależności od intensywności nauki ) 0.5-1 rok. a że nie planuję całe życie być programistą to wolę ten czas poświęcić na poznawanie kolejnej metodyki zarządzania projektami lub po prostu na odpoczynek…

    i możesz mi wierzyć lub nie ale z pisząc w symfony i stosując się do podstawowych zasad które narzuca ten framework mamy pewność że nie będziemy mieli w kodzie tak powszechnej w aplikacjach php “sieczki” czy “spaghetti”, oraz że kod jakościowo nie jest gorszy od tego napisanego w RoR lub Django…

  37. Avatar njoy powiedział 2 days later:

    Bardzo podoba się mi język ruby i framework RoR, ale szlag mnie trafia, kiedy “profesjonalisci” porownuja Framework Ruby on Rails do jezyka PHP!!!!

    Zend Framework, a tym bardziej Symfony nie ustepują Rails’om.

  38. Avatar pawel_k powiedział 2 days later:

    @njoy ZendFramework to nie framework. jako zbiór świetnych klas sprawdza się znakomiecie (chociażby jako uzupełnienie symfony o JSON czy Lucene), ale nazywanie ZF frameworkiem jest sporym nadużyciem (jakbyś został w domenach to zobaczyłbyś tą różnicę ;) )

  39. Avatar njoy powiedział 2 days later:

    @pawel_k – nie mogę się z Tobą zgodzić :) Po bliższym zapoznaniu ZF jest całkiem niezly.

    Obecnie mam okazje pracować przy duzym projekcie ktory powstaje na bazie ZF :)

    Z Symfony zapoznaje się obecnie :) – bardzo fajny, ale zostane przy ZF :)

    Przyznam, że na początku ZF nie spodobał się mi, ale teraz…. coraz bardziej się do niego przekonuje…

    Poza tym, nie ma sie co czarować ZF zostanie, a reszta frameworkow do PHP umrze (moze przetrwa Symfony), ale to dobrze. Chyba najwyższa pora, aby sie skupić wokol ZF i stworzyc prawdziwa spolecznosc i rozwijac projekt, tak aby byl coraz lepszy :)

    Co do domen hmmm… o tym możmemy pogadać na privie ;)

  40. Avatar Jaroslaw Zabiello powiedział 3 days later:

    zet: Nie zaprzeczysz, że PHP jest bardzo chaotyczny. Ewidentnie projektowały go jakieś cieniasy. Faktem też jest, że w PHP4 zaimplementowano obiektowość w zły, nieudolny sposób i gadanie że PHP4 nigdy nie miał być obiektowy, tak jak C, jest głupie. Może przyznajmy to szczerze od razu, że PHP nigdy nie miał być czymś więcej niż tylko językiem szablonów. Autorzy zamiast usiąść na dupie i przemyśleć kierunek rozwoju, zaczęli w sposób przypadkowy, doraźnie, dodawać do niego kolejne funkcje. Stąd dziś jest taki burdel w PHP. Funkcje mają niekonsekwentne prefiksy, niespójną kolejność parametrów. Też wielkości znaków dla zmiennych ma, a już dla klas i funkcji nie ma znaczenia. Co to ma być? Stary Pascal albo VisualBasic? :-) Żeby było śmieszniej, Symfony i inne “frameworki” kopiują bezmyślnie WielBłądzią konwencję nazw rodem z Javy. Po co skoro wielkość znaków jest nieznacząca? Nie lepiej trzymać się zatem konwencji “underscorowej”?

    Co do skalowalności, to proszę mnie nie rośmieszać. Ruby nie jest wcale gorzej skalowalny niż PHP. Elegancko się skaluje na mongrelach i load balancerze. Sesje i cache można oprzeć na memcached. Można narzekać na wydajność RoR (choć i tak jest szybszy od wspominanego tu Symfony) ale nie można mówić, że RoR skaluje się gorzej niż PHP. PHP jest szybki do prostych rzeczy, przy bardziej skomplikowanych aplikacjach, zwalnia. Czasem tak bardzo, że trzeba dodać jakiś akcelerator bo bez tego ani rusz. Odnośnie wydajności, to lepiej w ogóle nie wspominać o Django czy Pylons, bo one po prostu deklasują wydajnościowo każdy framework napisany w PHP.

    A tak swojaq drogą, to może kiedyś jakiś PHP9 dorośnie do tego, aby mieć wbudowaną wielowątkowość i ktoś pokusi się aby stworzyć taką aplikację, jak pythonowy serwer aplikacyjny Zope 3.

    njoy: Mówienie że Symfony w niczym nie ustępuje RoR traktuję jako dowcip. Symfony jest wolniejszy, bardziej skomplikowany, mniej intuicyjny. Być może dla kogoś kto w ogóle nie zna Ruby a zna dobrze PHP, tak nie będzie, ale znając choć trochę Ruby widać różnicę. To jest po prostu inna jakość. Jak tak patrzę na składnię Symfony, to ręce opadają. Np. po cholerę oni definiują rozwlekłe, “javowe” akcesory skoro PHP5 potrafi tworzyć je w sposób przezroczysty? Idiotyczne fascynacje językiem z kompletnie innej bajki.

    Większość chwalców PHP po prostu nigdy nie zapoznała się bliżej z Pythonem i Ruby dlatego nie wie o czym mówi. :)

  41. Avatar njoy powiedział 3 days later:

    uuu…zapowiada sie na ciekawa wymiane opini:) i dobrze…. :)

    ”...ale nie można mówić, że RoR skaluje się gorzej niż PHP…”

    @Jaroslaw Zabiello No nie, a Ty dalej to samo… :) Zacznijmy porownywac frameworki, a nie framework z jezykiem PHP ok?

  42. Avatar Paweł Kondzior powiedział 3 days later:

    Jarku szkoda slow, jesli ktos pisze ze ty sie nieznasz bo mowisz ze “Zev Suraski nie zrobil namespaces bo nie umial” i krzyczy na ciebei ze to jest nieprawda a potem sam podkresla ze w php 5 namespaces nie ma i beda w php 6 no to po prostu no comments ;)

    Zostawmy nasza polska elite programistyczna PHP w spokoju niech umra smiercia naturalna. Nie wkladajmy kija do mrowiska etc. ;-P

  43. Avatar pawel_k powiedział 3 days later:

    @Jaroslaw – Twoja krytyka jest niestety czasem bezmyślna. Krytykujesz nazewnictwo wielbłądzie – totalnie bez sensu. Nawet jeśli przy parsowaniu nie ma to znaczenia to chyba dla przejrzystości kodu obranie jednego standardu kodowania i konsekwentne się jego trzymanie znaczenie ma ogromne (o gustach się nie dyskutuje, akurat wybrali wielbłądzi i tyle).

    poza tym dalej krytykujesz php za czasy sprzed 7 lat. mamy php5, nie idealne ale pozwalające wejść php w świat aplikacji gdzie wcześniej byłby wyśmiany. i radzi sobie tam dobrze, mimo że (pewnie słusznie) wolałbyś tam widzieć ruby czy pythona.

    tak samo jak krytykujesz symfony – całkowicie niesłusznie. to że wzoruje się na RoR nie znaczy że jest kiepski – i na prawdę niewiele mu ustępuje. i wcale nie jest bardziej skomplikowany czy mniej intuicyjny – wręcz przeciwnie, przede wszystkim nie jest kopią RoR na siłę, tam gdzie uznano że warto pójść inną drogą bo będzie to bardziej pasowało do php to nie upierali się. Jakbyś nie podchodził do niego jako do “kolejnego kiepskiego frameworka w php” to dojrzałbyś jego moc sprawiającą że php może na polu aplikacji większych niż prosty cms konkurować z RoR. sam fakt że został wybrany przez yahoo chyba o czymś świadczy?

    ps1. proszę nie traktować mnie jako “chwalca php”, widzę jakie ten język ma wady, wiem że jest kiepski pod wieloma względami ale widzę też jego zalety i wiem jak je wykorzystać.

    ps2. ktoś kiedyś powiedział jedno zdanie z którym całkowicie się zgadzam: “php jest jak media markt – nie dla idiotów”.

  44. Avatar Jarosław Zabiełło powiedział 3 days later:

    njoy: Nie wiem czy to dobre miejsce na dyskusję, może lepiej to przenieść na pl.comp.lang.ruby? Odnośnie twego zarzutu, wiadomo, że chodzi mi ogólnie o “rozwiązania oparte na PHP”. Nie chce mi się pisać tak rozwlekle. Czepiasz się słówek.

    pawel_k: Może po Pythonie i Rubim za dużo zwracam uwagę na konsekwencję i piękno kodu… Ano czepiam się wielbłądziego stylu w PHP, bo jest denny. Skoro wielkość znaków nie jest znacząca to po co przyjmować taką konwencję? To jest bezmyślnie skopiowane z Javy, która odróżnia wielkość znaków. Podobnie bezmyślnie skopiowali sposób używania akcesorów w Javie. Mógłbyś wyjaśnić dlaczego Symfony tworzy takie niepotrzebne konstrukcje, skoro PHP5 może je obsługiwać prościej i bardziej przezroczyście?

    Nie podchodzę do Symfony jak do kolejnego kiepskiego frameworka w PHP. Może w klasie PHP to on jest i dobry Ale na tle Rails, Django czy Pylons nie ma nic do zaoferowania i niczym nie imponuje. Więc, tym co kochają PHP i chcą przy nim zostać na wieki wieków, powiem: a niech używają Symfony. Zawsze to lepiej niż jakiś spaghettti-code. Ja po wielu latach pracy w PHP odetchnąłem po poznaniu Pythona i (potem) Rubiego. Pracuje się szybciej, przyjemniej, kod jest łatwiejszy w utrzymaniu. No i te języki mają wielowątkowość i z racji bycia językami ogólnego zastosowania, nadają się do czegoś więcej niż tylko budowanie kodu HTML po stronie serwera.

    Dodam tylko, że nawet przez pewien czas próbowałem zapoznać się z PRADO, Symfony i CakePHP, ale szybko się zniechęciłem. Rails jest znacznie prostszy i bardziej intuicyjny i stwierdziłem, że szkoda czasu na użeranie się z kolejną próbą naśladowania filozofii RoR (PRADO naśladuje ASP.NET dla ścisłości) i to na dodatek w języku, do którego straciłem zainteresowanie i szacunek.

    A jeśli chodzi o CMS, to żaden pehapowy i tak nie dorasta nawet do pięt Plone 3. :P Zaś co do sloganu, to powiedz, jak coś stworzone w tak idiotycznie niekonsekwentny sposób, może być nie dla idiotów? :)

  45. Avatar pawel_k powiedział 3 days later:

    @Jarosław co do akcesorów – stosowanie __set i __get i innych funkcji magicznych w php5 akurat bardzo lubię, kwestia podejścia pewnie (dodam tylko że trochę programowałem w javie ;) ). w symfony sprawdza się to o tyle dobrze że dzięki nim tworząc w akcji linie np. $this->zmienna = 1; mamy w widoku dostęp do zmiennej $zmienna. nie ma tutaj bezsensownego kodu typu $view->assign( ‘zmienna’, 1 ); w akcji, czy $var[‘zmienna’] w widoku (piję tutaj do pseudo-implementacji tego typu podstawowych spraw w 99% frameworków php).

    i szczerz rozumiem Twoje podejście – jakbym zaczynał od wcześniejszych wersji php niż 5 (akurat miałem tą możliwość bawić się tym językiem od początku wejścia wersji 5 na rynek) to pewnie strzelił bym kopa temu językowi i śmiał się z niego jak Ty teraz. wersje wcześniejsze niż 5 to kompletna pomyłka i aż się dziwię że dalej php4 żyje i ma się dobrze. i widać niestety że programiści którzy wyrośli na php4 (i nie mieli poważnej styczności z innymi w pełni obiektowymi językami) nie do końca potrafią się przestawić na php5 i jego obiektowość bardzo wzorowaną na javie.

    również jakbym poznał RoR przed symfony to pewnie też porzuciłbym php, tyle że akurat poznałem całą filozofię railsów na przykładzie sf i szczerze po nim RoR nie oczarował mnie nowatorskim podejściem bo już go znałem, a wydaje mi się że to właśnie filozofia railsów przyciąga phpowcół bardziej niż składnia rubiego (przynajmniej tak mi się wydaje).

    i jeszcze jedno zdanie o symfony: “Może w klasie PHP to on jest i dobry Ale na tle Rails, Django czy Pylons nie ma nic do zaoferowania i niczym nie imponuje.” – tutaj się nie zgodzę. symfony ma bardzo zbliżone możliwości, a dzięki pluginom (http://trac.symfony-project.com/trac/wiki/SymfonyPlugins) można składać aplikacje niczym z klocków. i nie mówię że symfony przebija wszystkie wymienione przez Ciebie frameworki bo tego nie robi, ale też nie odstaje od nich na tyle żeby nim się nie zainteresować.

    co do Plone 3 – zgadzam się :)

    a co do sloganu – nc ;)

  46. Avatar zet powiedział 3 days later:

    @Jaroslaw Zabiello – nie zaprzeczę, przeciwnie: zgodzę się. To największa wada PHPa.

    Dlaczego gadanie, że PHP4 nigdy nie miał być obiektowy jest głupie? Tak było. Obiektowość była tam na “dokładkę”, tak jak kiedyś w Perlu, czy w C. Poza tym czemu dyskutujesz o PHP4, a nie o PHP5?

    RoR nie skaluje się gorzej niż PHP? To o czym jest artykuł do którego linka podałem? Facet pisze, że musieli powywalać większość tych “fajnych” rzeczy w rodzaju ActiveRecord, żeby działało. Pisze wprost: “It’s also worth mentioning that there shouldn’t be doubt in anybody’s mind at this point that Ruby itself is slow”. A Yahoo, Facebook, Digg jakoś na PHPa nie narzekają. Nie słyszałem o tej wielkości serwisach działających na Rubym (poza wspomnianym Twitterem).

    “Dodać akcelerator bo bez tego ani rusz”? No toś odkrył Amerykę – każdy kto poważnie traktuje szybkość działania aplikacji wie, że akcelerator to podstawa. Ale czy to ma być wada PHPa? (przy okazji 6 ma mieć akceletator wbudowany) Co do Pythona to nie zaprzeczam – tu nie ma sporu. Jest szybszy od PHPa (choć nie aż tak bardzo jak mogłoby się zdawać). Ruby jest wolniejsze od PHPa nawet przeszło trzy razy

    Co do Symfony – też się zgadzam, jest to według mnie framework przeładowany i przekombinowany. Ale w PHPie ma się wybór. Osobiście jestem zwolennikiem Zendowego frameworka, choć ponoć także Solar jest bardzo dobry. Co śmieszne raz zarzuca się frameworkom PHPowym, że brakuje im featuresów (ZF), raz, że mają ich za dużo (Symfony) :) A taki ZF jest właśnie dlatego tak dobry, że można go bardzo łatwo rozbudowywać i modyfikować. Brakuje ci porządnego ORMa (ORMa, nie żadnego ActiveRecorda)? Proszę bardzo, jest Propel, Doctrine, EZPDO. Chcesz świetny system szablonów? Wybieraj: SMARTY, Savant, Zend_View, ezTemplate, Flexy, itd. itp.

    @Paweł Kondzior – proszę mi wskazać gdzie napisałem, że autor się nie zna bo mówi “Zev Suraski nie zrobil namespaces bo nie umial”. Proszę mi też wskazać dowód na to, że Zeev Suraski nie umiał zrobić namespace’ów w PHPie (jakaś notka, mail na grupie dyskusyjnej, cokolwiek). Nie przeczę, może faktycznie nie umiał, ale proszę o wskazanie na to dowodów, bo jakoś nie przekonuje mnie stwierdzenie “gdzieś kiedyś czytałem”. To, że namespaceów jak dotąd w PHPie wynika chyba bardziej z tego, że w momencie tworzenie PHP5 nie widziano potrzeby ich wprowadzenia. Jeszcze nie dawno toczono dyskusje, czy są potrzebne w PHP6. W tej chwili 6 ma już je zaimplementowane, powstał też patch do PHP5, który wprowadza je i do tej wersji. Być może już w PHP 5.3 będą natywnie (choć wątpie – raczej nie będą chcieli wprowadzać na tym etapie aż tak drastycznej zmiany).

    Aha, serwer aplikacyjny dla PHPa już powstaje. Obsługi wątków jako takiej nie ma, choć są pewne mechanizmy, które pozwalają zrobić coś a’la wielowątkowość. Tyle, że sprawą dyskusyjną jest, czy na pewno ludzie tej wielowątkowości tak bardzo pragną. Architektura “shared nothing” jest traktowana jednak jako zaleta PHPa.

    Podsumowując PHP6 będzie miał (najprawdopodobniej) wbudowany “akcelerator”, namespacy, obsługę UTFa, late static bindy. Czego więc będzie mu brakowało? Jakim sposobem autor nie widzi przyszłości dla tego języka?

    Dodam, że nie jestem przeciwnikiem Pythona, czy nawet Ruby. To dobre, fajne języki, ale po prostu nie jest tak, że PHP im straszliwie ustępuje jeśli chodzi o pisanie na nich aplikacji webowych. Co więcej obawiam się, że ciągle jest w tym wypadku najlepszym wyborem. Co innego jeśli chodzi o aplikacje desktopowe – tu rządzi Python (choć oczywiście też nie do wszystkiego :))

  47. Avatar zet powiedział 3 days later:

    jeszcze jedna drobna uwaga: “Fenomem Ruby on Rails.” chyba fenomen :)

  48. Avatar sztywny powiedział 3 days later:

    Odbiegając od debilnych flejmów x vs. y (na które trzeba być przygotowany kiedy piszę się taki artykuł), mam spore wątpliwości co do pierwszego podpunktu. Wychodzisz od jakichś tam negatywnych doświadczeń z ASP.net/Javą i z faktu ich istnienia oraz z tego że są statycznie typowane przechodzisz do tezy że statyczne typowanie = zło dla programowania dla sieci. Tymczasem debata na temat wyższości statycznego typowania nad dynamicznym i vice versa w pewnych kręgach jest równie gorąca co ta vim vs. emacs, trwa też od wielu lat. Obecnie istnieje silny trend stosowania języków dynamicznych, ale całkiem możliwe że np. za 5 lat szala przechyli się na drugą stronę. Języki które przytaczasz są po prostu słabe, nie wszędzie mechanizmy o których mowa działają tak jak w nich. Statyczne typowanie + kompilacja nie oznacza automatycznie, że fragmentu programu nie można dynamicznie przeładować. Na przykład w Erlangu czy OCamlu można przeładować fragment skompilowanego programu (chociaż Erlang jest akurat dynamicznie typowany). W teoretycznej informatyce typy są bardzo ważną gałęzią i cały czas powstają nowe rozwiązania takich czy innych problemów, warto np. zobaczyć do jakiego stopnia rozbudwane są typy w Haskellu i jak potężnym mogą być mechanizmem. Zobacz np. http://pl.wikipedia.org/wiki/Inferencja_typów Ogólnie byłbym bardziej ostrożny w wydawaniu takich daleko idących osądów, nie popartych mocnymi argumentami.

  49. Avatar njoy powiedział 3 days later:

    jako ciekawostka para linkow ;)

    http://www.tiobe.com/index.htm?tiobe_index

    http://www.nexen.net/chiffres_cles/phpversion/17283-php_statistics_for_june_2007.php

    Wracajac do rozmowy….

    @pawel-k chwalisz Symfony, ale.. ZF naprawde nie jest taki zly…

    Swietna obsluga sesji, mamy helpery, pluginy, naprawde bardzo fajny ACL, lucene, nie bede sie rozpisywac… krotko…

    ZF jest ok, symfony tez, ale wedlug mnie ZF ma lepsze przyszlosc przed soba o ile PHP przetrwa…

  50. Avatar Jarosław Zabiełło powiedział 3 days later:

    Erlang faktycznie nie jest dobrym przykładem (już prędzej Scala, która potrafi zgadywać typy gdzie się da). Wiem, że jest duża dyskusja na temat typizacji i może komentarze w moim skromnym blogu to nie najlepsze miejsce, aby rozpętać kolejny wątek.

    Z .NET mam złe doświadczenie odnośnie nie tyle ASP.NET i generowanych stron webowych, co web serwisów oraz jednego systemu do synchronizacji danych między serwerami SQL. Każda zmiana w kodzie web serwisu wymagała ręcznej rekompilacji. Do tego IIS nie chciał zwalniać starych DLL z pamięci, ale robił to po jakimś bliżej niezidentyfikowanym czasie. Po prostu koszmar. Ten system do synchronizacji danych ostatecznie przepisałem w Pythonie. I zajęło mi to ułamek czasu w stos. do tego ile zajęło napisanie tego w .NET.

  51. Avatar rsz powiedział 3 days later:

    Niom. Jak ktoś nie przeczytał (i zrozumiał) min. 75% artykułów podlinkowanych na ltu, nie ma prawa się wypowiadać o typach :DDDDDD

  52. Avatar Jarosław Zabiełło powiedział 3 days later:

    zet: To nie tyle PHP4, co w ogóle całe to PHP nie miało być obiektowe, bo to był pierwotnie tylko język szablonów. Skoro jednak postanowiono z czasem dodać obiektowość, to powinni to zrobić przynajmniej zadowalająco. W PHP4 zrobili to źle. Dopiero za drugim razem im coś wyszło.

    Co do skalowalności, to znowu mylisz pojęcia. Fakt, że bieżąca implementacja Ruby nie jest szybka nie znaczy, że zbudowany na nim RoR się nie skaluje. Co do przełączania się AR między bazami, to przecież łatwo to dodać. Zresztą w PHP masz ten sam problem. Poza tym zdaje się że pominąłeś moją konkluzję w artykule. RoR jest świetny do małych i średnich projektów z duża ilością interaktywności w Ajaksie. Tam jednak, gdzie wydajność jest kluczowa, i gdzie złożoność aplikacji duża, wybrałbym Django albo Pylons – RoR. RoR to frameworkowy “silver bullet”.

    Co do dobrego ORM’a, to kiedyś próbowałem Propela, konfiguracja w XML i na dodatek wspomina się o jakiś problemach z JOIN’ami. Co do szablonów, to Smarty i cała reszta są gorsze od Haml’a czy ERb. A wszystkie razem i tak umywają się do pythonowego Mako.

    Jeśli chcę elastyczności, to nic nie równa się z Pylons. Wszystko można tam wymienić. Jeśli chodzi o sposób pracy z bazą, to mogę wybrać ORM (SQLAlchemy, SQLObject) lub użyć prawdziwej, obiektowej bazy danych (ZODB).

    Mówisz, że piszą serwer aplikacyjny w PHP? Gdzie?? Hehe, pewnie będzie się wlekł jak krowa. Tak samo chybiony pomysł jak próba pisania desktopowych aplikacji w PHP. Już teraz ludzie boją się że dodanie namespace w PHP6 zwolni go nawet o 10%.

    Bzdury piszesz, że w PHP5 nie widziano potrzeby wprowadzenia przestrzeni nazw. Przecież to było zapowiadane. Nawet niektóre książki o PHP5 zaczęły się o tym (jak widać pochopnie) rozpisywać. Sam widziałem jedną taką, jak opisywała działające już namespaces w PHP5. :) “PHP 5 originally had namespaces, but they were dropped during the beta process”: http://www.onlamp.com/pub/a/php/2004/07/15/UpgradePHP5.html i to było tyle na ten temat.

    W PHP6 ma być UTF-8 czy Unicode? Będzie, podobnie jak Python, potrafił w obiekcie unikodowym trzymać informację o gramatyce języka? Wyrażenia regularne i wszystkie funkcje operujące na stringach będą potrafiły rozpoznawać polskie znaki, sortować wg zasad polskiej pisowni?

    Widząc, to co jest w PHP5, śmiem w to wątpić. Np. co z tego, że dodali wyjątki, jak nie są nimi objęte wszystkie funkcje systemowe? Bez sensu. Niby coś dodali, ale jest to bezużyteczne, bo musisz sobie napisać kod, który to wykorzysta. W Pythonie i Ruby wyjątki działają na każdym poziomie i w każdej funkcji. Potrafisz np. w PHP wyłapać wyjątek po próbie załadowania złego pliku? Nie. Musisz badać kod jaki zwraca takie wyrażenie ‘require’. Znowu więc coś bardziej połatali niż znacząco ulepszyli. Ja tam nie widzę jakościowo lepszego podejścia w PHP5. Trzeba by chyba wymienić tych lamerów, co ten język rozwijają.

    Ja bym się tak PHP6 nie podniecał. Na razie jej nawet nie ma i wieki całe miną zanim wszyscy się na tą wersję przestawią. Aktualnie i tak ogromna większość kodu tworzona jest wciąż w PHP4. Ile lat musi upłynąć zanim wszyscy przepiszą biblioteki i te wszystkie projekty z PHP4, czy nawet PHP5?

    Wiesz dlaczego nie widzę przyszłości dla PHP? Bo powstała mu znacznie lepsza, już dostępna, konkurencja, a lepsze jest wrogiem dobrego. PHP poszedł w złym kierunku. Staje się językiem skomplikowanym, straci wiele zwolenników. Już dziś wiele początkujących ma problemy z używaniem obiektowości PHP5 a co dopiero jak dodadzą do tego kolejna javowe ustrojstwa składniowe. Python i Ruby są znacznie lepiej zaprojektowane, są łatwiejsze do nauki, bardziej spójne. Kto będzie się pakował w przekombinowany PHP6 jak może wybrać prostego Pythona? Nie dość, że prostszy to jeszcze szybszy.

  53. Avatar rsz powiedział 3 days later:

    Jarku, nie rozpędzaj się tak, obiekty unikodowe w Pythonie nie przechowują raczej gramatyki języka. Poza tym dlaczego piszesz, że serwer aplikacyjny w PHP będzie “wolny jak krowa”, a że RoR jest wolny, to zbywasz bez epitetów, dodając jednak, że “się skaluje”. Trąci to demagogią. No i skąd wniosek, że Python jest szybszy od PHP?

  54. Avatar rsz powiedział 3 days later:

    OK, że Python jest szybszy pewnie wziąłeś z shootouta. Różnica nie jest jednak duża, a tam są specyficzne testy – co paradoksalne, bo test ma być max. obiektywny, ale tutaj rozmawiamy o zastosowaniach w pisaniu aplikacji webowych, a nie ogólnych.

  55. Avatar greno powiedział 3 days later:

    Jarek, czy nie masz wrażenia, że obecna wersja SQLalchemy 0.4rc3 zamiast krok w przód, daje 2 w tył. Proste table.select() nie działa na widokach tylko na tabelach i pozostaje conn.execute(“select * from mojvidok “)

  56. Avatar pawel_k powiedział 3 days later:

    to jeszcze ja skomentuję 2 rzeczy ;)

    “Co do dobrego ORM’a, to kiedyś próbowałem Propela, konfiguracja w XML i na dodatek wspomina się o jakiś problemach z JOIN’ami. – w propelu z joinami większych problemów nie ma, chyba że chcesz złożyć bardzo skomplikowane zapytanie (ale wtedy możesz działać na obiekcie ResultSet zamiast na obiektach – może nie tak wygodne ale znacznie wydajniejsze). w wersji 2.0 problemów nie powinno być… co do konfiguracji to możesz ją mieć w xml’u lub generować model ze struktury bazy danych. dodatkowo jeśli korzystasz z propela w symfony możesz opisywać bazę w plikach yamla…

    “Jeśli chcę elastyczności, to nic nie równa się z Pylons. Wszystko można tam wymienić. Jeśli chodzi o sposób pracy z bazą, to mogę wybrać ORM (SQLAlchemy, SQLObject) lub użyć prawdziwej, obiektowej bazy danych (ZODB).” – symfony też nie jestem zmuszony do propela (który jest dołączony domyślnie), możesz korzystać np. z Doctrine z pełnym wsparciem do mechaniazmów generowania itp, lub skorzystać z innej biblioteki (np. Zend_Db_Table). to samo przykładowo z widokiem – jeśli wolisz np. beznadziejne smarty zawsze możesz wymienić domyślny widok…

  57. Avatar zet powiedział 3 days later:

    fajnie, że ktoś już poodpowiadał bo znowu bym pewnie napisał długaśny post prostujący te wszsytkie “niejasności” w tym co napisał Jarosław Zabiełło, a co raz mniej mi się chcę.

    Jarosławie – ja rozumiem, że PHP ci się nie podoba, masz do tego prawo. Faktem jest, że składnia tego języka nie jest zbyt spójna. Faktem jest, że na chwilę obecną nie ma w nim np. namespace’ów i kilku innych spraw. Jeśli to zniechęca Ciebie do niego tak bardzo, to OK, potrafię to zrozumieć. Prosiłbym tylko o nie uprawianie z powodu osobistych niechęci różnego rodzaju demagogi, typu “cieniaki nie potrafiły”, “na pewno będzie do kitu”, czy “PHP jest do bani bo jest wolne, a Ruby jest wolne, ale to nie ważne”. Prosiłbym też o rzetelność. Ja też mogę rzucać hasła typu “ezTemplate jest najlepszym systemem szablonów pod słońcem”, tyle, że póki nie będzie to podparte choć jednym solidnym argumentem nie będzie to nic poza pustym sloganem i biciem piany.

    Podsumowując: nie podoba się? W porządku, wytknij błędy (tam gdzie faktycznie są), używaj innych języków. Rób co chcesz, tylko nie prowadź bezsensownej kampanii flejmowo-fudowej.

  58. Avatar Jarosław Zabiełło powiedział 3 days later:

    rsz: chodziło mi o to, że Python potrafi przypisać określone kodowanie znaków dla obiektu unikodowego. To, że serwer aplikacyjny w PHP będzie wolny “jak krowa” nie znaczy, że w Ruby byłby specjalnie dużo szybszy, ale Ruby ma chociaż jakąś obsługę wątków, więc sądzę, że raczej by zakasował taki pehapowy “serwer aplikacyjny” chodzący na jednym procesie. Zresztą są próby pisania aplikacji desktopowych w PHP. Próby mało sensowne z tego samego powodu.

    zet: No cóż. Wcześniej nawet podobał mi się PHP, choć szybko rozbijałem sobie głowę o jego ograniczenia, np. brak porządnego Unicode. To była jedna z pierwszych rzeczy jaka zachwyciła mnie w Pythonie. Wszystkie koszmary z kodowaniem znaków w PHP odeszły w zapomnienie. Jak mam teraz zmuszać się do pisania w PHP, to chyba tylko za karę. :) Co do owych cieniasów, to wiesz dobrze że mam rację. Skopali projektowo ten język już tyle razy, że trudno myśleć inaczej.

    A co do porównania szablonów, to żaden pehapowy szablon nie wyjdzie zbyt dobrze z porównania z Mako. Mako to nie tyle system szablonów co system kompionentowy, i posiada ma bardzo elegancką, pythonową filozofię pracy. Strona główna Pythona używa od jakiegoś czasu Mako. Można tam tworzyć złożone szablony na drodze dziedziczenia, kaskady w łancuchu dziedziczenia. Ale ma też potężnie rozbudowane możliwości includowania, gdzie każdy komponent Mako może mieć własny, elastyczny cache włącznie z automatycznym czyszczeniem starej zawartości. Każdy szablon Mako jest automatycznie kompilowany do kodu i bytecodu Pythona. Można go więc też debugować za pomocą wygodnych IDE. Od początku był pisany z myślą o optymalizacji, więc Mako jest bardzo szybkie. Chciałeś parę argumentów, to je masz.

  59. Avatar Marek Małachowski powiedział 4 days later:

    Myślę, że dobrym rozwiązaniem jest także stosowanie kilku technologii równocześnie. Jestem od wielu, wielu lat związany z ASP. Co więcej, preferuję bardziej ASP 3.0 niż .NET ze względu na szybkośc tworzenia.

    Jednak brak dobrego MVC wymusił na mnie stworzenie sobie uniwersalnego narzędzia. I generalnie, to jak najwięcej kodu staram się wykonać już na poziomie bazy SQL. Dane do/z SQL przetwarzane są przez ASP, w klasach. Wyniki przetwarzania zawsze są zwracane w postaci obiektu MSXML, który następnie jest parsowany przez szablony XSLT (oczywiście z zasadami dziedziczenia).

    Dlatego też na codzień na przemian przestawiam się pomiedzy T-SQL, ASP i XSLT. Ale efektem tego są badzo elastyczne i w miare wydajne aplikacje web.

    Jedyne co mnie martwi, to że z każdą wersją Windowsa się zastanawiam czy M$ w koncu nie zrezygnuje z ASP, aby wymusic przepisywanie kodu na .NET :|

    Generalnie uwazam, ze XSLT jest nie doceniane. Z dobrym IDE jest to rewelacyjny system szablonow niezalezny od tego w jakim jezyku jest zrobiona aplikacja.

  60. Avatar Jarosław Zabiełło powiedział 4 days later:

    Marek: Miałem okazję pracować z kompleksowym rozwiązaniem opartym na XML i XSLT (Cocoon). Idea niby ciekawa, ale w praktyce tworzenie widoków za pomocą transformat XSLT jest skomplikowane. Poprawienie jakiejkolwiek pierdoły, czy dodanie nowych rzeczy (dział marketingu potrafił tu być bardzo twórczy) nie mogła być wykonana przez naszego designera. Wymagała ingerencji programistów. XSLT jest za skomplikowanym językiem dla 99.9% designerów. No i zakłada, że dane są trzymane w XML, co wcale nie jest często spotykane. Istnieją co prawda natywne bazy XML, ale są mniej popularne i chyba mniej dopracowane w stos. do relacyjnych. Generalnie, XML+XSLT – tak, ale dla bibliotek danych trzymanych w XML i mało zmiennych layoutów. W innym wypadku to nie ma sensu. Pochłania za dużo czasu i wysiłku.

    greno: A nie można w SQLAlchemy po prostu zamapować view jako tabelę? Tak robiłem w Django i Active Record i działało bez problemu.

  61. Avatar greno powiedział 4 days later:

    Może to wynika z braku moich umiejętności, ale w poprzedniej wersji mogłem tworzyć obiekt klasy Table niezależnie czy to była tabela czy widok, tj table1= Table(‘tabela’,autoload=True) i table2=Table(‘mojvidok’,autoload=True) dawało się z tym zrobić co chciałeś. Teraz obiekt z vidoku nie potrafi czytać kolumn, a debuger krzyczy: ‘SELECT \nFROM mojvidok’. Albo czegoś nie doczytałem w tutorialu (przykłady tylko do tabel) albo taki urok tej wersji.

  62. Avatar Jarosław Zabiełło powiedział 4 days later:

    Założę się, że jak podefiniujesz ręcznie kolumny zamiast używać autoload, to zadziała. Podejrzewam że tu jest problem . Np. views nie ma pk i to może dezorientować SA. Chyba SHOW COLUMNS po prostu nie działa na view a SA pewnie z tego korzysta (przykład dla MySQL)

  63. Avatar greno powiedział 5 days later:

    Jarku miałeś rację: ręczne definiowanie kolumn załatwiło sprawę, no coś nie jest to Active Record. Swoją drogę SA to nie taki super ORM. Dziękuję za podpowiedź.

  64. Avatar rsz powiedział 5 days later:

    ad #58:

    1) Ale przecież obiekty unikodowe w Pythonie nie przechowują żadnych informacji o języku. Właśnie po to zostały stworzone, żeby nie trzeba było nic przechowywać. 2) PHP nie musi chodzić w jednym procesie. Jest też dostępny model wątkowy (fakt, nieco niedopracowany) i – przede wszystkim – prefork, czyli model współbieżny (acz bardziej obciążający pamięć). 3) “Sądzę, że by zakasował” to nie jest zbyt poważne i obiektywne porównanie dwóch technologii. Ja np. sądzę, że mój Opel Vectra r. 1993 by zakasował na ćwierć mili kolegi Imprezę WRX STI. Tylko co z tego?

    Jeszcze raz apeluję o większą dokładność.

  65. Avatar tusla powiedział 5 days later:

    :) http://www.railsenvy.com/2007/8/24/rails-vs-php

  66. Avatar programista_java powiedział 19 days later:

    Tylko programiści Ruby/Pythona/PHP mają tyle czasu by pisać takie przydługawe, jednostronne komentarze. Napisał bym coś więcej, ale mam zbyt dużo pracy. Pozdrawiam. :)

  67. Avatar anonymous coward powiedział 20 days later:

    “mam zbyt dużo pracy” no cóż… nick sam mówi za siebie.

  68. Avatar rsz powiedział 21 days later:

    drętwa prowokacja :)

  69. Avatar Doniek powiedział 22 days later:

    Według mnie najlepsza jest ta technologia która pozwala ci osiągnąć to co chcesz w najprostszy sposób. A gadanie że A jest lepsze od B bo B szybciej wykonuje funkcję którą używasz raz na rok jest o kant stołu potłuc

  70. Avatar dreamweb powiedział 24 days later:

    zgadzam sie z ostatnim postem

  71. Avatar Zyx powiedział 27 days later:

    Zwolennicy Ruby -> wy jakieś kompleksy leczycie takimi trącającymi fundamentalizmem wpisami i komentarzami? Obiektywnie Ruby oraz jego framework wygląda zachęcająco, ale młyn robiony przez jego wielu użytkowników tak mnie zniesmacza, że szkoda słów.

  72. Avatar Piotr N. powiedział about 1 month later:

    Swietnu artukuł graruluje. Daje fajny ogólny przegląd sytuacji. Mogę powiedzieć, że skorzystałem :D

  73. Avatar grzejnik powiedział about 1 month later:

    Zazdroszcze Wam wiedzy :-( Troszke liznalem PHP (aplikacja do wyswietlania newsow). Obecnie wykorzystuje darmowe aplikacje CMS Joomla do robienia stronek oraz rozszerzenia do tego systemu. Czuje jednak, ze przy grzebaniu w kodzie brakuje mi wiedzy zeby zrozumiec co autor mial na mysli. Myslicie, ze wiek 29 lat to nie za pozno na zabranie sie do poznania tych wszystkich technologii???

  74. Avatar arag0rn powiedział about 1 month later:

    Kamyczek do ogródka railsów:

    http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html

  75. Avatar Jarosław Zabiełło powiedział about 1 month later:

    arag0rn: Ten tekst nic nie mówi o RoR. Mówi tylko sporo o tym łosiu, co wysmarował ten tekst. Nie ma co się egzaltować. Tu masz mój obszerniejszy komentarz do tego artykułu.

  76. Avatar ilear powiedział about 1 month later:

    Maly komentarz z troszke innej perspektywy, perspektywy laika (sic! that’s me:D) ale mimo wszystko odpowiadajacy na jedno z “domyslnych” pytan ukrytych w tym artykule. Wyczulonych patryiotow ostrzegam – brak polskich znakow w tekscie. Uzytkownicy world wide web nie potrzebuja krzaczkow;)

    Ja tam jestem laik w programowaniu, bo co prawda w pascalu pisalem…c++ nawet mocniej liznalem (w 3dni przerobilem symfonie pare lat temu i styklo na zaliczenie), troche skryptow pod linuksem i w dosie batow tez porobilem w swoim zyciu, nawet wiem ze w javie zmienne maja straszne dlugosci i duzo kropek:D Si. Troche glupio posrod tych szczytnych osiagniec wymieniac polroczna przygode z asemblerem ktorego faktycznie trzeba bylo zakumac na uczelni zeby puscili dalej, ale akurat to mialo swoj sens – fajnie programowac na najnizszym poziomie:D. Wszystkie te jezyki programowania nie przekroczyly u mnie poziomu UTWORZENIA jakiejkowliek sensownej aplikacji, ktorej przeznaczneie bylo by inne niz “na zaliczenie” przedmiotu:) Why? Przez lata studiow (7;P) w krytycznych chwilach z pomoca przychodzila mi motorola a1000, ktora przemycala wiedze na zaliczenia i egzaminy w pdfach i wordach, pozwalajac zchilloutowanemu mnie na zabawe po klubach zamiast drentwego wkuwania danych do mozgu. No i dopadlo mnie;) Ostatni projekt -> bazy danych 2. Sql..yhh. niedosc ze SQL trza by liznac to jeszcze z tego co pamietalem SQL to nawet nie jezyk programowania i sam mi nie wystarczy do zaliczenia…i strach zajrzal w moje oczy. Glownie ze wzgledu na wspomnienia z szybkiego kursu sciagnietego gdzies z neta, o html’u ktory kiedys tam przerabialem z ciekawosci (akurat na uczelni jakos nikt nie wymagal znajomosci htmla:D:D:D chyba bylo oczywistym ze to kazdy umie…gluptasy;)

    Z tym bagazem doswiadczenia w programowaniu (sic!;) , z pelna swiadomoscia czekajacego mnie wyzwania podjalem probe wybrniecia z sytuacji.

    Szybka konsultacja ze znajomym. Pada slowo Python. 1 dzien razem. 2 dni juz samemu. 2 nieprzespane noce, przegrzany dell inspiron;)... Uff skonczylem:D Biblioteka szkolna, obsluga wypozyczen rezerwacji 4 poziomow dostepu pelny fulwypas! No moze brakuje obslugi drukarki i czytnika podczerwieni do kodow kreskowych…no ale coz.. nie mialem 4 dni;p

    ...i to by bylo na tyle. Mimo ze dalej jestem laikiem jesli chodzi o aplikacje webowe..ba jesli chodzi o programowanie:D to ja juz wiem ktory jezyk moze najwiecej w najkrotszym czasie i w najintuicyjniejszy sposob:) Przy okazji tych 3 dni zakumalem sqla, poznalem htmla + css’a, nauczylem sie robic w photoshopie sliczne refleksy :D a to wszystko polaczylem pythonkiem i baza jest jak znalazl:) Teraz tylko jeszcze jeden dzien na napisanie 30stronnicowej (sic!) wmaganej przez pania kuzwa profesor dokumentacji i projekt gotowy.

    Tenkju pythonq;)

    Ku pokrzepieniu serc? ;)

  77. Avatar Leszek powiedział about 1 month later:

    Ponoć lepsze jest wrogiem dobrego tak? A ja powiem inaczej: popularne jest wrogiem lepszego. C# i Java pójdą w odstawkę i pozostanie tylko Python i Ruby… ROTFL

  78. Avatar http://nandrew.blogspot.com/ powiedział about 1 month later:

    Z tymi językami statycznymi to przesadziłeś. Ich zaletą są porządne IDE, które właśnie UŁATWIAJĄ debugowanie! Wyszukiwanie błędów w językach dynamicznych jest trudniejsze, zwłaszcza w PHP (ludzie nie używają IDE, tylko rozbudowane notatniki).

    W dodatku ASP.NET jest dwa razy szybszy niż PHP, bo strony są kompilowane a nie interpretowane za każdym razem.

    Co do języków dynamicznych, ich ‘używalność’ jest dobra tylko gdy projekt ma pełne testy jednostkowe. Bez tego banalne błędy mogą gubić projekt już u klienta. (Pierwsze języki obiektowe były dynamiczne, ale języki statyczne je wyparły właśnie przez jakość tworzonego kodu).

  79. Avatar http://nandrew.blogspot.com/ powiedział about 1 month later:

    Jeszcze zapomniałem dopisać: języki dynamiczne (PHP, Python, Rails) dobrze nadają się do tworzenia interfejsu, a jakie mają wsparcie dla tworzenia logiki biznesowej? transakcji biznesowych? Czyli tego wszystkiego co powoduje, że duże projekty nie mogą się obejść bez J2EE.

    Piszesz o ASP.NET, ale to jest tylko interfejs. Jak w Rails, PHP zrobić skalowalną aplikację? (Aplikacje w sensie systemu, a nie GUI do bazy danych).

  80. Avatar Jarosław Zabiełło powiedział about 1 month later:

    Z tymi IDE to przesadzasz. Chyba nie jesteś na bieżąco. Python od dawna miał wiele dobrych IDE, weźmy np, WingIDE Pro, Eclipse/PyDEV, SPE, Komodo, Eric 4, PythonWin itp, itd. PHP ma swój (b. dobry) Zend Studio Pro. Ruby doczekał się mocnego wsparcia ze strony świetnego Netbeans 6, InteliJ IDEA, Komodo, czy Eclipse/Aptany.

    Jeśli chodzi o debugowanie, to jasne, że w takim Pythonie jest to zdecydowanie łatwiejsze. Problemem w PHP jest zwykle słabej jakości kod. Jednak dobrze napisany, jest dosyć łatwy do debugowania.

    Co do szybkości, to zapominasz, że nawet do PHP istnieją różne akceleratory kompilujące w locie kod. Kolejne odwołania wykorzystują taki prekompilowany kod. Poza tym wszystkie moduły ma napisane w C a najwolniejszym elementem większości aplikacji webowych jest i tak baza danych a nie kod po stronie serwera. Python jest jeszcze szybszy od PHP, ale jego zasadniczą przewagą jest nie tyle szybkość, co b. czytelna składnia i spójność, wbudowane docstringi, bytecode, porządny Unicode – jest językiem dobrze dużo lepiej zaprojektowanym od PHP.

    Jesteś jakiś oderwany od rzeczywistości. Jeśli chodzi o zastosowania webowe (bo głównie o tą dziedzinę mi chodzi) to języki statyczne są w odwrocie. Pierwotne jęz. dynamiczne (masz na myśli Smalltalka?) były za wolne na tamtym sprzęcie. Dziś to się zmieniło i to radykalnie.

    Sun zatrudnił twórców JRuby. Microsoft zatrudnił twórcę Jythona i IronPythona. Google zatrudniło twórcę Pythona (zresztą Google jest w znacznej mierze oparte na Pythonie jeśli tego nie wiesz) Poza tym to nie ASP.NET wywołuje najwięcej szumu w branży, ale Ruby o Rails, który wypiera zbyt przekombinowane środowiska do budowania aplikacji webowych.

    J2EE? A dlaczego nie lżejszy Spring? :) J2EE jest przekombinowane i ciężkie jak betonowy blok. Zresztą tu chyba masz na myśli jakąś naprawdę wielką skalę. Owszem. Tam Java rozwija skrzydła. Złożone aplikacje webowe? Może nie Rails, ale Pylons, Django czy jeszcze lepiej – Zope 3 – z łatwością sobie dadzą radę.

    Skalowaną aplikację w PHP? A widziałeś jak śmiga Wikipedia? :) Da się? Da. Jeśli chodzi o Rails, to skaluje się poprzez dodanie większej ilości Mongreli.

    A co do tworzenia systemów, to do języków systemowych używa się języków systemowych: C, C++, Javy, C# itp. itd. Choć nie wiem czy taki Erlang też by się nie nadał. Jest niesamowicie stabilny. Ericson ma w nim napisany swój system, kilka milionów linii kodu i tylko parę minut jakiegoś przestoju na… rok.

  81. Avatar Andrew powiedział about 1 month later:

    Hmm, widać że znasz się na rzeczy. Inne języki obserwuje tylko z boku i właśnie zauważyłem, że mimo iż np do php dostępny jest ten Zend, to ludzie w komercyjnych projektach używają przerośniętych notatników i debugowania poprzez wyrzucanie stuff’u na konsole :-\

    Co do Pythona to rzeczywiście wygląda na to, że kiedyś będzie dominował w niektórych zastosowaniach. Komputery są coraz szybsze… I wiem, że google na nim stoi :)

    Co do pierwszych języków dynamicznych, z tego co ja czytałem (R. C. Martin), to odwrót był powiązany ze zbyt dużą ilością błędów i słabą jakością produktu wynikowego przez to. Teraz języki dynamiczne powracają dzięki TDD (rzadko stosowane w polsce na razie, ale moda na j. dyn. przyszła zza oceanu).

    Co do Springa to go wykorzystuje się RAZEM z j2ee, ale ma też inne zastosowanie. J2EE służy do budowy logiki aplikacji, a Spring do zarządzania nią i innymi warstwami. Fakt, w J2EE jest sporo nadmiaru (np EJB czasami), ale ten “nadmiar” bywa niezbędny. Oczywiście nie w web-tier.

    “A widziałeś jak śmiga Wikipedia” – wątpię czy tam skalowanie jest zrobione na poziomie serwera aplikacji. Raczej bazy.

    A, słowo system użyłem w znaczeniu systemu informatycznego (o którym pisałem) a nie operacyjnego. Nie wiem czemu ci się tak skojarzyło. BTW: podobno część Visty jest napisana w C# – to tłumaczy czemu jest taka wolna ;)

    Na koniec jeden smutny fakt (a może nie taki smutny dla programistów ;) Wymieniasz sporo frameworków, języków, itp. Często się mówi “dobierz narzędzie do zadania”, ok. ALE: w Szczecinie od dłuższego czasu pewna firma szuka 20 programistów C+, w Łodzi firmy same jadą po studentów do Warszawy. Czyli brakuje programistów najpopularniejszych języków (aktualnie Java, C+, C#). Jak złożysz zespół 10-15 programistów Pythona/PHP, którzy znają się na dobrym programowaniu i mają odpowiednie doświadczenie? (zwłaszcza o takich PHPowców trudno, którzy wiedzą co to warstwa logiki/domenowa). Na razie to jest problem :P

  82. Avatar Jarosław Zabiełło powiedział about 1 month later:

    O dobrych programistów w ogóle trudno. Jeśli chodzi o Pythona (lub Ruby), to jeśli trudno znaleźć doświadczonych programistów, trzeba albo ich podebrać innej firmie, albo podkupić jakiegoś jednego dobrego, dobrze go opłacić aby pomógł zbudować zespół programistów. Oczywiście musi umieć w miarę dobrze przekazywać wiedzę i zachęcać młodych aby omijali miny i kierowali się ku dobrym, “pythonistycznym” praktykom.

  83. Avatar flah tada powiedział 2 months later:

    a co z technologia adobe flex ?

  84. Avatar Jarosław Zabiełło powiedział 2 months later:

    Flash? Zapomnij. Google nie indeksuje podstron. Trudno się w tym pisze i debuguje (programowanie asynchroniczne, zdarzeniowe). Flash jest dobry do prezentacji lub jako wstawki. Ale oparcie wszystkiego na nim to pomyłka. Trochę na bazie kontestacji apletów i Flasha rozwinął się AJAX.

  85. Avatar qqrq powiedział 2 months later:

    Wydaje mi się, że niepotrzebnie przekreśla Pan PHP, Panie Jarku. Popularność PHP jest w tym przypadku o tyle wadą, że naprawdę dobre biblioteki/rozszerzenia czasami gubią się wśród zalewu miernoty (której jest duuużo). Trzeba też wziąć poprawkę na przeszłość PHP i docenić ten język, jako naprawdę przydatny i prosty. Jak się umie, to da radę napisać coś porządnego. A co do “piękna kodu”, to takich dyskusji unikajmy, bo są jałowe…

  86. Avatar piotrko powiedział 3 months later:

    qqrq: “A co do “piękna kodu”, to takich dyskusji unikajmy, bo są jałowe…”

    Poniekąd. Jednak przejrzystość i zwięzłość składni ma znaczenie dla szybkości i wygody pisania, jak też analizy kodu – a te cechy przekonują mnie do tego języka.

    Inspirujący artykuł, ciekawa dyskusja. Dzięki i pozdrawiam.

  87. Avatar weosły kosiarz powiedział 6 months later:

    Widzę, święty Perl i jego Catalyst nie załapał się na uwzględnienie w zestawieniu.

  88. Avatar Jarosław Zabiełło powiedział 6 months later:

    Nie używałem Catalysta więc się nie wypowiadam (używałem trochę Masona). Ogólnie nie przepadam za Perlem. Wolę przejrzystość i czystą obiektowość Rubiego, względnie Pythona.

    Ten tekst był napisany jakiś czas temu. Teraz ponad Rails postawiłbym Merba choć czekam jeszcze aż wyjdzie wersja 1.0.

  89. Avatar respectum powiedział 8 months later:

    No cóż, to chyba trzeba się trochę poświęcić…

  90. Avatar Jachu powiedział 9 months later:

    Bardzo ciekawe porównanie. Z porównaniem PHP do diabła to fakt ;) Ciężko się przesiąść …

  91. Avatar MaRiAnO ItAlIaNo powiedział 11 months later:

    Wymiękłem przy kilkudziesiątym komentarzu, mam nadzieję, że później nie było odpowiedzi na pytanie: > skoro wielkość znaków nie jest znacząca to po co przyjmować taką konwencję?

    Z prostego powodu – przeglądając kod, łatwiej OdczytaszNapisyUżywająceCameli niżnapisyichnieużywające.

    (Cameli powinno być w cudzysłowiu :))

  92. Avatar YarMobile.com powiedział about 1 year later:

    Ciekawy artykuł, zawiera nieco ciekawych informacji, choć troszkę trąci: - fetyszyzmem technologicznym za wszelką cenę - chęcią wywyższenia jednej technologii nad inną i przyczynienia się do jej powodzenia Zapewne też był napisany z chęci lansu. A z kolei wśród komentatorów też pojawiają się głosy świadczące o chęci poczucia się lepiej jako stosujący daną technologię.

    PHP może i ma swoje wady, ale jest popularny, powszechny i jak Autor napisał, też można w nim napisać dobrą aplikację.

    Ja sam jestem informatykiem dawno po studiach, znam nieco języków i twierdzę że zaczynanie programowania od PHP grozi nabyciem złych nawyków, ale w przeciwnym wypadku – nie.

    Poza tym gdyby się stanęło przed wyborem: słaba technologia i duża kasa przez dłuższy okres czasu, a czysta idealna technologia przy słabej za nią kasie, to co wybralibyście? Ja to pierwsze.

  93. Avatar ot tak sobie na momencik powiedział over 6 years later:

    tylko te gupki z faceboka jakoś się przekonały do php mimo czałej tej dysputy powyższej, moszna?

  94. Avatar ot tak sobie na momencik powiedział over 6 years later:

    tylko te gupki z faceboka jakoś się przekonały do php mimo czałej tej dysputy powyższej, moszna?

  95. Avatar ot tak sobie na momencik i przy okazji powiedział over 6 years later:

    tylko te cieniasy z faceboka jakoś się przekonały do php mimo całej tej dysputy powyższej, moszna?

  96. Avatar phpowiec powiedział over 8 years later:

    mamy rok 2015 i nadal w ofertach pracy php jest zaraz za java a mial juz dawno upasc hmmmm a to ciekawe. PHP zrobili do weba i tak bylo jest i bedzie niema co sie sprzeczac

  97. Avatar wychowany na php powiedział over 9 years later:

    Jest listopad 2016 roku i PHP wciąż dobrze funkcjonuje na rynku webowym. Ale coraz większego znaczenia nabierają technologie frontendowe, jak choćby framework AngularJS (do tworzenia stron typu Single Page Application – patrz przykład: http://angular-cms.pl), w którym używa się JavaScriptu (Angular 1) oraz TypeScriptu (Angular 2). Swoją drogą, ciekaw jestem, jak długo będzie trwała moda na TypeScript.

  98. Avatar Maciej powiedział over 9 years later:

    Gdyby ktoś tu trafił a był zainteresowany informacjami dla laika to polecam przeczytać https://informatykprogramista.pl/blog/aplikacje-webowe

(leave url/email »)

   Pomoc języka formatowania Obejrzyj komentarz