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

[Verwijderd]

De webtechnologie heeft een enorme ontwikkeling doorgemaakt en nog altijd wordt het terrein uitgebreid. Steeds vaker zie je allerlei toepassingen worden ontwikkeld in de vorm van webapplicaties, zodat het steeds interessanter is gaan worden om je als ontwikkelaar te richten op de mogelijkheden die een framework of taal biedt op het gebied van het web.

Tegenwoordig is PHP in opmars en begint het zo langzamerhand een serieuze taal te worden. Althans, voor wat betreft de mogelijkheden, want het imago is nog altijd behoorlijk negatief (huis-tuin-en-keuken taal). Naast PHP is er al een tijdje Java met veel mogelijkheden voor het web en sinds een poosje is er ook het .NET principe dat veel webmogelijkheden biedt.

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?

[Verwijderd]

PHP vergelijk met Java en .NET is een slechte en domme vergelijking. PHP is nog lange na niet wat de andere twee talen zijn en in het huidige ontwikkeltempo van PHP gaat dat ook nog jaren duren.

Daarnaast zijn er nog te weinig goede IDE's om PHP in te ontwikkelen, ook dat houdt PHP ontzettend tegen. Een nog groter meetpunt is dat de grote IT bedrijven in Nederland niet eens een PHP afdeling overwegen. Dat zegt al erg veel over de levensvatbaarheid van PHP op dit moment bij de grote Nederlandse bedrijven. Er is wel wat PHP daar, maar dat wordt tegenwoordig vaker naar Java/.NET verbouwd dan andersom.. Het MKB doet veel meer aan PHP, maar die zijn niet maatgevend hierin. De echte core applicaties waar de Nederlandse samenleving op draait worden nog steeds niet in PHP gebouwd, maar in diverse andere talen.

PHP is dus nog lang niet volwassen genoeg om vergeleken te kunnen worden met Java en .NET om nog talloze andere redenen. Ik heb er hierboven maar 2 (wel wat discutabele) punten uitgeligt. PHP is een volwassen taal om simpele CMS'en en websites mee te bouwen. De geavanceerdere applicaties en arbeidsintensieve applicaties worden nauwelijks in PHP gebouwd.

[Y0ur1]

Wat je gebruikt voor een webapplicatie ligt helemaal aan de klant, zijn wensen, budget, wat de applicatie moet gaan doen en vooral het vertrouwen wat een opdrachtgever en bedrijf al heeft in bijvoorbeeld java/.NET/PHP.

PHP kan mijns inziens in de verste verte niet tippen aan j2ee, j2ee is zo'n compleet andere wereld en zoveel uitgebreider dan PHP, het valt in vergelijking met php echt in het niets. Denk aan JSP, Servlets, EJB, helemaal OO (denk aan request, session en response objecten etc), heel veel APIs etc. Daarnaast heb je hele mooie frameworks zoals Spring en Struts, met daarbij bijvoorbeeld hibernate. Daar staat tegenover dat PHP een heel stuk makkelijker is en een leercurve heeft die veel minder steil is(als je het hebt over een curve met moeite/tijd), wat het veel toegankelijker maakt voor huis-tuin-en-keuken projecten en kleinere applicaties.

.NET webapplicaties heb ik geen ervaring mee maar dat is volgens mij ook aardig volwassen.

[Verwijderd]

PHP vergelijken met J2EE is als bash shell scripting vergelijken met C++.
Totaal ander publiek, technologie en doelstelling.
En waarom zou iemand voor .NET kiezen als je Java hebt?
Wil je per sé vastgebonden zitten aan Microsoft dan?

[pjonk]

Zoals YOur1 aangeeft is je keuze afhankelijk van de complexiteit en grootte van je webapplicatie. Voor een kleine webapplicatie kan een keuze voor ASP.NET of Java soms overkill zijn en ben je beter af met een script taal zoals PHP, ASP etc.
Achter grotere webapplicaties hangen over het algemeen grote databases. Je zal je dan snel te maken hebben met Oracle of MS-SQL en niet zo snel een MySQL database. Op veel gebieden (met name data integriteit) is MySQL nog steeds niet volwassen genoeg.
De combinatie PHP/MySQL heeft zich wel bewezen, maar ik heb mijn twijfels over een PHP/MS-SQL of PHP/Oracle combinatie.

P.S: Kijk ook eens naar Ruby on Rails en Python. Deze talen worden steeds populairder bij webontwikkelaars en dat is niet zonder reden.

[pjonk]

Verwijderd schreef op zaterdag 27 januari 2007 @ 10:15:
PHP vergelijken met J2EE is als bash shell scripting vergelijken met C++.
Totaal ander publiek, technologie en doelstelling.
En waarom zou iemand voor .NET kiezen als je Java hebt?
Wil je per sé vastgebonden zitten aan Microsoft dan?

Op ons werk doen we Microsoft en Java en voor de hand liggende combinaties zijn dan:
- Java -> Oracla -> Solaris (Tomcat webserver)
- ASP.NET -> MS-SQL -> Windows Server 2003.

En soms is het gewoon een wens van de klant om Microsoft technologie te gebruiken. De keuze van het platform hangt ook weer samen met de keuze voor een DBMS. Een Java en MS-SQL combinatie is minder voor de hand liggend dan ASP.NET en MS-SQL. Het .NET framework heeft logischerwijs gewoon de beste support voor MS-SQL.

[whoami]

Verwijderd schreef op zaterdag 27 januari 2007 @ 10:15:
PHP vergelijken met J2EE is als bash shell scripting vergelijken met C++.
Totaal ander publiek, technologie en doelstelling.
En waarom zou iemand voor .NET kiezen als je Java hebt?
Wil je per sé vastgebonden zitten aan Microsoft dan?

Och.... Wat is er mis met de MS tools ?

En hoezo, vastgebonden ? Je hebt ook de Mono implementatie van .NET , en er zijn ook tal van gratis tools voor .NET (nhibernate, spring.net, ... )

Je opmerking raakt dus kant noch wal, en heeft ook helemaal niets met de insteek van de topicstarter te maken.

[flowerp]

Ik sluit me helemaal aan bij de andere replies hier. PHP en Java/.NET vergelijken is alsof je een klein aardappelscheermesje van 25 cent vergelijkt met een luxe zwitsers zakmes.

Je ziet dit ook terug in de markt. Java (J2EE/Java EE) progammeurs zijn momenteel enorm gewild. Zo gewild zelfs dat ze de rollen kwa sollicitatie compleet om kunnen draaien en de betaalde salarissen niet mals zijn.

Als je al PHP, Java EE en ASP.NET wilt vergelijken, dan moet je je eigenlijk beperken tot de versies van Java EE en ASP van enkele jaren geleden. Een pure JSP pagina van omstreeks 2000 (dus zonder technieken als taglibs, web components, EJB, etc) of dezelfde ASP pagina van ongeveer die tijd (tegenwoordig classic ASP genoemd), is wel goed vergelijkbaar met PHP.

Java EE en ASP.NET liggen in de huidige versies al veel dichter bij elkaar. Bij sommige dingen ligt Java voor (bv met JPA), met andere dingen ligt .NET iets voor (bv Java's JSF vs .NET's Controls).

Kwa IDEs is het ook zeer gelijkwaardig. Java heeft met name Eclipse, maar er is ook nog oa Netbeans en een paar uitstekende commerciele oplossingen. .NET heeft natuurlijk Visual Studio, wat zeker in de huidige versie (2005) ook een zeer professioneel pakket is. Met name grafische layouts maken met Controls is in VS beter doorgevoerd dan momenteel in Eclipse mogelijk is.

Samengevat richt PHP zich meer op de prutser, en Java/.NET zich meer op de profesional. Dat er ook enkele profesionals met PHP werken en ook prutsers het met Java/.NET doen, doet niet af aan de algehele zaak.

Y0ur1 schreef op zaterdag 27 januari 2007 @ 00:56:
Daarnaast heb je hele mooie frameworks zoals Spring en Struts, met daarbij bijvoorbeeld hibernate.

Vergeet niet dat 'hibernate' (via JPA) tegenwoordig standaard in Java zit. Ook het vervolg op Struts (JSF) zit tegenwoordig standaard in Java.

[Grijze Vos]

whoami schreef op zaterdag 27 januari 2007 @ 12:22:
[...]

Je opmerking raakt dus kant noch wal, en heeft ook helemaal niets met de insteek van de topicstarter te maken.

Euhm, de TS heeft het over imago. Het imago van MS kan zeker wel een rol spelen in de keuze van het platform. (Los van of het slim is om daarop gebaseerd je keuze te maken.)

[ Voor 8% gewijzigd door Grijze Vos op 27-01-2007 12:46 ]

[Passenger]

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).

[Verwijderd]

Passenger schreef op zaterdag 27 januari 2007 @ 12:50:
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).

Je noemt nu allemaal pagina's zonder bijster interessante businesslogica. Ik denk ook dat businesslogica het sluitende argument is in een dergelijke vergelijking. Naarmate de businesslogica complexer wordt zal de taal / het platform daarin moeten faciliteren. Daarin blijft php behoorlijk achterop lopen.

[ Voor 0% gewijzigd door Verwijderd op 27-01-2007 13:13 . Reden: typo ]

[Passenger]

Verwijderd schreef op zaterdag 27 januari 2007 @ 13:12:
[...]
Je noemt nu allemaal pagina's zonder bijster interessante businesslogica. Ik denk ook dat businesslogica het sluitende argument is in een dergelijke vergelijking. Naarmate de businesslogica complexer wordt zal de taal / het platform daarin moeten faciliteren. Daarin blijft php behoorlijk achterop lopen.

Aha, kijk dat is een perspectief dat ik bij dergelijke discussies nog niet echt tegengekomen ben... Aan wat vorm van businesslogica moet ik dan denken?

[Y0ur1]

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).

Tuurlijk er zijn meerdere wegen die naar Rome leiden, de genoemde websites werken allemaal prima met php/mysql, voor wat het moet doen. Maar ze doen bijvoorbeeld niks met transacties, dat is waar java heel sterk in is, ik kan me niet voorstellen dat een bank php/mysql zou gebruiken. Ook is de ondersteuning van PHP anders dan van een applicatieserver van bijvoorbeeld IBM, ondersteuning is heel belangrijk voor de hoge pieten, werkt het niet dan moet er support zijn.

Verder is het ook gewoon belangrijk wat het budget is. Wil je relatief snel een website opzetten dan kies je php/mysql. Wil je het heel mooi ontwerpen, alle lagen mooi scheiden etc dan ga je voor j2ee.

[Verwijderd]

whoami schreef op zaterdag 27 januari 2007 @ 12:22:
[...]

En hoezo, vastgebonden ? Je hebt ook de Mono implementatie van .NET , en er zijn ook tal van gratis tools voor .NET (nhibernate, spring.net, ... )

Ik ben nog maar erg weinig Windows .NET applicaties tegengekomen die vlekkeloos onder Linux/MONO draaien hoor.
Trouwens, Mono zou ik al helemaal m'n vingers afhouden, zo snel als Microsoft er zin in heeft kunnen ze Mono verbieden omdat het inbreuk maakt op enkele van hun patenten (pas nog enkele artikels over verschenen, vind ze momenteel ff niet meer terug). Momenteel zien ze het door de vingers, maar er is geen enkele zekerheid voor de toekomst...
De TS heeft het ook over "imago".
Imho heeft Sun/Java wel een stukken sterker imago dan Microsoft/.NET.
En dan gaat Java ook nog eens opensource onder de GPL!

[ Voor 10% gewijzigd door Verwijderd op 27-01-2007 13:23 ]

[whoami]

Trouwens, Mono zou ik al helemaal m'n vingers afhouden, zo snel als Microsoft er zin in heeft kunnen ze Mono verbieden omdat het inbreuk maakt op enkele van hun patenten (pas nog enkele artikels over verschenen, vind ze momenteel ff niet meer terug). Momenteel zien ze het door de vingers, maar er is geen enkele zekerheid voor de toekomst...

Waarom zouden ze dat doen ? Ze zouden enkel in hun eigen vingers snijden; op heer meer platformen hun framework draait, hoe meer voordeel ze er bij hebben.
.NET / MS producten afschrijven enkel en alleen omdat het MS is, is ook maar dom.
(Trouwens afaik bestaat Java nu al geruim 10 jaar, en gaat het nu pas open-source gaan, terwijl C# al van in 2001 een standard is).

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.
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.

.NET niet kiezen met als enige reden 'het is van microsoft, vendor lockin etc...) vind ik ook maar dom.

Op de vraag wat het meest interessante platform is: dat hangt af van situatie tot situatie, het budget van de klant (als je in opdracht iets maakt), of de reeds bestaande infrastructuur en kennis van de klant.

[Verwijderd]

inderdaad, de groei op de besturingsysteem-markt(windows) is er voor microsoft alang uit. zijn de grootste en er valt dus niets meer te halen.

echter op de applicatie-markt(MediaPlayer11, MSN, IE8?) is microsoft nog lang niet uitgegroeid. waarom denk je dat microsoft .Net zo heeft opgezet dat het juist makkelijk naar een ander platform te converteren is, dit in tegenstelling tot de win32 api, welke echt voor windows is ontworpen.

projecten als mono bereikten in enke jaren al de compatibiliteit waar de wine developers een decenia voor nodig hadden. eigenlijk doet mono precies dat wat microsoft wilde. dat .Net applicaties ook op andere bestruringssysteem werkt zodat je straks ook WindowsMediaPlayer onder linux kunt gebruiken, of mischien nog wel erger MSN.

dankzij .Net kan microsoft zijn applicaties-markt los verkopen van de OS-markt en zo weer verder groeien. terwijl ze met de win32api en DirectX voorkomen dat mensen helemaal over kunnen stappen. .Net is bedoeld als concurrent van Java, omzo cross-platform op applicatie-nivo te kunnen concurreren. wat PHP dan in dit rijtje thuis doet is mij een raadsel. PHP is toch echt van een ander kaliber, met een ander doel op een andere manier.

PHP is zeker geen slechte programmer taal. het zit goed in elkaar voordat waarvoor het bedoeld is. het dynamisch weergeven van websites oftewel de presentatie laag. ik denk dan ook dat het imago wat PHP heeft gewoon niet thuis hoort in het rijtje van java of .Net en echte proffessionals die weten dat ook.

verder ben ik het met eerder post eens dat wat PHP vooral mist is een goed debugger en vooral meer keuze kwa IDE's. de ZEND IDE's is zeer goed en ook Eclips begint aardig te worden maar het mist gewoon iets. te weigig keuze en ik denk dat dat ook te maken heeft met het feit dat PHP geen debug-interface heeft, en IDE's dus eigenlijk moet gokken wat er nou gebeurt wat het ontwikkelen van grote projecten met PHP echt zeer langzaam en tergend complex maakt.

[Verwijderd]

Verwijderd schreef op zaterdag 27 januari 2007 @ 14:20:
verder ben ik het met eerder post eens dat wat PHP vooral mist is een goed debugger en vooral meer keuze kwa IDE's. de ZEND IDE's is zeer goed en ook Eclips begint aardig te worden maar het mist gewoon iets. te weigig keuze en ik denk dat dat ook te maken heeft met het feit dat PHP geen debug-interface heeft, en IDE's dus eigenlijk moet gokken wat er nou gebeurt wat het ontwikkelen van grote projecten met PHP echt zeer langzaam en tergend complex maakt.

Het belangrijkste wat PHP IDE's missen zijn inderdaad:

-> Standaard componenten (dropdownlists, checkboxlists, etc..)
-> Goede debuggers. Deze zijn er wel Vs.Php is er bijvoorbeeld één. Die werkt vrij goed. Echter maakt die ook weer gebruik van Microsoft Visual Studio.
-> Een IDE die gericht is op OO, zoals dat bij .NET en Java wel het geval is (Ieg bij de goede IDE's).

[Verwijderd]

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


Ik ben nog maar erg weinig Windows .NET applicaties tegengekomen die vlekkeloos onder Linux/MONO draaien hoor.
Trouwens, Mono zou ik al helemaal m'n vingers afhouden, zo snel als Microsoft er zin in heeft kunnen ze Mono verbieden omdat het inbreuk maakt op enkele van hun patenten (pas nog enkele artikels over verschenen, vind ze momenteel ff niet meer terug). Momenteel zien ze het door de vingers, maar er is geen enkele zekerheid voor de toekomst...
De TS heeft het ook over "imago".
Imho heeft Sun/Java wel een stukken sterker imago dan Microsoft/.NET.
En dan gaat Java ook nog eens opensource onder de GPL!

Jij hebt duidelijk geen flauw idee van Mono en de licenties waaronder .NET gepubliceerd is en wat het idee van .NET is. Ten eerste is Mono GEEN Microsoft project. Het wordt zelfs zwaar gesponsord door de grotereOpen Source bedrijven (Novell oa geloof ik). Mono maakt dus helemaal geen inbreuk op de patenten. Waar je die onzin vandaan haalt is mij volstrekt onbekend. Er is maar 1 deel van .NET gepatenteerd onder closed source en dat zijn de Windows Forms libraries. De rest is vrijlijk beschikbaar voor iedereen om het te implementeren. Mono gebruikt deze dan ook niet en maakt hierbij gebruik van GTK+, welke op dit moment de Windows Forms look and feel erg goed begint te benaderen. En als klapper op de vuurpijl, komt Mono vaak genoeg bij in lezingen van hoge MS .NET professionals van Microsoft zelf, waar ze zelfs eigenlijk wel trots zijn dat mensen die implementatie gemaakt hebben.

Complete onzin dus jouw hele verhaal.

[ Voor 9% gewijzigd door Verwijderd op 27-01-2007 14:37 ]

[PrisonerOfPain]

Verwijderd schreef op zaterdag 27 januari 2007 @ 14:36:
Het wordt zelfs zwaar gesponsord door de grotereOpen Source bedrijven (Novell oa geloof ik). Mono maakt dus helemaal geen inbreuk op de patenten.

Hoe sluiten die twee regels elkaar uit dan?

[ Voor 6% gewijzigd door PrisonerOfPain op 27-01-2007 14:38 ]

[ThunderNet]

Je hebt op .Net gebied zelfs een tweesplitsing van IDE's nu. Je hebt de Expression serie (o.a. Blend en Web) Voor puur alleen het ontwerpen van de User Interfaces, door de designer. Welke perfect samenwerkt met Visual Studio 2005, voor de ontwikkelaars.

Wat ik zelf altijd jammer vind is dat mensen php met asp vergeleiken. En er direct van uitgaan dat asp hetzelfde is als asp.Net. Als ik soms een php hobbyist een hele korte rondleiding geef in VS2005, en wat met Asp.Net mogelijk is. Zijn ze allemaal verbaasd

En zeker voor zwaardere business logic is het .Net platform erg fijn. Bijvoorbeeld dat je een deel van je applicatie kunt runnen binnen in SQL Server 2005. Afhankelijk van je applicatieontwerp kun je daar flinke snelheids winsten mee halen.

[Verwijderd]

@Exiss:
"Mono's implementation of those components of the .NET stack not submitted to the ECMA for standardization was the source of patent violation concerns for much of the life of the project. In particular, discussion has taken place about whether Microsoft could destroy the Mono project through patent suits. The problematic parts are not the core technologies submitted to the ECMA or the Unix/Gnome-specific parts. The patent concerns primarily relate to technologies developed by Microsoft on top of the .NET Framework, such as ASP.NET, ADO.NET and Windows Forms, i.e. parts composing Mono's Windows compatibility stack. These technologies are today not fully implemented in Mono and not required for developing Mono-applications. Not providing a patented capability would weaken the interoperability"
-> van Wikipedia

En blijkbaar weet jij veel minder van Mono/DotNet/Novell dan je denkt.
Nog niet gehoord van de patent-overeenkomst die ze gesloten hebben?
Lees er hier meer over
En nog meer nuttige info op Groklaw
Het komt er op neer dat Novell grof geld heeft betaald aan Microsoft om zichzelf (en hun klanten) te beschermen tegen rechtzaken ivm inbreuk op patenten, met als hoofdzaak het Mono platform.
Denk je dat ze enkele honderden miljoen dollar gaan betalen om zichzelf tegen iets te beschermen dat 100% zeker nooit zal gebeuren?
Think again
Door deze deal heeft Microsoft opnieuw bewezen dat ze ten alle tijde het Mono project kunnen tegenwerken en/of opdoeken.

Als kleine extra kan je hier lezen hoe sterk de Samba Foundation bijvoorbeeld gekant is tegen deze overeenkomst (alsook talloze andere open source organisaties).
Microsoft is en blijft een bedrijf met uiterst smerige tactieken, dat NIET te vertrouwen is.
Ze zouden maar al te graag de open source gemeenschap met de grond gelijk maken, en ze zullen elke kans grijpen om dat ook te doen.

[ Voor 12% gewijzigd door Verwijderd op 27-01-2007 15:15 ]

[Verwijderd]

Verwijderd schreef op zaterdag 27 januari 2007 @ 15:12:
@Exiss:
"Mono's implementation of those components of the .NET stack not submitted to the ECMA for standardization was the source of patent violation concerns for much of the life of the project. In particular, discussion has taken place about whether Microsoft could destroy the Mono project through patent suits. The problematic parts are not the core technologies submitted to the ECMA or the Unix/Gnome-specific parts. The patent concerns primarily relate to technologies developed by Microsoft on top of the .NET Framework, such as ASP.NET, ADO.NET and Windows Forms, i.e. parts composing Mono's Windows compatibility stack. These technologies are today not fully implemented in Mono and not required for developing Mono-applications. Not providing a patented capability would weaken the interoperability"
-> van Wikipedia

Windows Forms is helemaal niet geimplementeerd in Mono... Technisch is dat niet eens mogelijk, omdat Windows Forms in .NET (groten)deels gebouwd zijn op oude Windows componenten. EN laat die componenten nou net niet compatible zijn met Linux ed. Mono noemt het wel Windows Forms, maar in werkelijkheid is het een clone die onder andere GTK en OpenGL ondersteunt (Wat je ook mag verwachten van een Open Source implementatie).

Daar bovenop zegt de Wikipedia tekst niet meer dan dat men bang was voor mogelijke patentschendingen, maar niet dat dit ook het geval was. Er wordt dus nergens daadwerkelijk iets geroepen/gezegd over het schenden van de patenten of dat de patenten van MS in de weg zitten. Er wordt alleen gezegd dat MS ADO.NET, Windows Forms en ASP.NET niet neer gelegd heeft bij de ECMA. Dat is heel wat anders.


Bovendien is Wikipedia de meest onbetrouwbare vindbare bron over Microsoft die er maar is, aangezien alle MS bashers alle artikelen van hun versie van de waarheid toevoegen.

En blijkbaar weet jij veel minder van Mono/DotNet/Novell dan je denkt.
Nog niet gehoord van de patent-overeenkomst die ze gesloten hebben?
Lees er hier meer over
En nog meer nuttige info op Groklaw

Het komt er op neer dat Novell grof geld heeft betaald aan Microsoft om zichzelf (en hun klanten) te beschermen tegen rechtzaken ivm inbreuk op patenten, met als hoofdzaak het Mono platform.
Denk je dat ze enkele honderden miljoen dollar gaan betalen om zichzelf tegen iets te beschermen dat 100% zeker nooit zal gebeuren?
Think again

Door deze deal heeft Microsoft opnieuw bewezen dat ze ten alle tijde het Mono project kunnen tegenwerken en/of opdoeken.

Die links hebben helemaal niet direct te maken met Mono. Beter gezegd: Mono is een project gesponsord door Novell, niet van Novell. Mono wordt dus niet eens beschermd door die overeenkomst van Novell met Microsoft.

Als kleine extra kan je hier lezen hoe sterk de Samba Foundation bijvoorbeeld gekant is tegen deze overeenkomst (alsook talloze andere open source organisaties).
Microsoft is en blijft een bedrijf met uiterst smerige tactieken, dat NIET te vertrouwen is.
Ze zouden maar al te graag de open source gemeenschap met de grond gelijk maken, en ze zullen elke kans grijpen om dat ook te doen.

En Samba heeft met Mono en .NET te maken omdat

[ Voor 10% gewijzigd door Verwijderd op 27-01-2007 16:40 ]

[JKVA]

Ik denk dat het belangrijkste probleem van PHP is dat het een geinterpreteerde taal is ten opzichte van de gecompileerde, strong typed en OO talen C# en Java.
Dat zorgt ervoor dat je bij voorbaat al veel meer bugs introduceert tijdens runtime, waar een groot deel van de fouten al door de compiler herkend wordt. Bovendien is het simpelweg sneller, maar dat is niet de hoofdreden lijkt me.

@Whoami: Ik vind anders juist dat .NET een serieus nadeel heeft t.o.v. Java door de vendor lock-in. Niet omdat je aan Microsoft vastzit, maar omdat er veel minder innovatie is van derden.

Voor .NET heb je Visual Studio. Prachtig product, maar voor Java kun je kiezen uit onder andere Eclipse met tig plugins, IntelliJ, NetBeans, JDeveloper, etc. Zo kun je precies de IDE uitzoeken die bij je doel/smaak past. En zeg niet dat Eclipse een slap open source prulding is. Van zichzelf biedt het al tig functies en als je kijkt wat voor enorme IDE's BEA, IBM en dergelijke bovenop dit platform bouwen, dan vind ik dat een sterke troef van Java.

Tel daarbij op dat er vanuit de open source gemeenschap veel meer voor Java wordt gedaan dan voor .NET. Ja, ok, .NET heeft nu ook een NHibernate en een NSpring, maar in Java hebben we dat al jaren en er zijn nog tig alternatieven ook.

Maar, ik moet aan de andere kant ook eerlijk zijn en bekennen dat dat tegelijk weer een groot nadeel is van Java/J2EE. Het is, deels doordat er teveel keuzes zijn, veeeeeel te complex en moeilijk.

Maar daar wordt hard aan gewerkt. Zie EJB 3.0, JPA en JSF. En onder andere de standaardisatie van JBoss Seam.

[Verwijderd]

JKVA schreef op zaterdag 27 januari 2007 @ 16:36:
Tel daarbij op dat er vanuit de open source gemeenschap veel meer voor Java wordt gedaan dan voor .NET. Ja, ok, .NET heeft nu ook een NHibernate en een NSpring, maar in Java hebben we dat al jaren en er zijn nog tig alternatieven ook.

Java bestaat dan ook al ruim 4x zo lang als .NET. Dus dan is het logisch dat dit soort tools al veel langer bestaan he.... Niet zo heel vreemd. Erg kromme redenering dus.

[ThunderNet]

JKVA schreef op zaterdag 27 januari 2007 @ 16:36:
Ik denk dat het belangrijkste probleem van PHP is dat het een geinterpreteerde taal is ten opzichte van de gecompileerde, strong typed en OO talen C# en Java.
Dat zorgt ervoor dat je bij voorbaat al veel meer bugs introduceert tijdens runtime, waar een groot deel van de fouten al door de compiler herkend wordt. Bovendien is het simpelweg sneller, maar dat is niet de hoofdreden lijkt me.

@Whoami: Ik vind anders juist dat .NET een serieus nadeel heeft t.o.v. Java door de vendor lock-in. Niet omdat je aan Microsoft vastzit, maar omdat er veel minder innovatie is van derden.

Voor .NET heb je Visual Studio. Prachtig product, maar voor Java kun je kiezen uit onder andere Eclipse met tig plugins, IntelliJ, NetBeans, JDeveloper, etc. Zo kun je precies de IDE uitzoeken die bij je doel/smaak past. En zeg niet dat Eclipse een slap open source prulding is. Van zichzelf biedt het al tig functies en als je kijkt wat voor enorme IDE's BEA, IBM en dergelijke bovenop dit platform bouwen, dan vind ik dat een sterke troef van Java.

Tel daarbij op dat er vanuit de open source gemeenschap veel meer voor Java wordt gedaan dan voor .NET. Ja, ok, .NET heeft nu ook een NHibernate en een NSpring, maar in Java hebben we dat al jaren en er zijn nog tig alternatieven ook.

Maar, ik moet aan de andere kant ook eerlijk zijn en bekennen dat dat tegelijk weer een groot nadeel is van Java/J2EE. Het is, deels doordat er teveel keuzes zijn, veeeeeel te complex en moeilijk.

Maar daar wordt hard aan gewerkt. Zie EJB 3.0, JPA en JSF. En onder andere de standaardisatie van JBoss Seam.

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

[Verwijderd]

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


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

Fout.
Als je voor Java kiest, kan je ook nog kiezen voor:
IBM, gcj, gij, sun, HP, apple, blackdown, kaffe, ...
Allemaal verschillende implementaties van de virtual machine en/of SDK.
Kiezen voor Java wilt niet zeggen dat je gebonden bent aan Sun of Solaris.
Java draait PERFECT op Windows, Mac OS, Linux, FreeBSD, Solaris, ....
Wat niet kan gezegd worden van .NET natuurlijk.
Vendor lockin is wel degelijke een feit om rekening met te houden.

[JKVA]

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


Java bestaat dan ook al ruim 4x zo lang als .NET. Dus dan is het logisch dat dit soort tools al veel langer bestaan he.... Niet zo heel vreemd. Erg kromme redenering dus.

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.

[Verwijderd]

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


Fout.
Als je voor Java kiest, kan je ook nog kiezen voor:
IBM, gcj, gij, sun, HP, apple, blackdown, kaffe, ...
Allemaal verschillende implementaties van de virtual machine en/of SDK.

Microsoft
Mono
SharpDevelop (OS)

Kiezen voor Java wilt niet zeggen dat je gebonden bent aan Sun of Solaris.
Java draait PERFECT op Windows, Mac OS, Linux, FreeBSD, Solaris, ....
Wat niet kan gezegd worden van .NET natuurlijk.

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


Hey verrek, dat zijn dezelfde antwoorden!

[ThunderNet]

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

Fout.
Als je voor Java kiest, kan je ook nog kiezen voor:
IBM, gcj, gij, sun, HP, apple, blackdown, kaffe, ...
Allemaal verschillende implementaties van de virtual machine en/of SDK.
Kiezen voor Java wilt niet zeggen dat je gebonden bent aan Sun of Solaris.
Java draait PERFECT op Windows, Mac OS, Linux, FreeBSD, Solaris, ....
Wat niet kan gezegd worden van .NET natuurlijk.
Vendor lockin is wel degelijke een feit om rekening met te houden.

vziw is Sun nog altijd de organisatie die beslist hoe de taal er uit ziet, etc.
Daarnaast gaat het hier grotendeels over serverside webbased applicaties. En dus is multiplatform lang niet zo'n issue (immers, je output is over het algemeen gewoon HTML, en is wel overal te laten zien). En aangezien je het meestal maar op 1 server laat draaien.

[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.