publikuj: Opublikuj w wykop.pl Opublikuj we flaker.pl Opublikuj na OSnews.pl Opublikuj w delicious wydrukuj
14 skomentuj »

TAGI: framework , python , ruby , django , rails , twitter , aplikacja webowa

2009-09-22 13:45  |  Adam Golański

Frameworki WWW: przekleństwo czy błogosławieństwo webdewelopera?

Frameworki WWW: przekleństwo czy błogosławieństwo webdewelopera?

Rosnąca liczba frameworków przeznaczonych specjalnie do budowania aplikacji webowych zamienia pracę webmasterów w czystą przyjemność. Django, Ruby on Rails, Zend – przyśpieszają pisanie kodu aplikacji, a dzięki bibliotekom takim jak jQuery czy Prototype, łatwo stworzyć atrakcyjny interfejs. Jednak ta droga na skróty ma też, zdaniem niektórych, poważne wady.

Wszystkie gotowe frameworki starają się uczynić pracę webdewelopera prostszą. Lata temu, gdy stworzenie „aplikacji webowej” wiązało się z czarowaniem w Perlu, by stworzyć jakiś skrypt CGI, albo pisaniu w Javie osadzanych apletów (potem to wszystko trzeba było ręcznie łączyć z HTML-em), webmasterka, mówiąc dosadnie „ssała”. Nowe narzędzia, które pojawiły się w ostatnich latach, poważnie to zmieniły.

Podczas konferencji deweloperów Pythona, która odbyła się we wrześniu br. w Argentynie, znany programista Jacob Kaplan-Moss zaburzył jednak trochę tę idylliczną wizję. Podczas swojej prezentacji stwierdził, że „dokonaliśmy wielkiego przejścia w myśleniu – nie rozważamy już stron WWW, lecz aplikacje webowe”. Zdaniem Kaplana-Mossa, nadszedł jednak czas na nowe przejście, by myśleć holistycznie, o „witrynie internetowej” i wszystkich powiązanych z nią technologiach.

Czym są te „wszystkie powiązane technologie”? To szeroka kategoria, która obejmuje zarówno frameworki dla backendu, jak i HTML5. Do tej pory wszystko to sprawdza się, gdy przychodzi zrealizować bardzo standardowe projekty – jednak gdy pojawia się koncepcja stworzenia czegoś rewolucyjnego, wszystkie te dotychczasowe frameworki okazują się bezużyteczne.

Jako przykład Kaplan-Moss przedstawił startup 280Slides.com. To narzędzie tworzenia prezentacji zachowuje się jak pełnokrwista aplikacja desktopowa. Aby jednak urzeczywistnić swoją wizję, deweloperzy musieli stworzyć od podstaw nie tylko własny framework Cappuccino, ale też własny język programowania ObjectiveJ.

Dlatego zdaniem Kaplana-Mossa, współczesne frameworki zapędzają webdeweloperów w ślepy zaułek. Mają dwa podstawowe problemy – nie skalują się wystarczająco i zamykają aplikację w obrębie swoich ograniczeń. Zoptymalizowane dla standardowych potrzeb, zawodzą, gdy aplikacja zaczyna rosnąć. Pojawia się „,moment Twittera” – i wówczas, jak to malowniczo opisał współtwórca Django, „rozpętuje się piekło – przerosłeś swój framework i jesteś udupiony”.

«poprzednia 1 2 następna »

publikuj: Opublikuj w wykop.pl Opublikuj we flaker.pl Opublikuj na OSnews.pl Opublikuj w delicious wydrukuj
14 skomentuj »

Komentarze

  • jankoprowski

    #1 Jan Koprowski® 2009-09-22 14:18:47 0

    Przydałby się po prostu taki WYSIWYG dla frameworków. Agnostyczne połączenie EXT GWT 2.0 z frameworkami. Takie cos jest obecnie bardzo potrzebne.

    Próbował to zrobić Microsoft z ASP, ale im nie wyszło. Można się tylko uczyć na ich błędach. Mi osobiscie nie przychodzi do głowy jak mogłoby to działać.

    Projektuję interfejs, klikam w guzik, wpisuję URL, który jest przerabiany na "kontroler/akcja" i zaraz potem ląduję w odpowiedniej metodzie, gdzie muszę tylko wklepać kod. Tak może byłoby nawet fajnie.

    Ale wtedy co z agnostycznoscią bibliotek JavaScriptowych?

    IP: 192.198.151.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.21 Safari/532.0

  • Treo

    #2 Treo 2009-09-22 14:41:34 0

    Co masz na myśli pisząc o agnostyczności JavaScript?

    IP: 87.205.238.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

  • Greg234

    #3 Greg234 2009-09-22 14:47:42 0

    Po dojściu do "webmasterka, mówiąc dosadnie „ssała” odechciewa się czytania.

    Zachowajcię proszę jakiś w miarę rozsądny poziom :)

    IP: 83.12.56.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

  • eimi

    #4 eimi® 2009-09-22 15:40:29 0

    Greg234: Taki był duch oryginalnej prezentacji Kaplana-Mossa. Jeśli to Cię boli, przepraszamy za ten ohydny brak savoir-vivre. A masz jakieś merytoryczne uwagi? :)

    IP: 88.156.95.[...] Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1) Gecko/20090805 Firefox/3.5.2

  • jankoprowski

    #5 Jan Koprowski® 2009-09-22 16:01:09 0

    Wspomniałem o extJS, a mogłoby fajnie działać ze wszystkimi frameworkami.

    IP: 89.79.56.[...] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.21 Safari/532.0

  • Fallen

    #6 Fallen 2009-09-22 16:24:37 0

    Zgadzma się z wpełni z opinią Mossa.

    IP: 85.232.225.[...] Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.9.0.14) Gecko/2009090216 Ubuntu/8.10 (intrepid) Firefox/3.0.14 GTB5

  • slawek22

    #7 slawek22 2009-09-22 16:53:53 0

    Frameworki GUI JS kompletnie nie nadają się na produkcję. Są po prostu zbyt "ciężkie". Fajnie w tym wyglądają demka pojedynczego komponentu, ale prawdziwe aplikacje - zbyt wolne i zbyt długo się ładują (głównie pod IE z powodu ociężałości / powolności działania tej przeglądarki). 

    Częściową winę ponosi wspieranie przestarzałych technologii (np. IE6/7 czy quirksmode).

    Przykładowo kontrolka Tree z YahooUI jest tak wolna, że inicjacja zwykłego drzewka z 200 itemami zajmuje na dwurdzeniowym A64 kilka sekund (podczas których np. IE całkowicie przestaje odpowiadać). To samo tyczy się Dojo.

    Drag & Drop dla web :) Może za 5-10 lat kiedy przeglądarki microsoftu znikną z rynku lub zostaną zmarginalizowane.

    >Wspomniałem o extJS, a mogłoby fajnie działać ze wszystkimi frameworkami.

    Nie mogłoby. Nie ma jednolitego API, standardu czy podstawowego zestawu kontrolek dla frameworków.

    IP: 79.185.215.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.21 Safari/532.0

  • XooX

    #8 XooX 2009-09-22 21:29:04 0

    Przeglądarki Microsoftu nie znikną z rynku - chyba że Microsoft zniknie :) - i mają się całkiem dobrze. I niech tak zostanie...

    IP: 85.221.160.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.0.14) Gecko/2009082707 Firefox/3.0.14 (.NET CLR 3.5.30729)

  • Asdic

    #9 Asdic 2009-09-22 22:18:47 0

    Żadna sensacja - gość Ameryki nie odkrył. Każdy jezyk programowania jest ograniczony funkcjonalnie a każdy framework jeszcze bardziej to ogranicza. 

    Domniewam, że być może chodzi mu o stworzenie nowego języka który byłby kwintesencją obecnych ale to prowadzi do punktu wyjścia.

    IP: 85.221.160.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.0.14) Gecko/2009082707 Firefox/3.0.14 (.NET CLR 3.5.30729)

  • mikimoto

    #10 mikimoto 2009-09-23 08:48:44 0

    Bo to wszystko powinno wygladac troche inaczej, elementy strony internetowej powinny byc luzno ze soba powiazane tak aby kazdy element prosto i szybko przepisac. Wiekszosc frameworkow sie do tego nie nadaje, taki CakePHP czy Symphony po prostu w pewnym momencie zablokuja dalszy rozwoj aplikacji. Zend czy Pylons dla pythona sobie troche lepiej radza ale nadal to jest jakies ograniczanie. Lepiej poswiecic troche czasu i dobrze zaprojektowac wlasne elementy aplikacji ewentualnie w tych elementach korzystac z gotowcow, wtedy taka czesc latwo sie zastepuje czyms nowym.

    IP: 88.220.181.[...] Opera/9.80 (X11; Linux i686; U; en) Presto/2.2.15 Version/10.00

  • mateoo

    #11 mateoo 2009-09-23 12:34:04 0

    Frameworki to zło, większość czasu spędza się na wymyśleniu jak obejść ograniczenia żeby wykonać dokładnie to co się chce, do tego często nie można tego wykonać tak jak się chce, tylko trzeba wszystko robić zgodnie z zamysłami twórców frameworka które przecież nie zawsze muszą być słuszne.

    Myślę że przyszłość będzie raczej należała do generatorów kodu umożliwiających operowanie na własnych szablonach. To oszczędza czas a nie musi ograniczać koncepcyjnie

    IP: 212.75.100.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) FirePHP/0.3

  • Asdic

    #12 Asdic 2009-09-23 21:39:04 0

    Framework spełnia swoje zadanie pod warunkiem, że jest to framework dedykowany - czyli pod konkretny projekt.

    Trzeba się zastanowić dokąd zmierza Internet... Może trzeba spojrzeć rewolucyjnie i zamiast aplikacji typu server-side  iść w kierunku hybryd server-side client-side.

    Myślę, że nie uciekniemy od przetwarzania części kodu po stronie klienta.

    IP: 85.221.160.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.0.14) Gecko/2009082707 Firefox/3.0.14 (.NET CLR 3.5.30729)

  • michancio

    #13 michancio 2009-09-28 12:18:35 0

    Asidc: nie musimy tworzyć czegoś rewolucyjnego. Już to jest - chcesz sever-side client-side - patrz Adobe Flex+code behind oraz Adobe AIR.

    IP: 195.69.82.[...] Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; GTB6; SLCC1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30729)

  • hipertracker

    #14 hipertracker® 2010-05-10 14:47:48 0

    @mateo: to nie fremaworki, ale Django i podobne monolityczne frameworki są ograniczone tak, że potem "większość czasu spędza się na wymyślaniu jak obejść ograniczenia aby wykonać dokładnie to, co się chce".

    Ci, co mówią "po co mi framework" szybko skończą na tym że wymyślną swój własny, który potem... porzucą, bo się zamotają i znowu będą wymyślać kolejny. I tak w kółko. Takie typowe myślenie i praktyka wielu pehapowców... Frameworki są po to aby przyśpieszyć powtarzalne operacje, budowanie kolejnych witryn z kodu wielokrotnego użytku. I nowsze frameworki mają już bardziej modularną budowę, można prawie wszystko wymienić. Moss tak sobie pisze, bo jego Django jest zbyt monolityczne i on o tym dobrze wie.

    @slawek22: co do GUI i JS, to Google pokazał że można i ich biblioteka Closures (jest open source) jest z powodzeniem używana na wielką skalę.

    @Ascid: każdy język jest może jakoś ograniczony funkcjonalnie, ale ten zarzut dotyczy w raczej  niewielkim stopniu języków homoikoniczych takich jak Lisp czy Clojure (javowy dialekt Lispa). W języku homoikonicznym dane są programem, a program danymi, składnia danych i programu jest taka sama. Jeśli czegoś brakuje, nie trzeba pisać petycje do developerów, wystarczy napisać własne makra (makra lispowe nie mają nic wspólnego z prymitywnymi makrami C). Można w ten sposób zmieniać język w stos. do potrzeb. Podobnie elastyczny językiem, choć nie aż w takim zakresie jak makra Clojure, jest Scala. Z ciekawych frameworków napisanych w Scali można polecić Akka lub Lift (Akka może być włączony w Lifta).

    IP: 89.167.220.[...] Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8

Uwaga! Możesz zarejestrować się w serwisie i w ten sposób zarezerwować swój nick oraz ominąć konieczność ciągłego odczytywania wyrazów.

Aby dodać komentarz, musisz podać swój nick, treść komentarza oraz poprawnie przepisać oba słowa z obrazka (słowa muszą być rozdzielone spacją).
W treści komentarza można używać języka formatowania BBcode.

Polecane książki

Czytaj Webhosting

Chcesz być na bieżąco z naszymi informacjami? Zapisz się na Newsletter.

Zarejestruj domenę

Sprawdź dostępność swojej domeny:

.pl: 0 zł   .com: 19.90 zł
.com.pl: 0 zł   .eu: 19.90 zł