Django uslužuje 500.000 stranica na sat
 

Iliti ~140 stranica svake sekunde!
:1039:

Njihov setup.

heh :) ovo zvuci kao language/framework war :)

http://www.codinghorror.com/blog/archives/000838.html

Pazi, sa ovakvim setupom (hardver) onoliki downtimovi... primera radi juce je curse gaming bio down oko 1h a da nepricam o tome sto iz kesa redovno dobijam outdated sadrzaj...

gomila proizvoljnih zakljucaka (i netacnih ili delimicno tacnih komentara).. znaci bez zelje za advokatisanjem ili flejmom, cisto da skrenem paznju na netacne premise, jer covek pise o razlici u perfomansama izmedju interpretiranih i kompajliranih jezika, ali potpuno "zaboravlja" par stvari:

- razlika lezi u vremenu kompajliranja, ako se koristi kesiranje kompajliranog koda (sto podrzavaju i php i python, a verovatno i ruby), onda je ta razlika mnoooogo manje drasticna (a naravno niko nece da pravi tako tesko opterecen server bez keshiranja koda). Secam se podatka od pre jedno 6-7 godina da se kompajlirani perl izvrsava najvise 1.5 puta sporije od kompajliranog C-a, a u nekim slucajevima cak i brze (u malim programima gde perl samo poziva visoko optimizovane rutine i sistemske funkcije)...

- Usluzivanje bilo kakvog dinamickog sadrzaja na apachu je oko 200 puta sporije od slanja statickih strana (plus trosi mnogo vise CPU i memorije). Znaci niko normalan nece na serveru sa ogromnim loadom da generise strane direktno, pa je u sustini nebitno kako generises strane, mnogo je bitnije kako ih keshiras

- Razvoj u C-u je mnooooogo sporiji, sa vise bagova i problema, plus developeri kostaju vise (a manje poznaju specificnosti web programiranja). Radio sam, na pocetku karijere, na jednom solidno velikom projektu koji je pocet u C-u, a onda kad je potroseno pola godine i 100K funti na prvih 15% projekta, presli smo na perl i zavrsila sve do kraja godine...

Takodje u komentarima neko pise kako je C++ brzi od C-a, sto je obicna glupost, obrnuto je... a fortran je jos brzi od C-a, tako da mislim da bi svi trebali da krenemo da pravimo sajtove u fortranu :)

ivane, nisam mislio na sam clanak i poredjenje brzina - prilicno je irelevantno, nego na "broj strana" koji servira twitter koji je napravljen nad RoR-om kao "konkurentskim" framework-om, a poenta odgovora je da mozes da koristis koji god MVC framework trenutno postoji, ali kada dodje do skaliranja na velikom broju upita/s koji izlazi iz okvira samog framework-a:
1) moraces da izlomis dobar deo funkcionalnosti zbog kojih si uopste krenuo da ga koristis
2) na kraju ces skontati da lagano gubis prednost koju si imao na pocetku izborom udobnijeg okruzenja
3) neces mnogo spavati

takodje, ako procitas malo bolje clanak na codinghorror-u, naglasak takodje nije na samoj brzini kompajliranja posto je to prilican bull**** (slazem se). ofkorz, retko kome zatreba skaliranje tog obima.

hm.. sto se fortrana tice, ne bih se /bin/bash slozio, pre bi bilo tacno reci da se izuzetno lako skalira zbog same jednostavnosti jezika i da postoje izuzetno dobri kompajleri na trzistu, tako da ce prosecni sci-joe (veliku fortran koda u trenutnoj upotrebi nisu napisale osobe koje su po profesiji programeri) dobiti impozantno bolje rezultate sa svojim fortran kodom koji je napisao za 100 puta krace vreme, nego sa sklep/zbudz C kodom. btw. nigde nisam video poziv da web programeri predju na C/C++?!?

elem - poenta je, wtf znaci django servira ~140 strana u sekundi?

100% stoji. Poenta frameworka je da ti omogućava lak start i jednostano održavanje, ali kada se suočiš sa situacijom da ti trebaju ludačke performanse onda kompletna poenta pada u vodu pošto baš ono što frameworke čini zanimljivim sada predstavlja ogroman performance killer koji treba da bude odstranjen.

Ja imam jako dobra iskustva sa eaccelerator-om [php accelerator]

Server uptime: 1 day 16 hours 37 minutes 16 seconds
Total accesses: 1327299 - Total Traffic: 5.6 GB
CPU Usage: u564.15 s25.51 cu1.76 cs.21 - .405% CPU load
9.08 requests/sec - 40.0 kB/second - 4514 B/request
30 requests currently being processed, 8 idle servers

obicno je load oko 0.3, a cesto i 0.0x...

@invanhoe: prosto ne znam odakle da počnem sa demantijima, pa neću ni da počinjem :D

od pocetka :) problem sa C/C++ vs. rest of the world benchmarkovima je u tome sto obicno svaki benchmark koji sam video do sada posmatra uzak niche u kojem je fiktivni protivnik isti ili bolji od loseg ili osrednje napisanog C/C++ koda. naravno, ne sporim prakticne razloge koriscenja jezika koji sami brinu o jednom delu resursa i imaju bogate framework-ove.

Ti benchmarkovi bi bili smešni da nisu ponekad opasni. Tako su ljubitelji OCaml-a (koji je inače jako lep jezik) ubedili neke nesrećnike da je njihov omiljeni jezik brži od C-a, pa je rezultat završio na Slashdot-u: http://developers.slashdot.org/artic.../03/14/2258219

Za OCaml još i da im čovek poveruje ako ne zna, ali je web pun "dokaza" da je Java tu negde sa Fortranom po performansama, a ko god je imao prilike da vidi realan Java kod u akciji može da se uveri u suprotno.

A posebna je priča što je sva ta zafrkancija nepotrebna. Sasvim dovoljna reklama za npr. Python je da je lepši i lakši za programiranje od C-a (da ne pominjem ++ :D ) - čemu to izmotavanje sa benchmarkovima?

ma slobodno, nisam uopste u advocacy fazonu (bar trenutno :)).. ako sam rekao nesto glupo ili netacno slobodno udri... :)

Diskutabilno.

Dobar framework će da omogući da programiraš na višem nivou, dok će on na sebe preuzeti odgovornost i posao da se npr. kod izvršava paralelno na više jezgara, što je danas sasvim očekivano. Da li ćeš baš sam uspeti da budeš tako efikasan i da posao raspodeliš na više jezgara?

Uzmi za primer SQL. Odluka o tome kako izvršiti upit je skoro u potpunosti prepuštena bazi. I radi to dobro, zar ne?

@Dejan - Ta diskusija poteže definiciju frameworka, a to je nešto u šta ne bih želeo da se upuštam ;) Ograničimo ovu diskusiju na web frameworke - Django, Rails, ASP.NET, Symfony, CakePHP i sijaset drugih koji su na tržištu.

Navedeni primeri dodaju funkcionalnost u slojevima na sam jezik (obrada zaheva, apstrahovanje pristupa baze i drugim resursima, ORM, serviranje podataka itd) čime ubrzavaju razvoj, ali usporavaju izvršavanje. Otklanjanjem tih slojeva se dobija na brzini izvršavanja, ali se gube razne funkcionalnosti zbog kojih se inače frameworci i koriste tako da se zna desiti da sa nekim projektima dođeš u tačku da ti je framework kamen oko vrata i da bi ti bilo bolje da si počeo bez njega.

To je u suštini poenta onoga što sam rekao u prethodnom postu. Činjenica je da dobar deo tih frameworka optimizuje izvršavanje kako bi stvari bile rešene brže, ali retko kad to može da nadomesti gubitak performansi uzrokovan samim korišćenjem frameworka.

^Ma kako to?

Pa hajde da napravimo najobičniju stranicu u ASP.NET-u pa da mi onda neko pokaže ekvivalent u C ili C++ koji će jednako dobro (i jednostavno) da skalira od servera sa jednim procesorom do onog sa npr. 8 procesora.

Što se pominjanja SQL-a tiče, poenta je oko deklarativnog programiranja, a npr. ASP.NET to sasvim podržava. Evo primer:
I to je to. Nikakvo smaranje sa ovim ili onim oko baze, petljama, a pokažite mi kako će to loše da skalira, itd. Ili, pokažite mi ručno pisani kod koji će to da radi brže (a pogotovo ako se ne oslanja na framework).

Frejmvork je vrlo širok pojam, neki od njih teže da pokriju i performanse, a neki (o kojima Ilija priča) samo lakoću razvoja. Django, recimo, sam kreira tabele u bazi i SQL upite na osnovu modela i svakako ne može biti efikasniji od ručno optimizovanog upita. Barem do sad fokus njihovog razvoja nije bio na skalabilnosti.

To onda više liči na samo ORM, zar ne?

ORM, plus solidan templejt endžin, plus dobro osmišljeno URL mapiranje, validacija formulara itd. Otprilike sve što veb developeru treba. Mislim da se to može nazvati frejmvorkom. :)

Dobro, ali pošto je spemanje i dovlačenje podataka (tj. objekata) iz baze rešeno na "ORM način", onda je besmisleno gledati samo brzinu. ORM rešenja, koliko je meni poznato, nikad nisu bila brzinski šampioni u tim operacijama, naravno da nisu, upravo zbog O<->R mapiranja.

Hajde da uzmemo framework koji nije obavezno ORM. Npr. neki koji može da koristi stored proc za spremanje i izvlačenje podataka. Možda, Subsonic za ASP.NET.

Samo da dodam još malo ulja na vatru, ovo mi je promaklo (sorry Ilija, mislio sam da je od tebe krenulo :D)

Šta znači tačno ova rečenica?

Da "čista" rešenja ("čist" PHP, "čist" ASP.NET..) mogu da serviraju beskonačno mnogo upita na nekom hardveru i da nećeš doći u situaciju da dostigneš maksimum?

(Pa i "čist" PHP, itd. je framework.)

A šta kad koristiš npr. "čist" PHP i dođeš do maksimalnog broja upita koje hardver može da izdrži? Šta onda? Pa i onda moraš da "lomiš", po tebi.

Pa i ako ćeš da "lomiš", šta onda kad za 6 meseci opet dostigneš max? Opet "lomiš"? Pa dokle tako prijatelju? Dok ne odeš u asembler? Pa i tamo ima max.

Kupi se novi server (doda CPU, itd) i kraj priče.

Ne znači da od početka trebaš da ideš sa najsporijim rešenjem i traljavim programiranjem, naravno.

ova recenica znaci veoma prostu stvar - od trenutka kada korisnik zatrazi neki content do trenutka kada ga obavi deli ga N tralalala operacija i svaka apstrakcija i svaki layer se penalizuje na odredjeni nacin, u nekim situacijama cena nije bitna - u nekim jeste. kao sto sam spomenuo - u velikom broju slucajeva to apsolutno nije problem, ali twitter je primer u kojem je bilo potrebno osakatiti sam RoR da bi se aplikacija dovoljno dobro skalirala - as easy as that. druga opcija je da pises sve ispocetka, ili da se napravis pametan i kazes "e da sam ja to pisao - ja bih to u ... i stavio ... i upotrebio hepek i ... ma ljubi ga majka".

hm... pre svega sa modernim kompajlerima nisam siguran koliko je racionalno poredjenje sa asemblerom - ali da, ima situacija u kojima je potrebno spustiti se dovoljno "nisko", zasukati rukave i raspisati dobar deo stvari od nule - gde nula nije tabula rasa programiranja, nego komponente kao sto su custom index, custom parser content-a, custom whatever - kao sto spomenuh - ovo nije narocito cest slucaj, pogotovo ne u klasicnim biz aplikacijama (u prevodu - koji ce ti?), ali igrom slucaja u kompaniji u kojoj trenutno radim je tako nesto bilo neophodno (vast.com) - to svakako ne znaci da je neko bio retardirano dokon i frontend pisao C-u.

jel? mozda ako aplikacija moze prakticno da se skalira vertikalno, takodje - i vertikalno skaliranje ima veoma grube limite koje namece hardware, OS, kao i sam jezik/framework - npr. ruby i sa njim RoR nisu sampioni vertikalnog skaliranja - jedan request == 1 VM (ok, postoje neki standardni mehanizmi kojima se ovo moze delimicno kompenzovati i svakako je cena instanciranja ruby VM-a daleko manja od instanciranja npr. JVM-a) i to ti je sto ti je - i tu opet dolazimo do toga da sam super-mega framework koji te resava mnogih glavobolja na pocetku i ciji izbor izgleda kao jako dobar potez koji stedi mnoge sate programiranja, debagovanja, smanjuje kompletnu cenu izrade, ... name it - u takvoj situaciji pocinje da gubi ogromnu prednost koju je u prvom trenutku davao.

naravno, ali ovde je u pitanju situacija kada npr. odjednom aplikacija koja je iz racionalnih razloga bila pisana da podrzi max 10 upita u sekundi u nekom trenutku mora da skalira na 1000 upita u sekundi i kada "buy more iron" ne pomaze, ili je ekonomsko samoubistvo - struja kosta, rackspace kosta, iron kosta (ovo je barem jednokratna investicija) - ili kada naprosto ne resava problem.

ovo je rasprava koja moze da ide u beskonacnost, ali ono sto mene nervira u celoj prici je X je postigao Y bez price o uslovima Z - u prakticnom primeru to je:
1) django je podrzao ~140 upita u s (out of the box?)
2) twitter koji koristi RoR podrzava ~11K upita u s (out of the box?)
3) java je brza kao/brza od C/C++-a (10 primera u kojima ni u tragovima nije moguce videti ponasanje JVM-a kada GC divlja, ili su na nivou domaceg zadatka iz osnova programiranja - ne mislim nista lose, ali cesto takvi primeri pokazuju izuzetno malo, a buzz koji se generise je izuzetno velik)
4) ... name it, web je prepun potpuno banalizovanih benchmark-a

^Sorry, od kako je kompjutera prelazilo se na nove jezike/platforme i skoro uvek je pri tom dolazilo do gubitka performansi. I ne vidim da je to sprečilo prelazak na te nove platforme. Koji to mainstream framework (PHP, ASP.NET, Java, itd) nije na višem nivou od npr. C/C++, koji je bio mainstream u prošloj deceniji?

Po neki deo, ponekad, može da se uradi u jeziku nižeg nivoa zarad performansi, ali to je pre izuzetak nego pravilo. Znači zbog jednog slučaja od npr. 100, u kom smo jedan mali (dokazano kritičan) deo aplikacije, napisali u "nižem" jeziku --- to znači, šta, da je framework koji koristimo "izgubio prednosti" ili da ne koristimo taj framework?

Pominješ cenu struje, itd? Pa što se onda ne koriste C i C++ za web aplikacije? Ispade, svi su izvršili "ekonomsko samoubistvo", pošto ja taj C i C++ nešto ne viđam u web aplikacijama.

Koje su to uopšte web aplikacije pisane u C/C++ i koliko ih je u odnosu na one pisane u Javi?

Radi se o tzv. "dramaturgiji stranice" :)

Daj bre, sve pucaju Java aplikacije na svakom koraku zbog problema sa upravljanjem memorijom.. Ajde, šta misliš.. Je, isto se dešava i sa .NET aplikacijama..

A u isto vreme C/C++ imaju savršen model za isti problem, how yes no, baš su poznati po tome.

Već neko vreme pratim razvoj ove teme i ne mogu da ne primetim:

1. Svrha ove teme je postavljanje lepe vesti o jednoj od platformi koju koristim i u čijem razvoju učestvujem u slobodnom vremenu. Definitivno nisam želeo da pokrenem još jedan benchmark/language/framework/tehnološki rat.

2. Ovaj forum odista počinje da biva hejterski :(. Još gore, neki učesnici unose dodatnu zabunu time što ne čitaju prethodno napisano i/ili ne razumeju dovoljno dobro neke tehnologije/koncepte.

Toliko od mene na ovoj temi.

Ne bih da ulazim u diskusije, samo bih želeo da istaknem šta je u stvari "the root of all evil". Džabe džango, džambo, mambo-džambo... ne pomaže ni CPU ni framework ni Bog.

Znam za par koje koriste (ili su koristile) C/++ u delovima, radi optimizacije, od aplikacija 37signals-a do (prethodne inkarnacije) eBay-a. Javin GC nece nikad biti ni prineti custom memory alocatoru po pitanju performansi itd. itd.
Ali ne radi se o tome, uopshte.
Caboom je u pravu, samo ti, degojs, bash i ne razumesh, ili ne zhelish da razumesh shta pokushava da ti kazhe :)

:-)

U *DELOVIMA*. Nisam pitao u delovima, da se razumemo.

Pa čekaj malo, eBay znači, npr. 99% funkcionalnosti ostvaruje u Javi, 1% u C++ i šta sad --- reći ćemo da eBay ne koristi Javu? Pa nemojte priču o tome kako je nešto u delovima optimizovano pomoću C/C++, servirate kao da je cela aplikacija pisana u C/C++. Koliko ja znam eBay radi pod Javom, a ako su nešto izdvojili i uradili u C++, vala neka su.

Samo.. pa koji su to sajtovi koje daješ za primer? eBay? Jesi li ti pri sebi, bez ljutnje? Šta, većina sajtova treba da očekuje broj posetilaca kao eBay, pa hajde odmah da radimo kao oni? Imamo li svi i budžet za IT kao eBay?

Još si samo trebao da pomeneš i Google i njihov Google Web Server, pa da batalimo Apache i IIS.

Evo jednostavnog primera: koliko ljudi ovde je rešavalo problem velikog broja korisnika tako što je deo aplikacije prepisivalo u C++?


Ja njega duže vreme ne razumem, iskreno.

Ne, necu da pochinjem raspravu na tu temu... :)

Poenta cele priche je izolovati bottleneck i zakrpiti ga odgovorajucom metodom koja se ne svodi na puko "dodaj josh cpu-a i memorije" ukoliko ne mora. Niko pametan ne bi kreirao kompletne back-endove u C++u u danashnje vreme.
Pomenuh, 37signals su zbog problema skaliranja pisali par cgi programa u C-u u pozadini backpack-a (ne mogu da nadjem link ka celoj prichi o tome trenutno).
Da li su mogli da reshe problem dodavanjam X instanci Mongrel-a, uz par svezhih rekova? Mozhda, ali su ga reshili drugachije, optimizacijom na niskom nivou.


Btw, eBay nema nishta vishe u C++u, sve je u Javi... shto me ne chudi, kad im je jedan od problema bio "dostigli smo max broj varijabli u klasi i C++ kompajler je stao"... takav horor od softverskog dizajna ne bih zheleo ni da vidim :)

Alo, pa ti sada navodiš eBay kao upravo suprotan primer: rešili su se C++, ispade, a ne Jave. O čemu onda uopšte pričamo vezano za eBay, Javu i C++?

Slobodno vi izbegavajte bilo kakve frameworke i projektujte svoje sajtove od prvog dana kao da će biti u rangu sa Google.com i sličnim. I izvlačite primere gde je neko odradio možda 5% funkcionalnosti u C++ kao dokaz.. ne znam samo čega, a pri tom ignorišite bezbroj sajtova gde to nije rađeno.

I ja mislim da dalja diskusija nema smisla.

A da, ostaje mi samo da Petru i ekipi, koja radi to što radi, skromno poručim: samo napred.

Nije mi baš više jasno oko čega je sve rasprava :D ali što se frameworka tiče, u principu ih izbegavam kad god se radi o iole dugotrajnijem projektu. Moje iskustvo sa svim frameworcima (koja reč, majko Božja!) počev od starog lošeg MFC-a do DNN-a je da pružaju puno sve dok radiš 100% ono što su kreatori istog zamislili da ćeš da radiš. Čim treba da uradiš nešto neortodoksno, eto belaja na kvadrat.

Zato danas gledam da koristim biblioteke koje ne nameću dizajn, a ne frameworks.

:1043: egzaktli. Postavi se pitanje upotrebne vrednosti necega sto treba da ti olaksa posao a moras da provedes dodatno vreme da ga budzis. A da bi mogao da ga budzis moras da ga provalis dobro. A ako si ga vec provalio, onda si mogao i svoje da napises.

Ja pricam o onim "kompletnim resenjima".

Dakle, izuzeci, ne pravilo.

A da li misliš da ćeš tako lako doći u situaciju da to radiš?

Pravilo je da se "izuzeci" pojave u iole ozbiljnijim projektima i često potpuno obesmsle upotrebu frameworka.

Da ne bude zabune, ovo nije slučaj samo sa "gotovim" frameworcima (ima li srpska reč za ovo čudo?) već isto tako i sa internim koje naprave lokalne "arhitekte". Kad sledeći put budem menjao posao, moraću da pazim da nemaju "arhitektu" u timu

Ne znam. Do sada, ja lično nisam viđao izuzetke koji bi obesmislili upotrebu frameworka koji smo koristili (npr. Struts za Javu).

Dalje, da li je ASP.NET framework? Koji izuzetak će to da obesmisli upotrebu istog (ili gore navedenog Strutsa)?

Nemojte za primere da navodite RoR kome je, koliko ja znam, ionako namena rapid dev i koji se i inače nosi filozofijom "convention over configuration" ili DNN (znam da ga reklamiraju kao web framework, ali.. to je meni više CMS koji je OSS pa onda..), uzmite neki framework iz "teške kategorije", npr. Struts.

Nisam koristio Struts, pa ne mogu da komentarišem. Međutim, podsetiću te da si koristio DNN i rešio da ga batališ ;) Jeste da je DNN i CMS, ali je i razvojni framework.

Ne, ASP.NET ne bih kvalifikovao kao framework.

Haha, da, da.. ali taj DNN sam koristio na tuđi nagovor ;) (mislim da do tada nisam ni znao za isti). To je primer gde je sajt suviše jednostavan da ti je bilo kakav framework uopšte potreban. A sam DNN nikad nisam ni pogledao ozbiljnije.

Nego, na poslu su mi pre par meseci servirali (baš ovo što kažeš, neki Chief Software Architect) da projekat odradimo u DNNu, te sam na sve moguće načine morao da branim odluku da koristim samo ASP.NET. U stvari, meni je više bilo "O ne, ne DNN." :D

ASP.NET nije framework? Pa onda to nije ni Struts. E, Struts jeste framework, samo drugačiji (MVC) od ASP.NET-a.


(Vidi se da nisi upoznat sa Javom (za web) mnogo. Tamo svako ima svoj web framework. Zato tebi i izgleda da ASP.NET to nije :))

Koliko bi nam trebalo da startujemo bez DNN-a? Problem je nastao kad smo hteli nešto "out-of-the-box" kao što se gotovo uvek dešava sa uspešnim pojektima :D


Manje-više svako ima viziju šta je framework a šta nije. Po meni je granica kad počne da te "zaključava" u svoj dizajn. ASP.NET je prilično fleksibilna tehnologija i tako je ne smatram framework-om. U stvari, imaš više frameworka izgrađenih nad ASP.NET-om, od kojih su neki "zvanično" deo ASP.NET-a (Master pages) a neki ne (DNN).

Gledaj, nećemo da gledamo MS/ASP.NET jer je to izuzetno forsirana tehnologija, koja je još i deo .NET-a. Nije dobar primer za reper. Ti ostali framevorci :) za ASP.NET, jesu li uopšte rašireni, ima li knjiga za iste?

Uzmi Javu, gde to nije bio slučaj, te su tamo napravljeni, nezavisno ili uz pomoć Suna, framevorci ("platforme"?) koje su izuzetno fleksibilne i "enterprise class": pomenuti Struts ili Spring. Pa na Apache Struts stranici čak piše, ne znam da li još uvek, da taj framework nije namenjen malim sajtovima, već upravo obrnuto. Ako imaš sajt od 10-20 stranica, zaboravi Struts ili Spring, ne treba ti, oni to čak napominju. Ali ako imaš da radiš sajt od 200 (dinamičkih) stranica, sa kompleksnom logikom, i jedan i drugi će da budu ogromna pomoć, jer su od samog početka građeni za takve stvari. A nema govora da nisu fleksibilni. I pro knjiga za iste ima više nego dovoljno.

Dok npr. RoR jednostavno nije u toj klasi, nije tome ni namenjen, bar koliko sam ja upoznat.

Ne bih rekao da je ispravno uzeti jedan framework (DNN), koji je čak i više CMS (mi smo ga tako koristili, kao običan CMS), pa donositi zaključke o svim platformama. Pa svaki CMS ti omogućuje da postaviš sajt očas posla, za razliku od bilo kog "programerskog" frameworka. I nećeš baš omastiti brke ako poželiš da ih proširuješ.

Bojim se da ne mogu. Javu sam poslednji put koristio 2000-te i to jedan aplet koji komunicira sa socket serverom, tako da nisam u stanju niša određeno da kažem o Java "frejmvorcima".

Ja pominjem DNN jer je valjda jedini "frejmvork" koji obojica poznajemo. Inače, imao sam ista iskustva sa bukvalno svakim koji sam koristio, bio "kupovni", open-source ili interni. Recimo sa MFC-om možeš uz 3 klika da napraviš kostur-aplikaciju koja izgleda više nego super, ali probaj da uradiš nešto što oni nisu zamislili i ima oči da ti iskoče.

Sve je to lepo i slažem se, samo frejmvorci kao Spring i Struts (e da, tu je i Sunov JSF - JavaServer Faces) su otprilike u kategoriji sa ASP.NET-om, a npr. RoR to zasigurno nije i ne možemo ga uzimati kao predstavnika svih web platformi.

Ali ako znam da će web aplikacija biti korišćena za npr. unutrašnje potrebe neke manje firme, tj. mogu da znam da neće doći do vrtoglavog povećanja broja korisnika, funkcionalni zahtevi se neće mnogo promeniti i u budućnosti, itd, nema nikakvog razloga da ne koristim RoR, itd.