Jarosław Zabiełło - BLOG: Aplikacja webowa - wybór technologii

Aplikacja webowa - wybór technologii

Jarosław Zabiełło — Sat, 25 Aug 2007 21:22:00 +0200

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 Django¹. Nie tylko bez problemu pozwala podpiąć się do kilku baz, ale także do bardziej skomplikowanych struktur². Domyślny system szablonów Mako jest najlepszym systemem jaki znam. Oferuje rozbudowaną³ obiektowość, prostą składnię, doskonały cache dowolnego fragmentu i wg dowolnych zasad. Coś, o czym np. Rails może tylko pomarzyć⁴. 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 interfejsy⁵. 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ą⁶.

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 Rails⁷. Tam, gdzie wymagane jest jednak dobre wsparcie dla Unicode oraz gdzie wydajność jest bardziej kluczowa, wybrałbym Pylons⁸. 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)

¹ 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ą.

² 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.

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

⁴ 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).

⁵ 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.

⁶ 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.

⁷ 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. :)

⁸ 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. :)

"Aplikacja webowa - wybór technologii" by MaRiAnO ItAlIaNo

Tue, 29 Jul 2008 01:05:35 +0200

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 :))

"Aplikacja webowa - wybór technologii" by Jachu

Thu, 19 Jun 2008 19:28:35 +0200

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

"Aplikacja webowa - wybór technologii" by respectum

Thu, 01 May 2008 16:19:50 +0200

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

"Aplikacja webowa - wybór technologii" by Jarosław Zabiełło

Wed, 05 Mar 2008 22:46:17 +0100

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.

"Aplikacja webowa - wybór technologii" by weosły kosiarz

Wed, 05 Mar 2008 22:32:12 +0100

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

"Aplikacja webowa - wybór technologii" by piotrko

Sat, 24 Nov 2007 04:14:00 +0100

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.

"Aplikacja webowa - wybór technologii" by qqrq

Fri, 02 Nov 2007 15:18:40 +0100

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…

"Aplikacja webowa - wybór technologii" by Jarosław Zabiełło

Wed, 31 Oct 2007 22:50:04 +0100

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.

"Aplikacja webowa - wybór technologii" by flah tada

Wed, 31 Oct 2007 22:07:10 +0100

a co z technologia adobe flex ?

"Aplikacja webowa - wybór technologii" by Jarosław Zabiełło

Fri, 19 Oct 2007 01:22:30 +0200

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.

"Aplikacja webowa - wybór technologii" by Andrew

Thu, 18 Oct 2007 23:40:11 +0200

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

"Aplikacja webowa - wybór technologii" by Jarosław Zabiełło

Thu, 18 Oct 2007 22:00:27 +0200

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.

"Aplikacja webowa - wybór technologii" by http://nandrew.blogspot.com/

Thu, 18 Oct 2007 20:09:57 +0200

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).

"Aplikacja webowa - wybór technologii" by http://nandrew.blogspot.com/

Thu, 18 Oct 2007 20:00:43 +0200

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).

"Aplikacja webowa - wybór technologii" by Leszek

Mon, 08 Oct 2007 11:19:53 +0200

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

"Aplikacja webowa - wybór technologii" by ilear

Mon, 08 Oct 2007 01:41:35 +0200

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? ;)

"Aplikacja webowa - wybór technologii" by Jarosław Zabiełło

Thu, 04 Oct 2007 15:22:40 +0200

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.

"Aplikacja webowa - wybór technologii" by arag0rn

Thu, 04 Oct 2007 13:31:09 +0200

Kamyczek do ogródka railsów:

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

"Aplikacja webowa - wybór technologii" by grzejnik

Thu, 27 Sep 2007 20:09:54 +0200

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???

"Aplikacja webowa - wybór technologii" by Piotr N.

Wed, 26 Sep 2007 11:24:07 +0200

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

"Aplikacja webowa - wybór technologii" by Zyx

Sat, 22 Sep 2007 14:34:51 +0200

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.

"Aplikacja webowa - wybór technologii" by dreamweb

Wed, 19 Sep 2007 16:25:15 +0200

zgadzam sie z ostatnim postem

"Aplikacja webowa - wybór technologii" by Doniek

Mon, 17 Sep 2007 15:17:40 +0200

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

"Aplikacja webowa - wybór technologii" by rsz

Sun, 16 Sep 2007 18:26:01 +0200

drętwa prowokacja :)

"Aplikacja webowa - wybór technologii" by anonymous coward

Sat, 15 Sep 2007 20:41:35 +0200

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