Imago, toekomst en mogelijkheden: Java, .NET of PHP?

[Erkens]

whoami schreef op zaterdag 27 januari 2007 @ 13:35:
Met PHP kan je webapplicaties ontwikkelen, echter, wat versta je onder webapplicaties ? Vallen daar bij jou enkel websites onder ? Een Webapplicatie kan ook een rich client/Windows applicatie zijn, die op een PC of een mobile device draait, en die gebruik maakt van webservices... Dit kan je met .NET / Java doen, maar niet met PHP.

Waarom zou dat (als je dat al wilt) niet kunnen dan? Je kan met PHP net zo goed desktop applicaties maken, bijvoorbeeld met php-gtk. Maar wat je vaker ziet is dat de desktop applicatie in een andere taal gemaakt is (bijvoorbeeld met XUL) en gebruikt maakt van de webservices die door PHP geleverd worden.

maargoed, zoals je als zei:

Maar, dit moet geen language-war topic worden; ik wil alleen maar zeggen: PHP met J2EE/.NET vergelijken is idd een beetje appels en peren vergelijken.

[Verwijderd]

JKVA schreef op zaterdag 27 januari 2007 @ 16:51:
[...]

Dat valt wel mee. Spring en Hibernate zijn gemaakt omdat na een aantal jaren de ontwikkelaars EJB te moeilijk vonden en daardoor aan een alternatief begonnen zijn. Dat is ook pas sinds 2002 ofzo, weet niet de exacte jaren. Dus dat de Java taal daarvoor al bestonden maakt niks uit, dus ik vind jouw redenering krommer. J2EE is niet zo oud als Java.

Noem bovendien maar eens wat innovatieve third party innovaties van .NET die nu iedereen gebruikt.

Ik ben het er mee eens dat veel van de tools die er beschikbaar waren voor Java gewoon simpelweg geport zijn naar C#. Ik kan inderdaad zo snel ook geen C# tool opnoemen die er niet is in een Java variant.

Dit is echter niet vreemd en ook niets verkeerd aan. Andersom zou het net zo goed gebeuren.

[JKVA]

ThunderNet schreef op zaterdag 27 januari 2007 @ 16:43:
[...]


En als je voor Java kiest, zit je bij Sun.

En Sun is beter dan Microsoft omdat?

vendor-lockin vind ik hier dus een non-argument

Sun is niets beter dan Microsoft. Maar Sun neemt echter wel het initiatief bij de ontwikkeling van een open standaard voor Java/J2EE. Maar Sun doet dat samen met onder andere IBM, BEA, Apache, etceeeeetera. Kijk voor een lijst met namen die meedoen aan de JCP van JSF of EJB op deze links.
http://jcp.org/en/jsr/detail?id=220 (EJB 3.0)
http://jcp.org/en/jsr/detail?id=127 (JSF)

Dat is echt enorme vendor lock-in. Je zit vast aan 300 bedrijven over de hele wereld en uit verschillende branches. Wat een ramp.

[Verwijderd]

Verwijderd schreef op zaterdag 27 januari 2007 @ 16:51:
[...]

Microsoft
Mono
SharpDevelop (OS)

[...]

.NET Implementaties zijn er beschikbaar voor:
Windows
Mac
Linux
FreeBSD
Solaris


Hey verrek, dat zijn dezelfde antwoorden!

Sharpdevelop is geen .NET implementatie, het is een IDE voor .NET.
Er is geen enkele complete .NET implementatie beschikbaar voor Mac, Linux, FreeBSD of Solaris. Praktisch elke .NET applicatie gebruikt Windows Forms, en Windows Forms is enkel beschikbaar op ... jazeker... WINDOWS!

[Verwijderd]

Verwijderd schreef op zaterdag 27 januari 2007 @ 17:10:
[...]


Sharpdevelop is geen .NET implementatie, het is een IDE voor .NET.
Er is geen enkele complete .NET implementatie beschikbaar voor Mac, Linux, FreeBSD of Solaris. Praktisch elke .NET applicatie gebruikt Windows Forms, en Windows Forms is enkel beschikbaar op ... jazeker... WINDOWS!

Mono is meer dan 95% compleet voor 1.1 en aan een 2.0 / 3.0 implementatie wordt hard gewerkt.... Onzin dus (alweer).

[Verwijderd]

Verwijderd schreef op zaterdag 27 januari 2007 @ 17:13:
[...]


Mono is meer dan 95% compleet voor 1.1 en aan een 2.0 / 3.0 implementatie wordt hard gewerkt.... Onzin dus (alweer).

Zucht.
Plaats jij dan ff een screenshot van een normale .NET applicatie (in VB.NET of C#.NET) die zonder prutsen draait onder FreeBSD en/of Solaris?

[MacWolf]

Passenger schreef op zaterdag 27 januari 2007 @ 12:50:
Wat ik me nou afvraag, waarom wordt PHP altijd min of meer "uitgelachen" als het met Java en .NET vergeleken wordt?
Ik begrijp goed dat PHP een lage instapdrempel heeft en dat er daardoor veel prutsers in de community rondlopen die er alleen hobbymatig mee aan de slag gaan. En qua architectuur zijn er vast en zeker mooiere oplossingen te vervaardigen in zowel Java als .NET, dus qua volwassenheid van de taal an sich kan ik me er dan nog enigzins iets bij voorstellen.
Maar ik begrijp alleen niet waarom er altijd zo lacherig bij gezegd moet worden dat het een mug vs olifant vergelijking is. Er zijn toch redelijk wat voorbeeldjes te noemen van flinke websites die op php draaien? (Denk bijv. aan Tweakers.net, Webwereld, Zoom Gallery, Hyves (gedeeltelijk), en wat groter: Wikipedia en Digg).

Ach ja, onder ontwikkelaars heb je ook een groep die graag een beetje elitair doet. Wat dat betreft moet je er ook niets van aantrekken wat andere mensen denken, als jij maar zeker weet dat je de kennis en mogelijkheden hebt om mooie software te ontwikkelen. Zelf ben ik .NET ontwikkelaar en eigenlijk ontwikkel ik altijd in VB.NET, terwijl er een hoop mensen de voorkeur geven aan het Java-achtige C#. Maar ook hierbij maakt het eigenlijk geen donder uit in welke taal je programmeert, gezien je precies dezelfde API aanspreekt en 99% van wat je doet kan op precies dezelfde manier. Mijn voorkeur voor VB komt dat ik vroeger ben begonnen met programmeren op een TI/994a computer waarbij je in BASIC programmeerde. Toen ik ging werken bij mijn huidige werkgever had ik de keuze tussen C# of VB.NET en uiteindelijk is voor ons VB.NET een betere keuze, gezien de taal eigenlijk precies hetzelfde is als ASP.NET en men bij ons ook aan webontwikkeling doet. Gevolg: collega's die webontwikkeling doen kunnen nog eenvoudiger mijn code begrijpen / hergebruiken.

[Verwijderd]

Verwijderd schreef op zaterdag 27 januari 2007 @ 17:15:
[...]


Zucht.
Plaats jij dan ff een screenshot van een normale .NET applicatie (in VB.NET of C#.NET) die zonder prutsen draait onder FreeBSD en/of Solaris?

http://www.mono-project.com/Screenshots

Alsjeblieft. C# onder elk willekeurig OS in een .NET omgeving. C#.NET dus op het Mono framework, wat ook gewoon een .NET implementatie is net als de Microsoft versie. En als je dan nog te koppig bent om het te willen geloven, moet je het maar uitzoeken.

[whoami]

Mensen, kunnen we terug on topic gaan ipv hier een MS vs Sun of .NET vs Java war te starten ?

Plaats jij dan ff een screenshot van een normale .NET applicatie (in VB.NET of C#.NET) die zonder prutsen draait onder FreeBSD en/of Solaris?

Alsof een gebruiker wakker ligt van de taal waarin z'n applicatie geschreven is; als gebruiker X gewend is van onder *nix systemen te werken, dan kies je gewoon voor de Java kant; is gebruiker Y gewend van onder Windows te werken, dan ga je voor de .NET kant.

En nu terug naar de originele topicstart:

Als we kijken naar het imago (vooral naar klanten toe, maar ook voor je persoonlijke ontwikkeling als ontwikkelaar), naar de toekomst en de mogelijkheden, wat is doorgaans de meest interessante technologie (Java, .NET, PHP) om webapplicaties te ontwikkelen?

Mijn antwoord is best kort: klant is koning. Als de klant een volledig Unix park heeft staan, dan zou het dom zijn om voor .NET te kiezen. Afhankelijk van wat de klant wil, wat z'n budget is en wat de kennis binnen het bedrijf is, ga je gewoon de meest geschikte oplossing kiezen.

[Verwijderd]

MacWolf schreef op zaterdag 27 januari 2007 @ 17:29:
Toen ik ging werken bij mijn huidige werkgever had ik de keuze tussen C# of VB.NET en uiteindelijk is voor ons VB.NET een betere keuze, gezien de taal eigenlijk precies hetzelfde is als ASP.NET en men bij ons ook aan webontwikkeling doet. Gevolg: collega's die webontwikkeling doen kunnen nog eenvoudiger mijn code begrijpen / hergebruiken.

Dat is een erg slechte reden om voor VB.NET te kiezen... Keuze voor VB.NET vanuit historie is een logische, maar deze keuze is verre van logisch, zowel in technisch, architectonisch als praktisch oogpunt.

[ Voor 5% gewijzigd door Verwijderd op 27-01-2007 17:34 ]

[MacWolf]

Verwijderd schreef op zaterdag 27 januari 2007 @ 17:33:
[...]
Dat is een erg slechte reden om voor VB.NET te kiezen... Keuze voor VB.NET vanuit historie is een logische, maar deze keuze is verre van logisch, zowel in technisch, architectonisch als praktisch oogpunt.

Wel, de belangrijkste reden is gewoon dat ik me het meest comfortabel voel met de schrijfwijze vanwege mijn verleden en het technisch gezien geen voordeel is om in C# t.o.v. VB.NET te onwikkelen (ook geen nadeel, uiteraard), met beide talen kan je precies hetzelfde. Het verhaal m.b.t. ASP.NET was eerder een leuke bijkomstigheid achteraf gezien.

[whoami]

Toen ik ging werken bij mijn huidige werkgever had ik de keuze tussen C# of VB.NET en uiteindelijk is voor ons VB.NET een betere keuze, gezien de taal eigenlijk precies hetzelfde is als ASP.NET

ASP.NET is helemaal geen taal, maar een platform.

[Verwijderd]

whoami schreef op zaterdag 27 januari 2007 @ 17:32:
Mijn antwoord is best kort: klant is koning. Als de klant een volledig Unix park heeft staan, dan zou het dom zijn om voor .NET te kiezen. Afhankelijk van wat de klant wil, wat z'n budget is en wat de kennis binnen het bedrijf is, ga je gewoon de meest geschikte oplossing kiezen.

Maar ik vind dit de conclusie van het topic eigenlijk wel

[crisp]

Verwijderd schreef op zaterdag 27 januari 2007 @ 14:32:
[...]
Het belangrijkste wat PHP IDE's missen zijn inderdaad:

-> Standaard componenten (dropdownlists, checkboxlists, etc..)
[...]

Dat punt is geen gemis, gegenereerde markup zuigt gewoon
Er zijn trouwens wel PEAR (en andere) extensions voor, maar die heb ik persoonlijk ook al afgeschreven vanwege voornoemde zuigende markup

[ Voor 18% gewijzigd door crisp op 28-01-2007 01:03 ]

[flowerp]

MacWolf schreef op zaterdag 27 januari 2007 @ 17:29:
Toen ik ging werken bij mijn huidige werkgever had ik de keuze tussen C# of VB.NET en uiteindelijk is voor ons VB.NET een betere keuze, gezien de taal eigenlijk precies hetzelfde is als ASP.NET en men bij ons ook aan webontwikkeling doet.

Weet jij wel waar je het over hebt? ASP.NET is een platform, een framework, een set APIs, etc. Maar het is zeer zeker geen programmeertaal. De APIs van ASP.NET kun je gewoon aanspreken in elke .NET taal, waaronder dus C# en VB.NET.

whoami schreef op zaterdag 27 januari 2007 @ 17:32:
Mijn antwoord is best kort: klant is koning. Als de klant een volledig Unix park heeft staan [...]

Wat ik me afvraag, waarom gaat iedereen er hier op got toch altijd blind vanuit dat software altijd maatwerk is dat ontwikkeld wordt in opdracht van een klant die het dan ook zelf gaat draaien? De programmeurs van pak 'm beet Hyves gaan toch ook niet kijken wat hun 'klanten' aan hardware hebben staan? Die ontwikkelen een web applicatie, en stellen die beschikbaar voor hun klanten. De klanten werken alleen met de interface. Hyves is zelf volkomen vrij om de techniek te kiezen, zowel kwa OS, Software als hardware.

Relevant aan deze thread waarin werd vermeld dat Hyves deels in PHP was gemaakt; daar zijn de programmeurs van Hyves ook niet super happy mee. Hyves is echter niet vanaf het begin af aan opgezet als mega site. Het eigenlijke doel van het bedrijf erachter was om iets met software op mobiele telefoons te doen. De website hyves was maar een heel klein pruts dingetje voor erbij. Toen het opeens ging groeien hebben ze er wat bij geprogrammeerd, en toen het opeens immens ging groeien nog wat meer. Toen zaten ze er echter al te diep in om nog even naar een meer profesionele omgeving om te schakelen (die eigenlijk beter bij Hyves zou passen, ondanks dat ze inderdaad geen zware business logica draaien).

Quote van Koen Kam zelf: "php is een kut taaltje"

crisp schreef op zondag 28 januari 2007 @ 01:01:
[Het belangrijkste wat PHP IDE's missen zijn inderdaad:

-> Standaard componenten]

Dat punt is geen gemis, gegenereerde markup zuigt gewoon

(Web) Componenten zijn -veel- meer dan alleen een soort slimme HTML generators...

[ Voor 62% gewijzigd door flowerp op 28-01-2007 01:44 ]

[whoami]

Wat ik me afvraag, waarom gaat iedereen er hier op got toch altijd blind vanuit dat software altijd maatwerk is dat ontwikkeld wordt in opdracht van een klant die het dan ook zelf gaat draaien?

Dat is niet zo; de vraag van de topicstarter is echter:

Als we kijken naar het imago (vooral naar klanten toe, maar ook voor je persoonlijke ontwikkeling als ontwikkelaar), ...

Ik ben het natuurlijk wel met je eens dat er ook nog wel wat anders is dan maatsoftware; maar ook dan ga je een keuze maken op basis van het platform waar je applicatie dient op de draaien, het meest gebruikte platform van je doelgroep, etc...
Als het gaat over zoiets als Hyves, ga je toch ook kijken naar de kennis die in huis is bij je personeel / ontwikkelaars ? Naar de kosten en de baten van het platform die je wil gebruiken, etc...

[Erkens]

flowerp schreef op zondag 28 januari 2007 @ 01:29:
Relevant aan deze thread waarin werd vermeld dat Hyves deels in PHP was gemaakt; daar zijn de programmeurs van Hyves ook niet super happy mee. Hyves is echter niet vanaf het begin af aan opgezet als mega site. Het eigenlijke doel van het bedrijf erachter was om iets met software op mobiele telefoons te doen. De website hyves was maar een heel klein pruts dingetje voor erbij. Toen het opeens ging groeien hebben ze er wat bij geprogrammeerd, en toen het opeens immens ging groeien nog wat meer. Toen zaten ze er echter al te diep in om nog even naar een meer profesionele omgeving om te schakelen (die eigenlijk beter bij Hyves zou passen, ondanks dat ze inderdaad geen zware business logica draaien).

Quote van Koen Kam zelf: "php is een kut taaltje"

maw, ze hadden gewoon onvoldoende kennis van PHP, en er was totaal niet nagedacht over de applicatie, tja, lees nu je verhaal opnieuw en vervang PHP door bijvoorbeeld Java

[Voutloos]

Who the fuck is Koen Kam? Sinds wanneer is hij dé autoriteit, de spirituele alleswetende guru?
Ook met PHP kan je goed en professioneel bezig zijn, als je maar - net als bij andere talen/platformen - enige gedegen kennis hebt en een redelijk ontwerp maakt waarbij je ook een beetje aan de toekomst (groei) denkt.

[Verwijderd]

Artikels zoals dit voorspellen natuurlijk niets goeds voor PHP ivm security:
http://developers.slashdo...e.pl?sid=06/12/14/0410240

[Janoz]

@Erkens: Zou het heel misschien wel eens tot je door gedrongen zijn dat het hier niet gaat over een gebrekkige kennis van PHP van de ontwikkelaars van Hyves, maar om een gebrekkige kennis van andere platformen bij jou?

@Voutloos: Koen Kam is gewoon iemand die in de dagelijkse praktijk probeert een grote site draaiende te houden. Een ervarings deskundige dus. Ik denk dat je je meer aan kunt trekken van hem dan van welk willekeurige andere php-fan boy die enkel wat tegen het proffesionele aan heeft lopen hobbyen.

Je kunt je ontwerp nog zo fantastisch neerzetten, maar als je platform er gewoon niet in faciliteert houdt het op een gegeven moment gewoon echt op.

[Voutloos]

Tja, ik zeg dan ook nergens dat ik me iets aantrek van 'andere php-fan boys die enkel wat tegen het professionele aan lopen hobbyen'.

[Erkens]

Janoz schreef op zondag 28 januari 2007 @ 12:19:
@Erkens: Zou het heel misschien wel eens tot je door gedrongen zijn dat het hier niet gaat over een gebrekkige kennis van PHP van de ontwikkelaars van Hyves, maar om een gebrekkige kennis van andere platformen bij jou?

pardon? wie ben jij om dat te zeggen? wat weet jij nu over mijn kennis? man doe eens normaal, je bent hier verdomme een "voorbeeld" met die rode kleur van je, dan dien je niet zo te flamen en te trollen

[Janoz]

Erkens schreef op zondag 28 januari 2007 @ 12:29:
[...]

pardon? wie ben jij om dat te zeggen? wat weet jij nu over mijn kennis? man doe eens normaal, je bent hier verdomme een "voorbeeld" met die rode kleur van je, dan dien je niet zo te flamen en te trollen

Ten eerste vraag ik me gewoon hardop iets af, en ten tweede verdedig ik een groep ontwikkelaars die van onkunde beschuldigd worden, enkel omdat ze kritiek uiten op het platform waarmee ze dagelijks mee werken.

[Erkens]

Janoz schreef op zondag 28 januari 2007 @ 12:36:
[...]


Ten eerste vraag ik me gewoon hardop iets af, en ten tweede verdedig ik een groep ontwikkelaars die van onkunde beschuldigd worden, enkel omdat ze kritiek uiten op het platform waarmee ze dagelijks mee werken.

Right, en waar kom ik naar voren in dat plaatje? juist, nergens voor nodig om mijn kennis in twijfel te stellen...
Je kent me niet eens, waarom toch dergelijke uitspraken doen?

overigens werk ook ik vrij veel met o.a. PHP op mijn werk, en ja ook ik vervloek het soms, maar als je professioneel bezig wilt zijn is het gewoon niet slim om niet goed na te denken over je applicatie, als je er dan steeds wat bij "hacked" dan krijg je een bende ja, welke taal je ook gebruikt.

[Janoz]

Ik twijfel ook niet aan je ervaring met PHP. Sterker nog, ik denk dat je een van de beste PHP-ers bent die in /14 rondloopt. Ik twijfel echter wel aan je kennis van andere platformen. Die twijfel baseer ik op het gemak waarmee jij denkt dat je PHP en Java kunt vervangen in die quote.

[Erkens]

Janoz schreef op zondag 28 januari 2007 @ 13:19:
Ik twijfel ook niet aan je ervaring met PHP. Sterker nog, ik denk dat je een van de beste PHP-ers bent die in /14 rondloopt. Ik twijfel echter wel aan je kennis van andere platformen. Die twijfel baseer ik op het gemak waarmee jij denkt dat je PHP en Java kunt vervangen in die quote.

Lees nog eens heel goed wat ik daar heb gepost en waarop ik reageerde, dan wordt het ook duidelijk waarom ik hier Java aanhaalde (let ook op het woordje "bijvoorbeeld")
Ik had wellicht niet zijn hele post moeten aanhalen, waar het mij om ging was dus hun gebrek aan kennis mbt PHP en grote sites en zoals ik lees, hun geklungel, indien je deze kennis ook niet beschikt met bijvoorbeeld het Java of .NET platform dan ben je net zover van huis. dat bedoelde ik.

overigens heb ik voldoende kennis van het J2EE platform, en nee niet alleen in de hobby sfeer

[flowerp]

Erkens schreef op zondag 28 januari 2007 @ 11:45:
[...]maw, ze hadden gewoon onvoldoende kennis van PHP, en er was totaal niet nagedacht over de applicatie, tja, lees nu je verhaal opnieuw en vervang PHP door bijvoorbeeld Java

Tuuurlijk, dan zou het idd initieel net zo'n puinhoop zijn geworden, dat zal ik zeker niet ontkennen.

Je zal dan een structuur zien groeien die indentiek is aan wat een PHP'er zou doen: een bonte verzameling JSP pagina's zonder een algehele structuur. In elke JSP pagina worden lukraak dingen uit de request gehaald, wordt er kris kras wat Java code uitgevoerd, waarna er meestal een SQL query uitgevoerd wordt waavan er door de resultaten geittereerd wordt om HTML te outputten. Datatypes worden niet gebruikt. Request parameters zijn Strings, en als er dynamisch een query wordt opgebouwd heb je ook al geen types nodig. Het kleine beetje code waarvan men nog het benul had dat een classe handig zou zijn gebruikt dan ook maar gewoon Strings voor alles.

Geloof me, ik heb deze chaos echt voorbij zien komen

Wat is nu het verschil?

Het verschil is dat als een bedrijf met een dergelijke codebase groeit en mensen gaat inhuren. Als er dan personeel komt met een beetje verstand van Java EE, dan wordt het meteen duidelijk dat de boven geschetste aanpak niet de manier is om serieuze web applicaties te maken. En zal er direct werk verzet gaan worden om het geheel te refactoren naar een fatsoenlijk model.

Is de codebase echter PHP en gaat men nieuwe mensen inhuren, dan is de kans veel kleiner dat er iemand tussenzit die het gaat refactoren. Bovengenoemde aanpak is namelijk redelijk standaard in PHP. Grote kans dat het nieuwe personeel het op precies dezelfde wijze blijft doen en dat zo de code een chaos blijft.

Daarnaast, wil je het geheel naar een meer serieuze architectuur bouwen dan biedt Java EE (en ook ASP.NET natuurlijk) daar vele handvaten voor. PHP biedt dat gewoon niet. Nu kun je wel zeggen dat je de gehele PHP puinhoop dan maar overnieuwd schrijft in Java, maar in de praktijk gebeurd dat gewoon niet. Heb je echter een Java puinhoop, dan kun je deze wel stukje voor beetje refactoren naar een solide structuur. Business logic kan uit oude JSP pagina's gehaald worden en nieuwe pagina's kunnen via een solide MVC model opgezet worden, terwijl de oude pagina's daar gewoon naast kunnen blijven draaien.

De crux zit hem erin dat PHP eigenlijk alleen een scriptaaltje is voor de view layer. Je moet er helemaal niet complete systemen in willen gaan bouwen. Echter in de praktijk gaat bijna niemand PHP voor de view gebruiken en dan iets anders als de backend.

[japsai]

Y0ur1 schreef op zaterdag 27 januari 2007 @ 00:56:
helemaal OO (denk aan request, session en response objecten etc)

Ehm.. Die schrijf ik altijd gewoon zelf? Kan het echt niet als kinderachtig zien dat een taal niet standaard alles heeft ingebouwd..in tegendeel.

[wackmaniac]

Verwijderd schreef op zondag 28 januari 2007 @ 12:18:
Artikels zoals dit voorspellen natuurlijk niets goeds voor PHP ivm security:
http://developers.slashdo...e.pl?sid=06/12/14/0410240

Is het niet zo dat php net zo veilig is als dat je het zelf implementeerd? Ik ben alleen goed bekend met php en slechts zeer beperkt bekend met webdevelopment met java of .net, dus dit kan een hele domme opmerking zijn. Maar ik ben momenteel voor school een website aan het bekijken die in .net is gemaakt en daar zitten meer fouten in dan de gemiddelde php applicatie.

Ik ben het met je eens dat het vertrek van een dergelijke persoon bij php niet echt aanmoedigend is voor php.

Ik ben het overigens met de conclusie van whoami eens. Als de klant budget heeft voor php is dat geen enkel probleem en als de klant .net of java wil is dat maar zo. Ik ben er zelf voor om zo breed mogelijke kennis te hebben als je webdevver bent. Waar ik momenteel zelf tegenaan loop is dat er op opleidingen (althans bij mij) weinig aandacht wordt besteed aan de webdev kanten van java en dat er niet of nauwelijks aandacht wordt besteed aan .net en php. Misschien dat dit volgend jaar beter wordt als ik het webdev afstudeertraject inga

japsai schreef op zondag 28 januari 2007 @ 13:58:
[...]
Ehm.. Die schrijf ik altijd gewoon zelf? Kan het echt niet als kinderachtig zien dat een taal niet standaard alles heeft ingebouwd..in tegendeel.

Dan zou C++ ook kinderachtig zijn

[ Voor 10% gewijzigd door wackmaniac op 28-01-2007 14:11 ]

[Verwijderd]

Erkens schreef op zaterdag 27 januari 2007 @ 16:53:
Waarom zou dat (als je dat al wilt) niet kunnen dan? Je kan met PHP net zo goed desktop applicaties maken, bijvoorbeeld met php-gtk. Maar wat je vaker ziet is dat de desktop applicatie in een andere taal gemaakt is (bijvoorbeeld met XUL) en gebruikt maakt van de webservices die door PHP geleverd worden.

Kan er nou eens gestopt worden met dergelijke onzinnige uitspraken die elke keer als er een dergelijk (nutteloos) topic wordt geopend naar voren wordt geschoven.

Zoals je simpelweg geen spijker in de muur slaat met een potlood en geen web applicatie maakt met assembly, zo maak je ook geen desktop applicaties met php. Strekking: het feit dat iets kan maakt het niet automatisch geschikt.

japsai schreef op zondag 28 januari 2007 @ 13:58:
Ehm.. Die schrijf ik altijd gewoon zelf? Kan het echt niet als kinderachtig zien dat een taal niet standaard alles heeft ingebouwd..in tegendeel.

Dat is wel kinderachtig, want elke extra programmeur die op een project komt moet zodoende wegwijs worden in jouw 'framework'. Standaard ingebouwd betekend in de regel dus ook dat er makkelijker meerdere mensen op een project kunnen worden gezet.

[ Voor 23% gewijzigd door Verwijderd op 28-01-2007 14:14 ]

[Voutloos]

wackmaniac schreef op zondag 28 januari 2007 @ 14:07:
[...]
Is het niet zo dat php net zo veilig is als dat je het zelf implementeerd?

In het artikel staat:

The two issues — security problems in Web apps written in PHP, and security problems in PHP itself — are two distinct issues.

Let dus op de 2 soorten context voor 'veiligheid van taal X'. Je kan verder wel gelijk hebben, het gros van de lekken zit in PHP scripts ipv in de PHP implentatie zelf.

[ Voor 11% gewijzigd door Voutloos op 28-01-2007 14:14 ]

[JKVA]

japsai schreef op zondag 28 januari 2007 @ 13:58:
[...]


Ehm.. Die schrijf ik altijd gewoon zelf? Kan het echt niet als kinderachtig zien dat een taal niet standaard alles heeft ingebouwd..in tegendeel.

Bij .NET en J2EE spreek je niet over talen, maar over platforms. Die klassen die je noemt zitten al jaren in de Servlet API (J2EE) en zijn door miljoenen mensen over de hele wereld gebruikt. En zijn dus beter, sneller, veiliger, bruikbaarder, etc.

Ik heb ook weleens gedacht dat een platform mij in hoeken dwingt waarin ik niet wil komen. (denk ik nu nog weleens bij bepaalde frameworks) Ik raak controle kwijt en heb niet meer de touwtjes in handen.

Feit is dat je er simpelweg beter mee programmeert omdat je je code baseert op bewezen theorieen. Om maar te zwijgen over de tijdswinst die je maakt waardoor je je tijd aan andere dingen kunt besteden. Noem een willekeurige API in J2EE en het bestaat uit (tien/honderd) duizenden regens code die jij zelf niet hoeft te programmeren. En begin geen termen als bloated of traag te roepen. Die code is uitgedacht, goed en snel. En veilig, en je krijgt support. En... en... en...

Dat horen grote bedrijven graag. Dat geeft ze een gevoel van zekerheid.

[Verwijderd]

Overigens zie ik wel een plaats voor java in combinatie met php. Zoals bijvoorbeeld bij de applicatie server resin waar je php scripts in uit kan voeren. De achterkant zou je dan kunnen laten implementeren in Java en de voorkant in php. Een php-er is namelijk doorgaans een stuk goedkoper dan een 'javanist'.

[flowerp]

japsai schreef op zondag 28 januari 2007 @ 13:58:
[...]
Ehm.. Die schrijf ik altijd gewoon zelf?

Kenmerkend...

Kan het echt niet als kinderachtig zien dat een taal niet standaard alles heeft ingebouwd..in tegendeel.

-zucht- het gaat niet om de taal, maar om het platform.

Kenmerkend voor beginners dat ze niet het verschil kennen tussen deze 2 begrippen.

[misfire]

Op basis wat de TS aandraagt in de vraag zou ik geen enkel advies willen geven voor PHP, Java of .NET. Ik denk dat op het gebied van Web development dit wel de hoofdstromen zijn in technologie (Ruby On Rails kan er wellicht nog bij). Alledrie worden ze gebruikt voor veeleisende webapplicaties dus het is bewezen dat met zowel PHP, Java en .NET mooie websites kunnen worden gemaakt.

Ik denk dat PHP, Java en .NET op de volgende manieren zich van elkaar onderscheiden:

* Open source/kosten. PHP en Java zijn open source, en hier is een brede open source community voor. .NET is gesloten, hier is veel minder open source en heeft Microsoft al eerder laten zien dat ze open source initiatieven (zoals NUnit en NAnt) dwarsbomen ipv omarmen.

* One stop shopping. Bij .NET is alles van 1 vendor, en sluit alles dus (meestal) goed op elkaar aan en werkt alles op een vergelijkbare manier. Ook zijn er heel veel mensen die het op dezelfde manier doen als jij, want er zijn niet zo veel combinaties mogelijk. Bij PHP en vooral Java is het meer (uit)zoekwerk.

* Integratiemogelijkheden. Java is de integratiekoning geworden. Draait op vrijwel ieder OS, werkt met bijna ieder product, ondersteunt praktisch alle protocollen en standaarden. En dat is by design, door de primaire leverancier, niet één of ander third-party project dat al jaren achter de feiten aanloopt (lees: Mono).

* Ontwikkeling en innovatie. In zowel Java en .NET wordt erg veel geld gepompt in doorontwikkeling en innovatie. Bij Java heb je Sun, maar vergeet IBM niet (die investeren ongeveer 3 keer zo veel als Sun in Java) en andere JCP genoten, bij .NET Microsoft met een schijnbaar onuitputtelijke geldkraan. PHP ligt qua resources behoorlijk achter de andere 2.

* Leercurve. PHP is duidelijk makkelijker om te leren dan Java en .NET. Zoals in dit topic al behandeld is is er wel verschil tussen iets kunnen en iets goed kunnen. Dingen als architectuur, een goed ontwerp hebben en goed om kunnen gaan met veranderingen zijn gewoon moeilijk, of je nu in PHP werkt of niet.

Duidelijke verschillen, maar geen duidelijke winnaar. De vraag is, wat spreekt jou hierin aan?

[Erkens]

Verwijderd schreef op zondag 28 januari 2007 @ 14:11:
Kan er nou eens gestopt worden met dergelijke onzinnige uitspraken die elke keer als er een dergelijk (nutteloos) topic wordt geopend naar voren wordt geschoven.

Zoals je simpelweg geen spijker in de muur slaat met een potlood en geen web applicatie maakt met assembly, zo maak je ook geen desktop applicaties met php. Strekking: het feit dat iets kan maakt het niet automatisch geschikt.

ook jij moet eens leren lezen, want je zegt nu niks meer dan wat ik reeds gezegt heb...

Verwijderd schreef op zondag 28 januari 2007 @ 14:24:
Een php-er is namelijk doorgaans een stuk goedkoper dan een 'javanist'.

tja, als je goedkoop wil dan krijg je een PHP-er met minder ervaring, en juist daar zit het probleem en het cirkeltje is weer rond.

[flowerp]

Verwijderd schreef op zondag 28 januari 2007 @ 14:24:
Een php-er is namelijk doorgaans een stuk goedkoper dan een 'javanist'.

True, maar je krijgt waarvoor je betaald.

Een goede programmeur is niet automatisch goedkoper zodra hij in PHP programmeerd. Een php-er is goedkoper omdat het over het algemeen mindere programmeurs zijn. Iemand die serieus denkt dat scholing onzin is en dat scheiding van essentiele zaken (zoals busines logic en view code) de boel nodeloos complex maakt, die ga je toch geen vet salaris betalen?

Daarentegen, een -echt- goede programmeur is in PHP smaak nog moeilijker te krijgen dan in Java smaak en zal mischien nog wel duurder zijn ook. Goede programmeurs in PHP zijn zeldzaam, ook omdat zodra mensen echte liefhebbers zijn en verstand van zaken hebben, ze zelf ook wel inzien dat PHP niet de weg is. Bijna al deze mensen gaan dan op zoek naar een platform waar ze meer mee kunnen en dan komen ze al snel bij zoiets als .NET of Java uit. Voor web apps bieden deze gewoon zoveel meer, en er zit zoveel meer uitdaging in om alle ermee samenhangende concepten te leren.

Als we even in het midden laten of PHP goed of slecht is, dan nog is het voor de kennis hongerige die-hard coder simpelweg een saaie omgeving. Er valt weinig te ontdekken, en nog minder te leren.

Je ziet dus bij PHP een uitstroom van mensen zodra ze goed worden, en tegelijkertijd een instroom van mensen die dynamische websites willen maken, maar geen zin hebben om dingen over IT te leren en zeker niet de belangstelling hebben om technische zaken echt te willen doorgronden. Het gros van de PHP projecten zijn dan ook dingen waar het om het snelle geld gaat, en waar de robuustheid en ellegantie van de technische oplossing secundair is of zelfs helemaal niet van belang is.

In een bepaald segment zie je dan ook heel veel PHP gebruikt worden. Dit zijn dan vaak van die vergelijkings sitetjes, start pagina's en shopping portals die zelf amper functionaliteit hebben maar meer dienen om via google gevonden te worden en dan doorlinken naar de echte shopping site.

Begrijp me niet verkeerd. De economische waarde van dergelijke sites is groot, maar op technisch gebied stelt het allemaal zeer weinig voor.

Om op de originele quote van Mark terug te komen; het soort mensen dat een view in PHP kan maken, kan dat ook evenzogoed met puur JSP (dus geen JSF, taglibs, etc, maar alleen Java + HTML op de pagina). De vraag is natuurlijk of je dat wel wil...

[Verwijderd]

Erkens schreef op zondag 28 januari 2007 @ 16:27:
ook jij moet eens leren lezen, want je zegt nu niks meer dan wat ik reeds gezegt heb...

Pardon? Gedraag je even. Ik geef duidelijk aan waar de nadruk wat mij betreft zou moeten liggen: namelijk bij de juiste tool voor de juiste job. Iets wat jij in het eerder geciteerde betoog duidelijk niet doet, eerder het tegendeel.

Erkens schreef op zondag 28 januari 2007 @ 16:27:
tja, als je goedkoop wil dan krijg je een PHP-er met minder ervaring, en juist daar zit het probleem en het cirkeltje is weer rond.

Hoezo zit juist daar het probleem wanneer je php enkel inzet voor de view logica?

flowerp schreef op zondag 28 januari 2007 @ 16:27:
Een goede programmeur is niet automatisch goedkoper zodra hij in PHP programmeerd. Een php-er is goedkoper omdat het over het algemeen mindere programmeurs zijn.

Ja dat denk ik ook, en wel om de volgende reden (glad ijs):

Het aantal frameworks en standaard oplossingen is beduidend lager in php ten opzichte van .Net en Java. De kans op goede bagage is dus kleiner. Er zijn ook simpelweg minder complexe projecten uitgevoerd in php ten opzichte van .Net en Java. Dit betekent dus dat een php-er over het algemeen zich minder heeft bezig gehouden met complexe vraagstukken. Wederom is de kans op goede bagage kleiner.

En daarom denk ik dus ook dat een php-er een goedkopere arbeidskracht is aangezien de markt er minder van verwacht. Met het oog op view logica is php een uitermate geschikte taal. Dus ik zie wel heil in een mix tussen de twee (drie).

[Erkens]

Verwijderd schreef op zondag 28 januari 2007 @ 17:11:
Pardon? Gedraag je even. Ik geef duidelijk aan waar de nadruk wat mij betreft zou moeten liggen: namelijk bij de juiste tool voor de juiste job. Iets wat jij in het eerder geciteerde betoog duidelijk niet doet, eerder het tegendeel.

precies wat ik zeg dus, je kan idd niet lezen
je leest wat je wil lezen blijbaar, prima,moet jij weten natuurlijk, maar reageer dan even normaal wil je?

Ja dat denk ik ook, en wel om de volgende reden (glad ijs):

Het aantal frameworks en standaard oplossingen is beduidend lager in php ten opzichte van .Net en Java. De kans op goede bagage is dus kleiner. Er zijn ook simpelweg minder complexe projecten uitgevoerd in php ten opzichte van .Net en Java. Dit betekent dus dat een php-er over het algemeen zich minder heeft bezig gehouden met complexe vraagstukken. Wederom is de kans op goede bagage kleiner.

idd glad ijs ja, hieruit blijkt wel dat je dus weinig ervaring hebt met grote (complexe) PHP projecten, en ja daar zijn er meer van dan je denkt.
er is _geen_ verschil met betrekking tot die "complexe vraagstukken" als in welke taal of platform je ook gebruikt, jij denkt te veel bij PHP aan "simpele" websites en je vergeet naar de realiteit te kijken.

En daarom denk ik dus ook dat een php-er een goedkopere arbeidskracht is aangezien de markt er minder van verwacht.

de markt interesseerd het helemaal niet wat er gebruikt wordt, zolang het maar werkt en onderhoudt niet veel kost

[flowerp]

Verwijderd schreef op zondag 28 januari 2007 @ 17:11:
Met het oog op view logica is php een uitermate geschikte taal. Dus ik zie wel heil in een mix tussen de twee (drie).

Ik heb er nog even over nagedacht maar mischien heb je toch wel gelijk. In het verleden zagen we dat JSP's het toestonden om Java code erin te mixen. Sun ging uit van de profesionaliteit van de programmeur om het onderscheid te maken tussen view code en andere logica.

In de praktijk lukte dit echter niet. De volledige kracht van Java was beschikbaar op een JSP pagina en veel programmeurs konden de verleiding niet weerstaan hier van te snoepen in de view. Daar kwam bij dat er ook scripters bij zaten die eigenlijk te weinig van programmeren af wisten, maar omdat het toch 'allemaal java was' toch telkens probeerde om stukjes business of control logica te copy-pasten naar een JSP pagina.

Daarna is Sun gekomen met een apart taaltje voor de view: EL. Dit gecombineerd met JSTL levert voldoende expressiviteit op om alle view gerelateerde logica in uit te kunnen drukken. Tegelijk is het ook een compleet andere taal dan Java. Als jij in jouw project de rollen strak verdeeld tussen back-end en view programmeurs, dan -kunnen- de view programmeurs eenvoudig weg geen stukjes Java business logic in de pagina gaan copy pasten.

Echter, EL + JSTL is wel een duidelijk andere syntax dan 'gewoon' scripten. Hoewel het zeer eenvoudig is, zul je altijd mensen hebben die het niet willen leren. Als je nu de view logica in PHP doet (binnen een Java AS dus), dan kunnen mensen die in de view werken nog steeds niet stiekum Java business logica erin gaan zetten, maar wel de volledige syntax van een reguliere scripting taal gebruiken.

Persoonlijk denk ik nog steeds dat EL toch beter is in dit geval, maar er zouden inderdaad toepassingen kunnen zijn voor dit alternatieve scenario.

[pjonk]

Over view logica gesproken. Van ASP.NET WebForms en WebControls ben ik nou ook niet altijd even gecharmeerd. Een View Layer in PHP/ASP, Perl etc. implementeren gaat 10x sneller.
Monorail vind ik wat dat betreft wel interessant initiatief. Gebruiken .NET waar het heel sterk in is (OOP, type-safety, business logic, database-connectivity) en gebruik eenvoudige PHP like syntax van de Velocity Template Engine voor je view layer. Als extra voordeel heb je volledige controle over je HTML zodat het schrijven van W3C compliant code eindelijk mogelijk is

[flowerp]

Erkens schreef op zondag 28 januari 2007 @ 17:24:
idd glad ijs ja, hieruit blijkt wel dat je dus weinig ervaring hebt met grote (complexe) PHP projecten, en ja daar zijn er meer van dan je denkt.
er is _geen_ verschil met betrekking tot die "complexe vraagstukken" als in welke taal of platform je ook gebruikt, jij denkt te veel bij PHP aan "simpele" websites en je vergeet naar de realiteit te kijken.

Alleen al aan jouw manier van uitdrukken kun je afleiden dat jij duidelijk een wat lager opgeleid persoon bent. Jij bent klaarblijkelijk fanatiek en voor je zelf serieus bezig met PHP. Daarom voel je dan de drang om het te gaan verdedigen t.o.v. meer profesionele oplossingen.

Je moet het echter wel in perspectief zien.

Om het aan de hand van een voorbeeld uit te leggen: Ik ben sinds een half jaar fanatiek bezig met wielrennen. Ik train bijna elke dag en lees er veel over. Omdat ik nog maar pas begonnen ben, heb ik natuurlijk nog niet een super conditie. Ook is mijn fiets nog maar een simpel 2de-handsje waarvan het merk niet eens meer leesbaar is.

Nu kan ik wel zeggen dat fietsen fietsen is, dat mijn training net zo intensief is als dat van pro-renners en dat materiaal van 10.000-en euro's helemaal niet nodig is omdat ik het op mijn simpele fietsje toch ook voor elkaar krijg om die berg op te rijden.

Iedereen zal me dan natuurlijk meteen uitlachen. Een half jaartje training in m'n vrije tijd en een gammel fietsje kan natuurlijk niet op tegen mensen die dagelijks een uitgekiende en begeleide training voor hun beroep doen met gebruik van top materiaal.

Zie het ook zo met PHP. Leuk dat jij er goed mee overweg kan, en dat je jezelf in de avonduren hier wat mee bezig houdt. Probeer het echter niet te vergelijken met profesionele developers die jaren opleiding hebben genoten, nog meer jaren ervaring hebben en met top materiaal (Java EE of .NET werken). Het is gewoon een totaal ander klassement.

[Y0ur1]

flowerp schreef op zondag 28 januari 2007 @ 17:28:
[...]


Ik heb er nog even over nagedacht maar mischien heb je toch wel gelijk. In het verleden zagen we dat JSP's het toestonden om Java code erin te mixen. Sun ging uit van de profesionaliteit van de programmeur om het onderscheid te maken tussen view code en andere logica.

In de praktijk lukte dit echter niet. De volledige kracht van Java was beschikbaar op een JSP pagina en veel programmeurs konden de verleiding niet weerstaan hier van te snoepen in de view. Daar kwam bij dat er ook scripters bij zaten die eigenlijk te weinig van programmeren af wisten, maar omdat het toch 'allemaal java was' toch telkens probeerde om stukjes business of control logica te copy-pasten naar een JSP pagina.

Daarna is Sun gekomen met een apart taaltje voor de view: EL. Dit gecombineerd met JSTL levert voldoende expressiviteit op om alle view gerelateerde logica in uit te kunnen drukken. Tegelijk is het ook een compleet andere taal dan Java. Als jij in jouw project de rollen strak verdeeld tussen back-end en view programmeurs, dan -kunnen- de view programmeurs eenvoudig weg geen stukjes Java business logic in de pagina gaan copy pasten.

Echter, EL + JSTL is wel een duidelijk andere syntax dan 'gewoon' scripten. Hoewel het zeer eenvoudig is, zul je altijd mensen hebben die het niet willen leren. Als je nu de view logica in PHP doet (binnen een Java AS dus), dan kunnen mensen die in de view werken nog steeds niet stiekum Java business logica erin gaan zetten, maar wel de volledige syntax van een reguliere scripting taal gebruiken.

Persoonlijk denk ik nog steeds dat EL toch beter is in dit geval, maar er zouden inderdaad toepassingen kunnen zijn voor dit alternatieve scenario.

Vergeet niet dat het nog steeds gebeurt; het aanbrengen van scriptlets/declaraties en expressies in JSP (java code dus), het kan nog steeds. Alleen als je de dingen mooi wil oplossen en je programmeurs/jezelf wil dwingen zet je de scripting elements uit door scripting-invalid op te nemen in je deployment descriptor.

offtopic:
laat dat soort arrogante opmerkingen jegens Erkens gewoon achterwege, speel het op de bal/inhoud en niet op de persoon. Dit soort topics monden altijd weer uit in botsende egos en language-wars.

[ Voor 4% gewijzigd door Y0ur1 op 28-01-2007 18:17 ]

[Erkens]

flowerp schreef op zondag 28 januari 2007 @ 17:44:
Alleen al aan jouw manier van uitdrukken kun je afleiden dat jij duidelijk een wat lager opgeleid persoon bent. Jij bent klaarblijkelijk fanatiek en voor je zelf serieus bezig met PHP. Daarom voel je dan de drang om het te gaan verdedigen t.o.v. meer profesionele oplossingen.

quote: http://gathering.tweakers.net/forum/user_profile/92525

Beroep	loop wat rond en help af en toe eens iemand
Opleiding	iets met HBO ofzo

zegt genoeg lijkt me

Zie het ook zo met PHP. Leuk dat jij er goed mee overweg kan, en dat je jezelf in de avonduren hier wat mee bezig houdt.

in de avond uren hou ik me alleen met hobby projectjes bezig, deze kan je absoluut niet vergelijken met mijn dagelijkse werk

Probeer het echter niet te vergelijken met profesionele developers die jaren opleiding hebben genoten, nog meer jaren ervaring hebben en met top materiaal (Java EE of .NET werken). Het is gewoon een totaal ander klassement.

hier ga ik al niet eens aan beginnen om op te reageren, ik vind dat dit topic al genoeg ontspoord is naar geflame en getroll naar elkaar, ik denk dat het verstandigste is om jullie maar lekker verder te laten bekvechten hier, ik weet wel beter.

[Verwijderd]

Erkens schreef op zondag 28 januari 2007 @ 17:24:
precies wat ik zeg dus, je kan idd niet lezen
je leest wat je wil lezen blijbaar, prima,moet jij weten natuurlijk, maar reageer dan even normaal wil je?

Is het misschien als eens in je opgekomen dat je het dan wellicht heel onduidelijk hebt opgeschreven? Want wat jij vind dat er moet staan staat er simpelweg niet. Je corrigerende vingertje is dus op ze zachts gezegd ongepast.

Erkens schreef op zondag 28 januari 2007 @ 17:24:
idd glad ijs ja, hieruit blijkt wel dat je dus weinig ervaring hebt met grote (complexe) PHP projecten, en ja daar zijn er meer van dan je denkt.
er is _geen_ verschil met betrekking tot die "complexe vraagstukken" als in welke taal of platform je ook gebruikt, jij denkt te veel bij PHP aan "simpele" websites en je vergeet naar de realiteit te kijken.

Stap nu maar weer uit je Dr Phil rol, want jij echt niet waar ik aan denk. Je gebruikt wederom de stijl van argumenteren die niet correct is. Op die incorrecte stijl heb ik je in dit topic al gewezen. Het feit dat er voorbeelden zijn te noemen zegt namelijk niets.

Banken bijvoorbeeld gebruiken niet of nauwelijks php. Wanneer een bedrijf namelijk een bepaald risico ziet wordt er simpelweg niet gekozen voor php om een legio aan redenen. Denk hierbij support, bewezen technieken, etc. De kans dat een php-er dergelijke ervaring met zich mee brengt, een project voor een bank bijvoorbeeld, is dus aanzienlijk kleiner.

Erkens schreef op zondag 28 januari 2007 @ 17:24:
de markt interesseerd het helemaal niet wat er gebruikt wordt, zolang het maar werkt en onderhoudt niet veel kost

Op grond van laatste argumenten (werkt en kosten) interesseert het juist de markt wat er gebruikt wordt.

[flowerp]

pjonk schreef op zondag 28 januari 2007 @ 17:39:
Over view logica gesproken. Van ASP.NET WebForms en WebControls ben ik nou ook niet altijd even gecharmeerd. Een View Layer in PHP/ASP, Perl etc. implementeren gaat 10x sneller.

Initieel mischien wel, maar voor grotere (enterprise) projecten gaat deze aanvankelijke headstart al snel verloren. Als jij op elke pagina met de hand HTML gaat schrijven (of dat eventueel via een include doet), dan mis je bepaalde isolerende eigenschappen die het gebruik van web controls (web components in Java terminologie) juist zo interesant maken.

Zoals ik al eerder stelde, een web control is niet zomaar een HTML generator. Het is iets wat state heeft, wat bi-directionele data-bindings mogelijk maakt, wat op een universele manier events kan gooien en vangen en wat compleet generiek in de part-whole control tree past (composite design pattern).

Als jouw web applicatie enkele pagina's beslaat, waar 1 tot enkele programmeurs aan werken, dan zul je deze eigenschappen wellicht niet zo waarderen. Gaat het geheel naar enkele honderden pagina's en tientallen programmeurs dan zul je er heel blij mee zijn. Wordt jouw applicatie nog groter, dan zul je eigenlijk niet meer zonder kunnen.

Als extra voordeel heb je volledige controle over je HTML zodat het schrijven van W3C compliant code eindelijk mogelijk is

In een web applicatie wordt HTML steeds meer als de 'assembly taal van het web' gezien. Net zoals je in moderne C++ compilers helemaal niet meer de controlle -wilt- hebben over de gegenereerde assembly, zo wil je dat in web applicaties ook niet meer.

Als 1 van hun functies genereren de componenten markup. Dit stelt de page designer in staat om de pagina layout op een hoger niveau te designen. Tevens heeft het als voordeel dat hetzelfde component naar verschillende targets kan renderen. Dit is identiek aan de situatie dat er vanaf C++ code voor verschillende architecturen assembly gegenereerd kan worden.

Daarnaast heb je ook nog eens de mogelijkheid dat nieuwere versies van je componenten en/of renderkits meer optimale HTML genereren, zonder dat jij handmatig je markup hoeft aan te passen. Dit is dus een gratis winst die je krijgt door web controls/componenten te gaan gebruiken en die je misloopt door handmatig HTML te gaan zitten maken. Ook deze situatie is te vergelijken met C++ compilers. Door de jaren heen zijn deze steeds optimaler gaan compilen, zodat uit dezelfde C++ code steeds performance te krijgen was.

[Verwijderd]

flowerp schreef op zondag 28 januari 2007 @ 17:28:
Echter, EL + JSTL is wel een duidelijk andere syntax dan 'gewoon' scripten. Hoewel het zeer eenvoudig is, zul je altijd mensen hebben die het niet willen leren. Als je nu de view logica in PHP doet (binnen een Java AS dus), dan kunnen mensen die in de view werken nog steeds niet stiekum Java business logica erin gaan zetten, maar wel de volledige syntax van een reguliere scripting taal gebruiken.

Persoonlijk denk ik nog steeds dat EL toch beter is in dit geval, maar er zouden inderdaad toepassingen kunnen zijn voor dit alternatieve scenario.

Ik vind persoonlijk EL en JSTL vrij bloated: Je hebt veel view logica overhead in jsp. Neem bijvoorbeeld de choose-when-otherwise tags. Veel te veel regels xml voor zo'n simpele constructie. Wat dat betreft zit php (of ruby for that matter) vele malen beter in elkaar en is gewoon duidelijk leesbaar. Scriptlets is wat mij betreft geen alternatief, ook teveel java geprog om iets simpels voor elkaar te krijgen.

Zodoende

[flowerp]

Y0ur1 schreef op zondag 28 januari 2007 @ 17:45:
[...]
Vergeet niet dat het nog steeds gebeurt; het aanbrengen van scriptlets/declaraties en expressies in JSP (java code dus), het kan nog steeds. Alleen als je de dingen mooi wil oplossen en je programmeurs/jezelf wil dwingen zet je de scripting elements uit door scripting-invalid op te nemen in je deployment descriptor.

Precies, dat is natuurlijk ook wat ik bedoelde. In al onze nieuwe projecten is dat standaard het geval, zodat geen enkele scripter meer Java code op JSP pagina's kan gebruiken. Aanvankelijk leverde dat wel wat geklaag op van de oude garde. Voor nieuwe mensen is het echter geen enkel probleem omdat deze vanaf het begin af aan met deze methodiek werken.

[JKVA]

flowerp schreef op zondag 28 januari 2007 @ 18:06:
[...]
In een web applicatie wordt HTML steeds meer als de 'assembly taal van het web' gezien. Net zoals je in moderne C++ compilers helemaal niet meer de controlle -wilt- hebben over de gegenereerde assembly, zo wil je dat in web applicaties ook niet meer.
[...]

Gedurfde opmerking. Ik ben ook heel gecharmeerd van JSF, maar als er iets is wat ik belangrijk vindt, is het wel dat mijn uiteindelijke pagina aan webstandaarden voldoet. Dus validerende CSS en (X)HTML op het meest strikte niveau.
Ook wil ik JavaScript die in (op zijn minst) de gangbare browsers draait en wanneer JS uit staat, dat het nog steeds werkt.

Waarom wil ik dat? Omdat het dan op een enorme diversiteit aan clients kan draaien.

JSF is wat dat betreft (in dit stadium) nog verre van af en genereert nog steeds een partij troep waar je bang van wordt.
Al eens geprobeerd een paar commandlinks (100+) in een form te leggen? Krijg je gratis wagonladingen lelijke inline JS mee. Dat is ondertussen wel weer wat verbeterd, maar nog steeds ziet het er niet uit.

Nee, ik ben het wel ongeveer met je verhaal eens, maar ik wil wel op de één of andere manier controle houden over wat naar de client gestuurd wordt, zonder elke JSF component eerst te moeten herschrijven...

[pjonk]

@flowerp
Event based programming is leuk in de theorie. Alleen heeft ASP.NET een dermate complexe event-cycle dat het event-based programmeren snel verwarrend en contra-productief werkt. Event-based programming werkt prima voor desktop applicaties, maar voor webapplicaties is het niet praktisch. Het ASP.NET event-model leunt op JavaScript truukjes. Dit betekent dat je website al niet meer toegankelijk is voor clients zonder JavaScript.

JKVA schreef op zondag 28 januari 2007 @ 20:51:
[...]
Gedurfde opmerking. Ik ben ook heel gecharmeerd van JSF, maar als er iets is wat ik belangrijk vindt, is het wel dat mijn uiteindelijke pagina aan webstandaarden voldoet. Dus validerende CSS en (X)HTML op het meest strikte niveau.

Helemaal mee eens, sterker nog veel bedrijven eisen (X)HTML strict compliant website.
Op het gebied van HTML rendering slaan de standaard ASP.NET controls soms echt een pleefiguur.
Het kost gewoon enorm veel tijd om knappe HTML te genereren. Dit betekent dat je al snel eigen controls moet gaan schrijven en in dit geval neig ik om terug te gaan naar het KISS principe dus gewoon een eenvoudige HTML template merge.

[MisterData]

JKVA schreef op zondag 28 januari 2007 @ 20:51:
[...]

Gedurfde opmerking. Ik ben ook heel gecharmeerd van JSF, maar als er iets is wat ik belangrijk vindt, is het wel dat mijn uiteindelijke pagina aan webstandaarden voldoet. Dus validerende CSS en (X)HTML op het meest strikte niveau.
Ook wil ik JavaScript die in (op zijn minst) de gangbare browsers draait en wanneer JS uit staat, dat het nog steeds werkt.

Waarom wil ik dat? Omdat het dan op een enorme diversiteit aan clients kan draaien.

JSF is wat dat betreft (in dit stadium) nog verre van af en genereert nog steeds een partij troep waar je bang van wordt.
Al eens geprobeerd een paar commandlinks (100+) in een form te leggen? Krijg je gratis wagonladingen lelijke inline JS mee. Dat is ondertussen wel weer wat verbeterd, maar nog steeds ziet het er niet uit.

Nee, ik ben het wel ongeveer met je verhaal eens, maar ik wil wel op de één of andere manier controle houden over wat naar de client gestuurd wordt, zonder elke JSF component eerst te moeten herschrijven...

Het mooie is dat (in theorie, at least) je juist veel flexibeler bent als je je HTML laat genereren. Denk aan wat GMail doet: ze hebben een strakke AJAX-interface, en bieden ook een light-versie aan met (ik dacht) dezelfde functionaliteit. Ik geloof dat ze daarvoor zelf ook GWT (Google Web Toolkit) voor gebruiken; daarmee specificeer je je site in Java en wordt er een interface gegenereerd. Dat kan volledig volgens de standaarden natuurlijk.

Wat ik zelf ooit wel eens gedaan heb is een CMS gemaakt met XSLT. Je maakte je pagina dan in XML (met alle meta-informatie in tags etc) en de XSLT maakt er dan een HTML-pagina van met zoveel toeters en bellen als je wil. met een andere set xslt-bestanden zag de site er ineens heel anders uit

HTML wordt misschien niet de assembly van het web, maar het wordt wel steeds meer een resultaat van automatische generatie

[ Voor 3% gewijzigd door MisterData op 28-01-2007 21:28 ]

[roy-t]

Ik vind eigenlijk dat sinds versie 2.0 (en bijna 3.0) van het .NET platform, .NET een erg goede reputatie begint te krijgen onder devvers, de beginner support is zo uitgebreid en goed geregeld met de Express Editions van de .net talen (C#, VB, C++, Java.Net) ook is er een extra nieuwe toegankelijkere MSDN: www.learnvisualstudio.net en met tools zoals VisualWebDeveloper heb ik binnen een half uur een website kunnen opzetten die communiceert met een SQL Database (als ze nog alleen het installeren van de server wat duidelijker maakte...)

Dit maakt .NET in mijn ogen jong en fris, een goed platform om op te ontwikkelen.

Java begint eidenlijk van zijn "ik ben log" imago af te komen, en is op internet een gevestigerde (? nederlands anyone? ) taal aan het worden, die goed door ontwikkeld.

*MENING* PHP moet ik eigenlijk niks van hebben, er is gewoon geen interface of wat dan ook, mijn imago van php is dat de code zo ver afstaat van wat er eigenlijk gebeurt in de interface, en dat php gemaakt wordt in plain text editors zoals kladblok. En ja ik ben gewoon erg visueel ingesteld *MENING*

Als ik een klant was die een groot systeem wilde kopen zou ik nu zelf (persoonlijk) voor .NET gaan omdat het fris aanvoelt. Maar erg ver ligt het niet van elkaar af (er is zelfs een Java implementatie van .NET Java.NET!) Wel moet ik er bij zeggen dat ik zelf vind dat MS met de VS2005 serie de mooiste ontwikkel tools heeft die ik tot nu toe gezien heb!

edit: Antiflame Mening Tags ingevoegd!

[ Voor 3% gewijzigd door roy-t op 28-01-2007 22:13 ]

[flowerp]

JKVA schreef op zondag 28 januari 2007 @ 20:51:
JSF is wat dat betreft (in dit stadium) nog verre van af en genereert nog steeds een partij troep waar je bang van wordt.

Ben ik half met je eens. Aan de ene kant heb je gelijk. JSF is nog steeds vrij nieuw. Voorheen waren er wel wat preview versies op de markt, maar pas sinds kort (begin 2006) is de eerste versie in Java EE opgenomen.

Aan de andere kant, de JSF spec opzich zegt niets over -hoe- de componenten HTML genereren. Sterk nog, het rept eigenlijk helemaal niet met zo veel worden over HTML zelf. JSF staat als spec zo duidelijk boven HTML dat HTML eigenlijk niet meer dan slechts 1 van de mogelijke render targets is (hoewel zonder twijfel natuurlijk nu wel de belangrijkste en een verplichte target voor de standaard componenten).

Ook hangt de concrete HTML generatie af van de individuele componenten en (optioneel) hun renderkit. Componenten gebruik je dikwijls van een externe leverancier, zoals bijvoorbeeld ADF van Oracle. Er zit wel een setje standaard componenten bij JSF, maar dat zijn eigenlijk meer voorbeeld componenten.

Daarnaast is het zo dat JSF zelf een spec is en geen stuk software. De standaard JSF componenten van de Apache MyFaces implementatie genereerd dan ook iets andere HTML dan de standaard JSF componenten van de SUN RI implementatie. Weer is dit niet anders dan bij de C++ compilers. Met dezelfde source code en de zelfde target (stel x86) genereren gcc, cl.exe en icl.exe natuurlijk ook niet 100% identieke assembly.

Blijft natuurlijk het punt staan dat dit automatisch beter zal worden. Je hoeft bij wijze van spreke alleen je Java implementatie te updaten en de HTML die gegenereerd wordt zal meteen beter worden. Het is dus vooral een issue wat je applicatie ook toekomst vaster zal maken.

[Verwijderd]

therat10430 schreef op zondag 28 januari 2007 @ 21:54:

Als ik een klant was die een groot systeem wilde kopen zou ik nu zelf (persoonlijk) voor .NET gaan omdat het fris aanvoelt. Maar erg ver ligt het niet van elkaar af (er is zelfs een Java implementatie van .NET Java.NET!) Wel moet ik er bij zeggen dat ik zelf vind dat MS met de VS2005 serie de mooiste ontwikkel tools heeft die ik tot nu toe gezien heb!

J# zit standaard in Visual Studio, maar is altijd (en dat vinden alle java devvers en .net devvers) gelukkig een ondergeschoven kind geweest. Want J# schiet echt niet op...

[crisp]

Ik pak even de eerste reactie maar zal ook ingaan op de rest van de discussie mbt dit onderwerp

flowerp schreef op zondag 28 januari 2007 @ 01:29:
[...]
(Web) Componenten zijn -veel- meer dan alleen een soort slimme HTML generators...

True, en ze hebben ook zeker waarde voor bepaalde applicaties, maar naar mijn mening niet voor web-applicaties bedoelt voor het internet en web-pagina's.

Punt is dat een browser-omgeving geen homogene omgeving is, verre van dat zelfs. Vanuit dat oogpunt alleen al is het gewoon niet handig om de hele frontend-laag weg te abstraheren naar een black box; je krijgt dan echt monsterlijke gedrochten zoals volledige afhankelijkheid van javascript, serverside UA-sniffing en/of least-dominor gebaseerde markup en scripts.

Verder heeft de markup weer een relatie met je CSS en soms custom javascripts, dus een update van je web-component kan betekenen dat je ook je CSS of je clientside scripts weer zal moeten aanpassen. Erg toekomst-vast is het dus niet, tenzij je web-component een soort van templates ondersteund voor de front-end code.

Overigens kom ik zelf uit de back-end wereld (transactie-systemen voor banken en verzekeraars op mainframes en as/400) en ben ik gaandeweg steeds verder 'naar voren' gegaan via Java (websphere) en nu PHP met een bovenmatige interesse in browser-omgeving, markup en client-side scripting. Op de een of andere manier vind ik het laatste veel leuker aangezien daar nog behoorlijk veel diversiteit in zit en dus meer uitdagingen

[flowerp]

crisp schreef op zondag 28 januari 2007 @ 23:18:
Punt is dat een browser-omgeving geen homogene omgeving is, verre van dat zelfs. Vanuit dat oogpunt alleen al is het gewoon niet handig om de hele frontend-laag weg te abstraheren naar een black box;

Dat weet ik eigenlijk zo net nog niet. Een groot voordeel is natuurlijk dat deze black box wel degelijk support kan hebben voor zeer diverse browsers. Op het moment dat ik, stel, een progressbar op een pagina wil plaatsen dan wil ik op dat moment helemaal niet bezig zijn met een IE versie 5 of 6, of een Firefox zus of Safari zo.

Als ik op de pagina handmatig support voor diverse browsers zou moeten inbouwen, dan leidt dat al snel af van mijn eigenlijke doel m.b.t. die layout.

Daarnaast zorgt het systeem van abstracte UIComponents in JSF ervoor dat generieke begrippen in een user interface ook een gemeenschappelijk component hebben. Zo heb je b.v. de UISelectOne, die het begrip voorstelt dat de gebruiker 1 keuze kan maken. Dit kan concreet een HtmlSelectOneListbox zijn of een HtmlSelectOneMenu etc. Code voor gedrag hou je zo centraal, en de concrete rendering kan verschillen. Dit is zeer handig in de praktijk waar mensen de ene dag willen dat de user een keuze kan maken door een linkje te clicken, het de volgende dag een vinkje moet zijn en de dag daarna weer een radio button. Bij handmatig HTML is het gewoon meer werk om die dingen te veranderen, bij JSF is het zeer eenvoudig.

Een ander voordeel is dat de component schrijver normaal altijd ervan uit gaat dat het component geheel universeel overal gebruikt kan worden. Met handmatige HTML maak je vaak veronderstellingen, bijvoorbeeld dat het ding wat je maakt maar 1 keer op de pagina kan voorkomen.

Natuurlijk kan een component schrijver deze regels net zo goed aan haar laars lappen, maar het komt minder voor. De reden hiervoor is simpel; de component schrijver ontwikkeld haar component meestal als een afzonderlijk, opzichzelf staand iets. Bij handmatige HTML maak je iets meestal direct in de context van een bepaalde pagina. Het JSF systeem biedt componenten hulp bij de generatie van unieke en systematische IDs (oa d.m.v. naming containers). Bedenk overigens wel dat de beste componenten schrijvers zelf de mensen zijn die juist het meeste direct in HTML hebben gewerkt en daar ook het meest verstand van hebben.

Verder heeft de markup weer een relatie met je CSS en soms custom javascripts, dus een update van je web-component kan betekenen dat je ook je CSS of je clientside scripts weer zal moeten aanpassen.

Een (goed) component heeft een public API. In deze API staat beschreven welke elementen met CSS te stylen zijn. Bij updates zal dit zeker niet veranderen. Is een verandering toch nodig, dan zie je vaak dat men gewoon een nieuwe component maakt wat ter vervanging dient van de oude. Zo zul je dan bijvoorbeeld een HTMLDataGrid2 krijgen als de public API veranderingen code breekt die een HTMLDataGrid gebruikt.

Wanneer jij direct inhakt op de gegenereerde code, dan kan het inderdaad voorkomen dat met een update dingen breken. Feitelijk is dit niet anders dan dat je in bijvoorbeeld Windows ongedocumenteerde functies in je eigen code gaat aanroepen, of dat je in Java d.m.v.reflection waardes van private fields in library classes gaat gebruiken.

Helaas is de wereld natuurlijk niet altijd zo perfect. Javascript hacks voor bepaald gedrag is soms nodig, en het direct manipuleren van request parameters is ook niet altijd te voorkomen. Toch denk ik zeker dat deze manier van aanpak zeker een zeer goede stap in de richting is. Er is nog veel voor verbetering vatbaar, maar zowel ASP.NET als Java EE zijn er tenminste mee bezig.

[JKVA]

flowerp schreef op maandag 29 januari 2007 @ 00:45:
[...]


Dat weet ik eigenlijk zo net nog niet. Een groot voordeel is natuurlijk dat deze black box wel degelijk support kan hebben voor zeer diverse browsers. Op het moment dat ik, stel, een progressbar op een pagina wil plaatsen dan wil ik op dat moment helemaal niet bezig zijn met een IE versie 5 of 6, of een Firefox zus of Safari zo.

Als ik op de pagina handmatig support voor diverse browsers zou moeten inbouwen, dan leidt dat al snel af van mijn eigenlijke doel m.b.t. die layout.

Daarnaast zorgt het systeem van abstracte UIComponents in JSF ervoor dat generieke begrippen in een user interface ook een gemeenschappelijk component hebben. Zo heb je b.v. de UISelectOne, die het begrip voorstelt dat de gebruiker 1 keuze kan maken. Dit kan concreet een HtmlSelectOneListbox zijn of een HtmlSelectOneMenu etc. Code voor gedrag hou je zo centraal, en de concrete rendering kan verschillen. Dit is zeer handig in de praktijk waar mensen de ene dag willen dat de user een keuze kan maken door een linkje te clicken, het de volgende dag een vinkje moet zijn en de dag daarna weer een radio button. Bij handmatig HTML is het gewoon meer werk om die dingen te veranderen, bij JSF is het zeer eenvoudig.

Een ander voordeel is dat de component schrijver normaal altijd ervan uit gaat dat het component geheel universeel overal gebruikt kan worden. Met handmatige HTML maak je vaak veronderstellingen, bijvoorbeeld dat het ding wat je maakt maar 1 keer op de pagina kan voorkomen.

Natuurlijk kan een component schrijver deze regels net zo goed aan haar laars lappen, maar het komt minder voor. De reden hiervoor is simpel; de component schrijver ontwikkeld haar component meestal als een afzonderlijk, opzichzelf staand iets. Bij handmatige HTML maak je iets meestal direct in de context van een bepaalde pagina. Het JSF systeem biedt componenten hulp bij de generatie van unieke en systematische IDs (oa d.m.v. naming containers). Bedenk overigens wel dat de beste componenten schrijvers zelf de mensen zijn die juist het meeste direct in HTML hebben gewerkt en daar ook het meest verstand van hebben.


[...]


Een (goed) component heeft een public API. In deze API staat beschreven welke elementen met CSS te stylen zijn. Bij updates zal dit zeker niet veranderen. Is een verandering toch nodig, dan zie je vaak dat men gewoon een nieuwe component maakt wat ter vervanging dient van de oude. Zo zul je dan bijvoorbeeld een HTMLDataGrid2 krijgen als de public API veranderingen code breekt die een HTMLDataGrid gebruikt.

Wanneer jij direct inhakt op de gegenereerde code, dan kan het inderdaad voorkomen dat met een update dingen breken. Feitelijk is dit niet anders dan dat je in bijvoorbeeld Windows ongedocumenteerde functies in je eigen code gaat aanroepen, of dat je in Java d.m.v.reflection waardes van private fields in library classes gaat gebruiken.

Helaas is de wereld natuurlijk niet altijd zo perfect. Javascript hacks voor bepaald gedrag is soms nodig, en het direct manipuleren van request parameters is ook niet altijd te voorkomen. Toch denk ik zeker dat deze manier van aanpak zeker een zeer goede stap in de richting is. Er is nog veel voor verbetering vatbaar, maar zowel ASP.NET als Java EE zijn er tenminste mee bezig.

Jammergenoeg merk ik in de praktijk nog niet veel van die theorieen. In mijn ervaring voegt JSF toch (te) veel abstractie toe waar je naar mijn idee te weinig voor terugkrijgt.

Dat baseer ik niet op mijn eigen ervaringen met JSF, omdat ik er ondertussen al redelijk diep in zit, maar meer op de rest van mijn collega's. Ik geef bij ons op het bedrijf cursussen voor JSF en merk toch dat heeeeel veel collega's er moeite mee hebben. Vooral het nut van de (in hun ogen) complexe lifecycle ontgaat ze. En ja, ik besteed heel veel aandacht aan die lifecycle.

Nou ben ik er ook wel van overtuigd dat het beter wordt met JSF. Oracle heeft met ADF Faces een mooie stap gedaan en ook van AJAX4JSF ben ik heel gecharmeerd. Dat is namelijk abstractie waar ik wel blij van wordt.
Ook van Trinidad heb ik hoge verwachtingen. Een collega van mij is samen met Craig Mc.L. mentor van het Trinidad project bij Apache en wist te vertellen dat het momenteel één van de drukste projecten is, dus ik verwacht dat het snel is. Heb het zelf nog niet geprobeerd.

[crisp]

flowerp schreef op maandag 29 januari 2007 @ 00:45:
[...]


Dat weet ik eigenlijk zo net nog niet. Een groot voordeel is natuurlijk dat deze black box wel degelijk support kan hebben voor zeer diverse browsers. Op het moment dat ik, stel, een progressbar op een pagina wil plaatsen dan wil ik op dat moment helemaal niet bezig zijn met een IE versie 5 of 6, of een Firefox zus of Safari zo.

En dus krijg je halfbakken markup die consessies doet naar de least dominor (of erger: bepaalde browser-behavior tot standaard verheft en de rest als minderwaardig beschouwd) of serverside UA-sniffing waarbij browsers uitgesloten of verkeerd behandeld zullen worden. Verder is browser-support niet iets dat vastgelegd dient te worden in een framework, dat is een onacceptabele beperking.

Als ik op de pagina handmatig support voor diverse browsers zou moeten inbouwen, dan leidt dat al snel af van mijn eigenlijke doel m.b.t. die layout.

Daar heb je dan ook een frontend-developer voor wiens taak dat wel is. Als er 1 ding erger is dan generated clientside code dan is het wel clientside code geschreven door een serverside devver

[...]
Bedenk overigens wel dat de beste componenten schrijvers zelf de mensen zijn die juist het meeste direct in HTML hebben gewerkt en daar ook het meest verstand van hebben.

Gezien de beroerde kwaliteit van de generated code van dergelijke componenten zet ik daar mijn vraagtekens bij
Vaak zie je toch dat het inderdaad serverside goed opgezet is, MVC model volgt e.d. maar clientside is het vervolgens wel weer acceptabel dat content, opmaak en behavior met elkaar vermengt zijn?

[...]
Een (goed) component heeft een public API. In deze API staat beschreven welke elementen met CSS te stylen zijn. Bij updates zal dit zeker niet veranderen. Is een verandering toch nodig, dan zie je vaak dat men gewoon een nieuwe component maakt wat ter vervanging dient van de oude. Zo zul je dan bijvoorbeeld een HTMLDataGrid2 krijgen als de public API veranderingen code breekt die een HTMLDataGrid gebruikt.

Dus over een paar jaar zit je met een mengelmoes van HTMLDataGrid 1 t/m 10 en een framework dat voor alle 10 ondersteuning moet blijven bieden? Tsja...

Wanneer jij direct inhakt op de gegenereerde code, dan kan het inderdaad voorkomen dat met een update dingen breken. Feitelijk is dit niet anders dan dat je in bijvoorbeeld Windows ongedocumenteerde functies in je eigen code gaat aanroepen, of dat je in Java d.m.v.reflection waardes van private fields in library classes gaat gebruiken.

Feit is dat dergelijke componenten vaak toch behoorlijk beperkt zijn, zeker als je voor een hippe website of webapp net iets meer wilt.
Nogmaals: ze hebben zeker hun waarde, maar cutting edge moet je er niet van verwachten - en dus is het saai

Helaas is de wereld natuurlijk niet altijd zo perfect. Javascript hacks voor bepaald gedrag is soms nodig, en het direct manipuleren van request parameters is ook niet altijd te voorkomen. Toch denk ik zeker dat deze manier van aanpak zeker een zeer goede stap in de richting is. Er is nog veel voor verbetering vatbaar, maar zowel ASP.NET als Java EE zijn er tenminste mee bezig.

Front-end development (markup, CSS, clientside scripting) is en blijft een apart vak; het is onzin om te denken dat je dat volledig kan vervangen door een aantal componenten. Voor saaie intranet applicaties (homogene browser-omgeving!) is het vaak prima en kan het een hoop tijd besparen, maar voor internet toepassingen is het nog niet eens een klein stapje in de goede richting.

Een goed component heeft naar mijn mening templates voor de clientside code die vrijelijk aan te passen zijn en tevens ook goed beschreven zijn (dus geen 86KB aan obfuscated javascript). Verder moet het idee dat clientside coden makkelijk is en er door een serverside devver wel bij gedaan kan worden ook maar eens naar het land der fabelen verwezen worden. Als je serieus een goede internet applicatie wil neerzetten dan moet de frontend zeker niet de sluitpost zijn...

[Grijze Vos]

Ik snap niet zo goed waarom de vergelijking wordt gemaakt tusse JSF en plain HTML. Er wordt hier door de java-fanboys (laat ik dan ook maar populaire termen bezigen) net gedaan alsof je met PHP in een professionele omgeving direct HTML loopt te kloppen, wat een onzin.

Met PHP kun je net zo goed op een fatsoenlijke gestructureerde manier middels goede frameworks developen. Volgens mij heb je een behoorlijk gebrek aan visie als je dat niet zelf in kunt zien. En dan die opmerkingen over het niveau van php programmeurs, kom op zeg, het niveau in de IT is overal bedroevend laag (gemiddeld gezien), of je nu naar PHPers kijkt of naar JAVA-mensen.

Flowerp> Het kan juist interessant zijn om in een PHP omgeving te werken, de frameworks moeten nog gebouwd worden, en juist mensen met kennis van hoe het niet moet (bijv. foute keuzes in JAVA) kunnen die kennis benutten bij het construeren van PHP frameworks. Ik denk zelfs dat de uitdaging die daar ligt veel groter is dan het in elkaar hacken van wat componenten die door iemand anders bedacht zijn. Maar goed, to each their own, je kunt het allicht wat minder denigrerend brengen.

De vraag is niet of het kan met PHP, de vraag is zullen er in de komende tijd bedrijven het interessant genoeg vinden om zelf aan fatsoenlijke frameworks te werken. Het zou kunnen, maar ik vermoed dat Python en Ruby een deel van de aandacht zullen opsnoepen, waardoor PHP niet echt zal kunnen rekenen op de support die het nodig heeft.

[JKVA]

Grijze Vos schreef op maandag 29 januari 2007 @ 10:25:
Ik snap niet zo goed waarom de vergelijking wordt gemaakt tusse JSF en plain HTML. Er wordt hier door de java-fanboys (laat ik dan ook maar populaire termen bezigen) net gedaan alsof je met PHP in een professionele omgeving direct HTML loopt te kloppen, wat een onzin.

Met PHP kun je net zo goed op een fatsoenlijke gestructureerde manier middels goede frameworks developen. Volgens mij heb je een behoorlijk gebrek aan visie als je dat niet zelf in kunt zien. En dan die opmerkingen over het niveau van php programmeurs, kom op zeg, het niveau in de IT is overal bedroevend laag (gemiddeld gezien), of je nu naar PHPers kijkt of naar JAVA-mensen.

Flowerp> Het kan juist interessant zijn om in een PHP omgeving te werken, de frameworks moeten nog gebouwd worden, en juist mensen met kennis van hoe het niet moet (bijv. foute keuzes in JAVA) kunnen die kennis benutten bij het construeren van PHP frameworks. Ik denk zelfs dat de uitdaging die daar ligt veel groter is dan het in elkaar hacken van wat componenten die door iemand anders bedacht zijn. Maar goed, to each their own, je kunt het allicht wat minder denigrerend brengen.

De vraag is niet of het kan met PHP, de vraag is zullen er in de komende tijd bedrijven het interessant genoeg vinden om zelf aan fatsoenlijke frameworks te werken. Het zou kunnen, maar ik vermoed dat Python en Ruby een deel van de aandacht zullen opsnoepen, waardoor PHP niet echt zal kunnen rekenen op de support die het nodig heeft.

Ik zie het niet gebeuren, simpelweg door keuzes in de taal die het niet geschikt maken voor bedrijfskritische systemen, zoals dat het een scripttaal is en niet strong typed. Dat vind ik persoonlijk het grootste gemis aan PHP.

edit:

Tel daar het imago van PHP bij op...

[ Voor 1% gewijzigd door JKVA op 29-01-2007 10:34 . Reden: ff iets vergeten ]

[Janoz]

De vraag is wel degelijk of bepaalde dingen wel in php kunnen. Het is niet enkel de frameworks die missen, maar ook bepaalde platform functionaliteiten. Php heeft bijvoorbeeld enkel request scope. Er is geen application, session of page scope. Dat maakt ontwikkeling wel redelijk atomair en simpel, maar maakt andere dingen onmogelijk. Je kunt niet objecten en gegevens uitwisselen tussen verschillende threads. Ze weten niet eens van elkaar dat ze bestaan omdat ze allemaal in hun eigen php instantie draaien.

Het probleem is een beetje dat commentaar op php over het algemeen door veel mensen als denigrerend of neerbuigend wordt ervaren, zonder dat er daadwerkelijk op de argumenten ingegaan wordt. Ik ben php echt niet aan het afzeiken. Ik heb een ruime ervaring met beide platformen (java en php) en vind daarom dat ik een goede beoordeling kan maken.

[Grijze Vos]

Janoz schreef op maandag 29 januari 2007 @ 11:02:
De vraag is wel degelijk of bepaalde dingen wel in php kunnen. Het is niet enkel de frameworks die missen, maar ook bepaalde platform functionaliteiten. Php heeft bijvoorbeeld enkel request scope. Er is geen application, session of page scope. Dat maakt ontwikkeling wel redelijk atomair en simpel, maar maakt andere dingen onmogelijk. Je kunt niet objecten en gegevens uitwisselen tussen verschillende threads. Ze weten niet eens van elkaar dat ze bestaan omdat ze allemaal in hun eigen php instantie draaien.

Dat is inderdaad iets waar PHP aan mag (moet) werken. Maar toch, met session variables kun je al een heel eind komen met het creeren van een session scope. (Je kunt enigzins objecten daarin kwijt als dat nodig is.)

Page scope is niet expliciet aanwezig, maar (wat ik er zo van lees na wat googlen) is dat niet zo'n grote ramp. De application scope is dan nog het grootste probleem, maar zelfs dat is op te lossen met Shared Memory Management en een C++ applicatie. Uiteraard wil je dat hier iets fatsoenlijks voor komt vanuit PHP zelf, maar gewoon om aan te geven dat het wel kan.

Het probleem is een beetje dat commentaar op php over het algemeen door veel mensen als denigrerend of neerbuigend wordt ervaren, zonder dat er daadwerkelijk op de argumenten ingegaan wordt. Ik ben php echt niet aan het afzeiken. Ik heb een ruime ervaring met beide platformen (java en php) en vind daarom dat ik een goede beoordeling kan maken.

Oh, ik kan me absoluut vinden in jouw posts hoor, maar sommige anderen:

"Samengevat richt PHP zich meer op de prutser, en Java/.NET zich meer op de profesional."

"Alleen al aan jouw manier van uitdrukken kun je afleiden dat jij duidelijk een wat lager opgeleid persoon bent."

Dat soort opmerkingen kan ik goed ziek van worden hoor. Ik kan ook wel mensen gaan afzeiken en zeggen dat hun HBO opleiding geen fuck waard is 'want ik doe lekker universiteit', kom op zeg, we zijn geen kleuters, en we weten allemaal dat naast je studie je eigen vorming in de IT net zo belangrijk is.

PHP is zeker nog geen full-fledged platform met support voor intensieve buseniss logic, de vraag is of ze die in de toekomst wel gaan leveren. Als ik af en toe zie hoe die club kan ruzien over kleine implementatie details vraag ik me af of ze ooit toekomen aan belangrijke toevoegingen zoals bovengenoemde scope issues. M'goed, ik heb nog niet eens de tijd gehad het afgelopen half jaar om ook maar iets te lezen over PHP6, dus ik heb geen idee wat ze in store hebben voor ons de komende tijd.

[Janoz]

Grijze Vos schreef op maandag 29 januari 2007 @ 11:30:
Page scope is niet expliciet aanwezig, maar (wat ik er zo van lees na wat googlen) is dat niet zo'n grote ramp. De application scope is dan nog het grootste probleem, maar zelfs dat is op te lossen met Shared Memory Management en een C++ applicatie. Uiteraard wil je dat hier iets fatsoenlijks voor komt vanuit PHP zelf, maar gewoon om aan te geven dat het wel kan.

Maar werken met shared memory is bij lange na niet transparant. Daarnaast is het een half-half oplossing net als bij sessies. Je zult nooit bijvoorbeeld een irc of ftp connectie op kunnen slaan in je sessie (of application scope). De reden dat dit niet kan komt door een fundamentele keuze die op dag 0 gemaakt is. Elk script draait in zijn eigen procesje en geen van die procesjes weet iets van de andere procesjes.

Oh, ik kan me absoluut vinden in jouw posts hoor, maar sommige anderen:

"Samengevat richt PHP zich meer op de prutser, en Java/.NET zich meer op de profesional."

"Alleen al aan jouw manier van uitdrukken kun je afleiden dat jij duidelijk een wat lager opgeleid persoon bent."

Dat soort opmerkingen kan ik goed ziek van worden hoor. Ik kan ook wel mensen gaan afzeiken en zeggen dat hun HBO opleiding geen fuck waard is 'want ik doe lekker universiteit', kom op zeg, we zijn geen kleuters, en we weten allemaal dat naast je studie je eigen vorming in de IT net zo belangrijk is.

Daar heb je gelijk in. Die persoonlijke vorming echter betekend wel dat je open staat voor argumenten. Te vaak zie je bij mensen een "met php kan alles wat anderen ook kunnen" zonder dat ze kennis hebben van die andere platformen. De opmerking dat php-ers prutsers zijn is natuurlijk niet per definitie waar, maar als je de gemiddelde userbase van php naast de gemiddelde userbase van j2ee zet, dan denk ik dat die opmerking de plank niet volledig mis slaat.

PHP is zeker nog geen full-fledged platform met support voor intensieve buseniss logic, de vraag is of ze die in de toekomst wel gaan leveren. Als ik af en toe zie hoe die club kan ruzien over kleine implementatie details vraag ik me af of ze ooit toekomen aan belangrijke toevoegingen zoals bovengenoemde scope issues. M'goed, ik heb nog niet eens de tijd gehad het afgelopen half jaar om ook maar iets te lezen over PHP6, dus ik heb geen idee wat ze in store hebben voor ons de komende tijd.

Scope issues zijn maar een voorbeeld. Er zijn nog vele andere onderdelen die in php in vergelijking met het j2ee en het .net platform.

[Grijze Vos]

Janoz schreef op maandag 29 januari 2007 @ 11:51:
Maar werken met shared memory is bij lange na niet transparant. Daarnaast is het een half-half oplossing net als bij sessies. Je zult nooit bijvoorbeeld een irc of ftp connectie op kunnen slaan in je sessie (of application scope). De reden dat dit niet kan komt door een fundamentele keuze die op dag 0 gemaakt is. Elk script draait in zijn eigen procesje en geen van die procesjes weet iets van de andere procesjes.

Klopt. (Het werk voor de PHP crew is ook niet af. )

Daar heb je gelijk in. Die persoonlijke vorming echter betekend wel dat je open staat voor argumenten. Te vaak zie je bij mensen een "met php kan alles wat anderen ook kunnen" zonder dat ze kennis hebben van die andere platformen. De opmerking dat php-ers prutsers zijn is natuurlijk niet per definitie waar, maar als je de gemiddelde userbase van php naast de gemiddelde userbase van j2ee zet, dan denk ik dat die opmerking de plank niet volledig mis slaat.

Klopt, maar dat is natuurlijk wel een scheve vergelijking als je praat over professioneel gebruik. Dit topic gaat niet over de gemiddelde gebruikers, maar over die mensen die aan de bovenkant zitten van de gebruikersgroepen (althans, zo interpreteerde ik het topic.) Ik snap waar het sentiment vandaan komt, ikzelf heb in mijn eerste stapjes als php'er ook flink wat fouten gemaakt, dankzij de ontzettend slechte voorbeelden die overal te vinden zijn. Sites als phpfreakz e.a. zijn echt om te gruwelen als het om code-voorbeelden gaat. Maar nogmaals, we praten hier niet over de gemiddelde groep developers.

Scope issues zijn maar een voorbeeld. Er zijn nog vele andere onderdelen die in php in vergelijking met het j2ee en het .net platform.

Dat kan best. Ikzelf heb weinig ervaring met j2ee en .net, dus kan daar niet ontzettend goed over oordelen. Ik vind het overigens dan best vreemd dat tot nu toe jij de enige bent die met een goed voorbeeld is gekomen (scoping), terwijl voor de rest eigenlijk alleen in dit topic is gezeurd over het niveau van php-developers, en wat gepraat is over frameworks en hoe geweldig deze frameworks zijn voor de gemiddelde java-developer om zo gestructureerde code te kunnen uitpoepen.

[Verwijderd]

Grijze Vos schreef op maandag 29 januari 2007 @ 12:28:
Dat kan best. Ikzelf heb weinig ervaring met j2ee en .net, dus kan daar niet ontzettend goed over oordelen. Ik vind het overigens dan best vreemd dat tot nu toe jij de enige bent die met een goed voorbeeld is gekomen (scoping),

Het was nog niet expliciet benoemt, maar het is bij de meeste hier toch wel bekend dat php een aantal tekortkomingen heeft. Maar omdat php-ers nou eenmaal om deze tekortkomingen heen weten te programmeren is het wellicht interressanter om te kijken naar andere aspecten. En dan komen we bij je 'gezeur'/'gepraat'.

Grijze Vos schreef op maandag 29 januari 2007 @ 12:28:
terwijl voor de rest eigenlijk alleen in dit topic is gezeurd over het niveau van php-developers, en wat gepraat is over frameworks en hoe geweldig deze frameworks zijn voor de gemiddelde java-developer om zo gestructureerde code te kunnen uitpoepen.

Samenwerken is voor een project essentieel. Verschillende code stijlen en aanpakken bevorderen het samenwerken niet. En dat is nou precies dat gepraat over frameworks. Een framework zorgt ervoor dat je beter kunt samenwerken want je werkt naar een standaard aanpak toe.

[Grijze Vos]

Verwijderd schreef op maandag 29 januari 2007 @ 12:46:
Samenwerken is voor een project essentieel. Verschillende code stijlen en aanpakken bevorderen het samenwerken niet. En dat is nou precies dat gepraat over frameworks. Een framework zorgt ervoor dat je beter kunt samenwerken want je werkt naar een standaard aanpak toe.

En waar heb ik dat ontkend? Volgens mij heb ik al minstens twee keer gezegd dat die frameworks voor PHP dus gedeveloped dienen te worden, en of het vraagstuk in de TS mbt PHP dus staat of valt met de ontwikkeling van genoemde frameworks. (Onder andere, naast de taal/platform issues.)

Er kunnen nu nog 4 pagina's gevuld worden over php prutsers versus java experts, of hoe goed frameworks wel niet zijn, maar volgens mij heeft iedereen hier wel door hoe de vork in de steel zit m.b.t. deze punten.

Ik stel dan ook voor om het topic meer te stuwen in een richting die praat over de platform-specifieke problematiek wat betreft PHP, voorbeelden zoals het scoping issue. Dat is mijns inziens interessanter discussie voer.

[japsai]

flowerp schreef op zondag 28 januari 2007 @ 14:26:
[...]

Kenmerkend...

[...]

-zucht- het gaat niet om de taal, maar om het platform.

Kenmerkend voor beginners dat ze niet het verschil kennen tussen deze 2 begrippen.

Inderdaad, laten we het hebben over het 'platform' PHP (TS sprak over talen). Wat betreft de meeste genoemde gebreken kan ik me er in vinden, de applets en class-libraries zijn open, dus 'ongecontroleerd', maar ze zijn er zeker wel, misschien nog wel meer zelfs.
Over IDE gesproken, Eclipse werd genoemd als voorbeeld van een professionele omgeving voor JAVA, maar bijvoorbeeld de gevraagde OO ondersteuning kan zeker ook gebruikt worden voor PHP ontwikkeling in Eclipse.

[Y0ur1]

japsai schreef op zondag 28 januari 2007 @ 13:58:
[...]


Ehm.. Die schrijf ik altijd gewoon zelf? Kan het echt niet als kinderachtig zien dat een taal niet standaard alles heeft ingebouwd..in tegendeel.

Om nog preciezer te zijn; J2ee is native OO, PHP niet. Wat bedoel je met kinderachtig? Als die objecten, zoals session, request en reponse er al voor je zijn is dat toch makkelijk? gemak dient de programmeur.

[ Voor 21% gewijzigd door Y0ur1 op 29-01-2007 18:39 ]

[japsai]

Y0ur1 schreef op maandag 29 januari 2007 @ 18:34:
[...]


Om nog preciezer te zijn; J2ee is native OO, PHP niet. Wat bedoel je met kinderachtig? Als die objecten, zoals session, request en reponse er al voor je zijn is dat toch makkelijk? gemak dient de programmeur.

Het woord kinderachtig is niet van mij, dat werd gezegd over de afwezigheid van deze klassen in PHP. Maar als je community-gefundeerde versies van zulke klassen wilt aanvaarden zijn ze er wel hoor, alleen zoals ik al zei inderdaad niet zo statisch en zeker als hun varianten in J2EE. En inderdaad niet native, maar wat wil je daar mee zeggen? Dat ze native sneller zijn? Beter ondersteund? (Niet dat ik dat betwijfel)

Maar goed dat neemt niet weg dat er veel aan PHP OO ondersteuning verbeterd kan worden imho.

[ Voor 9% gewijzigd door japsai op 29-01-2007 18:57 ]

[Y0ur1]

japsai schreef op maandag 29 januari 2007 @ 18:45:
[...]


Het woord kinderachtig is niet van mij, dat werd gezegd over de afwezigheid van deze klassen in PHP. Maar als je community-gefundeerde versies van zulke klassen wilt aanvaarden zijn ze er wel hoor, alleen zoals ik al zei inderdaad niet zo statisch en zeker als hun varianten in J2EE. En inderdaad niet native, maar wat wil je daar mee zeggen? Dat ze native sneller zijn? Beter ondersteund? (Niet dat ik dat betwijfel)

Zoals ik al zei; gemak dient te programmeur, je hoeft het niet meer zelf te bouwen en als je sommige dingen wil aanpassen kan dat natuurlijk. Snelheid heb ik geen idee over, maar als je servlets eenmaal gecompileerd zijn gaat het supersnel, misschien niet zo snel als met php maar daar krijg je dan wel weer een heleboel voor terug. Maar ik heb nog niet zoveel ervaring met j2ee, gebruik het nu voor het eerst voor een schoolproject hea.

[Verwijderd]

Grijze Vos schreef op maandag 29 januari 2007 @ 13:00:En waar heb ik dat ontkend? Volgens mij heb ik al minstens twee keer gezegd dat die frameworks voor PHP dus gedeveloped dienen te worden, en of het vraagstuk in de TS mbt PHP dus staat of valt met de ontwikkeling van genoemde frameworks. (Onder andere, naast de taal/platform issues.)

Dude, chill
Het was geen aanval hoor. Jij vind dat de nadruk niet moet liggen op frameworks en ik denk dat je daar ongelijk in hebt. Scoping issues kennen we nu wel, evenals de matige referentie implementatie (een ref counter ipv een ref stack). Het zijn allen zaken waar omheen gepogrammeerd kan worden en voegt dus vrij weinig toe. De vraag is eerder hoe je er omheen programmeert; Vinden we met zijn allen nutteloos duur en tamelijk onbegrijpbaar het wiel opnieuw uit, of kunnen we een standaard aanpak gebruiken? En tuurlijk, het blijft een beetje een kip-ei verhaal.

[flowerp]

Grijze Vos schreef op maandag 29 januari 2007 @ 13:00:
[...]
En waar heb ik dat ontkend? Volgens mij heb ik al minstens twee keer gezegd dat die frameworks voor PHP dus gedeveloped dienen te worden, en of het vraagstuk in de TS mbt PHP dus staat of valt met de ontwikkeling van genoemde frameworks. (Onder andere, naast de taal/platform issues.)

Dus PHP heeft frameworks nodig om goed te worden. Java EE en .NET hebben die frameworks echter nu al. Waarom zou je dan wachten op PHP terwijl je ze vandaag al kunt gebruiken in Java en .NET?

[StephanL]

Ik heb altijd websites geprogrammeerd in PHP.

Een half jaar terug ben ik begonnen als junior developer in o.a. c++ en Java.In het begin dacht ik echt "Java, waarom geen php?" Nu inmiddels een half jaar later kan zeggen "Wat zit Java goed in elkaar!"
Ik heb het idee, dat het programmeren in Java veel overzichtelijker werkt en ik weet wel waarom.

Nu kan je natuurlijk zeggen, dat ligt aan de programmeur, en dat zal ook wel voor een gedeelte waar zijn, maar toch.

[faabman]

Interessant topic, even een paar stellingen eruit tillen.

Erkens schreef op zondag 28 januari 2007 @ 17:24:
de markt interesseerd het helemaal niet wat er gebruikt wordt, zolang het maar werkt en onderhoudt niet veel kost

Wat is hierbij je markt? MKB of Enterprise? Je stelling is op MKB zeker van toepassing, maar als je over Enterprise praat dan is deze stelling absoluut niet van toepassing. Daar is namelijk 1 ding het belangrijkst en dat is continuiteit. Dan een heel eind niets en dan misschien pegels.

@TS: Het zal al wel gezegd zijn (heb niet alle replies volledig doorgelezen). Het antwoord op jou vraag kan alleen worden gegevens als je je eigen doelgroep duidelijk voor ogen hebt. Ga je voor MKB applicaties (en oké, binnen het MKB kun je ook weer onderscheid maken tussen verschillende klantgroepen met verschillende verwachtingen) kies dan voor een platform wat voor de klant betaalbaar is en waarmee je relatief snel iets op kunt zetten, dat kan, voor zover mij bekend, gemakkelijk met PHP. Wil je vooral Enterprise klanten aanspreken, voor wie continuiteit belangrijker is dan kosten, dan zou ik voor Java of .NET gaan.

Anderzijds gaat het ook om hetgeen wat je voor je opdrachtgever doet. Ben je bezig met een website? Dan zijn de meer script-gerelateerde talen een uitkomst. Maak je een complete webwinkel, dan kan Java / .NET weer de betere keuze zijn.

[Verwijderd]

faabman schreef op maandag 29 januari 2007 @ 21:34:
Interessant topic, even een paar stellingen eruit tillen.


[...]
Wat is hierbij je markt? MKB of Enterprise? Je stelling is op MKB zeker van toepassing, maar als je over Enterprise praat dan en deze stelling absoluut niet van toepassing. Daar is namelijk 1 ding het belangrijkst en dat is continuiteit. Dan een heel eind niets en dan misschien pegels.

Inderdaad. En in het geval van continuiteit heb je het dus al snel over de vraag: krijgen we ondersteuning van een betrouwbaar bedrijf? Wie garandeert ons dat de gebruikte oplossing lang genoeg meegaat en ondersteunt wordt? Enzovoorts etcetera. Je komt dan in de praktijk snel uit bij oplossingen van bekende grote bedrijven zoals Microsoft (.Net) en Sun (Java), omdat die bedrijven kunnen garanderen dat hun technologie op lange termijn nog bruikbaar zal zijn en ondersteunt zal worden. Voor PHP is dat maar twijfelachtig.

Ik denk zelf dat Java in de nabije toekomst nog extra relevant wordt vanwege de platform-onafhankelijkheid en de open standaarden, maar dat valt nog te bezien.

Overigens is mijn persoonlijke mening dat de taal PHP een samenraapsel is van features uit andere talen, wat een ontzettende onoverzichtelijke zooi oplevert die aanzet tot het schrijven van slechte code. Maar dat wil NIET zeggen dat het niet soms "the right tool for the job" is.

Edit: kwam dit plaatje tegen - moest ik wel om lachen (niet de bedoeling om te flamen hoor) http://tnx.nl/php.jpg

[ Voor 4% gewijzigd door Verwijderd op 30-01-2007 00:47 . Reden: kleine toevoeging ]

[Y0ur1]

Verwijderd schreef op dinsdag 30 januari 2007 @ 00:39:
[...]


Inderdaad. En in het geval van continuiteit heb je het dus al snel over de vraag: krijgen we ondersteuning van een betrouwbaar bedrijf? Wie garandeert ons dat de gebruikte oplossing lang genoeg meegaat en ondersteunt wordt? Enzovoorts etcetera. Je komt dan in de praktijk snel uit bij oplossingen van bekende grote bedrijven zoals Microsoft (.Net) en Sun (Java), omdat die bedrijven kunnen garanderen dat hun technologie op lange termijn nog bruikbaar zal zijn en ondersteunt zal worden. Voor PHP is dat maar twijfelachtig.

Ik denk zelf dat Java in de nabije toekomst nog extra relevant wordt vanwege de platform-onafhankelijkheid en de open standaarden, maar dat valt nog te bezien.

Overigens is mijn persoonlijke mening dat de taal PHP een samenraapsel is van features uit andere talen, wat een ontzettende onoverzichtelijke zooi oplevert die aanzet tot het schrijven van slechte code. Maar dat wil NIET zeggen dat het niet soms "the right tool for the job" is.

Edit: kwam dit plaatje tegen - moest ik wel om lachen (niet de bedoeling om te flamen hoor) http://tnx.nl/php.jpg

http://tnx.nl/php Ik plaats alleen de link, verder zeg ik niks

[Verwijderd]

Hier weer even een reactie van de TS .

De reden waarom ik dit vraag is omdat ik momenteel voor de keuze sta met welke technologie verder te gaan. .NET valt momenteel af vanwege de hoge investeringskosten (ontwikkelomgeving, serverinrichting en er is totaal nog geen kennis, laat staan ervaring, aanwezig), maar ik heb zelf al wel geruime ervaring met Java (waaronder ook EJB en het Struts framework). Momenteel hebben we heel veel gedaan in PHP en ik heb geprobeerd om voor mijzelf de standaard daarin hoog te houden. PHP biedt geruime mogelijkheden om verschrikkelijk slordig te programmeren, maar als je houdt van mooie architecturen en je hebt discipline, dan kun je met PHP ook best hoogwaardig gestructureerde code schrijven (zo heb ik een eigen implementatie van het Model 2 paradigma ontwikkeld voor de structurering van de software van mijn projecten).

Echter, mijn hart heeft vanaf het begin dat ik het gebruikte gelegen bij Java. Ik vind het nog steeds een prachtige taal en nu heb ik de kans om daar voor te gaan. Ik wil mij graag verder ontwikkelen en heb het gevoel dat ik bij PHP aan het maximum zit en daarbij komt ook nog eens het veel slechtere imago van PHP.

Na het lezen van jullie vele bijdragen (waarvoor mijn dank!) en mijn eigen gevoel is mijn keuze voor Java een concreet feit.

Edit (aanvulling):
Eén van de grote voordelen van Java boven PHP is, zoals hier al reeds aangehaald, de scope functionaliteit. Hoe heerlijk is het om bijvoorbeeld bij een authenticatie een object aan te maken (met daarin bijvoorbeeld de naam van de gebruiker, het aantal logins enzovoort en om deze dan ergens op een statuspaneeltje te tonen) en deze te plaatsen in een sessiescope? In PHP moet je bij iedere (page)request deze gegevens weer ophalen.

Of stel een bepaalde functie in je applicatie mag maar door één persoon tegelijk gebruikt worden. Dan kun je dit realiseren middels de applicatiescope, terwijl je in PHP zoiets moet oplossen met bijvoorbeeld een wisselbestand of ergens in de database.

Dit zijn allemaal zaken waarvan het water me alweer in de mond loopt, als ik eraan denk .

[ Voor 23% gewijzigd door Verwijderd op 30-01-2007 09:38 ]

[Brakkie]

flowerp schreef op maandag 29 januari 2007 @ 21:20:
[...]


Dus PHP heeft frameworks nodig om goed te worden. Java EE en .NET hebben die frameworks echter nu al. Waarom zou je dan wachten op PHP terwijl je ze vandaag al kunt gebruiken in Java en .NET?

PHP heeft:

• Zend Framework MVC framework + Component framework
• Ez Components Component framework
• Cake PHP MVC framework
• Symfony MVC framework
• PHP doctrine ORM framework (alleen documentatie is up ivm met site onderhoud)
• PEAR Application repository
• Prado Component & event based framework voor php applicatie development

De meeste hiervan zijn al veel gebruikt binnen de php community. En PHP doctrine (orm mapper) heeft een veelbelovende toekomst voor zich liggen. Wanneer het gaat om het bouwen van web applicaties kan PHP met deze veel gebruikte frameworks en libraries goed meekomen.

PHP bied vrijheden die kunnen en vaak leiden tot slordig programmeren en het mixen van de verschillende lagen van een applicatie. Op andere platformen voor het bouwen van web applicaties kan dit echter ook het schijnt alleen bij php wat makkelijker te zijn. Het is de programmeur en de kennis van de programmeur die bepaald of een applicatie netjes in elkaar zit en hoe onderhoudbaar de applicatie in elkaar zit.

Kortom je kan met PHP prima applicaties bouwen die op een verantwoorde manier in elkaar zitten en er is een ruime keuze tussen verschillende frameworks.

[merauder]

Tijd voor een mening: Choose the right tool for the right job!!!!

PHP: De lokale visboer, automaterialenhandel of kroeg welke een simpele webapplicatie nodig heeft waar bijvoorbeeld de meest recente prijzen van af te lezen zijn in combinatie met bijvoorbeeld een simpel bestelsysteem. Feit is dat er voor dit soort klusjes een hoop prutsers aan het werk zijn.

.NET: Een bedrijf (sector doet er overigens niet toe) welke al voorzien is van een mooi Microsoft netwerk waar alles out of the box en met fabriekssupport al prima werkt. Zeer geschikt platform voor het intern afhandelen van o.a. interne administratieve handelingen en het naar buiten communiceren met dynamische pagina's.

Java: Perfecte taal voor netwerken en systemen die multi-platform zijn, goede support hoewel er ook vele derden er aan mee ontwikkelen. Maar hoe interessant is een platform als je met behulp van 1 taal en virtual machines ZOVEEL systemen kan bereiken.

Alle drie de platformen hebben factoren mee wat ze bij hen gebruikers gewoon populair maakt. Ik heb mijn voorkeuren, en gezien de verhitte discussies in dit topic zijn er meerderen die er zo over denken. Ik zeg er alleen bij dat ALS een taal in een situatie beter werkt, ik juist voor deze taal kies.

[Voutloos]

PHP: De lokale visboer, automaterialenhandel of kroeg welke een simpele webapplicatie nodig heeft

Tijd voor een mening: ik vind het woord 'simpel' denigrerend. Met PHP kan je ook wel complexe webapplicaties maken.

Let op: ik zeg niet dat PHP het antwoord op alles is, dat is het niet en het heeft genoeg vervelende issues/tekortkomingen. Maar kap aub eens (algemeen bedoeld) met steeds PHP en 'simpel' of 'prutser' in adem te noemen.

[JKVA]

Voutloos schreef op dinsdag 30 januari 2007 @ 13:19:
[...]
Tijd voor een mening: ik vind het woord 'simpel' denigrerend. Met PHP kan je ook wel complexe webapplicaties maken.

Let op: ik zeg niet dat PHP het antwoord op alles is, dat is het niet en het heeft genoeg vervelende issues/tekortkomingen. Maar kap aub eens (algemeen bedoeld) met steeds PHP en 'simpel' of 'prutser' in adem te noemen.

Daar wordt niet gezegd dat PHP voor prutsers is of simpel, maar dat het geschikt is voor simpelere opdrachten. En dat is ook waar. Er zijn namelijk betere tools voor de complexere jobs.

Niks denigrerends, maar gewoon kijkend naar de feiten en de praktijk waar de verschillende talen/platforms nu ingezet worden.

[Brakkie]

Daar wordt niet gezegd dat PHP voor prutsers is of simpel, maar dat het geschikt is voor simpelere opdrachten. En dat is ook waar. Er zijn namelijk betere tools voor de complexere jobs.

Dit wordt de hele tijd gezegd maar er wordt nergens benoemd voor welke complexere jobs op het gebied van het bouwen van web applicaties PHP minder geschikt is. En dit dan puur op het gebied van functionaliteit op het gebied van de taal en libraries/frameworks die ervoor beschikbaar zijn.

[Brakkie]

Verwijderd schreef op dinsdag 30 januari 2007 @ 00:39:
[...]
Inderdaad. En in het geval van continuiteit heb je het dus al snel over de vraag: krijgen we ondersteuning van een betrouwbaar bedrijf? Wie garandeert ons dat de gebruikte oplossing lang genoeg meegaat en ondersteunt wordt? Enzovoorts etcetera. Je komt dan in de praktijk snel uit bij oplossingen van bekende grote bedrijven zoals Microsoft (.Net) en Sun (Java), omdat die bedrijven kunnen garanderen dat hun technologie op lange termijn nog bruikbaar zal zijn en ondersteunt zal worden. Voor PHP is dat maar twijfelachtig.

PHP heeft ook een bedrijf achter zich wat een drijfende kracht is, namelijk Zend. Dit bedrijf heeft er alle belang bij dat PHP doorontwikkeld en ondersteund wordt. Ook kun je via Zend Support krijgen of via een van de partners die Zend wereldwijd heeft (ook in Nederland)

[JKVA]

Brakkie schreef op dinsdag 30 januari 2007 @ 15:05:
[...]


Dit wordt de hele tijd gezegd maar er wordt nergens benoemd voor welke complexere jobs op het gebied van het bouwen van web applicaties PHP minder geschikt is. En dit dan puur op het gebied van functionaliteit op het gebied van de taal en libraries/frameworks die ervoor beschikbaar zijn.

Ok, dit is volgens al wel gezegd, zelfs meerdere keren, maar bijvoorbeeld het transactiemanagement en declaratieve security in EJB. Dat zijn dingen die de kwaliteit van je systeem beter maken, dus grotere bedrijven zoals banken houden ervan.

[Verwijderd]

merauder schreef op dinsdag 30 januari 2007 @ 13:07:
Tijd voor een mening: Choose the right tool for the right job!!!!

PHP: De lokale visboer, automaterialenhandel of kroeg welke een simpele webapplicatie nodig heeft waar bijvoorbeeld de meest recente prijzen van af te lezen zijn in combinatie met bijvoorbeeld een simpel bestelsysteem. Feit is dat er voor dit soort klusjes een hoop prutsers aan het werk zijn.

.NET: Een bedrijf (sector doet er overigens niet toe) welke al voorzien is van een mooi Microsoft netwerk waar alles out of the box en met fabriekssupport al prima werkt. Zeer geschikt platform voor het intern afhandelen van o.a. interne administratieve handelingen en het naar buiten communiceren met dynamische pagina's.

Java: Perfecte taal voor netwerken en systemen die multi-platform zijn, goede support hoewel er ook vele derden er aan mee ontwikkelen. Maar hoe interessant is een platform als je met behulp van 1 taal en virtual machines ZOVEEL systemen kan bereiken.

Best aardige vergelijking, alleen sloeg je de plank compleet mis toen je .NET en Java opsplitste. .NET en Java vissen in exact dezelfde vijver qua type applicaties, bedrijven enzovoorts. Het enige verschil is dat Java applicaties vaak aan Oracle gekoppeld worden en ook redelijk vaak op linux/unix systemen komen te draaien. Maar voor de rest maakt het geen moer uit. Ik heb al zat cross platform applicaties gebouwd met .NET, geen enkel probleem en hetzelfde geldt voor fabriekssupport bij Java. Genoeg support te vinden, ook vanuit Sun.

[japsai]

Verwijderd schreef op dinsdag 30 januari 2007 @ 08:53:
Hier weer even een reactie van de TS .
...
Edit (aanvulling):
Eén van de grote voordelen van Java boven PHP is, zoals hier al reeds aangehaald, de scope functionaliteit. Hoe heerlijk is het om bijvoorbeeld bij een authenticatie een object aan te maken (met daarin bijvoorbeeld de naam van de gebruiker, het aantal logins enzovoort en om deze dan ergens op een statuspaneeltje te tonen) en deze te plaatsen in een sessiescope? In PHP moet je bij iedere (page)request deze gegevens weer ophalen.

Dat laatste hoeft niet volgens mij, wat is er tegen om zo'n user-object zichzelf te laten serializen (en omgekeerd) naar de sessie-store (t.o.v. sessie-scope) ? Ok ik kan wel wat argumenten bedenken, omslachtig(er) bijvoorbeeld, maar het verschil lijkt me wat kleiner dan dit voorbeeld deed lijken.

misschien raak ik de grote lijn een beetje kwijt

@Janoz: Ok, weer wat bijgeleerd

[Janoz]

Een reden tegen het serializen is dat er race problemen op kunnen treden. Bij Java en .net is er 1 sessie object bij de gebruiker. Weet je als client 5 request tegelijk te doen, dan werken alle 5 requests met dezelfde data. In php is het mogelijk dat twee scripts tegelijk starten. Beiden hebben dan een lokale kopie van de sessie variabelen waarmee ze werken en veranderingen in het ene script komen niet door in het andere script. Als aan het einde van het script de sessievars weer geserialized worden dan worden alleen die gegevens bewaard die als laatste weggeschreven worden.

[Janoz]

Brakkie schreef op dinsdag 30 januari 2007 @ 15:12:
[...]


PHP heeft ook een bedrijf achter zich wat een drijfende kracht is, namelijk Zend. Dit bedrijf heeft er alle belang bij dat PHP doorontwikkeld en ondersteund wordt. Ook kun je via Zend Support krijgen of via een van de partners die Zend wereldwijd heeft (ook in Nederland)

Naast het feit dat zend bij lange na niet zo krachtig is als bedrijven als bijvoorbeeld Microsoft, Sun en Oracle gaat het niet enkel om de kracht van de bedrijven, maar vooral om de continuiteit. Dat is nu juist iets waarin php heeft laten zien dat ze niet goed zijn. Hoeveel applicaties zijn er bijvoorbeeld niet gemold omdat in een versie plotseling register globals uit stond?

Natuurlijk is het geen slechte zet geweest om het te doen, maar als ze wat langer hadden nagedacht dan hadden ze het waarschijnlijk helemaal niet ingebouwd (het injecteren van uservars in de global scope). Je wilt als groot bedrijf niet dat je, elke keer als er een nieuwe release komt, je je hele software weer door moet omdat dingen mogelijk veranderd kunnen zijn.

[Ramasha]

Natuurlijk is het geen slechte zet geweest om het te doen, maar als ze wat langer hadden nagedacht dan hadden ze het waarschijnlijk helemaal niet ingebouwd (het injecteren van uservars in de global scope). Je wilt als groot bedrijf niet dat je, elke keer als er een nieuwe release komt, je je hele software weer door moet omdat dingen mogelijk veranderd kunnen zijn.

En nu noem je leuk Het zwakke punt van o.a. microsoft, bang/lui om een rigoreuze aanpassing te doen. Het is voor veel bedrijven die PHP draaide niet leuk geweest, maar dan draaide je al een onveilig systeem. De verwijzingen (o.a. $_GET[], $_POST[]) waren al langer geschikt.
Ik vraag me zeer zeker af of bijv. micorsoft, maar ook sun het zouden hebben aangedurfd om zo'n rigoreuze aanpassing door te voeren.

Nu kan je zeggen zorg niet voor dit soort fouten in PHP, maar alles wat door mensen is gemaakt/ontworpen zal fouten bevatten.

Just my 2 cents,

Verder een zeer hoogwaardige discussie, als PHP fan zeer leuk te lezen dat er ook redelijk over PHP kan worden gepraat.

Super Jongens

[Janoz]

Brakkie schreef op dinsdag 30 januari 2007 @ 15:05:
[...]


Dit wordt de hele tijd gezegd maar er wordt nergens benoemd voor welke complexere jobs op het gebied van het bouwen van web applicaties PHP minder geschikt is. En dit dan puur op het gebied van functionaliteit op het gebied van de taal en libraries/frameworks die ervoor beschikbaar zijn.

Met veel pijn en moeite zal uiteindelijk nog wel dezelfde functionaliteit te benaderen zijn, maar persoonlijk vind ik dat je dan druk bezig bent om het vierkante blokje door het ronde gaatje te duwen terwijl je ook gewoon het ronde blokje had kunnen pakken. 90% van de mensen die zeggen 'Ja, maar met php kun je ook complexe dingen doen' hebben alleen ervaring met php. Feit is dat je, wanneer je nooit wat anders hebt gezien, je ook niet weet hoe het anders kan. Een mooi tekenend voorbeeld vind ik het Ruby onRails topic. Als je kijkt welke mensen daar het meest lyrisch zijn over de mogenlijkheden dan zijn dit oud php-ers. Alleen hebben een soort 'man, wat is het ontwikkelen zo makkelijk met deze extra's in het platform'. Daarmee wel ik niet zeggen dat andere mensen er niet lyrisch over zijn, maar ik als Javaan heb veel dingen die in Ruby zitten al lang een keer eerder gezien.

Php mist gewoon dingen. Ik heb het scope verhaal al genoemd. Een ander iets is bijvoorbeeld object georienteerdheid. Wat er nu aan OO in php zit is imho een lachertje. Het niet impliciet aanroepen van constructors, geen fatsoenlijke overerving. Daarnaast zorgt het enkel op request gebaseerde systeem ervoor dat je voor elk proces die complete classstructuur weer moet interpreteren en eventueel moet deserializen.

Nu kun je OO wel een erg puristisch iets vinden, maar zeker bij iets grotere projecten wordt het steeds belangrijker dat het onderhoudbaar blijft en de correctheid makkelijk gegarandeerd kan worden. Correctheid bewijzen gaat veel makkelijker in een puur object georrienteerde omgeving omdat je daarin duidelijk kunt garanderen wat waarbij kan. Als je een locale variabele private maakt kun je er vanuit gaan dat niemand anders er bij kan. Dit maakt het isoleren van een stuk code veel makkelijker waardoor je bij onderhoud of controle niet je complete applicatie hoeft te controleren, maar enkel het stuk geisoleerde code hoeft te bekijken en daar keiharde garanties aan kunt hangen. Vervolgens kun je in de rest van je applicatie uitgaan van die garanties wanneer je dat stuk aanspreekt.

[Janoz]

Ramasha schreef op dinsdag 30 januari 2007 @ 19:57:
[...]


En nu noem je leuk Het zwakke punt van o.a. microsoft, bang/lui om een rigoreuze aanpassing te doen. Het is voor veel bedrijven die PHP draaide niet leuk geweest, maar dan draaide je al een onveilig systeem. De verwijzingen (o.a. $_GET[], $_POST[]) waren al langer geschikt.
Ik vraag me zeer zeker af of bijv. micorsoft, maar ook sun het zouden hebben aangedurfd om zo'n rigoreuze aanpassing door te voeren.

Ook microsoft heeft wel eens vanwege security backward compatibility moeten breken (was volgens mij tussen 1.1 en 2.0, in 2.0 waren enkele methoden niet meer beschikbaar. Preciese specs moet ik even opzoeken).

Dat het verder bij Sun en MS weinig voorkomt, komt omdat er daar een stuk langer over wordt nagedacht voordat iets wordt geimplementeerd. Dat klinkt stom, maar als je ziet hoe lang het traject is voordat bepaalde functionaliteit in de j2ee standaard wordt opgenomen. Tot die tijd zijn er vaak wel implementaties beschikbaar, maar wanneer je hiervoor kiest weet je dat het niet perse definitief hoeft te zijn. Daarnaast heeft php het probleem dat het als een simpel homepage dynamischer maak taaltje begonnen is waarbij iemand gewoon eens iets leuks in elkaar gedraait heeft om te zien hoever het komt. Dat is php lastig aan te rekenen.

Het probleem is meer dat ook bij nieuwe functionaliteiten vaak fundamentele fouten worden gemaakt en dat er niet op een normale manier met bugmeldingen omgegaan wordt. Degene verantwoordelijk voor security is niet voor niks opgestapt. Nog niet zo heel lang geleden liep er hier op GoT ook een thread over een vreemde lekkende scope van een ForEach. Dit is vervolgens als bug gemeld (dat was het ook) maar hierop werd vervolgens gereageerd met 'Its not a bug, its a feature' (Niet verzonnen!!!). Dat zijn niet de dingen die je wilt zien wanneer je een kritiek stuk software wilt ontwikkelen!

[Brakkie]

Janoz schreef op dinsdag 30 januari 2007 @ 19:29:
[...]

Naast het feit dat zend bij lange na niet zo krachtig is als bedrijven als bijvoorbeeld Microsoft, Sun en Oracle gaat het niet enkel om de kracht van de bedrijven, maar vooral om de continuiteit. Dat is nu juist iets waarin php heeft laten zien dat ze niet goed zijn. Hoeveel applicaties zijn er bijvoorbeeld niet gemold omdat in een versie plotseling register globals uit stond?

Natuurlijk is het geen slechte zet geweest om het te doen, maar als ze wat langer hadden nagedacht dan hadden ze het waarschijnlijk helemaal niet ingebouwd (het injecteren van uservars in de global scope). Je wilt als groot bedrijf niet dat je, elke keer als er een nieuwe release komt, je je hele software weer door moet omdat dingen mogelijk veranderd kunnen zijn.

Het voorbeeld wat je noemt wat betreft register globals vind ik juist een teken van durf en moeilijke beslissingen nemen die wel erg verstandig zijn. Maar goed dat zeg je zelf ook al min of meer.

Zend is dan misschien veel minder machtig en kapitaal krachtig dan de reuzen Microsoft, Sun en Oracle. Ze ondersteunen wel een scripttaal die nog steeds 1 van de snelst groeiende is. Daarnaast zijn ze goed bezig door te faciliteren in de ontwikkeling van een framework wat uiteindelijk PHP een meer volwassen speler tussen de andere web platformen zal maken. Daarnaast hoop ik wel dat PHP altijd makkelijk toegankelijk zal blijven om op een heel simpele manier dynamische websites te bouwen (en natuurlijk ook heel complexe apllicaties )

Ik ga trouwens over een maand beginnen als .Net programmeur en ga dan ook voor het eerst kennis maken met .Net en C#. Ik zal over een tijdje nog eens mijn visie op dit onderwerp posten, kijken of ie erg veranderd is.

[Janoz]

Php is ook zeker geen onkruid wat verdelgt zou moeten worden (alhoewel.. ). Het heeft zeker zijn plaats in de wereld van software ontwikkeling. Er zijn ook situaties waarin je beter php kunt gebruiken dan .net of java. Het probleem is echter dat er door veel mensen niet vanuit de behoefte wordt geredeneerd, maar vanuit hun eigen kennis kader. Als je alleen met php werkt denk je in php oplossingen en vindt je uiteindelijk ook overal nog wel een oplossing voor. Heb je bijvoorbeeld een tijdje met RoR gewerkt dan zul je inzien dat er meer wegen naar rome leiden en dat de php weg niet altijd de korste is.

[YopY]

Ikzelf ben begonnen met PHP, welke ook mede ervoor gezorgd heeft dat ik voor programmeren gekozen heb. Ondertussen ben ik al enkele maanden niet meer met PHP bezig geweest, en ondertussen heb ik Ruby on Rails ontdekt, en zijn we op de opleiding flink met Java bezig geweest.

Als ik nu terugdenk aan de tijd dat ik nog in PHP bezig was, herinner ik mij dat het grootste deel van de tijd dat ik ermee bezig was te maken had met het achtergrondverhaal - databaseverbindingen, data controleren, formulieren afhandelen, dat soort van dingen. Ook was ik veel bezig met het opnieuw schrijven van stukken code, omdat ik weer iets nieuws geleerd had.

Ondertussen heb ik de MVC methode ontdekt (RoR) en weet ik nu wat OOP is en hoe ik het goed toepassen moet. Grootste project in Java tot nu toe bestaat uit iets van 30 klassen, bijna 8 weken werk (is bijna af).

Binnenkort is het goed mogelijk dat ik weer met PHP bezig ga. Wat ik nu al wel weet is dat ik RoR na ga doen, en dat alles zoveel object-georienteerd mogelijk word.

Qua overzichtelijkheid vind ik RoR het beste, je weet bijna automatisch waar wat moet. Bij PHP mag je dat bijna altijd zelf bepalen, tenzij je een streng framework gebruikt waar eerder een mooi lijstje van gemaakt werd. Ikzelf heb alleen hier en daar een stukje van PEAR gebruikt tot nu toe, simpelweg omdat ik het zelf leuker vond om met het achtergrondverhaal bezig te zijn.

Nu ik met Java bezig ben, vind ik het echter wel gemakkelijk dat veel van dat soort spul al ingebakken zit. En dat het ook werkt, en dat je ook precies weet wat het doet zonder dat je de code zelf hoeft te bekijken. Ik heb nooit het voordeel van een IDE voor PHP ingezien, afgezien van de automatische foutcontrole en onderlijning. Met Java zie je nu gelijk wat er beschikbaar is voor een klasse, wat het doet, wat erin moet, wat eruit komt, en andere informatie. Vind ik wel handig.

Ik weet dat dit ook mogelijk is in PHP, maar voordat ik Java gebruikte zag ik daar simpelweg niet veel voordeel in. Ik vertrouwde gewoon geen dingen die ik zelf niet had gemaakt, ook al was dat van anderen misschien efficienter en veilig geweest.


In ieder geval, PHP kan wel gebruikt worden voor grotere applicaties (er zijn miljoenen goeddraaiende websites en webapplicaties die mbv PHP gemaakt zijn), en is zeer geschikt voor de beginnende (web)programmeur. Maar qua veiligheid (in een programmeertechnische manier) vind ik strong-typed en OO talen zoals Java toch beter. Je word sneller gedwongen om op een bepaalde manier te programmeren, wat de overzichtelijkheid (op de korte tot middelgrote duur, zolang je een goed ontwerp hebt) ten goede komt. Je kunt dat ook in PHP, maar het word niet gedwongen door de taal zelf.

Java of PHP? Persoonlijk zeg ik nu Java. Misschien moet ik later meer met PHP doen en verander ik mijn mening, maar op het moment vind ik Java beter.

[merauder]

Verwijderd schreef op dinsdag 30 januari 2007 @ 15:44:
[...]


Best aardige vergelijking, alleen sloeg je de plank compleet mis toen je .NET en Java opsplitste. .NET en Java vissen in exact dezelfde vijver qua type applicaties, bedrijven enzovoorts. Het enige verschil is dat Java applicaties vaak aan Oracle gekoppeld worden en ook redelijk vaak op linux/unix systemen komen te draaien. Maar voor de rest maakt het geen moer uit. Ik heb al zat cross platform applicaties gebouwd met .NET, geen enkel probleem en hetzelfde geldt voor fabriekssupport bij Java. Genoeg support te vinden, ook vanuit Sun.

De support van Sun zelf hoor je mij ook niet over klagen, dat is minstens zo ok als Microsoft. Punt is dat ik vooral deze vergelijking pak vanuit marketings-ooghoek, en dat is waarom men vaak in 'veilige Microsoftnetwerken' wil kiezen voor een oplossing uit die hoeken.

Moet eerlijk zeggen dat ik juist op dit moment mijn weg aan het kiezen ben tussen OF .NET of JAVA.

[Verwijderd]

merauder schreef op dinsdag 30 januari 2007 @ 23:03:
[...]


De support van Sun zelf hoor je mij ook niet over klagen, dat is minstens zo ok als Microsoft. Punt is dat ik vooral deze vergelijking pak vanuit marketings-ooghoek, en dat is waarom men vaak in 'veilige Microsoftnetwerken' wil kiezen voor een oplossing uit die hoeken.

Moet eerlijk zeggen dat ik juist op dit moment mijn weg aan het kiezen ben tussen OF .NET of JAVA.

Jouw vergelijking uit marketingoogpunt gaat ieg niet op voor een groot aantal van de Nederlandse IT bedrijven met zowel Java als .NET afdelingen.

[merauder]

Verwijderd schreef op dinsdag 30 januari 2007 @ 23:15:
[...]


Jouw vergelijking uit marketingoogpunt gaat ieg niet op voor een groot aantal van de Nederlandse IT bedrijven met zowel Java als .NET afdelingen.

Maar wel voor kleinere bedrijven die het budget maar hebben voor 1 platform En dan kom je weer op het punt, je hebt bedrijven met zowel .NET als JAVA afdelingen, waar zou die splitsing dan wel in zitten.

[flowerp]

merauder schreef op dinsdag 30 januari 2007 @ 23:03:
Moet eerlijk zeggen dat ik juist op dit moment mijn weg aan het kiezen ben tussen OF .NET of JAVA.

Als het je alleen om de techniek zelf gaat kun je je eigenlijk aan alle twee geen buil vallen. Zoals al eerder gezegd hier, ze zijn zeer gelijkwaardig. De voornaamste .NET taal C# en Java verschillen nu alleen op subtiele punten van elkaar (met C# 3.0 en LINQ wordt dit verschil wel wat groter) en de platformen en tooling komen ook dicht bij elkaar.

Een groot verschil zijn natuurlijk wel de kosten. Een klein bedrijf zou mischien eerder voor Java kiezen omdat ze weinig startup kapitaal hebben, en voor Java alles gratis te krijgen is. Je kunt de als stack bijvoorbeeld op Linux, Postgres en Jboss of Tomcat draaien en als tool Eclipse gebruiken. Je geeft dan geen cent aan software uit en de kwaliteit is vaak geen grammetje minder dan de commerciele mogelijkheden.

Bij Microsoft doet de kwaliteit zeker niet onder aan Java, maar er moet wel betaald worden voor alles. Natuurlijk draait asp.net alleen op een Windows server en voor tools kun toch het beste 1 van de betaalde versies van VS gebruiken. Als doekje op het bloeden zijn er wel tegenwoordig gratis express versies van VS en je kunt in principe ook gewoon een gratis DB als Postgres of MySQL gebruiken.

Nog een ander verschil is de beschikbaarheid van source voor het Java platform. Bij onduidelijk gedrag in Java zelf of in Jboss, kan ik gewoon met de debugger in een framework functie steppen en exact zien waar iets niet gaat zoals ik verwacht had. Dit is een mentaal intensief process, maar het heeft me al dikwijls gered.

Aan de andere kant; vanwege de beschikbaarheid van source is Java documentatie vaak slecht of ontbrekend. De Jboss documentatie is gewoon knudde, en dingen als Quartz lijken documentatie te hebben maar als je het even begint te lezen merk je dat het alleen een tutorial is en erg op de opervlakte blijft. Bij Microsoft is het precies omgekeerd. De MSDN documentatie is van zeer hoge kwaliteit. Ze moeten natuurlijk ook wel, maar als je liever documentatie leest dan sourcecode dan is dit zeker een voordeel.

[Verwijderd]

merauder schreef op dinsdag 30 januari 2007 @ 23:29:
[...]


Maar wel voor kleinere bedrijven die het budget maar hebben voor 1 platform En dan kom je weer op het punt, je hebt bedrijven met zowel .NET als JAVA afdelingen, waar zou die splitsing dan wel in zitten.

Nou JAVA en .NET, vier compleet verschillende karakters. Deze "stompzinnige" opmerking van mij zegt eigenlijk alles al.

[ Voor 5% gewijzigd door Verwijderd op 31-01-2007 01:27 ]

[Janoz]

De reden dat grote IT bedrijven beide afdelingen hebben komt meer omdat ze op beide markten mee willen doen. Hun klanten zijn degene die/waarvoor de keuze tussen .net of java gemaakt wordt. Waarop die keuze gebaseerd word, komt behoorlijk in de buurt bij wat merauder aangeeft.