ugrás a tartalomhoz

PHP vs. JAVA

gabesz666 · 2009. Aug. 5. (Sze), 10.24
Sziasztok!

Van pár nagyobb projektünk a munkahelyemen, amik backend-jét JAVA-ban programozzák. Mindenki panaszkodik, hogy lassú, bonyolult és erőforrás igényes és más nyelven meglehetne írni ugyanazt sokkal gyorsabbra. Állítólag nagyobb projekteknél ez nem kivitelezhető. Szerintetek mi az oka annak, hogy a vezető beosztású emberek (akik a programunkat megveszik vagy nem... :)) nem hajlandók belátni, hogy mással is lehet ugyanolyan jó? (pl. PHP) Főnököm azt mondja, hogy egyszerűen nem hajlandóak szóba állni az emberrel, ha egy komolyabb rendszert PHP-ben szeretnénk kivitelezni. Szerintetek mi ennek az oka? (ja, egyébként szigorúan webes fejlesztésekkel foglalkozunk)
 
1

Flame Warning

szaky · 2009. Aug. 5. (Sze), 11.10
Remélem, komoly érvek jönnek ide akármelyik oldalról, és nem flém :)
2

Én most mind a kettőt csinálom

Ustak · 2009. Aug. 5. (Sze), 11.32
és nem tudnék érdemi választ adni (php felé húz a szívem...még.)
Pár post:
cmswire.com
web2development c php java etc..
javavsphp

Béke:
Gábor.
3

"túl egyszerű a PHP"

zyron · 2009. Aug. 5. (Sze), 12.41
Nagyon sokan hibáztatják a PHP nyelvet azért, mert kevés tudással is el lehet benne készíteni sokmindent, és ennek gyakran gányolás az eredménye.
A Java eléggé bonyolult ahhoz, hogy mély ismeretek kelljenek ahhoz, hogy bármi értelmeset össze tudjál benne hozni.

Az egyetemen, a szakirányomat koordináló tanszék (elég Java+Eclipse+IBM mániás tanszék) egyik tanszéki munkatársa jelentette ki, hogy irtózik a PHP programozóktól, mert összecsapják a munkát, és példának azt hozta fel, hogy egy t-elekommunikációs cégnél volt egy PHP webalkalmazás és egy adatbázistáblában volt minden. Ez nem a PHP nyelv ellen, hanem a használói ellen szól. Autodidakta módon tanulják a programozást, nem értenek az adatbázis-tervezéshez, a tervezési mintákhoz, stb.

De van egy ellenpéldám is. Dolgoztam (bár nem sokat) az E-felvételi rendszer fejlesztésében, és az egy Symfony projekt.

Összességében azt tudom mondani, hogy míg a Java projektek velejárója a sok tervezés + UML diagram + létező és működő megoldások felhasználása (+ jobb esetben termérdek kódgenerálás), addig a PHP projektek jó része - ma Magyarországon - jó eséllyel eszetlen kódolás a felsővezetés szerint.

Hogy hogyan lehet őket meggyőzni ennek ellenkezőjéről? Referenciákkal, tervekkel, hatástanulmányokkal, illetve a TCO várható csökkenésének hangoztatásával a teljesítmény növekedése mellett.

Szerintem.
4

amúgy mindkettőt használtam és a személyes véleményem:

zyron · 2009. Aug. 5. (Sze), 12.51
PHP - nagyon sok mindent meg lehet vele valósítani (mindent, amit a Java-ban), csak valószínűleg relatíve több hákolással jár a meglévő library-k / plug-inek felhasználása. Nekem a PHP a nagy kedvencem, nagy projektekhez pedig symfony keretrendszer a nyerő.

Java - mindent meg lehet vele valósítani, és nagyon sok mindent már jó előre megírtak, és jó eséllyel jól írták meg. A működéshez szükséges sok egymásra épülő réteg miatt (ami az egységbezáráshoz, újrafelhasználhatósághoz szükséges) viszont jó eséllyel PHP-nél lassabb alkalmazások születnek.

És hogy legyen még egy alternatíva:
.NET - C# + ASP.NET kapós a felsővezetők körében, akik jó kapcsolatot ápolnak a Microsofttal. Egy nem túl komplex webalkalmazást, ami használ adatbázist, meg akár web service-eket is, egy nap alatt össze lehet kattintgatni Visual Studio 2008-ban. Itt is már nagyon kell tudni, ha nagyon összetett alkalmazást akarsz létrehozni, és kis hajtépés mire rájössz az apró fortélyokra, amik megkönnyítik az életedet. Viszont jól lehet benne teljesítményt optimalizálni. :)
33

szálkezelés

blacksonic · 2012. Szep. 29. (Szo), 16.03
szálkezelést pl. pont nem lehet PHP-ban
42

Valószínűleg nem használnám

bh · 2012. Szep. 30. (V), 19.04
Valószínűleg nem használnám élesben, de lassan lesz rá tesztelt megoldás: pthreads
5

+1

Szekeres Gergő · 2009. Aug. 5. (Sze), 14.49
phpban nagyon szabad kezet kapsz, főleg ha keretrendszer nélkül fejlesztesz. Ez az elején előny, de sajnos azzal jár, hogy a fejlesztők nincsenek rákényszerítve semmilyen konvenciókra.

PHP-ban nem kapsz kézhez annyi mindent, mint javaban vagy .netben. Nyilván vannak keretrendszerek, de sajnos ezzel inkább megosztották a nyelvet, manapság már nem php fejlesztőket keresnek, hanem egy adott keretrendszerben jártas fejlesztőt. Érdemes megnézni mit nyújt például a microsoft egy fejlesztő számára, és milyen környezetek vannak php-hoz.

A másik probléma, hogy PHP-t manapság sokan tanulónyelvnek használják, ha már elérnek egy szintre inkább ráálnak javara vagy .net-re (nyilván ennek anyagi okai is vannak). Így a fejlesztők nagy része nem bír kellő tapasztalattal.

A teljesítménnyel nem feltétlenül értek egyet: php oopban kódolva nem feltétlenül nyújt nagyobb teljesítményt (sőt..), mint egy asp alkalmazás (a javát nem ismerem).

Viszont ami a vezetőket igazán érdekli, az az hogy hány óra alatt tudsz lefejleszteni egy adott alkalmazást. És ez az a pont, ahol a php az alkalmazás nagyságától függően, egyre inkább lemarad.

De a lényeg, hogy nem feltétlenül rosszabb egy PHP-ban írt alkalmazás, csak sajnos az a tapasztalat, hogy általában az.
6

hatékonyság/gyorsaság

krisy · 2009. Aug. 6. (Cs), 00.49
Mi is fejlesztünk PHP-ban, és JAVA-ban, én nagyjából az alábbiakat tudnám felhozni a JAVA mellett:
- gyorsabb fejlesztés: ahogy már korábban is írták, rengeteg előre megírt (ingyenes vagy nem) könyvtár található JAVA-hoz, jóval több, mint PHP-hoz
- debug: habár lehet PHP-ban is debug-golni valamennyire, JAVA-s fejlesztőkörnyezetekben az igazán jó (előre beállított, nem bug-os stb.), gondolok itt az Eclipse-re, és a Netbeans-re is
- "biztonságosabb" kód: habár mind a két nyelvben lehet "gányolni", azért a JAVA egy elég erős kódbiztonságot követel meg, míg a PHP-s fejlesztőkörnyezetek nem. Mindezek mellett például a JAVA-s IDE-k már előre dobálják a warning-okat, és error-okat miközben írod a kódot, míg PHP-ban sokszor rejtve maradhatnak a hibák, amik felderítésével nagyon sok idő elmegy.

Röviden: (majdnem) mindent, amit meg lehet oldani JAVA-ban, meg lehet oldani PHP-ban is, a kérdés, hogy mennyire hatékonyan/gyorsan.

(egy zárójeles megjegyzés: ha PHP kódot írsz valószínű, hogy a kapott eredményt böngészőben szeretnéd megjeleníteni. pár hónapja mi belefutottunk abba, hogy PHP/IE7-tel kellett olyan táblázatokat generálni/megjeleníteni, amik egyszerre több száz/ezer sort tartalmaztak - lapozó nélkül. Ez egy JAVA-s alkalmazás (vagy bármi, ami a felhasználó gépén fut) megoldja, de ha ezt mondjuk úgy szeretnéd, hogy PHP-val generálsz kódot, amit aztán a böngésző megjelenít, az nagyon nehéz :-( )
7

Kontra

deejayy · 2009. Aug. 6. (Cs), 07.11
PHP-hoz is vannak IDE-k, azok is dobnak warningokat meg errorokat. Ha jól tudom (bár nem használtam) képesek debuggolni is.
9

Teljesen igaz, például

krisy · 2009. Aug. 6. (Cs), 09.10
Teljesen igaz, például Eclipse-hez is van PDT meg PHPEclipse, és azok is segítik a kódolást.
A hangsúly inkább azon van, hogy milyen mértékben, és hogyan!

Például PHP alatt összehozni valamiféle debug-ot (gondolok itt mondjuk az XDebug-ra) jóval bonyolultabb (több idő) mint mondjuk a JAVA-s IDE-k előre beépített debug részeit használni (és nem is olyan kényelmes).

Szerintem megvannak azok az alkalmazások, amiket egyértelműen érdemesebb PHP-ban fejleszteni (mondjuk egy webshop), és vannak, amiket egyértelműen érdemesebb JAVA-ban (mondjuk egy tömörítő).

Persze a legtöbbet mind a kettőben meg lehet csinálni, csak a kérdés, hogy a kész kód mennyire lesz karbantartható, az elkészült alkalmazás mennyire lesz jó/gyors, illetve mennyi idő/erőforrás mindezt összehozni!
14

PHP IDE

Hodicska Gergely · 2009. Aug. 7. (P), 21.00
Zend Studio szerintem már elég jó. Felinstallálod, és már debuggolhatsz is minden nélkül, csak egy click a zend toolbaron. A kódban fellelhető hibák egy jó részét is nagyon jól mutatja. Szóval annyira nem vészes a helyzet. Az tény, hogy java esetén jobb a helyzet, de részben abból is fakad, hogy típusos nyelv.

Szerintem megvannak azok az alkalmazások, amiket egyértelműen érdemesebb PHP-ban fejleszteni (mondjuk egy webshop), és vannak, amiket egyértelműen érdemesebb JAVA-ban (mondjuk egy tömörítő).
Szerintem itt most egyértelműen webes fejlesztés témakörről van szó.

Persze a legtöbbet mind a kettőben meg lehet csinálni, csak a kérdés, hogy a kész kód mennyire lesz karbantartható, az elkészült alkalmazás mennyire lesz jó/gyors, illetve mennyi idő/erőforrás mindezt összehozni!
Előbbi kettőben szerintem nincs nagy különbség (bár javaval nincs tapasztalatom), lehet PHP-ban is jól karban tartható, gyors oldalt készíteni. A harmadik pont érdekes, nincs benne tapasztalatom, de általában pont az ellenkezőjét szoktát mondani, főleg egyszerűbb alkalmazások esetén.
19

???

inf3rno · 2009. Aug. 25. (K), 13.11
Például PHP alatt összehozni valamiféle debug-ot (gondolok itt mondjuk az XDebug-ra) jóval bonyolultabb (több idő) mint mondjuk a JAVA-s IDE-k előre beépített debug részeit használni (és nem is olyan kényelmes).
Ezt hogy érted? XDebug felrakása egy dll fájl bemásolásából és a php inibe kb 3 sor írásából áll. Ebben szerintem nincs semmi bonyolult.

Persze abban egyetértek, hogy php-ben gáz a debuggolás. Egyelőre még nem találkoztam olyan programmal, ami végigkövette volna, hogy milyen változó milyen értéket kap melyik függvényben stb. Szóval nagyon sok esetben maradt az echo az egyedüli eszköz.
Nem tudom Java-ban ilyesmire milyen lehetőségek vannak?


Php-ben rengeteg kidolgozott keretrendszer van, szóval én nem hiszem, hogy nehezebb lenne fejleszteni benne, mint más nyelven. Nyilván ismerni kell valamelyiket a sok közül. :-) Egyébként kb. ugyanez a helyzet javascripttel.
8

igenis meg nem is

szaky · 2009. Aug. 6. (Cs), 09.07
Tényleg kevésbé lehet debugolni, de egy eclipse már elég komoly kódellenőrzést végez. Egyszerűbb dolgokat lehet debugolni pl xdebuggal, összetettebeket pl firephp-val (jó, oké, ez nem igazi debug). Viszont az utolsó bekezdéseddel megvétóznám: itt nem a webes-nemwebes technológiákat állítjuk szembe, hanem a webes technológiákat. Egy javás rendszerben is pont ugyanolyan nehézkes egy többezer sort tartalmazó html-t legenerálni/megjeleníteni.

Az összehasonlítás nem mindig egyszerű. Pl olyan kérdések is vannak, hogy 3 év programozói tudássa melyikben lehet jobb szoftvert építeni . És 5 évvel? Milyen tudás kell ahoz, hogy egy nagyon gyorsan változó oldalt kezeljünk sok rövid határidővel? Vagy egy egyszer-megírom-soha-többet-nem-nyúlok-hozzá tipusúhoz? És még egy tucat kérdést fel lehet tenni, mielőtt el lehetne dönteni, hogy egy adott feladathoz hogy állunk hozzá.
10

Ha tényleg szigorúan csak

krisy · 2009. Aug. 6. (Cs), 09.15
Ha tényleg szigorúan csak webes technológiákat nézünk, akkor teljesen igazad van szerintem is :-)

Ezekben belül is szerintem szépen lehet "szegmentálni": mondjuk egy "sima" fórumot én biztosan PHP-ban kezdenék el, de mondjuk egy online értékbecslőt tuti valamiféle JAVA-s motorra tennék!

(csak halk kérdés: mostanában JSP/JSF-fel mi a helyzet? nem nagyon hallani róla ... :-( )
11

Egyetemen nyomatják,

zyron · 2009. Aug. 7. (P), 13.03
máshol nem nagyon találkoztam JSF-fel élesben.

Szerintem már egy fórumot is gyorsabb összekattintgatni Visual Studioban, ha sajátot akarsz írni. Meg webshopot is.

Én a PHP-t ma már főleg annak ajánlanám, aki nem bérel vagy üzemeltet saját szervert, hanem valahol tárhely szolgáltatónál helyezi el a céges oldalát, mert egy PHP+MySQL tárhely jóval olcsóbb, mint egy ASP.NET-et vagy JSP-t kezelni tudó tárhely. (Pedig egyébként nem lenne sokba egy IIS vagy egy Apache Tomcat.)

Ha cég vagyok és belső webalkalmazást kell fejleszteni, akkor egy C# + ASP.NET van meg legolcsóbban/leggyorsabban, pont a fejlesztői órák miatt. Egy PHP programozó, aki normális munkát végez elkér annyit, mint egy .NET fejlesztő. Sőt, ha van egy Sharepoint szerverem, akkor még olcsóbb, mert diákmunkában 1000 Ft-os órabérért alkalmazhatok fejlesztőket.

Összességében egyet kell értenem az előttem szólókkal abban, hogy a technológia kiválasztása nagyban függ attól, hogy hol futtatod az alkalmazást, ki használja, illetve mekkora alkalmazásról van szó. De a méretre is jó ellenpélda az E-felvételi, ami PHP-ban íródott.
12

Licensz

Poetro · 2009. Aug. 7. (P), 15.42
Azért ASP.NET alatt nem olyan olcsó azért fejleszteni, főleg ha sok felhasználó van. Csak a Windows Server 2003 SE ~1000USD, ehhez jönnek hozzás a Visual Studio-k, ha a fejlesztés abban folyik, és nem csak command line compilert használ az ember. Azért egy Debian és egy Open Source fejlesztő környezet ennél jóval olcsóbb szoftverek tekintetében.
13

1000 USD

janoszen · 2009. Aug. 7. (P), 18.58
Kérdés, hogy 1000 USDből mennyi fejlesztési időt spórolsz meg összekattogtatott webshoppal.
15

összekattintgatás

Hodicska Gergely · 2009. Aug. 7. (P), 21.08
Részben itt is bajban vagyok, mert nem fejlesztettem még sose ASP.NET-ben, de azért némileg kétkedéssel olvasom, hogy ott csak úgy összekattintgatom a dolgokat. Biztos van jó sok kész elem, de azért azt gyanítom, hogy elég hamar eljön az a bonyolultság, ahol már ez kevés, és ott valszeg ugyanúgy elmegy a fejlesztéssel az idő. Plusz gondolom ő sem fog magától skálázható megoldásokat adni, neked kell ezért dolgoznod, DB sem lesz magától skálázható, szintén neked kell megfelelő sturuktúrát kiépítened. (Gondolom mondjuk fejlettebb ORM cuccok lehetnek .NET-hez, kérdés meddig elegek ezek a megoldások.)
16

Kattintgatás

Joó Ádám · 2009. Aug. 8. (Szo), 03.31
Plusz gondolom ő sem fog magától skálázható megoldásokat adni


A Neptun.NET-ről esetleg hallott már valaki?
18

Ez csak egy

deejayy · 2009. Aug. 25. (K), 11.56
Ez csak egy tapasztalat:

Egyik volt munkahelyemen egy belső irodai alkalmazás fejlesztésébe kezdtek a kollégák, adminisztratív feladatok gyorsítására. Volt egy képük, hogy kb. mit kell tudnia, mire kell és lehet használni, stb. Ezt a fejlesztők a saját toolkitjükbe (talán ASP.NET?) beleálmodták, és összekattintgatták, kész is lett. Aztán amikor a csoport elé tárták, akkor egy-két észrevétel volt, hogy hát "itt ez gyorsabb lenne", "ez úgy célszerűbb, hogy". Kis idő elteltével eljutottunk oda, hogy a toolkitjükből mindent ki kellett szedni, és alapról fejleszteni mindent, mert az adott komponens nem tudta azt, ami a feladat ellátásához kellett.

Persze, össze lehet kattintgatni.

Az egyetemen is magyaráztak valamit, hogy "UML diagram, CASE eszközök, legenerálja a forráskódot". Nyilván, egészen az első felhasználói igényig... márpedig az a legfontosabb, nem?
17

Rant két kalóriával

vbence · 2009. Aug. 8. (Szo), 11.25
Enterrise környezetben a JAVA a standard. Érthető ha a webalkalmazásuk alapjául ugyanzt az eszközt vélasztanák (valószínűleg már ismernek cégeket/szakembereket akik ezzel dolgoznak).

Magáról a nyelvről annyi a magánvéleményem, hogy kevés ilyen tökéletes dolog létezik :) A JAVA-t az OOP nyelvnek fejlesztették mindig is.
Ellentétben a C++szal ahol egy meglévő nelyvre ültették rá. Ugyanez a helyzet a PHPval is. Egy nagyon buta szkriptnyelvet ptóbálnak okosítani, ami már elég jól megy, viszont például a "pacjage" vagy "namespace" csak most került bele. Én még mindig komoly problémákba űtközöm OOP tájékán (pl. static initialization). A nylev és eszközei még mindig a globálok használatára bátorítanak. Az ügyetlen this kulcsszót kell használni. Stb stb stb

Ami a PHP-t hogyismondjam... komolytalanná teszi az az inkompatibilitás. Semmi nem garantálja hogy egy függvény ugyanúgy fog működni a következő release-ben, vagy hogy nem tesznek bele valami a globális scope-ba (pl egy DateTime nevű osztály) ami aztán működésképtelenné teszi a webalkalmazásod (pedig csak egy alverziót frissítettél).
20

felelevenítés

blabla · 2012. Szep. 27. (Cs), 23.49
Hello

Egy alkalmazást szeretnék fejleszteni. Közösségi oldal, méghozzá olyan ahol a userek egymással játszanak, tehát elég sok kattintgatás lenne az oldalon. A kérdés az, ami a topic címében van: miben álljak neki?

Pár adalék:
-Van már egy működő rendszer joomla! környezetben, (ami jelenleg is működik) igaz egy ócska, régi, elavult, még az 1.0-ás verzió alá lett fejlesztve a komponens. Azóta elkezdtem ugyan joomla 1.5 alá tenni de időm kevés, mert a dolog színtiszta hobbi.
-Nem vagyok profi php-s, csak autodidaktás :D, de a nyelvet ismerem, a fent említett működő rendszert is én írtam (gányoltam ;) )és azóta is elég intenzíven használom a PHP-t a munkám miatt.
-JAVA-t egyáltalán nem ismerem, semmilyen szinten, azonban C-ben otthon vagyok.
-Szívesen megtanulnám a JAVA-t (de nem mindenáron), mert ki tudja mikor vágnak ki a melóhelyemről.
-Saját szerverre van lehetőségem.
-A cél hogy minél gyorsabb legyen az alkalmazás.

Szóval mit javasolnátok, most, 2012-ben?
Előre is köszönöm a választ
21

Kb ugyanaz

janoszen · 2012. Szep. 28. (P), 00.19
A PHP es a Java viszonya nem valtozott. Az elobbi meg mindig annyival van beljebb, hogy szinte barhol elfut, a Javanak viszont maceras az uzemeltetese (relative). Nekem most van Javas projektem es sokkal kevesbe tudok a lelkivilagara hatni terheles, stb. szempontbol, mint mondjuk a PHP-nak.
22

Kérdés, hogy milyen

BlaZe · 2012. Szep. 28. (P), 02.34
Kérdés, hogy milyen lehetőségeid (idő, energia) vannak a fejlesztésre, és mit szeretnél elérni. Ha a karriercélú fejlődés erősen benne van a tervben a project kapcsán, akkor a Java lehet a jobb választás, viszont ha Javaban állsz neki, akkor egyhamar nem lesz kész, hiszen sokmindenben nagyon más, mint a php. Önmagában csak a felhasználandó technológiák kiválasztása és megtanulása is embertelen sok időt elvisz, ha valaki nincs otthon benne. Persze neki lehet esni Java fejlesztésnek úgy is, hogy Servlet, JDBC, JSP (JSF már komolyabb dió), vagy valami egyszerű template engine, aztán csókolom, de akkor semmi értelme Javaban csinálni. A Java erőssége nem a kilóra kódolásban jön ki.

A melyik a jobb kérdésre meg nem igazán lehet válaszolni, a produktum minősége jobban függ a programozótól, illetve a megvalósítástól, mint a nyelvtől. Mindkettőben lehet nagyon lassú, és nagyon gyors, nagyon gány, vagy nagyon jó programot is írni. Nem gondolom, hogy kategorikusan ki lehet jelenteni, hogy egyik, vagy másik gyorsabb, jobb. Másra való a 2 nyelv (bár a java ma már lényegesen több egy programozási nyelvnél). Sebességet tekintve ha csak a nyelvet önmagát vesszük, a Java gyorsabb, de megvalósítástól függően már nem feltétlenül igaz ez.

Hogy valami konkrétumot is mondjak :), a fentieket olvasva, és a feladatot (se funkcionálisan, se méreteiben) nem ismerve szerintem a php jobb választás, hiszen abban otthon vagy.
32

Sebességet tekintve ha csak a

MadBence · 2012. Szep. 28. (P), 16.56
Sebességet tekintve ha csak a nyelvet önmagát vesszük, a Java gyorsabb, de megvalósítástól függően már nem feltétlenül igaz ez.

Ha PHP-ban nekiáll az ember valami bonyolultabb alkalmazáslogikát írni az ember, akkor szerintem a köré pakolt dolgok (apache/egyéb, java-ban nem vagyok otthon webszerverek terén) elhanyagolhatóak (ki lehet javítani, ha nincs igazam :)). A PHP kb 20x lassabb a Javanál, ez elég indok, hogy ha lehet, akkor ne PHP-t használjunk.
23

:-) Én most hasonló

inf3rno · 2012. Szep. 28. (P), 03.41
:-)
Én most hasonló dilemmában vagyok, csak nodejs és java kérdésében. (Amúgy ajánlom nodejs-t php helyett.) Én asztali alkalmazást írnék...

Nodejs-ben van egy appjs nevű cucc, amivel bemásolható programokat lehet írni, kb olyan, mintha egy chrome ablakban futna a cucc. A hátránya, hogy látják a kódomat, és bármikor belenyúlhatnak. Ugyanúgy stateless a gui, mint egy normál weblapnál, nem lehet azt megcsinálni, hogy mondjuk felépítesz egy dom fát egyetlen html-ben, és azt módosítgatod lekéréstől függően. Szóval még egy kicsit kiforratlan, mondjuk a html-t sem erre találták ki. Előnye, hogy ismerem a html-t a javascript-et, szép lasan a nodejs-t is, és az egész kliens - szerver megoldást. További előnye, hogy bármikor át lehet alakítani több felhasználósra, ha az ember leválasztja a szerver részt (az én esetemben ez nem szempont). Ott van még a mongoDB, ami szintén érdekel, hogy hogy néz ki egy relációs adatbázissal összehasonlítva.

Java-ban van a JavaFX 2, ami egy elég szép nagy rendszer, ahogy néztem van róla 600 oldalas könyv, hogy hogyan kéne használni. NetBeans-ben össze lehet kattintgatni a teljes GUI-t (mondjuk a html-t meg dreamveawer-ben). Css-t használ stíluslapnak. Lehet MSI telepítőt készíteni vele, ami tartalmazza magát a java-t is, szóval ugyanúgy garantálható a futási környezet, viszont a kódba nem lát bele senki. Ott van még a hibernate a relációs adatbázisokhoz, ami nagyon jó dolog, és relációs adatbázishoz jobban értek, mint noSQL-hez. Ugyanúgy meg lehet írni akár kliens-szerver alapon az alkalmazást, ha úgy akarom, de a GUI-nál nem kötnek a html hátrányai.

Sebességben mindkettő ugyanolyan jó szerintem. Valszeg az lesz, hogy kipróbálom mindkettőt egy-két űrlap erejéig, aztán meglátjuk, hogy melyik a kényelmesebb...
24

Gyorsaság

blabla · 2012. Szep. 28. (P), 07.51
Kösz a válaszokat. Ôszintén szólva én is php-ban gondolkodm, de ott van azért a, hogy jó lenne még egy "lábon" állni...Amúgy idôm...hát ...néha sok néha semmi.Ha php-ról van szó akkor nem kell a nulláról kezdeni.

Most egy nagyon málé és béna kérdést teszek fel. Ha jól gondolom a JAVA programokat le kell fordítani futtatás elôtt. Hogy lehet az, hogy egy php script nagyjából ugyanolyan gyorsan fut le (ahogy itt és máshol többen írták, hogy egyik sem sokkal gyorsabb), mint egy lefordított JAVA kód? Én csak C és php/perl összehasonlítást tudok, de szó szerint ég és föld a különbség a futás ideje között (természetesen a C javára) ugyanazt a feladatot (konkrétan adatolvasás és sok sok io mûvelet, stb) megvalósító program esetén. Akkor most hogy is van ez?
25

Szerintem a php c-ben írt

inf3rno · 2012. Szep. 28. (P), 08.19
Szerintem a php c-ben írt kódot használ az io műveletekhez, ami szintén be van fordítva. A java a jvm nyelvére fordul, nem gépi kódra, szóval valamivel lassabb, mint a befordított c-ben írt dolgok, cserébe viszont nem kell minden platform-ra új programot írni. Egyébként a java a php-hez képest tisztább, szárazabb érzés. Az egész ott kezdődik, hogy nem dokumentációba kell írogatni ahhoz, hogy működjön a kód kiegészítés, mert típusos nyelv. Közben JavaFX-ről megnéztem 3 tutorial video-t, és azt kell, hogy mondjam, hogy kedvet kaptam hozzá.
26

ok, igy már ok

blabla · 2012. Szep. 28. (P), 08.37
Azt hittem gépi kódra fordít, de akkor így már világos.
27

Egyébként lehet fordítani a

Karvaly84 · 2012. Szep. 28. (P), 08.48
Egyébként lehet fordítani a gcj-vel gépi kódra. De nem igazán szokták használni. Vagyis én nem sok helyen láttam.
29

JIT

eddig bírtam szó nélkül · 2012. Szep. 28. (P), 10.16
Van még egy olyan is, hogy JIT (Just In Time compiler)
Még nem volt 2-es java, mikor próbálgattam, akkor nem jelentett érzékelhető gyorsulást (csak mérhetőt)
De azóta eltelt pár év... :-)
28

Fordít gépi kódra, de a JVM,

BlaZe · 2012. Szep. 28. (P), 10.03
Fordít gépi kódra, de a JVM, nem a compiler. Úgy értem a JVM performance tuningol futás közben, ennek egyik eszköze a gépi kódra fordítás, és a gyakran használt részek fejben tartása (ezért eszik pl a server vm sokkal több ramot, mint a client vm). Ezért is van az, hogy vannak olyan jól behatárolható feladatok, amikben még a c-t is megveri sebességben.

Ami miatt sokszor azt érezni, hogy egy java alapokon írt weboldal "lassabb", hogy egyszerűen többmindent csinál, mint egy php oldal. Ha már javat használunk, akkor kihasználjuk a frameworköket, bár még ettől se feltétlenül kell lassabbnak legyen. Viszont a javas webes megoldások jellemzően egy komolyabb architektúra frontendjei, gyakran SOA környezetben, és ez a háttér adja a válaszidő növekedését.

Régebben méregettem egyes java containerekben hello world, meg fibonacci sorok generálási sebességét weben keresztül, változó mennyiségű konkurrens felhasználóval. A poén kedvéért mellétettem a php+apache2(+xcache) párost is, és jobb mutatókat produkált a legtöbb java container. Sebesség szempontjából kimondottan combos megoldás a Resin, ráadásul tudja ezt úgy, hogy közben J2EE web profile implementáció.

És ha már előkerült a php vs java sebesség összehasonlítgatás, meg a resin, akkor érdekességként megemlítem, hogy a Resinnek van saját, külön warként deployálható (vagyis javaban írt) php implementációja is, ami állítólag agyonveri teljesítményben a zend féle php-t. De szerintem ez inkább érdekességként jó, legalábbis meglévő alkalmazást én nem mernék portolni alá. A php amúgy is hemzseg a kompatibilitási és egyéb átgondolatlan butaságoktól, és akkor ezt még megpróbálják lekövetni egy implementációval... Bár kimondottan erre a platformra fejlesztve érdekes megoldás lehet, ráadásul a php szokásos biztonsági sebezhetőségei se igazán érintik.

Úgyhogy röviden, ha az az érzés, hogy lassabb a java, akkor az azért van, mert többmindent csinál a háttérben.
30

Kérdeznék valami ami már nem

Karvaly84 · 2012. Szep. 28. (P), 10.24
Kérdeznék valami ami már nem ide tartozik:

Az Oracle oldalán szoktam látni hogy a Java EE SDK csomagban a web profilos verziót amiben a GlassFish-nek van egy web profilos változata. Ez miben tér el a sima változattól?
31

Itt a különbség:

BlaZe · 2012. Szep. 28. (P), 12.20
Itt a különbség: http://glassfish.java.net/webprofileORfullplatform31x.html

Néhány api, feature nincs benne a web profileban, ami sima webes alkalmazás esetén nem is feltétlenül szükséges (full EJB, JMS stb).
34

úgy néz ki php lesz

blabla · 2012. Szep. 29. (Szo), 19.53
Úgy néz ki maradok a php mellett. Olvasgattam összehasonlításokat, véleményeket ( az ittenieket is, amiket köszönök szépen) és úgy döntöttem keresek egy fw-t és abban fogok dolgozni. Bár itt is vannak véleménykülönbségek, hogy inkább saját legyen vagy valami open source-os és azok közül is melyik.

De felmerült bennem még egy kérdés (egy kicsit elkanyarodván a topic címétől), meg szeretnélek kérdezni titeket, hogy mit gondoltok arról ha bizonyos funkciókat nem a php hanem C programok végeznének? Elvileg ennek gyorsítania kellene rendszert. Szerencsére a saját szerver megoldott és így megfelelő biztonsági beállítások mellett szerintem a külső program meghívás php függvények alkalmazhatóak.

Van valakinek tapasztalata ilyen téren? Megéri, nem éri meg, milyen részeket lehetne C-ben írni és kiváltani a PHP-t? Adatbázis kezelés, számolási metódusok? Vagy egészen odáig is elmehetek, hogy a php csak egy közvetítő réteg lenne a C program és a web között? És ha ezt választom akkor van-e szükségem FW-re egyáltalán?
35

Amire van php függvény, az

BlaZe · 2012. Szep. 29. (Szo), 20.14
Amire van php függvény, az gyakorlatilag c-ben fut. Így pl az adatbáziskezelést (legalábbis a lekérdezések futtatását stb) nem érdemes kitenni c-be.

Olyan bonyolult alkalmazáslogikád van, olyan látogatottság mellett, amit a php nem biztosan bírna el és muszáj c-ben írni? Erről nincsenek ismereteim, mert ilyet nem igazán csináltam, de abban nem vagyok teljesen biztos, hogy a külső program futtatása php-ból egy hatékony dolog. Általában a programindítások nem a leggyorsabb műveletek. Akkor már inkább valami socketes kommunikáció egy szerverrel. De ez nagyon messze vezet. Erre valóban szükséged van? Illetve ha már c-ben írod az alkalmazáslogikát, akkor mi szükség van a php-ra?
36

Igazad van

blabla · 2012. Szep. 29. (Szo), 21.07
Igazad van, a konkrét alkalmazás esetében a számítások (előreláthatólag) nem olyan jelentősek,hogy a futásban nagy különbségek legyenek. Mondjuk sok io művelet esetén (pl adatfile-okból grafikonok gyártása) a futási sebességek különbsége elég jelentős lehet (ez viszont tapasztalat), nem beszélve arról hogy a php scriptek futási ideje korlátozva szokott lenni (akár a tűzfal ki is lőheti) és a user nem utál jobban semmi mást, mint a homokórát a web böngészőjében:)
38

Nem tudom milyen

BlaZe · 2012. Szep. 29. (Szo), 23.54
Nem tudom milyen grafikonokról van szó, meg mekkora forrás adatmennyiségről, de ha felhasználónként más grafikonok vannak (requestenként kell generálni), akkor fontold meg pl valamilyen js chart használatát, vannak belőle jók. Így nem terheled a szerver oldalt a grafikával, csak az adatokat kell átadni. Ha pedig mindenki ugyanazt kell lássa, akkor célszerű lehet egy háttérfolyamattal generálni a grafikonokat adatváltozás esetén.

De itt már asszem elkanyarodtunk kicsit a topictól :)
37

"Van valakinek tapasztalata

inf3rno · 2012. Szep. 29. (Szo), 22.59
"Van valakinek tapasztalata ilyen téren? Megéri, nem éri meg, milyen részeket lehetne C-ben írni és kiváltani a PHP-t? Adatbázis kezelés, számolási metódusok? Vagy egészen odáig is elmehetek, hogy a php csak egy közvetítő réteg lenne a C program és a web között? És ha ezt választom akkor van-e szükségem FW-re egyáltalán?"

Ha ilyenekben gondolkodsz, akkor már inkább írd meg c#-ban az egészet. Csak nyersz vele...
39

FW, külső progrmok

Pepita · 2012. Szep. 29. (Szo), 23.58
- Valamelyik, nagyon egyszerű framework hasznos lehet, még akkor is, ha külső (pl. c) programok mellett döntesz. A vezérlési szerkezeteket, routing-ot, stb. könnyebben megvalósíthatod, mint fw nélkül. Feltéve, ha gyorsan belejössz az adott fw használatába. Többen negatív véleménnyel vannak róla, én mégis javasolnám a CodeIgniter-t. Kicsi, érthető, gyors.

- Oldalkéréskor kezdeni RAM-ba tölteni külső progit, majd paramétereket átadni neki - szerintem csak lassabb lehet, mint PHP-ban megírni. Lehetnek kivételek ez alól, ha vmi nagy terhelésű mutatvány van. Tehát csak akkor van értelme, ha állandóan futó process-ként meg tudod oldani és csak kommunikál vele a PHP. Viszont nem tudom, hogy ez mennyire megvalósítható a szervereden, és nem biztos, hogy megéri a többletmunkát (végülis: nagyrészt a PHP is c-ben íródott - asszem írta már más is).

- Ha csak közvetíteni használnál PHP-t, akkor is érdemes egy egyszerűbb fw-t használnod. Nincs ilyen tapasztalatom, de úgy gondolom: "nem éri meg", esetleg ha az egészet c-ben írod.
40

ok, meggyőztetek

blabla · 2012. Szep. 30. (V), 10.42
Köszönöm a válaszaitokat, maradok a php fw használatánál és hanyagolom a c-t.
41

Symfony-t ajánlom, annak a

inf3rno · 2012. Szep. 30. (V), 18.16
Symfony2-t ajánlom, annak a legprofibb a kódja.
44

ZF2

joed · 2012. Okt. 4. (Cs), 00.31
Szerintem meg a Zend Framework 2-nek ;-)
46

Néztem azt is múltkor,

inf3rno · 2012. Okt. 4. (Cs), 02.17
Néztem azt is múltkor, sf2-ben mondjuk 50 soros egy osztály zf2-ben meg 100 körül van, ergo Symfony 2 sokkal kidolgozottabb... Persze nem csak a méret számít. Inkább úgy fogalmaznék, hogy a SOLID elveknek Symfony 2 sokkal jobban megfelel, mint zf2, és én szeretek ezek szerint az elvek szerint programozni...
48

Az azért kicsit erős

BlaZe · 2012. Okt. 4. (Cs), 12.52
Az azért kicsit erős szerintem, hogy azért jobb egy fw egy másiknál, mert egyikben 50, másikban 100 sor egy osztály. Ennek így nem sok értelme van. Ugyan én egyiket sem ismerem, ezért nem is szállnék vitába magával a kijelentéssel, hogy a Symfony 2 kidolgozottabb, de az átgondoltsághoz az osztályméretnek csak érintőlegesen van köze, de ha hosszról beszélünk, már akkor is inkább a metódusnak a méretével van értelme foglalkozni, nem az osztályéval, hisz van olyan osztály, aminek egyszerűen több metódusa kell legyen, hogy értelmesen lehessen használni. Én se szeretem a spagetti kódot, de láttam már nagyon átgondolt frameworkot néhol többszáz soros osztályokkal. Az átgondoltságot én már inkább absztrakcióban és használhatóságban mérném. De ahogy mondtam is, ebben nem tudom hogy áll az említett 2 framework.
52

Minél nagyobb egy osztály,

inf3rno · 2012. Okt. 4. (Cs), 13.30
Minél nagyobb egy osztály, annál valószínűbb, hogy nem teljesíti az SRP-t (értsd több dolgot csinál egyszerre). Az átgondoltságáról nem tudok nyilatkozni, mert nem én fejlesztettem. Csak annyit tudok, hogy ahol ilyen kódot írnak, ott azért van szakmai tudás a háttérben.
55

A mögöttes gondolattal

BlaZe · 2012. Okt. 4. (Cs), 13.48
A mögöttes gondolattal egyetértek, de ez nem feltétlenül jelenik meg a sorok számában. Van olyan osztály, aminek jónéhány metódusa van, és kell legyen, mert az objektum több fontos szolgáltatást valósít meg. Az objektumon magán, nem pedig funkcionálisan. Vagy szimplán csak bonyolult a logikája, amit csak részben, vagy egyáltalán nem lehet kiszervezni belőle.

De értem amit mondasz, és alapvetően egyet is értek vele.
49

*trollmode*

MadBence · 2012. Okt. 4. (Cs), 12.58
Tudom ajánlani a vapor.js frameworköt: ha szereted a rövid kódot, garantáltan elnyeri a tetszésedet! :)
50

:D

tiku I tikaszvince · 2012. Okt. 4. (Cs), 13.07
Én kérek elnézést! :D
53

Amazing :D

inf3rno · 2012. Okt. 4. (Cs), 13.30
Amazing :D
56

Nagyon jó de a nálam jó ideje

Trudy · 2012. Okt. 4. (Cs), 19.45
Nagyon jó de a nálam jó ideje a HTML9-Boilerstrap viszi a pálmát.
57

WIN

deejayy · 2012. Okt. 5. (P), 10.49
WIN
59

ReTroll

Arnold Layne · 2012. Okt. 5. (P), 13.53
Nekem valahogy a vanillajs jobban bejött. De ez sem rossz, majd kipróbálom ezt is. ;)
43

zend

joed · 2012. Okt. 4. (Cs), 00.29
Érdekesnek találom, hogy nem merült fel a Zend. Nyugaton szokás de-facto enterprise PHP company-nek nevezni. A Zend Studio (Eclipse), Zend Server és a Zend Framework olyan csomagot nyújtanak a vállalati webalkalmazások teljes életciklusára, amit más nem tud. Ha az NYSE-nek megfelelt, szerintem nektek is érdekes lehet.

Az egyetemen (Corvinus) engem is körberöhögtek, mikor a szakdolgozatom gyakorlati részét PHP-ban akartam megcsinálni és ezt már akkor is az intézmény elköteleződé$ei meg a kollégák ismereteinek porosságának számlájára írtam.

Jó vezetői döntéseket csak naprakész és pontos információk alapján lehet hozni. Ez az informatikában hatványozottan igaz. Aki nem vette észre, hogy az utóbbi 2-3 évben a PHP megérett a vállalati alkalmazásra (nagyrészt a Zend-nek köszönhetően) az nagy valószínűleg elég sok dologról lemaradt.

Ahogy az előttem szólók is mondták: nem a nyelvet kell hibáztatni azért, mert könnyű használni és meredek a tanulási görbéje; ennél fogva sok a kontár PHP fejlesztő.

Ha valaki alapos programozási ismeretek és gyakorlat nélküli fejlesztőket enged rá egy PHP projektre, ne csodálkozzon, ha nem jönnek az eredmények!
45

A Zend Studio (Eclipse), Zend

MadBence · 2012. Okt. 4. (Cs), 01.16
A Zend Studio (Eclipse), Zend Server és a Zend Framework olyan csomagot nyújtanak a vállalati webalkalmazások teljes életciklusára, amit más nem tud.

Amennyiben a kijelentés a PHP platformra vonatkozik, akkor egyetértek. De ha nem, akkor azért megemlíteném a .NET-et, ami mellett nem kéne csak úgy elhaladni.
(De ez már offtopic, a téma címe Java vs PHP volt)
47

Igen

joed · 2012. Okt. 4. (Cs), 12.01
Igen, itt a PHP platformra gondoltam és más PHP-s megoldás szállítókkal összehasonlítva. Természetesen, egy .NET-tel össze sem hasonlítható a PHP enterprise szinten.
51

Sokat fejlesztettek a nyelven

BlaZe · 2012. Okt. 4. (Cs), 13.11
Sokat fejlesztettek a nyelven az elmúlt jópár évben, de több olyan dolog is van, amiért a PHP-t nem szeretik enterprise környezetben. Ebből sokminden le van írva fentebb. A PHP egy jó nyelv weboldalak készítésére, de szerintem az egy buta törekvés, hogy be akarják passzírozni enterprise környezetbe. Ott le van osztva a terep a Javanak és a .NET-nek, és ilyen környezetben lényegesen előnyösebb nyelvi eszközökkel, háttérrel indulnak, szabványok szerint fejleszthetőek, vagyis a PHP gyakorlatilag itt soha nem fog tudni komolyabban labdába rúgni. Ehelyett arra kéne inkább törekedni, hogy végre kijöjjön egy olyan PHP verzió, ami átgondolt és a későbbiekben tudják tartani a visszamenőleges kompatibilitást. Mert az egy horror, amilyen problémák elő tudnak jönni egy verzióváltással. Végre eljutottak oda, hogy elkezdtek kikukázni egy csomó hülyeséget (register_globals és társai), de a függvénykészlet is sok helyen átgondolatlan, a ZE2-ben is vannak még itt-ott bugok. Ide kéne fókuszálni szerintem, hogy a saját terepén megőrizze a vezető szerepét, és ne szaladjon el mellette pl a NodeJS és más olyan megoldások, amik a webes szakmában esetleg veszélyeztetik. Én pont ezért nem látom túl sok értelmét ennek a topicnak, mert nagyon vékony az a sáv, ahol felmerül a PHP, vagy Java (vagy .NET) döntés létjogosultsága.
54

+1, szerintem sem egy

inf3rno · 2012. Okt. 4. (Cs), 13.33
+1, szerintem sem egy kategóriában van a php és a java.
58

Téma

joed · 2012. Okt. 5. (P), 13.28
Enerprise WEBES projektekről beszélünk. Nem adatbányászatról, nem OLAP-ról nem TPS-ről. Páran elmondták miért nem szeretik a Java-t webes alkalmazásban, pont ezek miatt rúg labdába a PHP.
Ne akarj banki tranzakciós rendszert vagy hangolót fejleszteni PHP-ban. Használd amire való: webalkalmazásokhoz.
60

Attól, hogy egy project

BlaZe · 2012. Okt. 5. (P), 16.37
Attól, hogy egy project front-endje webes, attól még a PHP nem lesz versenyképesebb enterprise környezetben, és nyilván webes enterprise rendszerről beszéltem, nem egy banki tranzakciós rendszerről. A PHPnak ott van előnye a Javaval szemben, ahol felesleges beröffenteni egy Javat, mert verébre halálcsillaggal lenne :) Illetve nyilván a PHP sokkal alkalmasabb web hosting környezetben futtatásra, mint a Java. Kemény lenne ügyfelenként saját alkalmazásszervert futtatni pl :) Viszont ami igen fontos, hogy az, hogy a PHP nem jó választás enterprise környezetben, nem jelenti azt, hogy nem lehet jó rendszert összerakni PHPban. Enterprise környezet != nagy terheltségű, illetve jól összerakott rendszerek.

Egyébként Javaban semmivel nem rosszabb webes rendszert összerakni, mint PHPban (sőt), csak sokszor felesleges, illetve nem praktikus, lásd az előző mondataimat. Aki ilyet állít, valószínűleg nem mozog elég otthonosan Javaban. Javahoz nagyon komoly webes frameworkök vannak (hogy 2 érdekes megközelítést mondjak, érdemes megnézni pl a wicketet, vaadint) stb. Hogy Javara jellemzően nincsenek ilyen "mindentmegcsinálunkhelyetted" CMSek, az tény, de ez is csak a 2 környezet erősen eltérő felhasználási szokásai miatt van. Nagy általánosságban elmondható, hogy a PHP magas szinten webes megoldásokat ad a fejlesztők kezébe, a Java meg frameworköket.