Grote websites: Java vs PHP

[IntToStr]

Ik ben zelf Java ontwikkelaar met een verleden als PHP ontwikkelaar. Nu was ik laatst wat aan het praten met een collega over grote websites, zoals bijv. tweakers, marktplaats of hyves. Het viel ons op dat veel grote (Nederlandse) sites met PHP zijn gemaakt. Hoe komt het eigenlijk dat dit soort sites in zoveel gevallen met PHP en niet met bijv. Java zijn gemaakt?

Zou het puur het 'hobbyproject' zijn dat uit de hand is gelopen? Meestal maakt de hobbyist niet even een applicatie met Java EE technologie. Bomen en bos en zo met alle frameworks etc...

Stel je zou nu een project starten dat uitgroeit tot de grootte van bijv. tweakers.net. Zou het niet veel verstandiger zijn om het project met Java uit te gaan voeren? Je hebt de performance, de application servers, Java EE. Voordelen voor PHP zijn mogelijk dat je makkelijker hosting en ontwikkelaars kunt vinden, al zou dat in beide gevallen voor een grote site geen groot probleem moeten zijn. Voor PHP heb je het Zend Framework, voor Java bijv. Spring en Hibernate. Ontwikkelen in PHP gaat mogelijk wel sneller dan in Java.

Voor een simpele webapplicatie is PHP waarschijnlijk makkelijker, maar als je naar meerdere servers gaat, met problemen met session management etc., wint Java dan niet op vele vlakken?

Wat is jullie mening hierover?

[branneman]

Vaak groeien projecten inderdaad uit een zolderkamer, wat door een hobbyist is ontwikkeld in de taal waar hij zich prettig bij voelt.

Voor het vergelijken van php & java op dit vlak zijn er veels te veel dingen waar je rekening mee moet houden, en om te beginnen kan alles met beide talen, het is maar net wat je ontwikkelaars het beste kunnen. PHP is iets meer rapid development, Java heeft wat meer infrastructuur voor schaalbaarheid, maar beide komen er wel in the end. Technologie kan bepaalde aspecten makkelijker maken, maar wat je ook kiest, je komt er wel.

Daarnaast is een vergelijking van de taal vs taal niet helemaal reëel, software als je http server, je ide, je framework, je logitech g15 of je ms natural ergonomic 3000 keyboard.

Kies gewoon waar jij je prettig bij voelt, beide omgevingen zijn volwassen genoeg om alle problemen de baas te zijn. Bij "grote websites" kom je zoveel verschillende problemen tegen, waar de 2 talen bij elk probleem beter of slechter blijken, dat het niet meer echt boeit in my opinion.

Ook ik ben ontwikkelaar en heb oa ervaring met php & java, waarvan high traffic websites

[Confusion]

quote:

IntToStr schreef op zondag 15 november 2009 @ 14:55:
Ik ben zelf Java ontwikkelaar met een verleden als PHP ontwikkelaar. Nu was ik laatst wat aan het praten met een collega over grote websites, zoals bijv. tweakers, marktplaats of hyves. Het viel ons op dat veel grote (Nederlandse) sites met PHP zijn gemaakt.

In eerste instantie wel, maar vaak worden later delen herschreven. De backends van Marktplaats en Hyves zijn allang geen PHP meer. Marktplaats werkt onder andere met een Java message bus en een oud-collega van me heeft een baan bij Hyves gekregen vanwege zijn ervaring met C++ en Python. In hoeverre de frontends nog PHP zijn weet ik niet.

[Luqq]

quote:

Confusion schreef op zondag 15 november 2009 @ 15:44:
[...]

In eerste instantie wel, maar vaak worden later delen herschreven. De backends van Marktplaats en Hyves zijn allang geen PHP meer. Marktplaats werkt onder andere met een Java message bus en een oud-collega van me heeft een baan bij Hyves gekregen vanwege zijn ervaring met C++ en Python. In hoeverre de frontends nog PHP zijn weet ik niet.

Die C++ ervaring is misschien nodig geweest voor hun desktop app, die is in C++ geschreven.

[Sebazzz]

En zelfs tweakers.net is geen 100% php meer, de pricewatch leunt bijvoorbeeld gedeeltelijk op Java voor cachingmogelijkheden.

[IntToStr]

Toch wel redelijk wat ik verwachtte dus. Begonnen als PHP en na grote groei wordt de backend toch bijv. Java.

Interessant om te weten hoe dit bij de 'grote sites' nou eigenlijk opgebouwd is :-)

[GlowMouse]

quote:

Sebazzz schreef op zondag 15 november 2009 @ 16:12:
En zelfs tweakers.net is geen 100% php meer, de pricewatch leunt bijvoorbeeld gedeeltelijk op Java voor cachingmogelijkheden.

Java vervangt hier eerder MySQL dan PHP.

[frickY]

PHP heeft tegenwoordig ook prima caching en clustering methodieken, waardoor ik niet direct zie waarom Java beter geschikt zou zijn?

[Bryan Tong Minh]

quote:

branneman schreef op zondag 15 november 2009 @ 15:37:
Vaak groeien projecten inderdaad uit een zolderkamer, wat door een hobbyist is ontwikkeld in de taal waar hij zich prettig bij voelt.

Dat lijkt mij inderdaad voor een groot gedeelte het geval. Voorbeeld, MediaWiki, de software achter Wikipedia is in 2002 geschreven door een student die PHP uit wilde proberen. Inmiddels is dit uitgegroeid tot een code base die de nummer 5 website van het internet draait.

[kwaakvaak_v2]

quote:

frickY schreef op zondag 15 november 2009 @ 16:51:
PHP heeft tegenwoordig ook prima caching en clustering methodieken, waardoor ik niet direct zie waarom Java beter geschikt zou zijn?

Precies... als je je php omgeving goed opzet, met bijvoorbeeld APC en Memcached, kun je er zeker grotere projecten mee maken. Ik proef in dit topic toch weer een beetje dat typische javanisten toontje, dat PHP een inferieur script taaltje is.

Tuurlijk heeft PHP zijn quirks, net als elke andere taal. Maar het is 9 van de 10 keer de programmeur die de fouten maakt, waarbij de grootste fout van veel PHP programmeurs is dat ze denken dat alles via de browser moet gebeuren en perse met MySQL moet werken, maar dat is helemaal nergens goed voor, PHP werkt net zo goed via de shell, waarbij je heel makelijk dingen kunt pre-processen. Er zijn legio alternatieven voor de M in LAMP zoals Mongo of CouchDB. Jobqueue management met Gearman. Opties te over, net als je dat bij java (of welke andere taal dan ook)

Zoals zo vaak komt het gewoon neer op de creativiteit en kennis van de programmeur. Ja programmeur, geen scripter. Dat zijn twee totaal verschillende disciplines in mijn optiek. Scriptjes hacken zonder ontwerp wat in elkaar, en komen later tot de conclusie dat ze een draak hebben gemaakt, programmeurs daarintegen plannen hun applicatie eerst voor ze ook maar 1 letter code hebben gemaakt.

quote:

Sebazzz schreef op zondag 15 november 2009 @ 16:12:
En zelfs tweakers.net is geen 100% php meer, de pricewatch leunt bijvoorbeeld gedeeltelijk op Java voor cachingmogelijkheden.

HUH??? Leg eens uit, hoe kan java beter cachen dan PHP?? pre-processen naar cache data daar kan ik mij iets bij voorstellen. Maar als pure cache?, daar zie ik het voordeel van java even niet bij

[Voor 13% gewijzigd door kwaakvaak_v2 op 15-11-2009 18:09]

[Sebazzz]

@hierboven: plan: Tweakers.net introduceert snellere Pricewatch-engine
Ze maken gebruik van Java om bepaalde data in het geheugen te houden zodat de boel een stuk sneller draait. De pricewatch draait dus nog steeds op PHP, maar niet 100%.

[SKiLLa]

@kwaakvaak_v2: je doelt op 'scriptkiddies' en niet op scripters; scripters zijn gewoon programmeurs die in een scripttaal ontwikkelen.

En het voordeel van een Java/.Net backend - waar toepasselijk (dus niet per definitie !) - moet je meer zoeken in de complexiteit en het feit dat die app b.v. naast Apache/IIS kan leven (b.v. als middle-tier caching). Het gaat er niet om dat het in PHP niet mogelijk zou zijn, maar je moet in een Fiat Panda net zo min gaan autoracen als boodschappen doen in een Ferrari F430, ondanks dat beiden mogelijk zijn ...

[Alex]

Een argument wat ik in dit hele topic mis is eigenlijk voornamelijk productiviteit en 'natuur'.
Met alle respect, maar ik ga geen Bash-script in PHP schrijven omdat dit zo makkelijk is.
Nee, voor de shell heb je Bash, voor middleware heb je talen zoals Progress, etc.
De talen zijn hiervoor gemaakt en geven maximale productiviteit voor die specifieke omgeving.

Vaak is het ook niet echt een keuze van de programmeur maar zijn er een hoop randvoorwaarden.
Een van de architecten van Hyves vertelde mij 2 weken terug dat hij het totaal niet interessant vind waarin de front-end is geschreven. PHP is ooit gekozen, dus doen ze dat daarmee.
Net voor de database hebben ze ooit een tooltje gebouwd wat server side connection pooling deed voor MySQL. In C++. Dat was de meest logische optie. Mede omdat er geen PHP draait op die database server. En dat het gewoon handiger is om daar op die plek C++ te gebruiken vanwegen dat die taal het mogelijk maakt om dit heel efficient te doen.
Andere factoren zoals overdraagbaarheid spelen ook mee in zo'n keuze.

PHP is geen Fiat Panda, C++ ook geen Ferrari. Maar het zijn talen met andere doelen en daarmee hebben ze voordelen. Ik zie PHP dus het liefste enkel gebruik worden in de Front-end. Maar voor sommige projecten werkt ASP.NET met VB of C# goed, of JSF met Java of Scala.

[Jrz]

Emm.. Java of PHP maakt niet zo veel uit. Je kan met allebij prima grote schaalbare onderhoudbare websites maken. En je kan in beide net zo goed er een teringzooitje van maken.

Vroegah zou ik Java hebben geadviseerd. Nu Rails, wat een verademing. Als dat geen mogelijkheid is zou ik op dit moment eerder PHP aanraden voor "websites". :-) Had nooit gedacht dat het zo ver zou komen lol

[Janoz]

quote:

kwaakvaak_v2 schreef op zondag 15 november 2009 @ 18:06:
Precies... als je je php omgeving goed opzet, met bijvoorbeeld APC en Memcached, kun je er zeker grotere projecten mee maken. Ik proef in dit topic toch weer een beetje dat typische javanisten toontje, dat PHP een inferieur script taaltje is.

Ik heb nog even naar alle reacties boven je gekeken, maar nergens zie ik dat echt terug. Eerder een stukje realisme. Wat ik vervolgens wel weer in jouw reactie terug zie is het typische 'fanboy'-achtige op de barricade springen omdat iemand ergens zegt dat php in sommige gevallen toch wel niet de beste keuze zou kunnen zijn.

Bijna alle fouten worden door de ontwikkelaars gemaakt. Maar als je project groter wordt en het overzicht dus kleiner, dan is het wel zo makkelijk dat je een platform gebruikt dat fouten voorkomt. Ik maak uit je post op dat je behoorlijke ervaring hebt met PHP, maar om meerdere platformen te kunnen vergelijken kom je er niet met enkel ervaring met 1 van de platformen. Simpel het feit dat je geen idee hebt waarom caching in een jee omgeving makkelijker te implementeren zou kunnen zijn geeft imho aan dat er nog wel een deel is dat je nog niet weet over de mogelijkheden bij enterprise software development. Het zou niet gek zijn om je horizon eens iets te verbreden en ook andere technieken eens een serieuze kans te geven om het gevaar van een one trick pony af te wenden.

[.oisyn]

Ik wilde hier een reactie tikken, maar toen zag ik dat Janoz dat eigenlijk al had gedaan

quote:

kwaakvaak_v2 schreef op zondag 15 november 2009 @ 18:06:
HUH??? Leg eens uit, hoe kan java beter cachen dan PHP?? pre-processen naar cache data daar kan ik mij iets bij voorstellen. Maar als pure cache?, daar zie ik het voordeel van java even niet bij

Wat dacht je van het feit dat je in PHP doorgaans aan een request scope vast zit, waardoor je niet gewoon objecten in het geheugen kunt houden maar telkens weer moet serializen/deserializen, terwijl je met Java juist een application scope heeft waarbij een nieuw request gewoon een event is dat afgehandeld moet worden?

[Voor 31% gewijzigd door .oisyn op 15-11-2009 22:12]

[TomWij]

Het hangt er op de eerste plaats van af wat er tot jouw beschikt staat, niet alles werkt op ieder platform. Dus hangt het er vanaf of je het moet doen met wat het internet jouw ter beschikking geeft, of je eigen server ter beschikking hebt of meerdere servers ergens kan laten plaatsen. Uiteraad hangt de keuze daarvoor ook weer af van wat je met het project wil bereiken en welk budget je hier voor over hebt.

Verder ga ik voort op wat Janoz zei: Bestudeer gewoon eens de verschillende dingen; lees er over, zoek de sterke en zwakke punten op, begrijp op welke manier de taal voor jouw handig kan zijn. Vergelijk vervolgens de sterkste door er wat mee te proberen en neem wat jou het beste ligt.

Tenzij je puur PHP tegenover Java plaatst raad ik je aan eens de verschillende opties op deze pagina onder de tabel te lezen. Eens je wat verdiept te hebben in de verschillende dingen vind je misschien wel iets wat jouw nog beter ligt, of misschien is iets wat je nu al gebruikt is eigenlijk toch de juiste keuze.

Moest ik meer professionel kennis hebben dan zou ik je bijvoorbeeld ASP.NET met C# aanraden maar helaas kan ik die keuze dan niet tot in de details verdedigen, het is natuurlijk iets wat je zelf moet bekijken en over oordelen. Bij de meeste discussies is er immers geen beste taal om iets te doen, die moet je zelf ontdekken.

[Wolfboy]

De keuze van een taal moet altijd een kosten-batenanalyse zijn. Waar Java het bij grotere projecten waarschijnlijk op executietijd zal winnen zal PHP het (zeker bij kleinere projecten) winnen kwa benodigde tijd om iets te bouwen.

Voor iets als de pricewatch backend zou je nooit PHP willen gebruiken. Dat wil zeggen, vanaf het moment dat database + PHP + memcached (oid.) niet meer direct voldoende zijn en je dus een eigen server wil bouwen om de resultaten te genereren, dan wil je geen PHP meer gebruiken.

Waarom niet? Nou... voldoende redenen te noemen, maar de voornaamste voor mij zouden het gebrek aan multithreading zijn waardoor je altijd van andere architecturen afhankelijk bent om je processen te spawnen. En zodra je dus niet 1 blijvend proces kan hebben blijf je dus bezig met data inlezen/wegschrijven wat je normaal gesproken gewoon in het proces zou behouden.


Waarom kiezen mensen er dan voor om in PHP te schrijven?
Omdat...

• ze de taal al kennen en mede daardoor er snel in kunnen ontwikkelen.
• de meeste van deze projecten inderdaad als hobbyproject starten.
• de initiele kosten van java hoger zijn (minder hosting beschikbaar, meer tijd nodig voor de initiele constructie, etc.)
• php voor veel dingen "snel genoeg" is

Dat gezegd hebbende ben ik zeker geen liefhebber van PHP, maar zie ik ook Java niet graag als "web" taal. Java vind ik prima voor backends maar als frontend heeft het zeker niet mijn voorkeur.

[ACM]

Als we nu helemaal opnieuw moesten beginnen met de huidige kennis en inzichten, dan zou ik niet gauw een compleet andere architectuur voorstellen... Wel zouden we dan nog meer gebruik maken van de (JMS-)message queue/topics om zaken buiten de requests om te verwerken, memcached om voor-verwerkte objecten te cachen en misschien wel PostgreSQL ipv MySQL niet omdat ie sneller is, maar over het algemeen wel voorspelbaarder. Daarnaast zouden we wellicht nog wat sneller naar Java grijpen om een deel van de requests te verwerken, zoals we nu al voor de pricewatch hebben.

[kwaakvaak_v2]

Een server zou ik zelf ook nooit in PHP schrijven, laat daar geen twijfel over bestaan. Het kan, maar het gaat nooit de performance geven van een higherlevel taaltje. Dat wil zeggen, hangt een beetje van de server af en de hoeveelheid data die het moet verwerken per dag, en wat de overlap in die data is. Iets wat 10.000 keer per dag exact hetzelfde is, kan prima in php. Maar iets dynamisch waarbij elke request een complexe query is, dan moet je idd goed afwegen of je dat in PHP wil doen, of iets wil maken wat idd een wat meer REST achtige structuur heeft waarbij een request een event is en data wat makkelijker over de server gedeeld kan worden. Of een andere DB laag kiezen indien mogelijk, indexed views kunnen soms als voldoende verlichting brengen om je app toch in 1 taal domein te houden.

nee geen php fanboy/evangelist, maar ik wel iemand die praktisch kijkt naar wat een toepassing moet kunnen en daar de beste combo voor kiest. En voor web zou ik zelf nooit java kiezen, al was het alleen maar door slechte ervaringen in het verleden met een tomcat installatie. Dat zou ik eerder zoals hierboven al iemand opmerkte iets als Rails pakken als ik echt een dedicated server oplossing nodig had. Maar voor veel projecten kun je aardig uit met wat relatief simpele cache files op disk, of memcached. In memcached kan ik prima een object in zijn volledigheid in kwijt en delen over meerdere php requests. Optimaal, nee waarschijnlijk niet, afdoende voor de meeste projecten dat zeker

[Voor 21% gewijzigd door kwaakvaak_v2 op 16-11-2009 10:15]

[IntToStr]

Laat ik trouwens even voorop stellen dat het niet de bedoeling was om php(ontwikkelaars) af te kraken of zo.

Tot een bepaalde grootte kun je alles prima met php, memcached, etc. af, maar op een bepaald moment kom je toch echt uit op meerdere servers. Je zou hier als voordeel van php kunnen zien dat alles request scope is, dus het maakt niet uit op welke server je uitkomt. Maar kan php bijv. ook de sessies over meerdere servers gebruiken? Hoe ga je met zoiets om in php?

In bovenstaande posts zie ik ook een paar keer genoemd dat php als frontend wordt gebruikt en java als backend. Waarom niet gewoon jsp's? Zeker in combinatie met Spring MVC of Spring Webflow en diverse taglibraries kun je toch op een makkelijke manier ook je presentatielaag maken.

Hoe combineer je eigenlijk php en java in 1 applicatie? Er lijkt wat ondersteuning te zijn in bijv. zend server, maar ik heb zend server eigenlijk nog nooit in gebruik gezien ergens (kan aan mij liggen ). Verder zie ik wat experimentele support op php.net en een project wat PHP/Java Bridge heet.

Overigens ging mijn 'vraag' over wat je zou doen als je bijv. tweakers.net op dit moment van de grond af opnieuw zou bouwen waarbij je uitgaat van hetzelfde gebruik. Is PHP dan nog steeds de keuze? Voor kleinere projecten zou ik zelf ook sneller voor PHP kiezen.

[kwaakvaak_v2]

quote:

IntToStr schreef op maandag 16 november 2009 @ 11:06:

Tot een bepaalde grootte kun je alles prima met php, memcached, etc. af, maar op een bepaald moment kom je toch echt uit op meerdere servers. Je zou hier als voordeel van php kunnen zien dat alles request scope is, dus het maakt niet uit op welke server je uitkomt. Maar kan php bijv. ook de sessies over meerdere servers gebruiken? Hoe ga je met zoiets om in php?

In bovenstaande posts zie ik ook een paar keer genoemd dat php als frontend wordt gebruikt en java als backend. Waarom niet gewoon jsp's? Zeker in combinatie met Spring MVC of Spring Webflow en diverse taglibraries kun je toch op een makkelijke manier ook je presentatielaag maken.

Ik heb met die JSP's geen ervaring, maar de ervaring met servlets onder tomcat die ik had was niet zo rooskleurig dat ik het nog een keer zou gebruiken. Veel te zwaar voor relatief simpele schermen, PHP processen waren gewoon lichter in de praktijk. Maar ik spreek wel over 5 a 6 jaar terug, dus of het relevant is voor de huidige java stand, weet ik niet. Toen alles wat de java club geleverd had, omgeschreven naar relatief simpele php met XML koppelingen naar het midoffice systeem en nooit meer omgekeken.

[Janoz]

quote:

kwaakvaak_v2 schreef op maandag 16 november 2009 @ 11:19:
[...]


Ik heb met die JSP's geen ervaring, maar de ervaring met servlets onder tomcat die ik had was niet zo rooskleurig dat ik het nog een keer zou gebruiken. Veel te zwaar voor relatief simpele schermen, PHP processen waren gewoon lichter in de praktijk. Maar ik spreek wel over 5 a 6 jaar terug, dus of het relevant is voor de huidige java stand, weet ik niet. Toen alles wat de java club geleverd had, omgeschreven naar relatief simpele php met XML koppelingen naar het midoffice systeem en nooit meer omgekeken.

PHP is inderdaad heel goed te gebruiken als frontend oplossing, maar als je ook daadwerkelijk je midoffice zou moeten implementeren dan is een JEE omgeving een stuk makkelijker.

Let er trouwens wel op dat je een behoorlijk verkeerd beeld gekregen hebt wanneer je geprobeerd hebt enkel servlets te gebruiken voor je web-GUI. Zelfs 5 jaar terug had het een heel stuk gescheeld wanneer je JSP's gebruikt had (Als php ontwikkelaar had je je daarmee waarschijnlijk een stuk meer thuis gevoeld), en dat terwijl scriptlets in JSP's tegenwoordig niet meer helemaal the way to go zijn.

[ACM]

quote:

IntToStr schreef op maandag 16 november 2009 @ 11:06:
Tot een bepaalde grootte kun je alles prima met php, memcached, etc. af, maar op een bepaald moment kom je toch echt uit op meerdere servers. Je zou hier als voordeel van php kunnen zien dat alles request scope is, dus het maakt niet uit op welke server je uitkomt. Maar kan php bijv. ook de sessies over meerdere servers gebruiken? Hoe ga je met zoiets om in php?

Natuurlijk kan je dat in php bereiken... Je hebt kans dat je dan niet php's sessie-management wilt gebruiken, magoed, die van Java is ook niet ideaal voor het soort grote sites dat je noemt. Het lijkt mij iig niet erg ideaal om alle data die je aan een gebruiker koppelt tijdens zijn bezoeken in het ram van een server te houden als je niet eens zeker weet of die gebruiker wel binnen afzienbare tijd terug gaat komen.
Je zal dus altijd moeten kijken wat voor soort sessies je nodig hebt en hoe je die data aan de gebruiker koppelt.
In ons geval hebben we hele simpele, kleine sessies waar geen variabele data in staat en die staan gewoon in de database (en zitten gecached in memcached).

quote:

In bovenstaande posts zie ik ook een paar keer genoemd dat php als frontend wordt gebruikt en java als backend. Waarom niet gewoon jsp's? Zeker in combinatie met Spring MVC of Spring Webflow en diverse taglibraries kun je toch op een makkelijke manier ook je presentatielaag maken.

Vziw ontwikkeld php alsnog eenvoudiger dan jsp. Zeker als je al een complete php-omgeving hebt natuurlijk.

quote:

Hoe combineer je eigenlijk php en java in 1 applicatie? Er lijkt wat ondersteuning te zijn in bijv. zend server, maar ik heb zend server eigenlijk nog nooit in gebruik gezien ergens (kan aan mij liggen ). Verder zie ik wat experimentele support op php.net en een project wat PHP/Java Bridge heet.

In ons geval door middel van een tomcat-omgeving die reageert op simpele get-requests waarbij de resulterende data een stuk data is volgens php's serialization. Waardoor het triviaal in php, zonder verdere data-conversie, te vertalen is in php-objecten.

quote:

Overigens ging mijn 'vraag' over wat je zou doen als je bijv. tweakers.net op dit moment van de grond af opnieuw zou bouwen waarbij je uitgaat van hetzelfde gebruik. Is PHP dan nog steeds de keuze? Voor kleinere projecten zou ik zelf ook sneller voor PHP kiezen.

Zie hierboven. Als dat nu zou moeten gebeuren ben ik samen met crisp degene die die beslissing uiteindelijk moet nemen En ik betwijfel het of ik, gegeven zeker met ons huidige team, van PHP zou afstappen. Als frontend-taal is het over het algemeen prima, en de meeste dingen die wij doen zijn vaak ook weer niet zo vreselijk complex dat je er heel moeilijk om moet doen in php.

[IntToStr]

quote:

Janoz schreef op maandag 16 november 2009 @ 11:45:
[...]

PHP is inderdaad heel goed te gebruiken als frontend oplossing, maar als je ook daadwerkelijk je midoffice zou moeten implementeren dan is een JEE omgeving een stuk makkelijker.

Let er trouwens wel op dat je een behoorlijk verkeerd beeld gekregen hebt wanneer je geprobeerd hebt enkel servlets te gebruiken voor je web-GUI. Zelfs 5 jaar terug had het een heel stuk gescheeld wanneer je JSP's gebruikt had (Als php ontwikkelaar had je je daarmee waarschijnlijk een stuk meer thuis gevoeld), en dat terwijl scriptlets in JSP's tegenwoordig niet meer helemaal the way to go zijn.

Als toevoeging hierop: een jsp kun je gewoon als template gebruiken net zoals je dat met php waarschijnlijk doet (smarty bijv.). Je hebt expression language icm jstl om (kort door de bocht) de koppeling tussen java en template te maken. Met diverse andere tag libraries (Spring, DisplayTag) kun je op eenvoudige manier extra koppelingen of functionaliteit toevoegen zonder dat je java kennis nodig hebt.

[IntToStr]

quote:

ACM schreef op maandag 16 november 2009 @ 11:57:
[...]

Natuurlijk kan je dat in php bereiken... Je hebt kans dat je dan niet php's sessie-management wilt gebruiken, magoed, die van Java is ook niet ideaal voor het soort grote sites dat je noemt. Het lijkt mij iig niet erg ideaal om alle data die je aan een gebruiker koppelt tijdens zijn bezoeken in het ram van een server te houden als je niet eens zeker weet of die gebruiker wel binnen afzienbare tijd terug gaat komen.
Je zal dus altijd moeten kijken wat voor soort sessies je nodig hebt en hoe je die data aan de gebruiker koppelt.
In ons geval hebben we hele simpele, kleine sessies waar geen variabele data in staat en die staan gewoon in de database (en zitten gecached in memcached).

Dit is in ieder geval ook altijd een streven van mij: zo min mogelijk in sessie. Door dit in de database te zetten ben je inderdaad wel van (een deel van) de ellende af.

quote:

[...]

Vziw ontwikkeld php alsnog eenvoudiger dan jsp. Zeker als je al een complete php-omgeving hebt natuurlijk.

Vanuit een php-omgeving is het uiteraard altijd makkelijker om in php te werken. Of het werkelijk makkelijker is dan jsp valt denk ik wel mee. Ligt puur aan de ervaring van de ontwikkelaar met de betreffende taal lijkt me.

quote:

[...]

In ons geval door middel van een tomcat-omgeving die reageert op simpele get-requests waarbij de resulterende data een stuk data is volgens php's serialization. Waardoor het triviaal in php, zonder verdere data-conversie, te vertalen is in php-objecten.

[...]

Zie hierboven. Als dat nu zou moeten gebeuren ben ik samen met crisp degene die die beslissing uiteindelijk moet nemen En ik betwijfel het of ik, gegeven zeker met ons huidige team, van PHP zou afstappen. Als frontend-taal is het over het algemeen prima, en de meeste dingen die wij doen zijn vaak ook weer niet zo vreselijk complex dat je er heel moeilijk om moet doen in php.

Ok, duidelijk Ook als je mocht kiezen tussen een team dat ipv PHP-specialisten Java-specialisten zijn?

Tot nu toe heb ik een beetje gechargeerd naar Java in dit topic, maar ik denk dat PHP toch zeker ook op een goede manier gebruikt kan worden voor de implementatie van een 'grote website'.

[YopY]

quote:

IntToStr schreef op maandag 16 november 2009 @ 12:00:
[...]

Als toevoeging hierop: een jsp kun je gewoon als template gebruiken net zoals je dat met php waarschijnlijk doet (smarty bijv.). Je hebt expression language icm jstl om (kort door de bocht) de koppeling tussen java en template te maken. Met diverse andere tag libraries (Spring, DisplayTag) kun je op eenvoudige manier extra koppelingen of functionaliteit toevoegen zonder dat je java kennis nodig hebt.

Nee, maar dan moet je JSP en JSTL kennis hebben, . JSTL is wel meer 'verbose' dan PHP of een template taal zoals Smarty, dus dan zou ik sowieso een alternatieve (template) taal gebruiken. Ben ik niet zo thuis in echter.

[ACM]

quote:

IntToStr schreef op maandag 16 november 2009 @ 12:52:
Ook als je mocht kiezen tussen een team dat ipv PHP-specialisten Java-specialisten zijn?

Als het compleet zonder randvoorwaarden opnieuw opgezet moet worden zou ik niet weten wat de beste optie is. 't Heeft namelijk beide gewoon voor- en nadelen, niet alleen in de sfeer van de uiteindelijk draaiende applicatie. Sterker nog, de uiteindelijke productieomgeving is relatief gezien eigenlijk helemaal niet zo belangrijk, je ontwikkeltraject en eenvoud waarmee het allemaal tot stand komt is wat dat betreft natuurlijk veel belangrijker

quote:

Tot nu toe heb ik een beetje gechargeerd naar Java in dit topic, maar ik denk dat PHP toch zeker ook op een goede manier gebruikt kan worden voor de implementatie van een 'grote website'.

Tenzij er structurele schalingsproblemen in een platform zitten, waar je in jouwe situatie last van hebt, is eigenlijk elk platform wel geschikt [/open deur]

[Confusion]

quote:

kwaakvaak_v2 schreef op maandag 16 november 2009 @ 10:10:
Een server zou ik zelf ook nooit in PHP schrijven, laat daar geen twijfel over bestaan. Het kan, maar het gaat nooit de performance geven van een higherlevel taaltje.

Over het algemeen gebruik je je juist 'lower level' talen als het je om de performance gaat. PHP is een 'higher level taaltje'.

quote:

Dat wil zeggen, hangt een beetje van de server af en de hoeveelheid data die het moet verwerken per dag, en wat de overlap in die data is. Iets wat 10.000 keer per dag exact hetzelfde is, kan prima in php.

Hoe vaak iets moet gebeuren is niet relevant. Iets dat een miljoen keer per dag exact hetzelfde is, doe je niet in PHP, als je het 10% sneller in Java kan en dat 10% op je serverkosten scheelt.

quote:

Maar iets dynamisch waarbij elke request een complexe query is, dan moet je idd goed afwegen of je dat in PHP wil doen, of iets wil maken wat idd een wat meer REST achtige structuur heeft

Je kan ook prima REST in PHP doen.

quote:

Of een andere DB laag kiezen indien mogelijk, indexed views kunnen soms als voldoende verlichting brengen om je app toch in 1 taal domein te houden.

'Indexed views' als voorbeeld van 'een andere DB laag'?

quote:

nee geen php fanboy/evangelist, maar ik wel iemand die praktisch kijkt naar wat een toepassing moet kunnen en daar de beste combo voor kiest. En voor web zou ik zelf nooit java kiezen, al was het alleen maar door slechte ervaringen in het verleden met een tomcat installatie.

Kortom, je hebt hoegenaamd geen ervaring met Java en blaast er toch hoog van de toren over, waarbij je allemaal termen en concepten dusdanig chaotisch door elkaar gebruikt, dat je niets kloppend of informatiefs zegt.

[kwaakvaak_v2]

quote:

Confusion schreef op maandag 16 november 2009 @ 16:24:
Hoe vaak iets moet gebeuren is niet relevant. Iets dat een miljoen keer per dag exact hetzelfde is, doe je niet in PHP, als je het 10% sneller in Java kan en dat 10% op je serverkosten scheelt.

Niet als het 200% meer ontwikkel + onderhouds kosten met zich mee brengt. Dan kan het op papier allemaal heel erg mooi en prachtig in java werken, meestal wint de ROI het bij web applicatie's het van de prachtige infrastructuur. Meestal is een PHP ding een korte termijn, uitzondering zoals altijd daargelaten.

quote:

'Indexed views' als voorbeeld van 'een andere DB laag'?

Maak jij maar eens een indexed view in MySQL aan dan

quote:

Kortom, je hebt hoegenaamd geen ervaring met Java en blaast er toch hoog van de toren over, waarbij je allemaal termen en concepten dusdanig chaotisch door elkaar gebruikt, dat je niets kloppend of informatiefs zegt.

ik zeg toch ook nergens dat ik wel ervaring met Java heb of wel dan? Nee ik heb wel ervaring met PHP, en meer dan voldoende om echt te weten waar ik het over heb. Okay, ik mikte lower en higher door elkaar, daar heb je idd een punt..

[Confusion]

quote:

kwaakvaak_v2 schreef op maandag 16 november 2009 @ 17:13:
Niet als het 200% meer ontwikkel + onderhouds kosten met zich mee brengt.

En zo zijn er nog talloze relevante factoren. Precies waarom ik protesteer als jij als relevant criterium aanhaalt "of er tig keer 'exact hetzelfde' gebeurt".

quote:

Maak jij maar eens een indexed view in MySQL aan dan

Als mensen over 'de DB laag' spreken, dan hebben ze het meestal over de abstractielaag binnen de applicatie die met de database communiceert. Van kale queries tot een compleet ORM framework of iets er tussenin. Daarnaast zit er weinig overlap tussen de problemen die je oplost door voor een andere programmeertaal te kiezen en de problemen die je oplost door voor een andere DB te kiezen.

quote:

ik zeg toch ook nergens dat ik wel ervaring met Java heb of wel dan?

Je voert een ervaring met Tomcat aan om 'voor het web nooit voor Java te kiezen'. Zelfs als Tomcat het enige platform was waarmee je Java webapplicaties kon beheren, en dat ook de enige functie van Tomcat was, dan nog zou dat niet relevant zijn.

[cariolive23]

Komt nog bij dat vele problemen met database-performance worden veroorzaakt doordat applicaties bijzonder ongelukkig met de database omgaan, het datamodel naar het object is ingericht en niet t.b.v. performance (de bekende Object Relationele Mismatch, ORM), er geen kennis van de genoemde database aanwezig is (fatsoenlijke configuratie kun je dus wel vergeten) en men niet (goed) weet je queries moet optimaliseren. Dan maakt dus geen moer uit of je nu met PHP, Java of Delphi programmeert, de database zal zich altijd in onmogelijke bochten moeten wringen om toch nog maar wat resultaten op te lepelen.

De performance van een webapplicatie is een optelsom van factoren, de gekozen programmeertaal en de gekozen database zijn er slechts twee van.

[MSalters]

Er zullen niet veel developers hier zijn die 10 miljoen+ clients moeten ondersteunen, maar PHP schaalt dus niet geweldig als je zover gaat. 't Werkt wel soepel met je eerste 1000 clients, maar als dat er 100x zoveel zijn 6 maanden later dan heb je al structurele problemen met je load. En met nog eens 100x meer clients doet het echt pijn.

[Voutloos]

quote:

MSalters schreef op maandag 16 november 2009 @ 19:27:
PHP schaalt dus niet geweldig als je zover gaat.

"Languages don't scale, architectures do".

Je statement is echt hopeloos generiek en is dan gewoon onwaar. De bottleneck zal meestal gewoon ouderwets bij een beperkte resource liggen. Bijvoorbeeld die ene tabel waarin alle 1M users steeds continu in moeten schrijven.

[.oisyn]

PHP ís een architectuur. Het staat buiten kijf dat we het hier niet over de taal PHP hebben.

[Voor 6% gewijzigd door .oisyn op 16-11-2009 19:52]

[Confusion]

quote:

.oisyn schreef op maandag 16 november 2009 @ 19:52:
PHP ís een architectuur. Het staat buiten kijf dat we het hier niet over de taal PHP hebben.

PHP beperkt je in de architectonische keuzes, maar om nou te zeggen dat het een specifieke architectuur is... Sowieso levert dat spraakverwarring op. Het lijkt me makkelijker andere termen te gebruiken voor de (delen van de) architectuur die het gebruik van de taal (het framework?) PHP afdwingt.

[Alex]

.oisyn, is dat zo? Productiviteit is een issue. Een server is goedkoper dan een persoon.
Het uitdrukken van jezelf doe jij in Nederlands en soms in Engels, maar niet in Asperanto. Je maakt ook daarin een keuze. Ik denk dat de keuze voor het goed kunnen beschrijven van jouw applicatie belangrijker is dan het platform.
Deze manier van beschrijven zorgt vaak ook voor een essentieel onderdeel van de architectuur.

Volgens mij moet je 3 onderdelen onderscheiden bij een stelling als die van de TS:
1. Platform: Welke boundaries heeft het platform voor de te maken applicatie.
2. Expressiveness: Welke taal geeft je de optie om het dichtste tegen je domein aan te praten?
3. Architectuur: Welke archituur plaat is het efficientst voor deze oplossing.

Alle 3 valide vanuit mijn point-of-view.
Je ziet vaak dat de keuze gemaakt wordt op basis van 1 van deze 3 punten. Door een gebrek aan kennis maar nog vaker door de eerder besproken groei van applicaties.
Als we het louter over groei hebben, dan dien je Expressiveness te laten gaan. Platform en Architectuur zijn dan belangrijk. Echter als het over ROI gaat, dan is het snel komen tot een oplossing belangrijker. Vaak zie je dan dat Platform(deployment) en Expressiveness(Productiviteit) belangrijker is.

[Confusion]

quote:

Alex schreef op maandag 16 november 2009 @ 20:54:
Productiviteit is een issue. Een server is goedkoper dan een persoon.

Die flamewar kunnen we beter laten liggen. Het hangt nogal van de omstandigheden af; voor beide zijn argumenten.

quote:

Ik denk dat de keuze voor het goed kunnen beschrijven van jouw applicatie belangrijker is dan het platform.
[..]
Deze manier van beschrijven zorgt vaak ook voor een essentieel onderdeel van de architectuur.

Op welke manier zorgt die 'manier van beschrijven' daar voor? Bedoel je daarmee dat de keuze op punt 2 de mogelijkheden op punt 3 beinvloedt? Dat is volgens mij precies wat .oisyn zegt.

quote:

1. Platform: Welke boundaries heeft het platform voor de te maken applicatie.
2. Expressiveness: Welke taal geeft je de optie om het dichtste tegen je domein aan te praten?
3. Architectuur: Welke archituur plaat is het efficientst voor deze oplossing.

Ze staan allemaal niet los van elkaar; zeker 1 en 3 niet. Wat betreft punt 2 zullen heel wat mensen Lisp of Prolog antwoorden, omdat ze daarin gemakkelijk constructies kunnen fabriceren waarmee ze heel dicht op het domein kunnen komen. Alle grote gangbare talen onderscheiden zich daar relatief weinig in.

[Alex]

quote:

Confusion schreef op maandag 16 november 2009 @ 21:03:
[...]

Die flamewar kunnen we beter laten liggen. Het hangt nogal van de omstandigheden af; voor beide zijn argumenten.

Ik zie dat niet als een flamewar maar als een boeiende discussie. Ik zie het namelijk als het hotste issue. Mede ook omdat ik vind dat talen juist het onderscheid maken, terwijl platformen dat niet doen

quote:

Op welke manier zorgt die 'manier van beschrijven' daar voor? Bedoel je daarmee dat de keuze op punt 2 de mogelijkheden op punt 3 beinvloedt? Dat is volgens mij precies wat .oisyn zegt.

Volgens mij maakt een keuze in 2 enkel 3 minder snel of sneller uitvoerbaar.
Het goed beschijven zorgt voor snellere productie en hogere beheersbaarheid.
Je ziet daarom vaak Ruby op dit punt terugkomen. Of degene die je hieronder tegen komt.

quote:

Ze staan allemaal niet los van elkaar; zeker 1 en 3 niet. Wat betreft punt 2 zullen heel wat mensen Lisp of Prolog antwoorden, omdat ze daarin gemakkelijk constructies kunnen fabriceren waarmee ze heel dicht op het domein kunnen komen. Alle grote gangbare talen onderscheiden zich daar relatief weinig in.

Grappig dat je ze noemt: Lisp of Prolog. 2 talen die geweldig waren, maar waarvan het platform de beperking is/was.
Gangbare talen hebben vaak helaas een andere approach, zij gaan voor abstractie ipv beschrijving. Daarom zie je dan ook weer dat functionele constructs terug komen, die verhogen productiviteit dan weer.

Al met al is dit een lastige discussie, maar ik denk dat mijn uiteenzetting van deze 3 punten wel duidelijk laat zien dat je een keuze moet maken over meerdere assen. Ik zie daarbij punt 3 als de minst zware. Je kunt immers in elke 'gangbare'(lees is als object georienteerde of recente taal zoals Java, Scala, Python, Ruby, C/F#) taal en binnen de gangbare platformen(Java, PHP, Ruby .NET) elke architectuur neerzetten die je wil.
Mogelijk moet je daarom in de selectie Architectuur daarom vervangen door Frameworks. Welke tooling is er beschikbaar?

[kwaakvaak_v2]

@confusion, vergeet bij de ROI berekening voor een webapplicatie niet dat het vaak relatief korte trajecten zijn en geen systemen die jaren mee moeten gaan. En vanuit dat oogpunt ben ik het wel met Alex eens, een server is goedkoper dan een programmeur. En ja dat is misschien krom vanuit een programmeurs oogpunt. Maar bedrijven kijken helaas vaak niet naar mooie oplossingen. Die willen nu resultaat en dat het dan op de korte termijn even wat meer kost is vaak geen probleem.

Neemt niet weg dat ik vind dat elke programmeur ongeacht taal, altijd zijn best moet doen om een zo efficient mogelijk systeem te maken. Uiteindelijk is een taal een hulpmiddel, geen doel.

[ACM]

quote:

MSalters schreef op maandag 16 november 2009 @ 19:27:
Er zullen niet veel developers hier zijn die 10 miljoen+ clients moeten ondersteunen, maar PHP schaalt dus niet geweldig als je zover gaat. 't Werkt wel soepel met je eerste 1000 clients, maar als dat er 100x zoveel zijn 6 maanden later dan heb je al structurele problemen met je load. En met nog eens 100x meer clients doet het echt pijn.

Je doet nu net alsof dit probleem alleen bij PHP bestaat... Maar er is, vziw, geen enkel (web)platform dat transparant en zonder interventie van programmeurs en systeembeheer opschaalt van 1000 clients naar 10 miljoen+ Tenzij het natuurlijk op voorhand al opgezet was om 10 miljoen+ te halen, maar doorgaans is "scale up" redelijk beperkt en "scale out" eigenlijk altijd iets dat wel ergens extra werk kost.
Je hebt altijd ergens een resource die niet efficient gebruikt wordt, en bij zo'n groei is de kans groot dat je bijvoorbeeld je databaseserver ineens moet opsplitsen over meerdere servers of zelfs (deels) moet vervangen door meer op de taak gerichte omgeving(en). Of in het geval van JVM's dat je interjvm-communicatie (synchronisatie van sessies ofzo) ineens een bottleneck wordt.

[Cheatah]

quote:

kwaakvaak_v2 schreef op maandag 16 november 2009 @ 23:56:

Neemt niet weg dat ik vind dat elke programmeur ongeacht taal, altijd zijn best moet doen om een zo efficient mogelijk systeem te maken.

Eén aspect van efficiënt is dat het ook kostenefficiënt moet zijn. Valt het binnen de verwachtingen van de klant dat een site 10.000 concurrent users aan moet kunnen? Zo nee, waarom zou je daar dan extra tijd in steken?

[kwaakvaak_v2]

quote:

Cheatah schreef op dinsdag 17 november 2009 @ 08:39:
[...]

Eén aspect van efficiënt is dat het ook kostenefficiënt moet zijn. Valt het binnen de verwachtingen van de klant dat een site 10.000 concurrent users aan moet kunnen? Zo nee, waarom zou je daar dan extra tijd in steken?

Precies... maar daarom kun je het nog wel een beetje efficient bouwen.. Stukje eer van je werk zeg maar Je moet het zeker relatief zien, als iemand een site heeft die hooguit 2 a 3 keer per jaar veranderd heeft het weinig nut om die een enorm schaalbaar systeem te verkopen.

[RedRose]

Eén belangrijk aspect wat hier wordt vergeten is dat je te maken hebt met wisselende kwaliteit van mensen. Mijn ervaring is dat je 8 van de 10 keer (ik heb geturfd ) blij mag zijn dat de mensen waar je mee werkt ook daadwerkelijk hun platform van haver tot gort kennen, ook al affichieren ze zich als senior software engineer. Daarbij komt dat je in de meeste organisaties er complete teams van programmeurs worden ingehuurd om een klus te doen en er dan weer vandoor gaan. Dat betekent dat de achterblijvers vaak bottlenecks in load kunnen gaan oplossen en die achterblijvers zijn dan vaak weer de mensen die een platform goed door hebben, maar bijvoorbeeld geen kaas hebben gegeten van de eigenlijke functionalitieit en daardoor vaak weinig structurele oplossingen aandragen. Kijk, bij een site als Tweakers werken mensen met passie en diepgaande kennis voor en van hun vak, zowel op PHP niveau als op systeemniveau. Dat kan je complexe architecturen bouwen en er redelijk zeker van zijn dat alles blijft staan of in ieder geval snel wordt opgelost als er iets misgaat.

Dat heeft gevolgen voor de communicatie tussen projectteams en devvers en sysadmins en heeft daardoor gevolgen voor het platform dat je kiest. Een voordeel van Java (maar ook .Net) ten opzichte van PHP is dat veel, zo niet alles, expliciet verbose moet worden gemaakt, waardoor de managebility van een grote architectuur een stuk beter wordt.

Een ander voorbeeld van voordelen van Java / .Net tov PHP komt kijken bij transaction based websites, zoals banken en vliegtuigmaatschappijen. Dat HTTP-requestje is leuk, maar wordt in zo'n geheel eigenlijk van ondergeschikt belang aan een vliegboeking of een financiele overboeking. Dan is het echt fijn als je een application scope hebt, waardoor je transactions naar achterliggende DBs en servers kan doen zonder dat het PHP proces helemaal volgaat omdat die zit te wachten op een response (ok gechargeerd, maar je begrijpt wat ik bedoel).

quote:

kwaakvaak_v2 schreef op dinsdag 17 november 2009 @ 09:16:
Precies... maar daarom kun je het nog wel een beetje efficient bouwen.. Stukje eer van je werk zeg maar Je moet het zeker relatief zien, als iemand een site heeft die hooguit 2 a 3 keer per jaar veranderd heeft het weinig nut om die een enorm schaalbaar systeem te verkopen.

Je moet code op welk platform dan ook altijd zo efficient mogelijk bouwen. Maar daarmee ben je er dus nog lang niet. PHP is een leuk platform enzo, maar bij de wat grotere sites knal je al snel tegen beperkingen aan, alleen al omdat ze veel worden gewijzigd door grote groepen mensen (Denk Joomla of Drupal met 10 sites en 100 content editors... dat gaat niet werken).

En vergis je niet in hoelang systemen meegaan! Veel systemen die ik nu aan het verbouwen ben komen uit 2003 - 2004 en veel van die sites hebben een brakke PHP implementatie die heel veel nutteloze clockcycles kost of vaak een wat overgearchitectureerde java oplossing, die eigenlijk wel efficienter is qua verbruik en die kan worden verbouwd en worden hergebruikt in een nieuwe situatie. Dan is een programmeur niet zo veel duurder dan een server.

Ik vraag me af of een aantal mensen hier echt denken dat een webproject maar een paar weken duurt en dat het opgeleverde slechts kort meegaat

quote:

Alex schreef op maandag 16 november 2009 @ 20:54:

Volgens mij moet je 3 onderdelen onderscheiden bij een stelling als die van de TS:
1. Platform: Welke boundaries heeft het platform voor de te maken applicatie.
2. Expressiveness: Welke taal geeft je de optie om het dichtste tegen je domein aan te praten?
3. Architectuur: Welke archituur plaat is het efficientst voor deze oplossing.

Voor wat betreft nummer 2: er bestaat geen taal die dicht tegen je domein aan kan praten. Daarnaast kunnen alle moderne talen goed een domein modelleren . Daarom is dat punt van geen belang. Ik vind punt 1 en 3 eigenlijk hetzelfde in deze context.