PHP 8 met jit-compiler en attributes is uit

PHP 8 is uitgebracht. De nieuwe versie van de taal heeft veel veranderingen, waaronder de toevoeging van de jit-compiler waarmee scripts sneller worden. Ook heeft PHP 8 de mogelijkheid om attributes toe te voegen.

PHP 8 is sinds donderdag beschikbaar. Een van de belangrijkste toevoegingen aan de nieuwe programmeertaal is jit, of Just In Time. Dat is een andere manier van het compilen van een script naar machinecode, in plaats van code die in een virtuele machine wordt uitgevoerd, wat voor minder overhead zorgt. In theorie zou dat tijdwinst kunnen opleveren als de code cpu-intensief is. Voor websites, waar PHP het vaakst gebruikt wordt, is de winst waarschijnlijk minimaal.

Een andere belangrijke toevoeging is die van attributes. Daarmee kan metadata worden toegevoegd aan classes en functions. Ontwikkelaars vroegen daar al langer om en gebruikten altijd omwegen door bijvoorbeeld metadata via annotaties in comments toe te voegen, maar dat werd niet door alle parsers standaard meegenomen. In PHP 8 worden attributes wel standaard onderdeel van de syntax.

PHP 8 krijgt ook ondersteuning voor union types. Ook die functie werd door ontwikkelaars vaak in de in-line comments gedaan. Met union types 2.0 kunnen gebruikers structuren specificeren binnen variables.

De nieuwe blob van de taal is vanaf donderdagmiddag te downloaden en te implementeren. Volgens de ontwikkelaars zouden beheerders niet veel moeite moeten hebben tijdens de migratie als ze de vorige 7.x-versies al hebben geïmplementeerd. Daarin zijn veel van de in versie 8 verdwenen functies al uitgefaseerd. Overigens meldde Microsoft eerder al PHP 8 niet te ondersteunen.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (135)

Dafuq? Zijn er echt mensen die dit denken? PHP is by far de meest gebruikte taal op het web. Er zijn honderden developers die PHP gebruiken. Er zijn grote websites die PHP gebruiken (welke ondere andere Facebook, Wikipedia en ook Tweakers). Daarnaast moet je ook rekening houden met dat goedkope webhosting bijna altijd PHP aanbied. Ik moet al ferm zoeken om een hosting te vinden met ASP.net of een andere taal.

Het enige waar ik je gelijk in kan is dat PHP an sich niet gebruikt word, maar in 90% van de gevallen een framework gebaseerd op PHP waarbij Symfony en Laravel volgens mij de meest gebruikte zijn. Als je bij legacy applicaties kijkt zal je zien dat het eerste wat men toen deed een soort van framework bouwen was. Ik denk dat enkel een beginnende (PHP-)programmeur een vanilla-php site maakt.

Ik weet niet wiens reactie meer over zichzelf zegt. (Jup, da's het besef dat mijn reactie mss niet de beleefdste is)

Je hebt zeker gelijk dat PHP nog steeds bestaat, maar laten we ook niet doen alsof het verrassend is dat mensen de indruk hebben dat langzaamaan sterfende is. Wat Rob Coops over praatte was het maken van nieuwe websites en applicaties, dus de stelling "oh, er zijn legacy systemen zoals Tweakers en Wikipedia die er nog aan vast zitten" is niet echt relevant. En wat betreft Facebook: die hebben juist extreem veel moeite gedaan om bij PHP weg te komen (zover ik weet draaien ze nog steeds hun eigen taal Hack wat bedoeld was om de migratie weg bij PHP zo makkelijk mogelijk te maken).

Hoe dan ook, laten we naar de stelling kijken dat nieuwe projecten minder met PHP worden gedaan. Als we naar de StackOverflow developer survey kijken dan zien we op z'n minst dat tussen programmeurs PHP 1 van de meest dreaded (% programmeurs die bij PHP weg willen, maar het nu nog gebruiken) en minst wanted (% programmeurs die PHP niet gebruiken, maar er wel mee willen werken) talen is. In hoeverre programmeurs beslissingen maken over de technologie die gebruikt wordt voor projecten is verschillend per bedrijf, maar het zal zeker een grote impact hebben.

Aan de andere kant, wat betreft talen die programmeurs in de praktijk gebruiken is er vanaf 2019 tot 2020 niks veranderd (exact 25.8% van programmeurs gebruikt PHP beide jaren). Dat klinkt trouwens als redelijk veel, maar talen zoals Python en Java zitten rond de 40 en C# rond de 30 (en Javascript natuurlijk rond de 70, maar Javascript is lastig te vergelijken, want voor veel programmeurs is het een secundaire taal).

Mijn persoonlijke indruk is dat nieuwe websites nog prima met Wordpress en zo worden opgezet, maar ik heb persoonlijk ook al in geen 3 of 4 jaar een nieuwe web applicatie gezien die in PHP is opgezet (alhoewel m'n vrouw wel recent op werk een offerte van een bedrijf uit Bangladesh kreeg voor een project wat voorstelde om het in PHP te doen). Praktisch alle nieuwe backends die ik langs zie komen zijn in Node (Javascript/Typescript), Java of C#. Betekend natuurlijk niet dat er geen nieuwe systemen zijn met PHP, maar wat ik probeer te zeggen is dat ik zeker wel begrip heb voor Rob Coops reactie. Uiteindelijk is het super simpel om vanuit 1 bedrijf of 1 markt een visie te hebben op alles wat er in de markt gebeurd, en de enige manier om er op te reageren is te proberen kijken naar objectieve zaken zoals bijv. die jaarlijkse survey die ik eerder aanhaalde.

[Reactie gewijzigd door David Mulder op 26 november 2020 21:02]

Nextcloud is een aardig aan de weg timmerende in php geschreven applicatie.
Oracle heeft natuurlijk 2 jaar geleden een knuppel in het java-hok gegooid met de licentie aanpassingen.

De licentie aanpassingen zijn op zich niet een heel groot probleem zeker niet, omdat er genoeg bedrijven een (gratis) versie compilen, aangezien alles van de Java die Oracle maakt nu ook in de open source variant zit. Persoonlijk zou ik wel een variant kiezen die TCK tested is. Ik denk dat er meer uitdagingen zitten in de af en toe wel grote aanpassingen die ze willen gaan doen in de non-LTS versies. Het is moeilijk om zowel de LTS als de laatste non-LTS versie met support te ondersteunen (deze hebben maar 6 maanden support) als ze functies als serialisatie gaan aanpakken in non-LTS versies waar ze alleen compatibiliteit met N-1 proberen te halen.

[Reactie gewijzigd door MetalfanBlackness op 26 november 2020 22:35]

Het is moeilijk om zowel de LTS als de laatste non-LTS versie met support te ondersteunen (deze hebben maar 6 maanden support)

Zowel welke versie LTS is of non-LTS alsmede de support van 6 maanden is volledig afhankelijk van de vendor. Als jij morgen Java 15 op je eigen website ter download aanbied en dat LTS noemt, dan is Java 15 een LTS.

En wat betreft Facebook: die hebben juist extreem veel moeite gedaan om bij PHP weg te komen (zover ik weet draaien ze nog steeds hun eigen taal Hack wat bedoeld was om de migratie weg bij PHP zo makkelijk mogelijk te maken).

Het kan verkeren. Een van de drijvende krachten achter HHVM, waar Hack op draait is nu release manager van PHP 8.0: Sara Golemon. Zij heeft JIT van HHVM meegenomen naar PHP.

Ja zeker denk ik precies wat Rob coops denkt. node.js icm typescript, maar ook python is wat mij betreft 100 keer sterker dan php. PHP heeft gewoon last van remmende voorsprong. Er zijn nog zat projecten die er ooit in gestart zijn en het dus nog gebruiken, maar dat zegt niet dat het dan ook een goede taal is om een nieuw project in te starten.

NodeJS .NET Core, python etc zijn gewoon veel beter geschikt voor dit soort zaken. En hosting... AWS een van de grootste hosting providers, ondersteund dit gewoon, en voor weinig. Er zijn zat andere hosting providers waar je dit soort dingen eenvoudig weg kunt zetten. Daarnaast heb je idd frameworks als wordpress, maar daarvoor hoef je geen php te kunnen. Dat is gewoon een framework waar al de wereld aan plugins voor beschikbaar is. en ja dit soort projecten maakt php nog relevant, maar voor nieuwe producten nee daarvoor is het niet echt een geschikte omgeving.

Je praat alsof PHP oude rommel is. Kan je toelichten waarom je dat vind? Volgens mij is PHP gewoon marktleider op het gebied van web.

Technisch is PHP een beetje oude rommel geworden. Halt, halt, wacht met de downvotes, dank u wel.

Voor de basis functionaliteit, het renderen van een html pagina, is PHP meer dan doeltreffend. PHP is de afgelopen jaren best verbeterd met meer "moderne" zaken, zoals types enz. En heel wat oudere zaken zijn obsolete gemaakt en verwijderd.

Als iemand dat een 20 jaar carrier met PHP gedaan heeft, kan je zeggen dat PHP mij goed bedient heeft over de jaren.

Maar ... de web wereld is ook veranderd. Wat je meer en meer ziet, is dat websites meer gebouwd worden als applicaties, dan puur pagina/pagina structuur. SPA's enz is tegenwoordig meer aanwezig dan afwezig.

Het gevolg is dat PHP meer als een data provider ingezet word voor SPA's, dan een web pagina generator. Vroeg was PHP ook meer "misbruikt" als communicatie platform in grote projecten, iets waar het niet voor design was. Dit had best wel leuke performance issues maar je had niet echt veel keuze in die tijd. Niemand ging zo een zaken schrijven in C, C++ of Java ( ja er zijn firma's maar dit is niet de meerderheid ). De simpelheid van PHP maakt het enorm makkelijk om projecten uit de grond te stampen en goedkope programmeurs te vinden.

Dit veranderd meer en meer.

NodeJS maakt het simpeler voor bedrijven dat hun personeel op 1 taal willen houden, om zo minder een split te hebben tussen front en back-end.

Go opent de deur voor een veel meer performance data provider voor front-end SPA's. Makkelijk aan te leren, snel, minder geheugen gebruiken enz. Al die verhalen van bedrijven dat omschakelende van PHP naar GO en in het process 3/4 van hun server dumpte, zegt genoeg.

Persoonlijk ben ik na heel wat jaren van zwoegen "switch ik over of niet", uiteindelijk omgeschoold naar Go full time. Ik zal even een lijstje geven van punten, van "waarom" of de "voordelen" zoals ik ze zag.

Snelheid

PHP is ontworpen voor 1 actie uit te voeren, de resultaat terug te sturen en dan al het werk te vergeten. Het voordeel van zo een ontwerp, is dat het simpeler is om te programmeren. Je acties zijn in sequentie en je moet geen rekening houden met coroutines, async, ... Maar het kost je performance. VEEL performance. Er zijn projecten om PHP in geheugen te houden zoals Swoole enz maar dit zijn 3de partij projecten en je neemt risico's als je gans je infrastructuur opbouwt hier rond.

Go is gewoon snel uit de box. Je wilt zaken in geheugen houden. Easy ... Je kan template cachen zonder memcache of andere 3de partij applicaties. Resource hergebruiken zoals DB pools enz. Geen probleem ( ja, zit ook in PHP ). Maar PHP kan bijvoorbeeld niet gzip in een sync pool plaatsen zodat je enorme snelheid winst kan halen bij het constant zippen van je content. Of je moet weeral een sync applicatie maken, socket communicatie enz ( kost allemaal performance en geheugen ).

Het is een andere stijl van programmeren dan met PHP. Die extra controle heeft enorme gevolgen voor de snelheid dat je uit een server kan halen, tegenover PHP.

Installatie / Gebruik

PHP zit je vaak te kloten met Apache of whatever server. Je moet de balans vinden van hoeveel PHP worker je in geheugen wilt. Wacht, ik moet ook memcache hebben. O en een hele serie van PHP extensies. HTTPS? Zucht ...

Laat staan de situatie waar je lokale ontwikkelingsomgeving iets andere zaken geïnstalleerd heeft dan je deploy omgeving. Het eet gewoon tijd. Docker is gewoon de zoveelste oplossing, wat ook weer tijd eet. Je geeft meer en meer controle over alles aan zoveel verschillende applicaties en extensies, waar je uiteindelijk onderhevig bent aan de goodwill van die app ontwikkelaars.

Go geeft je een HTTP server op nog geen 5 minuten tijd ( in je code! ). Memcache, makkelijk in te bouwen op nog geen 200 regels. Wilt je HTTPS certificaten die automatisch installeren en automatisch updaten? Effen "golang.org/x/crypto/acme/autocert" toevoegen in je import, een paar regels code en voila. Automatisch certificaten dat geïnstalleerd worden op iedere klant dat je product draait. Geen gezeikt met manueel zaken in te stellen of "andere" oplossingen te vinden. Dezelfde binary kan je deployen op zoveel server als je wilt met veel minder mentale overheid van wat draait waar met elke versie.

Geen gedoe met installeren van weeral de zoveelste aparte applicatie voor het automatiseren. Leuk als je applicatie over meerder server loopt. Eenmaal deploy en voila. Je moet je geen zorgen maken van verschillen tussen je development en deploy omgeving want het is 1 binary met exact dezelfde "applicaties" iedere keer ingebouwd.

Programmeren

PHP is letterlijk de taal om quick en dirt iets te kunnen maken. Je kan enorm makkelijk zonder 2 keer na te denken een product schrijven. Eenmaal dat je daaruit wilt stappen, vooral in bedrijven, dan zit je weer geboden aan frameworks. Wat dan weer de framework hell creëert waarbij je meer de framework leert dan de taal. En wat omschakelen tussen bedrijven moeilijker maakt wanneer iedere bedrijf hun keuze van framework draait ( sommige frameworks hebben massieve verschillen tussen elkaar ).

Go heeft frameworks maar ik zie de meeste mensen en bedrijven gewoon basis Go draaien, met links of rechts een paar packages voor whatever extra dat je nodig hebt. Dit maakt het heel wat makkelijk om in bedrijf A en B code aan te kijken, zonder je blind te staren naar de zoveelste framework, met hun eigen idee's over hoe alles moet werken.

Ja, Go zijn error handeling is enorm frustrerend als je van PHP komt. Maar als ik eerlijk mag zijn, de hoeveelheid code dat mensen draaien in PHP zonder enige error handeling is ENORM!! Het gevolg is dat PHP het veel te makkelijk maakt voor data corruptie in je databank te krijgen, waarbij code X doet, een fout negeert en je half complete dat in je databank hebt.

Te veel mensen kakken op PHP voor wat vaak de schuld is van de programmeurs zelf dat geen goede ontwikkeling patroon hebben. Want PHP is zo flexibel dat je eigenlijk slechte gewoontes aanleert van het begin.

Als ik code compile met Go, zelf zonder enige (Unit) tests, ben ik vrij zeker dat deze code geen kritische problemen zal opleveren dat men data kan comprimeren.

Conclusie

PHP is perfect goed voor de meeste websites en ik wens PHP voldoende succes toe. Maar de wereld is veranderd en we stellen deze dagen meer eisen aan onze "web applicaties" dan vroeger.

Is Go soms frustrerend als hell. O JA! Als je 20 jaar gewoon bent van PHP's nogal zachte hand in je code en dan krijg je de norse professor Go dat je constant op je vinger slaagt, dan wens je zo graag terug te gaan naar die zachte lerares. Maar in het einde, is de norse professor die dat je meer aanleert en je veel meer zekerheid bied op data integriteit.

Mijn applicatie doet zaken dat ik nooit kon met PHP, niet zonder C/C++ applicaties te schrijven die PHP moeten ondersteunen of een half dozijn 3de partij applicaties.

En hier spreek ik vooral in context van Go as web oplossing. Go kan veel meer dan web applicaties. Dit geeft mij meer toekomstige flexibiliteit.

PHP loopt achter op de tijden. Er zijn genoeg mensen dat wilde dat PHP een ingebouwde HTTP server krijgt ( niet die single process test ding dat er nu in zit ). Maar dat is een richting dat men niet wilde uitgaan. Je ziet ook in de split van PHP en Facebook, hoe Facebook hun PHP een andere richting uitging.

Op zicht blijft PHP eigenlijk te lang, ter plaatse vastklampen en de markt groeit met meer en meer concurrenten dat meer kunnen. Het gevolg zie je langzaam, hoe minder en minder start-up's beginnen met PHP. Hoe bedrijven switchen naar full NodeJS oplossingen. Of hoe men puur Go gaat. PHP zal nog jaren meegaan, levend op hun oude gebruikersbasis maar langzaam zal dat cijfertje zakken. De verbeteringen in PHP zijn enorm welkom maar men losten nooit het fundamentele probleem op, waarom nieuws bedrijven liever andere technologieën gebruiken.

En de JIT is in mijn mening een slechte oplossing. Zal het PHP iets sneller maken, ja. Maar de kostprijs is ook dat de core code onleesbaar word en minder makkelijker word voor contributers aan PHP. Een JIT in PHP zal niet Python vervangen. Noch zal het de markt dat Go nu begint in te palmen vervangen want PHP's fire-and-forget aanpak bij requests is nog altijd dezelfde. Noch zal het NodeJS iets aandoen. PHP evolueert maar het is gewoon te laat. Men had meer serieus moeten zijn 10 jaar geleden ( en de markt veranderingen moeten inzien ), ipv zo lang op hun achterste te zitten.

PHP is nog marktleider en zal het nog lang blijven. Voor basis websites is er totaal niets mis met PHP. Het is ontworpen hiervoor en doet zijn job perfect. Maar eenmaal dat je een teen buiten zo een project zet, dan kost PHP je enorm op performance en andere gebieden.

Zoals je altijd zeggen: Gebruik de juiste tool voor de job. En voor de meer moderne SPA wereld of Hybride SPA oplossingen, is PHP gewoon niet gebouwd.

Genoeg tekst voor vandaag. Sorry voor de blog.

[Reactie gewijzigd door Wulfklaue op 26 november 2020 20:03]

Het gaat niet om de programmeer taal maar om de technieken die je toepast voor het juiste project. DDD, event sourcing, cqrs en welke storage.

PHP is een prima taal en vaak te vinden bij MKB en enkele grote jongens die het gebruiken zoals een bekende bank. Enterprise gaat vaak toch in JAVA en .net.

Echter je verhaal duid ook aan dat de technieken in je PHP tijd niet op orde waren, waarbij het tegenwoordig heel makkelijk is om alles op de laatste versies te draaien met dank aan containers en onze vrienden van alle grote cloud hosting bedrijven die heel toegankelijk zijn.

Ik ben blij dat je in GO hebt gevonden wat voor jou werkt.

Maar je verhaal is te kort door de bocht.

[Reactie gewijzigd door erics86 op 26 november 2020 23:17]

Je kan tegenwoordig zelfs serverless gaan met PHP.

Ik herken ergens wel de frustratie. Ik merk ook dat PHP het niet haalt qua performance en mogelijkheden bij Node/JavaScript en dat het daardoor wordt ingehaald door andere talen.

Maar als ik dan JavaScript moet typen dan moet ik echt huilen. Het is zo'n ongestructureerde rommel. Ja, ik weet dat er typescript is, maar dit zou out-of-the-box moeten werken.

Dat ligt hem voornamelijk aan de developer, niet zozeer de taal (ik bedoel, PHP?); als je het hebt over structuur dan zul je eerder denken aan de cultuur rondom een taal, ipv de taal zelf.

In mijn eigen ervaring, PHP leek pas netjes gestructureerd toen ik naar school ging, Java leerde, en Zend Framework uitkwam / een ding werd.

iig, zelfde met Javascript, dat ligt hem maar net aan de developer en cultuur. Angular 1.x was bijvoorbeeld een heel 'nette' manier om JS te schrijven.

Meeste talen werken vanuit de basis al met bijv. fatsoenlijke classes, strict types en typehinting. Waar JS dit pas via omwegen ondersteunt als je bijvoorbeeld typescript of een framework als Angular/Vue gebruikt.

Om nog maar daar te laten dat de package manager van JS ook een rommeltje is. Iedereen doet maar wat. Reclames, donaties, grote lappen output waar je niks mee kunt.

Ik denk dat dat hem inderdaad deels in de cultuur rondom de taal is, maar vergeleken met andere talen is het zeker niet de meest gestructureerde variant en dat vind ik dan wel weer het goede van PHP.

[Reactie gewijzigd door roooii op 27 november 2020 10:40]

In mijn beleving is PHP juist een ongestructureerde taal. Maar de laatste keer dat ik keek was het PHP 4.0
Wat betreft Javascript geef ik je helemaal gelijk. En moet er aan toe voegen dat het ene nieuwe framework na het ander uitkomt, vandaag is RAZOR hot en morgen Angular, en overmorgen?
Maar goed ik schrijf c#, misschien stel ik te hoge eisen, aangezien AOP al iets was wat ik sinds 2005 (soms) doe.

PHP 4.0 is niet echt een goede graadmeter om te bepalen of PHP structuur heeft

Niettegenstaande dat je veel moeite hebt gestoken in een pitch van Go en dat ik niet afbreuk wil doen aan die moeite: enkele jaren geleden spraken er ook veel mensen met dezelfde passie over Ruby On Rails en hoe het php volledig zou vervangen. Daar hoor je intussen niets meer van.

PHP is gigantisch en als er 1 ding is dat ik heb geleerd in mijn opensourcecarrière, dan is het dat je soms beter meesleutelt aan de bestaande oplossingen om die beter te maken dan te proberen het wiel te heruitvinden. Ik bedoel: kijk naar het zootje aan JavaScript packages...

Dat gezegd zijnde zie ik wel potentieel in Go, maar om nu te pretenderen dat het op alle vlakken de verheven programmeertaal boven PHP is, vind ik wat kort door de bocht.

RoR is nog best populair bij de SF startups, maar ik geloof niet dat het een grote community heeft in Nederland.

Je Avatar suggereert dat je veel PHP gebruikt iig

Als ik het goed begrijp zegt hij niet dat PHP op het web nauwelijks nog gebruikt wordt. Hij vraagt zich af of een hoop daarvan niet legacy is en of bedrijven die nu nog een groot nieuw project beginnen zo snel voor PHP zouden kiezen. Dat is een legitieme vraag wat mij betreft.

PHP is als taal in ieder geval niet legacy. Deze versie komt ook met allerlei toevoegingen die passen bij een moderne taal (zoals een nullsafe operator, named arguments en match ondersteuning). De package manager van PHP, Composer, heeft laatst ook een grote update gehad, ik vind 'm persoonlijk fijner dan bijvoorbeeld npm.

Veel MKB zetten hun software op in PHP, dat komt voornamelijk door frameworks als Laravel en natuurlijk Wordpress. Ik denk niet dat het stervende is. Laravel bijvoorbeeld, is écht een goed product als het op productiviteit aankomt.

Leuk, die toevoegingen ‘die passen bij een moderne taal’, maar hoeveel van de argumenten uit PHP: a fractal of bad design zijn nog van toepassing in PHP 8? Dit zijn problemen die niet aanwezig horen te zijn in een ‘moderne’ taal.

Ik heb even gekeken naar de blogpost maar een aantal dingen zijn de afgelopen jaren wel opgelost die in de blog staan. Zoals de 0 == "Foo" vergelijking returned nu false.

Het is natuurlijk niet allemaal in 1 major release op te lossen maar er wordt wel hard aan de weg getimmerd.

Het is / wordt een moderne taal misschien, maar ze moeten ook (voor een deel iig) code van 20 jaar geleden nog ondersteunen; je kunt dat niet gewoon weggooien, dan krijg je een schisme zoals Python 2 vs 3, of webapps die alleen op IE werken.

Je kunt wel een taal bouwen die naar PHP (en vnl de PHP runtime) "compilen", zo werken een aantal web-talen zoals Typescript, Coffeescript, Dart, etc ook; ze gebruiken JS als hun versie van assembly.

Inderdaad.

Ja er is nog heel erg veel PHP op deze planeet net als dat er bijvoorbeeld ook nog verrassend veel perl rond hangt en zelfs Cobal en Fortran niet dood te krijgen zijn. Maar ik kan me geen bedrijf voorstellen dat nu nog besluit dat hun volgende grote project absoluut in perl of in Fortran geschreven moet worden of dat er ook maar iemand is die nog denkt dat dat echt een goed idee is.

PHP is net zo'n verhaal ja er is nog heel wat PHP op deze wereld en het zal vast nog vele jaren bij ons blijven maar ik denk niet dat veel bedrijven een nieuw project op zullen zetten in PHP. Ik zie ze eerder naar dingen als node en typescript grijpen als ze een web pagina/service willen bouwen en bijvoorbeeld Java of python als ze een backend service opzetten.

Ik heb een tijdje met Python (Flask, Django), PHP (Laravel), Java (Spring Boot, Play!) gewerkt en ik vind PHP met Laravel echt niet zo heel slecht hoor. Sterker nog, al die Laravel kennis kon ik best meenemen naar Django (en elk andere MVC framework eigenlijk).

En waarom ben je dan van de een naar de ander overgestapt (en in welke volgorde)? Was dat omdat een opdrachtgever dat wilde? Technische vooruitgang? Kon je in de een meer dan ander?

Switchen van Studieprojecten, stage en een baan. Ik heb niet het gevoel dat ik alle frameworks op zo'n level heb gebruikt dat ik kan oordelen wat echt de voor- en nadelen zijn; het waren namelijk toevallig allemaal projecten van scratch, dus nog een kleine codebase. Laravel is erg goed gedocumenteerd en werkt daardoor ook wel fijn imo. Spring Boot vond ik bijvoorbeeld wat teveel boiler plate met een iets meer steep learning curve, maar at the end of the day maak je toch een RESTful API met deze frameworks (meestal), gebruik je Migrations, gebruik je een ORM laag, maak je gebruik van Middleware, OAuth2, noem maar op. Verder schrijf je dan vaak in Vue, React, Flutter, Swift, Android Native je front-end web/app client etc. Dus in principe ben ik vrij neutraal over de meeste talen en frameworks. Ik ben uiteindelijk ook maar een curious junior dev dat van alles uit wilt proberen

Wij werken anders altijd met Laravel voor de backend, waar we een Vue applicatie voorzetten. Ik zie zelf geen reden om PHP te mijden.

Sure er zijn andere alternatieven voor, maar PHP werkt imho prima en zal ik persoonlijk ook niet zo heel snel vervangen voor iets anders

Dit is ook mijn ervaring. Voor zover mijn ervaring, maakt het mij niet super veel uit of je nou een backend API bouwt met Laravel of Django/.NET Core. Uiteindelijk werk je toch wel met Postgresql/MySQL, Vue/React, Flutter/React Native/iOS (Swift) of Android (Kotlin) Native. In de meeste gevallen gebruik je zo'n MVC framework volgens mij toch echt voor de batteries-included packages/capabilities (built-in routing, ORM-laag, migrations, seeding, DI, en nog veel meer). Taal/framework wordt op een gegeven moment een preference denk ik. Kennis kun je toch wel meenemen naar andere talen en frameworks in de toekomst. Principe blijft vergelijkbaar.

Maar ik kan me geen bedrijf voorstellen dat nu nog besluit dat hun volgende grote project absoluut in perl of in Fortran geschreven moet worden

Oeh ik werk bij een bedrijf waar we zeker nog fortran projecten starten. Het is best nog actueel in wetenschappelijk onderzoek.

Heeft natuurlijk vooral te maken met het punt dat Fortran bepaalde rekenkundige optimalisaties kan maken die in C-achtigen meer overhead hebben en dat er aanzienlijk wat bibliotheken voor simulaties e.d. bestaan die op Fortran bouwen.
Voor iedere andere use-case verklaar ik je compleet voor gek als je in Fortran wil bouwen

Ik werk bij een online verzekeraar en al onze nieuwe API's zijn gebouwd in PHP

PHP is marktleider, maar dat is vooral te danken aan het feit dat het geen licenties vereist en dus goedkoop uitrollen is in een linux omgeving die ook weer geen licenties vereist. Als jij een grote hoster bent dan kun je dat dus goedkoper aanbieden. Als het goedkoop is word het veel gebruikt, daardoor krijg je veel software ervoor en tutorials, waardoor het weer veel word gebruikt. En zo is de cirkel rond.

Waar de marktadoptie bijna niets mee te maken heeft is hoe "goed" PHP als "taal" is. Voor de duidelijkheid, ik denk dat het een prima bruikbare taal is. Mijn persoonlijke voorkeur ligt elders, maar dat maakt PHP niet slecht. Het goed of slecht van de meeste talen hangt gewoon van programmeur voorkeur af en bedrijfseisen etc...

Overigens is PHP ondertussen behoorlijk oud... Is volgens mij een van de oudere serversided languages nog in gebruikt. Maar ook dat is geen argument voor "rommel" Maar je vraagt je wel af hoeveel legacy ze nog meesjouwen.

Ja, PHP is een taal die populair is bij de "kleine gebruikers" waardoor hosters die zich richten op kleine gebruikers weer zorgen dat ze PHP aanbieden enz. Je gaat als enterprise geen web applicatie draaien op een hostingpakket van een tientje per maand dus dat die hosters standaard alleen PHP aanbieden maakt hen niet uit.

Ik ben wel eens op zoek geweest naar goedkope hosters (onder de €50 per maand) die Python/Django aanbieden en dat valt tegen. Uiteraard PythonAnywhere en uit m'n hoofd had Hetzner ook wel wat pakketten maar de keus was vrij beperkt. Je bent dan toch al snel aangewezen op je eigen VPS draaien waar je Django of Flask op installeert.

Kleine gebruikers? De hele EC is overgestapt op Drupal, wat in PHP is geschreven. Witte Huis idem dito. Je zou ervan verschieten hoeveel grote websites op php draaien.

Het Witte Huis draait al een tijdje niet meer op Drupal. Het is nu Wordpress. Ook PHP.

Dat zijn grote gebruikers, daar heb ik het niet over. Ik heb het over de kleine gebruikers, en daar is PHP overduidelijk de populairste taal. Veel huis-tuin-en-keuken hosters richten zich op de kleine gebruikers dus ontkomen niet aan PHP aanbieden.

Is het Witte Huis wel een grote gebruiker? Bekend misschien, dus het zal vast een drukke site zijn, maar het is niet zo dat Trump er z'n nucleaire codes host of de onderhoudsplanning van Air Force One er op plant. Het is gewoon een "domme" CMS site met waarschijnlijk een handjevol ontwikkelaars, vergelijkbaar met veel andere kleine gebruikers.

Volgens mij is PHP gewoon marktleider op het gebied van web.

Dat valt enorm tegen hoor. Je vindt het niet terug in de statistieken van b.v. stackoverflow (vragen), indeed (banen), reddit (artikelen, news), GitHub (repos, code) of Amazon (boeken).

Als PHP op al die gebieden bij lange na niet de grootste is, zelfs minimaal, hoe kan het dan de marktleider zijn?

Natuurlijk is Wordpress veel gebruikt en PHP, maar C is toch ook geen marktleider op het web omdat de Linux kernel, Postgres en MySql in C geschreven zijn?

Natuurlijk is Wordpress veel gebruikt en PHP, maar C is toch ook geen marktleider op het web omdat de Linux kernel, Postgres en MySql in C geschreven zijn?

Lijkt me een vrij scheve vergelijking. De meeste mensen zullen de Linux kernel niet aan gaan passen in C.
Vrij veel mensen die Wordpress (professioneel) gebruiken zullen wèl in PHP uitbreidingen of aanpassingen schrijven voor hun website.

Meh, meestal zijn het bestaande plug-ins. Wordpress wordt niet voornamelijk als ontwikkel platform (framework) gebruikt, maar vooral als algeheel content management system.

Ik denk dat het meer scheef is in jouw ogen omdat je wilt dat het scheef is, niet omdat het echt scheef is.

Het is zeker waar dat heel veel website draaien op PHP. In dat opzichte zijn ze zeker marktleider (alleen WordPress is al goed voor meer dan 30% van alle websites). Maar hoeveel wordt er nu nog in ontwikkeld? Hoeveel developers schrijven (bijna) dagelijks PHP code? En als je nu wat nieuws begint, kies je dan voor PHP? Ik denk dat in dat opzicht PHP al lang geen marktleider meer is.

Ik heb even in quarantine gezeten, maar wat wordt er vandaag de dag gebruikt om websites te bouwen in plaats van PHP?

Python, JavaScript, Rust...
Ik heb eigenlijk meer het idee dat websites steeds meer cliënt-side JavaScript-applicaties zijn die zaken als SQL-queries vanuit de browser afhandelen in plaats van een statische pagina die dynamisch gegenereerd wordt door middel van dit soort queries.

In de praktijk zullen beide technieken wel gecombineerd worden.

[Reactie gewijzigd door 84hannes op 26 november 2020 20:08]

Niet helemaal. Het zijn javascript cliënts die http request doen naar een backend (php, java, python, nodejs etc). Die backend doet de query naar de DB

Odata en GraphQL laten developers dan wel weer queries schrijven in de client-code. Hoewel de daadwerkelijke SQL-query dan alsnog via een API verloopt.

OData en GraphQL genereren die laag voor je als je die niet zelf schrijft, de tussenlaag, of "controller" laag, zal wel moeten bestaan. Als jij je database direct via JS gaat aanspreken kan je buurman dat ook, vandaar dat er altijd server-side lagen tussen moeten zitten

Als je zo’n backend zelf schrijft kun je ook voor C, C++, Kotlin, Go, C# of wat dan ook gaan. Je bent dan op geen enkele manier gebonden aan specifieke server-talen. Als je een JSon-API gebruikt kun je voor heel veel talen de API-code laten genereren met bijvoorbeeld Swagger.

Met swagger kun je wrappers om de api end points genereren voor een makkelijkere integratie van consumers van de api.
Of server side basale input/output serialization. Maar that's it. De domain logic zul je toch echt zelf moeten bouwen. En dat is nou juist waar het voor een developer pas interessant wordt.

De domain logic zul je toch echt zelf moeten bouwen.

Uiteraard. Maar dat doe je in je favoriete taal, en dat is bij maar heel weinig mensen php. Mensen gebruiken nog liever Ruby!
https://insights.stackove...nd-wanted-languages-loved

Ik heb stiekem het idee dat al die client side JavaScript ook wel fijn is qua kostenbesparing.

Veel clients tegenwoordig zijn flink overspecced. Als je dan een deel van het werk van de server naar de client kan verplaatsen zonder dat je gebruiker dat merkt (het wordt er voor hen misschien zelfs wel sneller op) dan scheelt dat je in je uitgaven voor de server. Bij een Wordpress blogje over een verzorgpony maakt het niet uit, bij een webapp die 100.000 bezoekers per uur heeft kan dat toch wel flinke besparingen opleveren.

zonder dat je gebruiker dat merk

Daar zit hem juist de angel in. Je kunt alles wel client-side doen en lekker server resources besparen, maar je gebruikers zitten met apparaten die heet en langzaam worden, en waar de batterij snel op gaat. Als er een concurrent is die minder client resources gebruikt (b.v. door meer op de server te doen) zijn je gebruikers zo weg.

Denk je dat gebruikers überhaupt door zullen hebben dat het door die website komt, en zal dat op zichzelf genoeg reden zijn om te stoppen met het gebruik van de website/dienst? YouTube op oudere laptops werkt ook niet perfect, om een bekend voorbeeld te noemen, maar ik zie daarom niet zomaar mensen Vimeo of DailyMotion gebruiken.

Denk je dat gebruikers überhaupt door zullen hebben dat het door die website komt,

Ja, lees maar eens hoeveel klachten er zijn over apps of sites die te veel de batterij leegtrekken. "Niet de batterij leegtrekken" zien we hier ook veel meer als eis komen van de klant als we een mobile website/app ontwikkelen.

Client side JavaScript bestaat al lang, maar is geen ontwikkelteam als PHP/ c#/ go. Het is een techniek die gebruikt wordt om alleen bepaalde stukjes van een pagina te verversen met (nieuwe data), en kan met verschillende server side oplossingen worden toegepast, waaronder ook PHP.

Dat gezegd hebbende levert dat vooral een data besparing op en een reductie van de benodigde rekenkracht van je server. Veel frameworks werken al op die manier, maar staat verder, zoals gezegd los van je taal.

Dat gezegd hebbende levert dat vooral een data besparing op

Die data besparing is ook een beetje een myth. Nu met GrapQL komt dat eindelijk een beetje meer in zicht, maar met serverside rendering is culling van de data heel gebruikelijk en natuurlijk. B.v. een lijst met personen waarvan je alleen de naam rendert. Die gaat in HTML naar de client met alleen de naam. De HTML is heel repeterend dus comprimeert enorm goed. Merk je amper wat van in extra data.

Een naïeve client vraagt de lijst met gebruikers op bij een user endpoint, en krijgt dan allemaal extra data mee: achternaam, leeftijd, zelf woonplaats en adres. Dat levert dus juist geen extra data besparing op, maar kost je meer data.

Serverside rendering doet ook aan data aggregatie vanuit meerdere services server-to-server, wat vaak best snel is. De naïeve client request (te veel) data van elke logisch server apart. De user list, de inventory list, de latest deals, het aantal online users, je eigen statistieken, het zijn allemaal aparte requests.

Ja, met API gateways, en GraphQL is het op te lossen, maar dan moet de client dat WEL doen, EN het is extra gedoe (dus extra tijd, dus extra kosten).

Natuurlijk is dat waar, ik ga er wel vanuit dat je het 'goed gebruikt'/ 'goed toepast' en niet zegt, geef me alles, dan toon k daar één waarde van. Maar zo is het met alles als je het niet goed gebruikt. Als je de HTML juist slordig maakt en steeds wijzigt, comprimeert dat weer minder goed, en valt dat punt ook van tafel.

Als ik een naam van iemand wil hebben en tonen, wil ik ook alleen de naam opvragen/ ontvangen en niet allerhande extra gegevens. Dat werkt hetzelfde met SQL query's, vraag ik 100 velden op, en toon ik er slechts 1, dan is dat natuurlijk trager / zwaarder dan wanneer ik toch dat 1e veld opvraag.

Dat werkt hetzelfde met SQL query's, vraag ik 100 velden op, en toon ik er slechts 1, dan is dat natuurlijk trager / zwaarder dan wanneer ik toch dat 1e veld opvraag.

Precies, maar als je daar te veel data opvraagt is het meestal server to server over een snel datacenter lan. Natuurlijk is dit ook niet de bedoeling en vertraagt de boel, maar als je client to server te veel data opvraagt heeft dat veel meer effect.

Afhankelijk van hoe je "data engine" (als algemene term) in elkaar zit is het meestal ook makkelijker via een SQL query exact te specificeren welke data je wilt. Met veel end-points is dat gewoon een stuk lastiger, zeker als het data uit diverse bronnen (services) betreft.

Eigenlijk is dan nog de snelste manier om een soort virtuele pagina te renderen met al je data, en die hele "pagina" dan als 1 json structuur over de lijn te sturen. Maar hoe vaak zie je dit in de praktijk?

Dat zie je in praktijk niet of nauwelijks, omdat het te weinig toevoegt ten opzichte van de energie/ ontwikkeltijd die erin zit dit helemaal uit te optimaliseren.
Het is vaak sneller (ontwikkeling) om 1 dataset te creëren die je terugkrijgt voor bepaalde onderdelen, omdat je die set kan gebruiken voor meerdere doeleinden dan voor alles de specifieke set te creëren met alleen de benodigde velden.

Redenen om het wel uit te optimaliseren zijn bijvoorbeeld enorme besparingen op data gebruik en benodigde rekenkracht(en daarmee wellicht enorme kosten besparing), of vanwege performance / snelheid waarmee informatie gepresenteerd moet worden, maar (in mijn ogen) daar is het web minder geschikt voor, dit soort bijna micro optimalisatie. En is ook steeds minder belangrijk wegens steeds hogere snelheden over de digitale snelweg.

Java / Kotlin / Go / Python / Node.. en PHP.

Ruby, Python, Node, C#, Java.

Javascript

Ondanks de opkomst van allerlei cloudsystemen, is simpele shared webhosting in de meeste gevallen nog altijd de goedkoopste en eenvoudigste oplossing voor mensen die "gewoon een website" willen hebben. Daarom is PHP nog altijd zo populair, want het is een kwestie van de files uploaden en het werkt. Programmatuur geschreven in andere talen brengt in zo'n scenario bijna altijd meer kopzorgen met zich mee.

Dat is leuk voor een hobby-website, maar juist een probleem als je het serieus gaat gebruiken. Wat gebeurt er als je meerdere files aanpast, en er komt een request binnen als je wel het ene bestand, maar niet het andere hebt aangepast? Vergelijkbaar, wat gebeurt er wanneer er een request binnenkomt terwijl je een bestand aan het aanpassen bent? Een foutmelding lijkt me niet echt acceptabel voor een grote site, dus je zult toch side-by-side moeten uitrollen.

Het overgrote deel van het internet bestaat uit dergelijke "hobby-websites". Er zijn talloze bedrijven met slechts een handjevol medewerkers en veruit de meeste websites hebben hooguit enkele tientallen bezoekers per dag.

Als je het IT-nieuws leest, zou je denken dat iedereen opereert op de schaal van Amazon of Google, maar de realiteit is dat er een heleboel gebeurt op kleinschalig niveau. En daar is PHP meer dan geschikt voor.

Voor veel usecases is PHP prima. Het lijkt alsof PHP bij sommige mensen nog steeds het 'Personal Home Page' imago heeft.

Het probleem is dat je php ook zonder fatsoenlijk framework kan gebruiken. Dan kom je ellende tegen daar wordt je eng van.

Ik heb geen ervaring met laravel, maar daar heb ik wel goeie verhalen over gehoord. Zelf hou ik het liever bij c#

Het gekke is dat ik dat soort argumenten niet vaak hoor voor een taal als javascript bijvoorbeeld. Terwijl daar natuurlijk exact hetzelfde geld.

Bij PHP lijkt er toch meer een stigma op te rusten.

Ik denk dat het voor een server-side taal belangrijk is dat het een stevige fundering heeft. php zelf heeft dat niet, je hoeft maar te knipperen met je ogen en er zit ergens een kwetsbaarheid in. Een goed framework kan dat verhelpen.

Dat kan met eigenlijk alle talen wel, ASP. Net is een framework, de onderliggende taal is prima zonder framework te gebruiken en ook flink mee te rommelen hoor. (Zij het dat er meer controle op bepaalde punten in de taal zitten dan in PHP)
Ik ken voorbeelden waarbij ook dan (andere talen, zelfs met frameworks) een float ergens in wordt gestopt, bij een waarde wordt opgeteld en dan naar int wordt gecast om vervolgens te kijken of de int >= 0.
Hint: Leuk wanneer je float te groot wordt voor je int.

Ik denk dat voor velen die ontwikkelaar zijn de PHP taal en omgeving (frameworks) relatief onbekend is omdat het niet wordt geleerd op school. En onbekend maakt onbemind.

Een taal kan je bepaalde zaken afdwingen, maar een slechte ontwikkelaar kan er in elke taal een zooitje van maken, net zoals je een slechte chauffeur in een goede auto kan zetten, het wordt dan niet ineens een goede chauffeur ofzo.

Of het voordeel van PHP is dat je het zonder Framework kan gebruiken en je heel snel on speed kan zijn.

Wanneer je ziet wat er in de meeste talen met frameworks nodig is om een Hello World in een browser te toveren kan dat in PHP in theorie met een enkele regel. Zelfde als bij ASP bijvoorbeeld.

Het mooie van PHP is dat je ook hele mooie frameworks zelf kan bouwen wanneer je wil en eigenlijk zonder moeilijke constructies eenvoudig kan beginnen met een maagdelijke lege file.

Er zitten zoveel valkuilen in qua beveiliging, ik denk dat het beter is om een goed ondersteund framework te pakken. Tenzij je echt enorm goed weet waar je mee bezig bent.

Wanneer iemand niet weet waar hij/zij mee bezig is, vraag ik mij af waarom zo iemand überhaupt toegang tot toetsenbord en muis krijgt.

Het probleem is dat men zich verschuild achter frameworks en taal(limieten).

Zit er een security bug in een applicatie.... schuld van framework,
Belangrijke data achtergebleven in geheugen... ja, schuld van taal, java garbage collector doet werk niet goed.
SQL injectie... Ja, Framework form handler zit fout.

Probleem is dat ik als "klant" cq opdrachtgever daar eigenlijk geen moer mee te maken heb. Dus verwacht ik van fabrikant/leverancier dat hij de volledige controle heeft en houd om dat soort basale zaken te voorkomen. Ik weet nog dat ik met een traject bezig was met een grote Franse leverancier en het SKN. Ook over data framework waar ze niks aan konden doen. Sorry maar dan hebben ze gewoon het verkeerde framework was mijn opmerking.

[Reactie gewijzigd door Wim-Bart op 27 november 2020 13:51]

Het lijkt alsof PHP bij sommige mensen nog steeds het 'Personal Home Page' imago heeft.

PHP werd ooit populair omdat het de prutser generatie (als geuzennaam) aansprak. Nu PHP door de jaren heen steeds meer Java, C# achtig is geworden kun je je afvragen wat nu echt de doelgroep is geworden. Moest PHP het Personal Home Page wel echt loslaten en een Java/C# worden? Java en C# bestaan immers al.

Ik denk dat het voor PHP wel echt noodzaak was om te ontwikkelen. Anders hadden we het er nu niet meer over en werd het niet zo veel gebruikt.

Hoewel PHP meer richting talen als Java en C# gekropen is, zijn er wezenlijke verschillen. PHP maakt bijvoorbeeld gebruik van dynamische types. Verder is een belangrijk verschil dat PHP geïnterpreteerd wordt en niet gecompileerd.

Ik denk dat PHP nog steeds toegankelijk is voor mensen die hobbymatig wat met het web willen doen. Waarschijnlijk toegankelijker dan de meeste andere talen gezien je het heel makelijk tussen je HTML in stopt. CMS platformen zoals WordPress zijn dan ook relatief makkelijk te tweaken door mensen met weinig PHP kennis.

Ik denk dat het een taal is die prima kan bestaan naast andere talen. Het heeft zichzelf bewezen door het vele gebruik. Dat komt volgens mij juist omdat het zowel hobbymatig als professioneel goed is in te zetten.

Net voor de eeuwwisseling werd ik door een mede-student gewezen op een ding wat volgens hem heel populair ging worden op het web: PHP 2. Het alternatief was destijds CGI waarbij Apache voor ieder request een (doorgaans Perl) interpreter opstartte. Dat schoot allemaal niet echt op, maar PHP was geïmplementeerd als een Apache module waardoor de interpreter 'meeliftte' op de aanwezige pool Apache webserver processen. Draaide allemaal ongelofelijk rap op mijn Pentium 166MHz. Daarnaast zat er ook een vrij goede 'binding' voor de mysql database client in. Naar mijn mening waren de cruciale factoren toen dat het 1) snel was en 2) relatief eenvoudig op te zetten en voor te programmeren.

Dit werd al vrij snel opgepikt in de OSS wereld en de beroemde "LAMP" stack, wat zo'n beetje 'out of the box' op iedere Linux distributie werd aangeboden. Aangezien het zo laagdrempelig was kreeg je een beetje het "Visual Basic" effect waarbij de reputatie van een programmeertaal onderuit ging omdat er zoveel beginners rommelcode in schreven.

Met de nieuwe features is het gelukkig makkelijker geworden om een fatsoenlijke software architectuur neer te zetten, maar ik vermoed dat er anno 2020 ook nog een hoop gerommeld wordt in PHP

Je doet net alsof PHP een soort verloren iets is? Denk dat meer dan de helft van het internet gewoon nog op PHP draait hoor. Juist voor backend API applicaties is het zeker geschikt. Ik zou PHP echt wel in mijn wapen arsenaal opnemen als het bij de usecase past.

Denk dat meer dan de helft van het internet gewoon nog op PHP draait hoor.

Maar wat gebruikt de helft van de programmeurs vandaag de dag voor taal? Ik heb sterk het gevoel dat dat juist niet PHP is.

Github laat zien dat er over de laatste 5 jaar nog aardig wat contributeurs met PHP werkten. Onder het kopje 'Top languages', ongeveer 80% naar beneden scrollen bij bovenstaande link, zie je een grafiek. PHP staat al een tijdje op plek 4.

Klopt, maar plek 4, geeft dat aan dat meer dan de helft van de programmeurs in PHP werkt?

Red Monk zet PHP ook op 4:

https://redmonk.com/sogra...7/language-rankings-6-20/

Combineer je met PYPL, dat zie je PHO op 5 met 5,92%:

https://pypl.github.io/PYPL.html

Tiobe zet PHO op 8 met 1,79%:

https://www.tiobe.com/tiobe-index/

Niemand zegt dat het allemaal *weinig* is, het blijft in de top tier, maar ik kan er niet uit afleiden dat PHP op de een of andere manier de taal is die de meeste programmeurs (50%+ dus) gebruiken.

Het klopt inderdaad dat de interesse voor sommige andere talen groter is en dat die interesse groeit. Zoals je bronnen laten zien zit het percentage developers dat aan PHP doet ergens tussen de 1.5 en 6 procent. Dat is zeker niet de helft van de developers.

Toch is bijna 80% van de websites op PHP gebouwd. Een groot deel van de PHP draaiende websites zijn min of meer kant en klare pakketen zoals WordPress. Die pakketen en de plugins daarvoor zijn eenmaal ontwikkeld. Daar zit denk ik niet veel maatwerk aan voor het gros van de websites. Er zal ongetwijfeld ook nog veel legacy zooi in omloop zijn.

Volgens mij kun je als ontwikkelaar zonder problemen een baan vinden als PHP ontwikkelaar. Er is misschien meer vraag naar ontwikkelaars van andere talen, maar daar zijn dan ook meer ontwikkelaars die mee dingen naar de baan.

Als je een beginnend ontwikkelaar bent kun je gewoon de talen leren die je zelf interesseren. Zolang dat geen dode talen zijn kun je vast wel ergens werk er in vinden. PHP is verre van dood, maar als andere talen je meer interesseren kun je deze zonder problemen overslaan.

Toch is bijna 80% van de websites op PHP gebouwd.

Ik vind die claim bedenkelijk. Oud type scanner dat voornamelijk naar de .php extensie kijkt, en websites die geen extensie hebben negeren. Om maar even een willekeurige website te nemen:

https://w3techs.com/sites/info/theguardian.com

Die gebruikt Scala en Java. Maar dat geeft die w3techs compleet niet weer.

Daarnaast, kant en klare paketen zoals Wordpress vind ik een beetje gek om op die manier te gebruiken. Zoals in andere antwoorden hier al; dan kun je net zo goed zeggen dat het hele web op C draait, omdat MySQL, Postgres en Linux C zijn. Het is niet totaal onwaar, maar in de discussie waar het gaat over waar mensen in programmeren is het toch niet helemaal van toepassing.

[Reactie gewijzigd door flowerp op 27 november 2020 23:23]

Ik ben het wel met je eens dat die statistieken misleidend of in jouw woorden bedenkelijk zijn. Dat men komplete paketten in PHP neer zet geeft natuurlijk helemaal een vertekend beeld. Daarom benoemde ik dat ook. Als je die niet mee telt en alle legacy zooi ook niet mee telt, dan is het PHP marktaandeel natuurlijk een stuk kleiner.

Uiteindelijk is het voor ontwikkelaars natuurlijk interessant welke talen op dit moment gebruikt worden en in welke mate. Hoeveel andere developers bezig zijn met een andere taal of daar interesse in hebben zijn hier waarschijnlijk betere indicatoren voor.

Het was niet mijn bedoeling om het beeld te vertekenen, enkel om te verkennen waar PHP nu staat in het ontwikkel landschap. Ik denk dat het nog relevant is. Echter zeker niet waar de meeste ontwikkelaars mee bezig zijn op het moment.

Zelf ben ik professioneel niet met PHP bezig. We werken met Java, maar ik zit meestal in de front-end (HTML, CSS, JS). Voor prive projecten gebruik ik nog wel eens PHP. Ook omdat ik het leuk vind om wel eens naar een andere taal te kijken. Zo vind ik het ook leuk om wel eens een projectje met C of Lua te doen.

Wordpress has entered the chat

Alsook drupal, en waarschijnlijk tig andere cms'en

maar zijn er anno 2020 nog echt bedrijven die nieuwe sites bouwen in PHP?

https://slack.engineering/taking-php-seriously/

Ironisch genoeg gaan ze direct in op hoe ze hack gebruiken om de negatieve delen van PHP te mitigaten.

Drupal, WordPress ...

Symfony, Laravel, Phalcon, Yii

Joomla .

Don't feed the troll.

Lol, wat een gast. Getuigt wel van een goede dosis humor!

"Voor backend applicaties kan ik het me al helemaal niet voorstellen dat een zich zelf respecterend bedrijf nog met PHP aan moddert. "

De Europese unie bijvoorbeeld? (geen bedrijf maar wel een grote speler)

https://eufossa.github.io/symfony-hackathon-2019/ (EU-Free and Open Source Software Auditing Community) (en ja die man links met die bril, dat ben ik )

PHP is meermaals afgeschreven als oud, en zwak. Maar de laatste jaren is er de nodige aandacht bestaat aan betere kwaliteit en consistentie. PHP 8 rekent serieus af met een paar grote fouten uit het verleden. En zal zeker nog de komende tijd een flinke speller blijven.

[Reactie gewijzigd door s.stok op 29 november 2020 19:51]

Dit vind ik nogal krom, ja php is niet de nieuwste meer, maar het word voor 90% van alle websites en webapps nogsteeds gebruikt. Wordpress en laravel applicaties maken daar al meer dan 60% van op. Er zijn alternatieven die misschien beter/sneller zijn, ja, maar wat je nu benoemde klopt van geen kant.

Legacy producten ja natuurlijk gebruiken die dat nog ik heb het over grotere projecten nieuwe services. Zijn er echt nog bedrijven die op Maandag ochtend tijdens een Zoom call besluiten dat dit nieuwe project van de grond af aan in PHP opgebouwd gaat worden?

Dat is precies wat ik bedoel met er zijn ook sites die nog op perl draaien maar laten we eerlijk wezen er zijn geen bedrijven meer te vinden die een nieuwe service opzetten op basis van perl of wel?
Het lijkt me dan ook dat PHP niet veel anders is. De legacy producten zullen nog vele tientallen jaren blijven bestaan dat weet ik ook heus wel maar zullen er echt nog bedrijven die nieuwe projecten in PHP bouwen?

90% van de web apps is onzin. Al is het maar J2EE dat zelfs tijdens de hoogtijdagen van PHP een flink aandeel voor z'n rekening nam. Nu zijn het node typescript en meer van dat soort talen die hun aandeel opeisen en natuurlijk zijn veel van die java projecten echt nog lang niet dood zeker niet binnen de grote corporates die vaak de geen waren die ze origineel schreven. Toch even opgezocht volgens: https://w3techs.com/technologies/details/pl-php is het 79% (veel meer dan ik verwacht had) en ruim 41% daarvan is nog php5 ook. Dat is schokkend om eerlijk te zijn.

Ja, die bedrijven zijn er nog altijd. Zat zelfs.

Ja, want er is nog een belangrijke factor: beschikbare werknemers met skills.

Leuk een project met Angular of ReactJS, maar dan kom je al snel terecht bij een peperdure freelancer.

Zijn er echt nog bedrijven die op Maandag ochtend tijdens een Zoom call besluiten dat dit nieuwe project van de grond af aan in PHP opgebouwd gaat worden?

Jup, aanstaande maandag weer

het blijkt wel dat je toch wat last hebt van tunnelvisie als je denkt dat PHP niet meer gebruikt wordt. ik werk ook wel eens met nodejs en django (of C#) maar veruit de meeste applicaties creër ik in laravel met forge envoyer of vapor, ik zou niet weten waarom dit niet zou kunnen meekomen met nodjs of java of welke andere taal ook.

Ja.

Ik werk bij de een van de grotere webwinkels voor zakelijk Nederland. Wij hebben onze nieuwe site gemaakt in PHP+Twig (Frontend) + GoLang (backend).

Waarom?

Het personeel dat we hebben, kent PHP van voor naar achter. Er is personeel voor te krijgen in tijden waarin personeel vinden zo ongeveer het grootste probleem is wat het bedrijf kent. (Corona even niet meegerekend.)

Als je denkt dat PHP legacy is, dan kom je echt van een andere planeet dan waarin ik leef. En eerlijk gezegd heb ik voor het maken van simpele applicaties op het web die backends aanspreken weinig problemen met PHP. Als daar serieus backend werk bij komt kijken grijp ik tegenwoordig naar Go. We hebben naar NodeJS gekeken, maar de cleanheid van Go sprak ons meer aan en alles wat we nodig hadden kunnen we er mee doen.

Dus ik ben zelf wel blij dat ik GoLang erbij heb geleerd voor backend werk, maar er zijn genoeg werknemers die daar niet zelf de tijd/moeite in steken of zin in hebben. Daar moeten we als bedrijf dus maar mee leren leven en keuzes maken.

[Reactie gewijzigd door Crew One op 26 november 2020 22:18]

Overigens meldde Microsoft eerder al PHP 8 niet te ondersteunen.

Enigszins misleidende zin. Er zijn gewoon Windows-builds van PHP 8, deze worden alleen niet meer door Microsoft zelf geproduceerd.

Evenals:

Voor websites, waar PHP het vaakst gebruikt wordt, is de winst waarschijnlijk minimaal.

Het is erg specifiek van de workload maar er zijn zeker real-world applicaties waar het grote effecten heeft gehad al in de beta's.

Noem dan even de web apps waar het die grote (positieve? ) effecten heeft.

Als ik https://www.php.net/releases/8.0/en.php zelf bekijk zie ik echte sites er weinig op vooruit gaan met de JIT.

[Reactie gewijzigd door Olaf van der Spek op 26 november 2020 18:51]

About a 10% out-of-the-box improvement with PHP 8.0 over the current PHP 7.4 stable series, but at least for some areas more performance can be squeezed with just-in-time compilation. Stay tuned for that data soon and the official PHP 8.0.0 release due out on Thursday.

Bron: https://www.phoronix.com/...HP-8.0-Features-Benchmark

Ik ben toch erg blij met deze cijfers, zeker als je daarbij dus nog JIT bij optelt.
Persoonlijk denk ik wel dat veel frameworks op vooruit gaan met JIT, over algemene sites (e.g. WP) weet ik het niet, maar die zijn veelal ook niet zo goed geoptimaliseerd.

[Reactie gewijzigd door foxgamer2019 op 26 november 2020 18:57]

Let wel dat dit de eerste versie is met JIT support en de eerste versie in de 8.x reeks. Het is een basis om verder te kunnen optimaliseren.
Zo'n optimalisatie zag je ook terug in de 7-reeks, met elke minor versie werd PHP een beetje sneller.

Kan je PHP nu niet beter in WSL2 draaien?

Het wordt wel moeilijk voor programma's als XAMPP/EasyPHP, maar om eerlijk te zijn vond ik destijds al een VM met Linux (of zoals nu native Linux, docker of met Homestead eventueel) betere opties.

Inderdaad. Vooral als je ontwikkeld voor een Linux productie-omgeving.

Waarom zou het moeilijk worden voor programma's als XAMMP/EasyPHP? Qua compileren worden de verschillen tussen Windows en Linux juist steeds kleiner, omdat Visual Studio 2019 steeds beter compatibel is met de Linux compilers.
De kleine afwijkingen die nog in de PHP-sources zaten voor Windows zijn weer verder verdwenen. Zodra PHP extensies aangepast waren voor PHP 8 waren ze vaak ook vrijwel direct bruikbaar op Windows. Vaak was de enige aanpassing dat in PHP 8 de include van win32/php_stdint.h vervangen moest worden door main/php_stdint.h. Zo iets:

#if defined(_MSC_VER) && _MSC_VER <= 1916
#include <win32/php_stdint.h>
#else
#include <main/php_stdint.h>
#endif

Zie https://www.apachelounge.com/viewtopic.php?t=6359 voor PHP 8 builds met veel extensies.

Ik wist niet dat de builds beter konden, maar dit lijkt me een user project en niet echt officieel? Dat kan prima natuurlijk, maar veelal beter als er ook een grote community achter zit.

Persoonlijk zou ik het wel makkelijker vinden met iets als WSL, zeker omdat je iets als een package manager kan gebruiken voor installeren van extensies en libs. Het is weliswaar niet even snel als native, maar WSL wordt steeds beter en sneller, uiteindelijk rol je de code meestal ook uit op een Linux-platform.

Maargoed, er zijn zoveel verschillende smaken en ideeën hierover.

Natuurlijk is het een user project, maar wat is er wel “officieel”? PHP extensies kennen stuk voor stuk wel een community. Mooi voorbeeld is dat een Linux gebruiker vroeg om een port van de LibXL extensie naar PHP 8. Ik kwam een heel eind:

https://github.com/iliaal/php_excel/issues/264

Er bleef een puntje over en toen heb ik even een ping gedaan naar @cmb69, die nu de officiele PHP voor Windows builds doet en ook nog eens release manager van een PHP 7 (7.2?) versie was. Die zette me op het goede spoor. Gevolg: de sources van de Excel extensie zijn nu ook geschikt voor PHP 8, zowel op Linux als op Windows. Linux gebruikers compileren hem zelf en ik compileer hem voor de Apachelounge lezertjes.

Docker is sowieso een zegen vind ik. Wij deployen de meeste PHP applicaties via CI en dan is het developen in een docker-compose situatie die nagenoeg identiek is aan de test en live versie geweldig. Als ik dat vergelijk met een aantal jaren terug, toen je zat te klooien met lokale PHP installaties of een centrale server die je via NFS, FTP of SMB benaderde... alleen maar om te zorgen dat je dezelfde versie van PHP had met de juiste plug-ins! Idem voor nodejs trouwens, hoewel de verschillen tussen de node versies daar minder groot zijn, mede door babel.

In de enterprise wereld waar ik rond loop, zie ik het vrijwel nooit.. het is C# en Java wat de klok slaat.. al zie je in de scientific hoek, ook bij die bedrijven Python ook vaak

Ik ben als freelancer ook werkzaam in de Enterprise wereld waar wel veel PHP gebruikt wordt.

Vergeet niet dat ieders persoonlijke realiteit maar een heel klein deel van de wereld is. Wat jij wel of niet ziet betekent niet dat dit overal ook zo is.

Dat klopt.. dat claim ik ook niet en als je expertise voornamelijk ligt bij c# dan zie je dat het meest..

dan zie je dat het meest.

Dan lees je de reactie van @rjd22 toch niet goed. Jij ziet namelijk niet (volledig) wat het meest gebruikt wordt, net als dat rjd22 dat niet ziet en vele andere developers niet. Ik werk ook als freelance PHP'er en heb voor diverse grote bedrijven mogen werken, waaronder een telecombedrijf, een mediabedrijf en een overheid. En binnen dat soort organisaties zie je vaak meerdere programmeertalen gebruikt worden. En laat ik nou nooit C# tegenkomen

Dus laten we eens kijken naar wat objectievere bronnen:

• De Tiobe index (algemene index) zet PHP op plaats 8 en C# op plaats 5. Extreem zwakke opwaartse trend voor allebei.
• De PYPL index (welke taal mensen willen leren) zet PHP op plaats 5 en C# op plaats 4 beide met een neerwaartse trend in populariteit.
• De StackOverflow developer survey van 2020 wat betreft professioneel gebruik zet PHP op plaats 9 en C# op plaats 7. Wat betreft trends zegt de survey dat in termen van 'developer dread' ("% of developers who are developing with the language or technology but have not expressed interest in continuing to do so") staat PHP op plaats 6 (samen dus met zaken zoals VBA, Assembly, C en Objective-C) en C# op plaats 18.

Gebruik zelf noch PHP noch C# op het moment (alhoewel ik vroeger lang met PHP heb gewerkt), dus het maakt geen verschil voor mij, maar interessant om te zien.

[Reactie gewijzigd door David Mulder op 26 november 2020 20:23]

Wat jij wel of niet ziet betekent niet dat dit overal ook zo is.

Het geeft echter wel een hint, zeker als je bij veel verschillende bedrijven kijkt. Combineer je het dan met dingen als stackoverflow (vragen), indeed (banen), amazon (boeken), GitHub (code), en je ziet eigenlijk overal weinig van PHP terug, dan is het niet gek om te denken dat PHP misschien niet zoveel meer in geprogrammeerd wordt.

Het geeft ook geen hint. Ik zie zelf bar weinig van Go, Java of C#. Ik weet zeker dat veel mensen ermee bezig zijn maar in mijn realiteit van de wereld (of de zoek bubbel waarin Google me gestopt heeft) is daar weinig van te zien.

In mijn bubbel is PHP bruisend en weet ik van vele grote bedrijven die PHP nog dagelijks gebruiken voor backend systemen of grote process management systemen maar ook front facing API's.

Feit blijft dat ieders bubbel maar een klein onderdeel van de werkelijkheid is. Te vergelijken met een speldenknop in een groot weiland. En dat dat we dus daarom dat niet kunnen gebruiken om te zeggen dat een bepaalde taal bijna niet meer gebruikt wordt.

Let op dat ik dus ook stackoverflow (vragen), indeed (banen), amazon (boeken) en GitHub (code) noem.

Als PHP inderdaad zo enorm veel gebruikt werd, dan zou je het daar met kop en schouders boven andere talen moeten uitsteken. Dit is echter niet het geval.

Zat PHP in enterprise wereld hoor. Java natuurlijk wel heer en meester daar.

Toch wel trots op mijn persoonlijk 100% zelf geschreven PHP websites met ook nog een interactief krommingsveldprogramma.
Geen idee hoe ik gemod ga worden maar noem toch in elk geval één van de sites: https://dbphysics.com ,vond 't wel leuk gedaan, mijn eerste PHP project.
Alles PHP 7.x. Hopelijk geen weggevallen functies bij eventueel latere migratie naar PHP 8. Maar zo snel de hoster 't implementeert toch maar even checken of de website 100% compatible is met PHP 8.

Als jij zo handig bent zet je dan niet zelf een simpel VPSje op? Heb je controle over veel meer zaken.

Dat je handig bent met een programmeertaal maakt je niet automatisch ook handig met het (zo veilig mogelijk) en beheren van een VPS

Betaal dankzij een actie tarief €0,45 p/m voor mijn hosting, nergens goedkoper.
En het hele server gebeuren hoef ik niet op te letten, (security) updates, etc... geen zin (meer) in.
Gewoon 'set & forget', ideaal.

Volgens de ontwikkelaars zouden beheerders niet veel moeite moeten hebben tijdens de migratie als ze de vorige 7.x-versies al hebben geïmplementeerd.

Het is te zeggen. De functies die eruit gegaan zijn geven nu een deprecation warning wanneer het uitgevoerd wordt, maar werken nog wel. Wie niet naar z'n logs kijkt zal dus ook niet zo maar klakkeloos kunnen upgraden.

[Reactie gewijzigd door runelaenen op 26 november 2020 18:27]

Tja, een goede developer houdt natuurlijk de roadmap en changelog van PHP bij, en weet jaren van te voren wat er gaat veranderden

Jammer dat de officiele Docker images nog achter lopen: https://hub.docker.com/_/php

Mooie updates. Ik gebruik zo'n beetje alles wat ze toegevoegd hebben al in andere talen, zeker geen loze toevoegingen.

Hier is een mooi filmpje met de populariteit van de verschillende frameworks (gebaseerd op github stars):

https://www.youtube.com/watch?v=9z_2wmJOom4

in 2020:
1. Larvel - PHP
2. Flask - Python
3. Django - Python
4. ExpressJS - JS
5. RoR - Ruby

Zeer blij met deze nieuwe versie. php is enorm gegroeid de afgelopen jaren. Ik heb truien laten printen met een heel groot php 8 logo achterop voor mijn team