Es gibt meistens Unterschiede (mal größer, mal kleiner) zwischen "was mag ich persönlich am liebsten" und "was kann ich ertragen, was insgesamt am besten ist". Was ich damit sagen will: nützlich ist, was viele können. Worse Is Better. Dein Framework mag hervorragend sein, aber kommerziell wäre der Einsatz wahrscheinlich eine große Fehlentscheidung, weil Du Schwierigkeiten haben wirst, jemanden zu finden, der es beherrscht. Natürlich kannst Du jemanden einstellen, der es noch nicht kennt und den darauf trainieren, aber auch das werden nicht allzu viele Leute mitmachen, die Alternativen haben, weil es für sie totes Wissen ist, das sie nicht bei ihrem nächsten Job wiederverwenden können.
Das ist, glaube ich, auch der Hauptgrund, warum PHP so massiv viel verwendet wird, obwohl es in jedem einzelnen Bereich Sprachen gibt, die besser geeignet sind (da mag man sicher drüber streiten, aber Java, C# etc für Enterprise, Python & neue Hype-Sprachen für ML & Co, Ruby für Web, JS für manches andere): Du findest überall Menschen, die PHP können, PHP ist bei vielen Teams der kleinste gemeinsame Nenner mit dem jeder arbeiten kann, Du kannst auch durchschnittliche Menschen einsetzen, nicht nur Informatiker. Und am Ende hilft es ja niemandem, wenn Du mit Technologie X in 10 Jahren die perfekte Version deiner Software hast, Du willst in 10 Wochen eine lauffähige Version haben.

Ich glaube: neue Frameworks kannst Du heute nur noch als Großunternehmen in den Markt drücken (und dann musst Du dir sehr sicher sein und viel Geld in die Hand nehmen) oder auf Open Source setzen und Entwickler überzeugen. Letzteres ist auch nicht leicht und klappt am Ende vor allem dann, wenn es Leute gibt, die mit den bisherigen Lösungen nicht wirklich klarkamen, weil sie ihnen zu viel oder zu wenig Magic hatten, zu viel oder zu wenig Plugins, zu viel oder zu wenig explicity, zu viel oder zu wenig Mindestwissen. Mein Gefühl ist, dass vor allem die Frameworks erfolg haben, bei denen der Einstieg leicht fällt, die aber nach oben hinaus nicht zu früh umständlich werden. Und Framework heißt da nicht nur Kernel + Routing, sondern auch ORM, Form-Handling und -Validation, 3rd-Party-Erweiterungen und so weiter - und ganz wichtig: Community und Eco-System, Du brauchst als Entwickler ja nicht nur Code und Dokumentation, sondern auch Schulungen, Kurse und vielleicht die eine oder andere Konferenz.
Das ist alles auch ein Kreis, entweder verstärkt es sich selbst (mehr Entwickler => mehr Leute, die damit Geld verdienen => mehr neue Features => mehr 3rd-Party-Plugins => alles wird einfacher => mehr Firmen wollen es nutzen => für Entwickler ist es sinnvoll, es zu lernen => mehr Entwickler) oder es wird ein Teufelskreis (keiner nutzt es => keine Firma nutzt es => keiner schreibt neue Module => keiner will's lernen, weil er sich keine Zukunft davon verspricht => keiner nutzt es). Ganz ähnlich, so mein Eindruck, ist das auch mit Perl gelaufen, da ging's irgendwann in so einen Teufelskreis und immer mehr Leute springen ab, weil es ihnen um praktischen Nutzen geht und sie sehen, dass sie vielleicht noch ein oder zwei Jahre Perl machen können, aber dann irgendwann ihren Job los sind und keinen neuen finden werden. Die Lampenputzer, die rechtzeitig verstanden haben, dass die Zeit der Gaslampen vorbei war, als die Elektrizität massentauglich wurde, haben sich angepasst.

Quote

Ich hätte da jetzt noch eine Frage dazu, heißt das nun dass Perl mit DBI für SQL Injection nicht sicher ist??

Wer behauptet denn sowas? Perl hat sogar 2 Funktionen zum Quoten die explizit aufgerufen werden können, sowas hat PHP nicht.

Wenn Du in Perl mit prepared Statements arbeitest, werden diese Funktionen implizit aufgerufen, was SQL Injektionen verhindert. Und was in Perl auch geht: Platzhalter in Funktionen die über den $dbh aufgerufen werden, auch da wird implizit gequoted.

Die eigentliche Zweckbestimmung für prepared Statements ist jedoch eine Andere nämlich die Performance.

MFG

Steh alles in der Doku, man muss sich einfach mal richti damit befassen.