PHP Framework gesucht

vilden

Lt. Junior Grade
Registriert
Juli 2007
Beiträge
481
Hey ho :)

Ich suche z.Z. ein Framework was mir die Arbeit etwas erleichtert. Ziel ist es ein PHP-Frontend für eine Datenbank (mysql) zu erstellen um die darin enthaltenen Daten zu suchen, bearbeiten und ggf. neue anzulegen.

Welche Frameworks habt ihr im Einsatz bzw. könnt ihr empfehlen ?


gruß
 
Da ich mit Webprogrammierung mein Geld verdiene, arbeite ich mittlerweile nur noch mit Ruby Frameworks (Rails und Sinatra um genau zu sein).

Wenn ich im PHP Bereich für Fullstack vor der Wahl stände, würde ich mir am ehesten Symfony 2 antun (dazu Doctrine als ORM). Dort scheinen viele intelligente Konzepte eingeflossen zu sein, die die Hässlichkeit von PHP gut wegkapseln.

Ansonsten: Im PHP Bereich habe ich vor ein paar Jahren mit Codeigniter und CakePHP gearbeitet: Codeigniter ist eher eine lose Sammlung von Bibliotheken und man muss viel von Hand erledigen und CakePHP war immer grottenlahm.
 
Zend Framework? Symfony 2?
Das sind so die beiden Platzhirsche.

Je nach Umfang kann aber auch ein Framework im Sinatra-Stil wie z.B. Silex sinnvoll sein.
 
Danke für die Infos!


g0l3m schrieb:
Da ich mit Webprogrammierung mein Geld verdiene, arbeite ich mittlerweile nur noch mit Ruby Frameworks (Rails und Sinatra um genau zu sein).


Warum nutzt du Ruby für die Webentwicklung bzw. welche Vorteile siehst du darin ?

Bisher hab ich nur gelesen das Ruby ein besseres Sicherheitskonzept hat und die Syntax wohl einfacher ist. Ist aber denke ich Ansichtssache..
 
Um es kurz zu machen: Ich persönlich mag PHP einfach nicht (und halte es auch für einen ziemlichen Schrotthaufen).

Warum? Namespaces seit noch nicht so langer Zeit, horizontale Vererbung erst mit 5.4, nach wie vor ein unsagbar inkonsistenter monolithischer Sprachkern (haystack <-> needle) und immer wieder in den Schlagzeilen mit ziemlich peinlichen Sicherheitslücken. Nachdem die Sprache anscheinend von Analphabeten "konzipiert" wurde, haben nun wohl C-Dilletanten das Ruder in der Hand.

Dazu ist die Syntax hässlich wie die Nacht (wird nur noch von Javascript getoppt) und umständlich zu tippen (Klammern, Curly Brackets, Semikolons <- alles Pflicht).

Und wenn ich mir diese Quotes ansehe, wundert mich gar nichts: http://en.wikiquote.org/wiki/Rasmus_Lerdorf

Ich mache das nun schon ein paar Jahre und muss meinem Kram erledigt so erledigt bekommen, dass er mir 3 jahre später nicht um die Ohren fliegt bzw. Geld verdienen. Ich bin deswegen vor längerer Zeit dazu übergegangen, meine "Werkzeuge" in Frage zu stellen. Kernfrage war dabei: Warum benutze ich das und komme ich damit effektiv zum Ziel? Mit PHP war ich nie so richtig warm und "bauchgefühlt" fand ich das Arbeiten damit auch nicht so toll/effektiv.

Für die Webentwicklung ist Rails m. E. nach mit das Beste, womit man im Moment entwickeln kann. In dem Ding stecken so viele schlaue Gedanken, die ziemlich viel von dem abdecken, was im Web wichtig ist: Migrationen für die DB Evolution, automatisches Deployment, Testgetriebene Entwicklung, Asset Pipeline, REST als Architekturstil. Daneben schreibt man mit 1-3 Zeilen simpelstem Code komplexe Queries für DB Abfragen. Wenn man aus der PHP Ecke kommt, weiss man von solchen Dingen gar nichts, hat man sie einmal benutzt, will man das nicht mehr hergeben.

Daran war ich halt interessiert und Ruby ist die Sprache, in der Rails geschrieben ist. Ich habe mich vor Rails ca. 1 Jahr mit Ruby beschäftigt und finde sie toll: Die Objektorientierung, die Konsistenz, die Standardbibliothek, die tollen Gems, die Möglichkeiten: Das Killerfeature für mich ist immer wieder die Metaprogrammierung in Ruby und nur deswegen ist Rails Rails.
CakePHP ist ja an Rails angelehnt, aber dadurch, dass PHP __NICHTS__ bzgl. Metaprogrammierung kann (z. B. Klassen zur Laufzeit wiedereröffnen und und Methoden erweitern), kann man Rails auch nicht in PHP nachbauen.

Was auch interessant ist: Rails ist bei den Standardsachen (CRUD) deutlich schneller als alle anderen PHP Frameworks und CMS, die ich in den Fingern hatte. Rails spuckt z. T. die HTTP Responses in deutlich unter 50 ms aus - das habe ich mit keinem PHP Framework gehabt.

Und... Ruby weiss nichts vom Web, ist also eine echte All-Purpose Sprache. Ich nutze sie noch für die Linux Systemadministration und in Zukunft für iOS Programmierung (mit Rhodes).

Letzendlich ist es aber so, dass man mit den verfügbaren Skriptsprachen (Perl, Python, PHP, Ruby) generell die meisten Probleme gelöst bekommt. Wenn man damit intensiver arbeitet/arbeiten muss, sollte man halt mal nach dem "wie" fragen. Die Lernkurve für Ruby/Rails ist in jedem Fall steil, das ist nix für "ich schaue es mir mal nebenbei an".

Ruby ein besseres Sicherheitskonzept hat und die Syntax wohl einfacher ist

Das Sicherheitskonzept wird immer vom Programmierer vorgegeben, gerade bei Webanwendungen. Die Syntax einfacher... hmm, auf jeden Fall einfacher zu tippen und zu lesen.

Code:
# ruby code, my_array ist eine lokale var
# die vom typ "Array" ist
# in Ruby ist übrigens ALLES ein Objekt
# es gibt keine Skalare
# selbst 1 (oder 10) ist ein Objekt der Klasse "Integer"

my_array.each do |element|
  print element
end

# ======== PHP ===========

# das ist das PHP Analogon dazu
# ich finde das Geklammere mittlerweile lästig
# Semikolon auch
# das vergesse ich oft, wenn ich von Ruby wieder
# zu PHP wechsele

foreach ($my_array as $element)
{
  echo $element;
}

# =====================
# =====================

# und hier mal ein conditional
# unless ist Negierung, also ! in PHP
# Übersetzung: schreibe 'array has elements' wenn my_array nicht leer ist

print 'array has elements' unless my_array.empty?

# ======== PHP ===========

if (count($my_array) > 0)
{
  echo 'array has elements';
}

# oder als ternärop als Einzeiler
# den finde ich aber auch wieder recht sperrig
# beim lesen

echo count($my_array) > 0 ? 'array has elements' : '';
 
Zuletzt bearbeitet:
@g0l3m

Danke für die ausführliche Antwort!
Ich werde mich jetzt mit Rails auseinandersetzen und Vergleiche zu PHP ziehen.

Die Syntax von PHP liegt mir auf den ersten Blick mehr, da ich viel mit C,C++ und C# gearbeitet habe. Aber daran solls nicht scheitern :)
 
Brauchste bloß noch Rails-fähige Server... Die meisten kostengünstigen Hoster bieten nun einmal nur PHP.

Gibts für Rails eigentlich eine Entsprechung zu suphp? Wenn nicht, dann ist es auch für VHosts nur mittelprächtig.
 
Wer noch mehr aktuelle Infos auf einen Blick dazu will, warum einige Leute PHP "nicht so toll" finden, sollte sich mal dies hier zu Gemüte führen. http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

Ich habe seit Jahren viel mit PHP zu tun und mir hängt es echt zum Hals raus. Leider ist es fast unmöglich, große Projekte im Nachhinein auf eine andere Sprache umzustellen. Selbst nur einzelne neue Module nicht mehr mit PHP laufen zu lassen, gestaltet sich sehr schwierig, aber wir arbeiten daran. In unserem Fall ist allerdings eine Migration auf Python geplant, nicht Ruby/Rails.

Ich kann jedem nur empfehlen nicht mit PHP anzufangen. Der große Vorteil von PHP ist das einfache Deployment, aber das wiegt aus meiner heutigen Sicht die vielen Nachteile und unerwarteten WTFs einfach nicht auf. PHP ist benutzbar, mehr aber auch nicht.

A good carpenter can drive in a nail with either a rock or a hammer, but how many carpenters do you see bashing stuff with rocks?
 
Ehrlich gesagt finde ich diese Rants absolut nutzlos. Jede Sprache hat seine Macken, genauso Ruby. Vor allem ein Framework nach der Sprache auszuwählen ist so sinnvoll....
Guter Code kommt von guten Entwicklern, dreckiger Code lässt sich in jeder Sprache schreiben, genauso wie guter Code.

Wer in PHP sch*** Code fabriziert, der macht es auch in Ruby, Java, Python und co. Und wer guten Code schreibt dem ist die Sprache ziemlich egal.
 
Es geht ja nicht nur um ein paar "unschoene" Sachen, sondern um eklatante Absurditaeten im Sprachdesign.

Wenn da andauernd die Funktionen inkonsistent benannt oder die Parameter wild vertauscht sind, ist das eine Sache, mit der man klarkommen kann. Aber die Sprache verhaelt sich einfach an vielen Stellen komplett anders als erwartet. Das macht (soweit ich weiss) keine andere (weit verbreitete) Sprache so.

Der Hammer ist sowieso, dass Stable-Versionen veroeffentlicht werden, obwohl Unit Tests fehlschlagen, die ja genau dafuer existieren, um Regressionen zu verhindern. Muss ich an Version 5.3.7 erinnern? Einfach unglaublich.

Den Rant habe ich einfach mal gepostet, weil er ziemlich umfangreich und aktuell ist. Da soll sich jeder selbst ein Bild machen.
 
Daaron schrieb:
Brauchste bloß noch Rails-fähige Server... Die meisten kostengünstigen Hoster bieten nun einmal nur PHP.

Gibts für Rails eigentlich eine Entsprechung zu suphp? Wenn nicht, dann ist es auch für VHosts nur mittelprächtig.

Warum mittelprächtig? Sowas wie suphp ist gar nicht notwendig. Als ich vor ein paar Jahren Webserveranbindung von Scriptsprachen evaluiert habe, ist suphp aufgrund der Performance gleich rausgeflogen, da es bei jedem Request alles neu geladen hat. Damit macht man jeden Server platt. Mit fcgid habe ich gute Erfahrungen gemacht: Das vereint das Sicherheitskonzept von suphp (Benutzerseparierung auf vHost Ebene) mit guter Performance, da ein einmal geladener Interpreter als Thread verbleibt und neue Requests ohne Neuladen abarbeitet.

Da fcgid nur ein API/Protokoll ist, habe ich Ruby (und Rails) damit ebenso angebunden. Alternativ gibt es noch Passanger oder man deployt direkt auf einem der vielen Ruby-Webserver: Thin, Puma, Mongrel. Oder man schaltet vor diese einen Apache als ReverseProxy - es gibt 1000 Möglichkeiten.

Allerdings sind Linuxkenntnisse und das selbstständige Administrieren der Webkisten auf der Shell fast schon Pflicht - ich würde mir das Fremdgewürge mit irgendwelchen obskuren Standardkisten ohne Shell nicht antun wollen.

character schrieb:
Ich kann jedem nur empfehlen nicht mit PHP anzufangen.

Danke, dem schliesse ich mich an. Python interssiert mich übrigens auch sehr.

ice-breaker schrieb:
Guter Code kommt von guten Entwicklern, dreckiger Code lässt sich in jeder Sprache schreiben, genauso wie guter Code.

Wer in PHP sch*** Code fabriziert, der macht es auch in Ruby, Java, Python und co. Und wer guten Code schreibt dem ist die Sprache ziemlich egal.

Ach, das sind doch nur Plattitüden. Schön für Dich, wenn Du das kannst (guten Code in jeder Sprache schreiben), es gibt aber nunmal eine riesige Bandbreite an Programmierskills der einzelnen Leute. Es kommt nicht jeder als Programmiergenie auf die Welt und warum soll man sich das Leben schwerer machen (mit PHP z. B.) als es eh schon ist.

Gerade wenn man anfängt und unsicher ist, helfen einem die Konzepte und Konventionen, die durch verwendete Pattern & Architekturen gerfordert werden, sehr.

Als (abstrakteres) Beispiel will ich hier mal REST anführen. In der PHP Welt sieht man häufig solche Krücken:

Code:
GET http://domain.tld/backend/main.php?do=article&table=tl_content&id=3

Respektiert man REST als Basis jeglicher Kommunikation im Web, wird das daraus:

Code:
GET http://domain.tld/backend/articles/3/edit

Und als Nebeneffekt versteht man gleich noch, wie HTTP funktioniert und was das Web eigentlich (technisch) ist. Hier geht es auch nicht um die popelige Lösung eines Problems (Zugriff auf einen Artikel zum Editieren via URL), hier geht es um fundamentale Standards, die seit Jahren/Jahrzehnten exisitieren.

Ruby z. B. erzwingt frühzeitig die Auseinandersetzung mit objektorientierten Konzepten und der Code, der in Form von Gems (Erweiterungen, ähnlich PEAR) verfügbar ist, hat sehr häufig eine hohe Qualität, von dem man gut lernen kann.

Wenn es im PHP Bereich schon seit Jahren Frameworks wie Flow 3 oder Symfony 2 geben würde, dann hätte man da auch viel zum Abschauen, aber z. B. bei Joomla, Drupal und Wordpress gibt es leider nichts zu holen, ganz im Gegenteil.
 
Zuletzt bearbeitet:
g0l3m schrieb:
Wenn es im PHP Bereich schon seit Jahren Frameworks wie Flow 3 oder Symfony 2 geben würde, dann hätte man da auch viel zum Abschauen, aber z. B. bei Joomla, Drupal und Wordpress gibt es leider nichts zu holen, ganz im Gegenteil.
Also liegts doch am Entwickler und nicht an der Sprache?!
g0l3m schrieb:
Ach, das sind doch nur Plattitüden. Schön für Dich, wenn Du das kannst (guten Code in jeder Sprache schreiben), es gibt aber nunmal eine riesige Bandbreite an Programmierskills der einzelnen Leute. Es kommt nicht jeder als Programmiergenie auf die Welt und warum soll man sich das Leben schwerer machen (mit PHP z. B.) als es eh schon ist.
Was wiederum am Entwickler liegt und nicht an der Sprache. Übrigens gibt es etwas, was man Erfahrung nennt. Diese kommt nicht vom Lesen eines Tutorials und Lernen einer Programmiersprache.
 
g0l3m schrieb:
Als (abstrakteres) Beispiel will ich hier mal REST anführen. In der PHP Welt sieht man häufig solche Krücken
Ein sinnloser Vergleich, weil es Plain-PHP (eine Sprache) mit einem Framework vergleicht, welches dem MVC-Modell folgt. Nimmst du im Gegensatz auch in PHP ein MVC-Framework hast du genau die gleichen Ergebnisse. Nimmst du kein Rails sondern bastelst dir den Webserver in Ruby selbst, hast du genauso keine sprechenden URLs.


g0l3m schrieb:
Wenn es im PHP Bereich schon seit Jahren Frameworks wie Flow 3 oder Symfony 2 geben würde, dann hätte man da auch viel zum Abschauen, aber z. B. bei Joomla, Drupal und Wordpress gibt es leider nichts zu holen, ganz im Gegenteil.
Es gibt seit 2005 Symfony, Rails seit 2004, also beides ziemlich gleich lang.
Wenn man dann eben kein Symfony nutzt, weil Menschen frickeln wollen, ist es deren Sache, die werden dann aber auch nicht Rails nutzen.
Es liegt eben am Entwickler, und an nichts anderem.




Ich klinke mich da aber aus, alleine der Vergleich ist lächerlich, eine Sprache gehen ein Framework, tztz. Und dann verfolgt eben jede Aussage dieses Fanboy-Muster, dass alles in einem schlecht ist und im anderen gut. Alleine dass vollkommen ignoriert wird, dass man genauso in Ruby rumschmieren kann und den größten Bockmist verzapfen kann, zeigt schon den Tunnelblick, eine Sprache/Framework kann noch so genial sein, wenn der Nutzer ein Idiot ist, dann kann nur Mist bei rauskommen. Das Problem hat man im Java Enterprse Bereich sehr stark, jahrelang belächelte man die anderen Sprachen, weil sich die die "weniger guten Entwickler" tummelten und nun hat man dort haargenau das selbe Problem, denn es gibt einfach noch mehr als genug Entwickler, die keine Ahnung haben.
 
Zuletzt bearbeitet:
Ach Mensch… natürlich wollte ich keine Programmiersprache (PHP) mit einem Full Stack Framework (Rails) vergleichen :rolleyes:

Es ging mir um die Konzepte. Anders ausgedrückt: Warum wird man im OpenSource PHP Bereich mit vielen Dingen konfrontiert, mit denen man sich gar nicht beschäftigen muss, weil sie schlichtweg keinen Sinn machen? Oder: Warum wird man auf einer anderen Plattform schneller an ebenjene sinnvollen Konzepte herangeführt?

Gerade für jemanden, der anfängt sich z. B. mit Webprogrammierung auseinanderzusetzen und keine formale Ausbildung in irgendeiner Form hat, fällt es so u. U. leichter, schneller besser programmieren zu lernen.

Unabhängig davon habe ich oben schon geschrieben:

Letzendlich ist es aber so, dass man mit den verfügbaren Skriptsprachen (Perl, Python, PHP, Ruby) generell die meisten Probleme gelöst bekommt.
 
character schrieb:
Ich kann jedem nur empfehlen nicht mit PHP anzufangen. Der große Vorteil von PHP ist das einfache Deployment, aber das wiegt aus meiner heutigen Sicht die vielen Nachteile und unerwarteten WTFs einfach nicht auf. PHP ist benutzbar, mehr aber auch nicht.
Dem Kunden (und für DEN arbeitet man) ist es egal, in was du schreibst. Er erwartet, dass das Projekt danach auf seinem Strato-Account läuft. Problem erkannt?
Die extreme Verbreitung von PHP ist DER Vorteil schlechthin. Du kannst auch gern deine Seiten in ASP.NET schreiben, wenn du es toll findest, aber deine Kunden werden dich dann fragen, wieso das Hosting 5x so teuer ist wie bei der Konkurrenz. Geld ist der entscheidende Faktor, nicht obskure Vorlieben... und hier gewinnt PHP um Längen.

g0l3m schrieb:
Als (abstrakteres) Beispiel will ich hier mal REST anführen. In der PHP Welt sieht man häufig solche Krücken:

Code:
GET http://domain.tld/backend/main.php?do=article&table=tl_content&id=3

Respektiert man REST als Basis jeglicher Kommunikation im Web, wird das daraus:

Code:
GET http://domain.tld/backend/articles/3/edit

Ruby z. B. erzwingt frühzeitig die Auseinandersetzung mit objektorientierten Konzepten und der Code, der in Form von Gems (Erweiterungen, ähnlich PEAR) verfügbar ist, hat sehr häufig eine hohe Qualität, von dem man gut lernen kann.
Was du da oben mit den URLs beschreibst ist eher eine Frage der .htaccess (um mal beim Apache zu bleiben), als eine Frage des Frameworks. Aber, um mal genauer darauf einzugehen: Du beschreibst hier n Backend-Edit in Contao. Was juckt mich im BE der Aufbau einer URL? Guck dir lieber die FE-URLs an, insbesondere in Contao 2.11. DAS sind hübsche URLs.

Aber wo wir schon dabei sind: Gibts für Ruby (so heißt die Sprache, Rails ist nur n Framework, sowas gibts für PHP auch!) denn so genial einfache und einfach zu erweiternde CMS wie Contao?

Und was bringts mir, wenn ich zwanghaft objektorientiert arbeiten muss? OO ist eine MÖGLICHKEIT, kein Zwang. Genau das macht PHP: Es gibt mir flexible Mittel. Wenn ich bloß n Dreizeiler schreibe, dann fang ich nicht mit Klassendeklarationen an.

g0l3m schrieb:
Ach Mensch… natürlich wollte ich keine Programmiersprache (PHP) mit einem Full Stack Framework (Rails) vergleichen :rolleyes:
Du hast aber genau das gemacht.
Vergleich also entweder Ruby mit PHP oder Rails mit Zend Framework oder Symphony. Gerade im 2. Falle kommst du dann an den Punkt wo du dich ernsthaft fragen wirst: Was sollte mein Gebashe eigentlich? Ist doch ganz nett hier...

Gerade für jemanden, der anfängt sich z. B. mit Webprogrammierung auseinanderzusetzen und keine formale Ausbildung in irgendeiner Form hat, fällt es so u. U. leichter, schneller besser programmieren zu lernen.
...nur wenn er auch noch eine Umgebung findet, in der er seine Arbeit testen kann. Ein LAMP/WAMP-Server ist weit schneller aufgesetzt als ein Ruby-Server.

Du gehst hier aber immer noch davon aus, dass man direkt anhand eines Frameworks (Rails) lernt. Tut man aber nicht, man lernt erst einmal die Basics und wechselt DANN zum Framework. Ob es wirklich leichter ist, Ruby zu lernen anstatt PHP, das sei mal dahin gestellt. Ich habe so meine Zweifel.
 
Daaron schrieb:
Was du da oben mit den URLs beschreibst ist eher eine Frage der .htaccess (um mal beim Apache zu bleiben), als eine Frage des Frameworks. Aber, um mal genauer darauf einzugehen: Du beschreibst hier n Backend-Edit in Contao. Was juckt mich im BE der Aufbau einer URL? Guck dir lieber die FE-URLs an, insbesondere in Contao 2.11. DAS sind hübsche URLs.


Bei REST geht es nicht nur um das Aussehen der URL. Wenn man beispielsweise ein und die selbe URL mit verschiedenen HTTP-Accept Headern anspricht, dann sollte die ein und sie selbe URL auch entsprechendes zurückliefern ohne dass man an ihr etwas verändert hätte. Und da braucht man dann ein Framework dafür. Schöne URLs sind sicherlich nicht der primäre Hintergrundgedanke hinter REST.

edit: aber ok, sein Beispiel sah so aus als ginge es nur um das Aussehen von URLs, das stimmt.
 
Zuletzt bearbeitet:
Du fragst in diesem Beispiel aber offensichtlich eine Backend-Seite an. Dein Accept-Header fragt nun nicht gerade nach ner Audio-File oder sonstwas. hier wird allein von der Logik her immer HTML-Text erwartet. Such dir also lieber ein Beispiel, bei dem der Header eher mal abweichen wird.
 
Daaron schrieb:
Du fragst in diesem Beispiel aber offensichtlich eine Backend-Seite an. Dein Accept-Header fragt nun nicht gerade nach ner Audio-File oder sonstwas. hier wird allein von der Logik her immer HTML-Text erwartet. Such dir also lieber ein Beispiel, bei dem der Header eher mal abweichen wird.

:confused_alt:

Das Beispiel oben kommt nicht von mir, es war lediglich eine in den Raum geworfene Anmerkung zu REST.

Und ob dort immer HTML erwartet wird ist zu bezweifeln (ich kenne das CMS nicht, nur exemplarisch), würde man einen nativen Smartphone-Client für's Backend schreiben, dann würde man sich mit application/json oder xml vermutlich zufrieden geben. Audio hingegen ist dann doch eher exotisch bei REST..
 
Zuletzt bearbeitet:
Daaron schrieb:
Dem Kunden (und für DEN arbeitet man) ist es egal, in was du schreibst. Er erwartet, dass das Projekt danach auf seinem Strato-Account läuft. Problem erkannt?
Da wir SaaS anbieten, habe ich das Problem nicht.

Auch bei unseren Kooperationen kenne ich aber niemanden, der eine Programmiersprache vorgibt. Da werden bei Bedarf auch andere Systeme eingerichtet. Generell wird bei denen auch viel Java und ASP.NET verwendet.

Insofern gelten deine Aussagen eher für selbstständige Auftragsentwickler.

Daaron schrieb:
Geld ist der entscheidende Faktor, nicht obskure Vorlieben... und hier gewinnt PHP um Längen.
Das mag vielleicht bei Kunden so sein, die mal irgendwas entwickeln oder anpassen lassen und das wars dann.

Bei SaaS (oder längeren Kooperationen) spielt aber die Wartung und (bei uns) insbesondere Weiterentwicklung eine große Rolle. Da sind die Kosten für Server, die "auch was anderes als PHP können", vollkommen irrelevant, da hier sowieso nicht mit irgendwelchen vorkonfigurierten Hosting-Paketen hantiert wird.

Aber: Selbst das normale Webhosting von Strato ab 6 EUR im Monat unterstützt PHP, Perl, Python und Ruby. Also so schlimm ist das mit der Verfügbarkeit wirklich nicht.

Ausserdem sagt ja auch keiner, dass man PHP nicht verwenden soll. Die Frage ist nur, ob es die beste Wahl ist, wenn man ein neues Projekt anfängt und sich die Sprache aussuchen kann. Ich muss das ganz klar verneinen.
 
Zuletzt bearbeitet:
character schrieb:
Ausserdem sagt ja auch keiner, dass man PHP nicht verwenden soll. Die Frage ist nur, ob es die beste Wahl ist, wenn man ein neues Projekt anfängt und sich die Sprache aussuchen kann. Ich muss das ganz klar verneinen.

Wenn du aber zum Bäcker gehst und dort um Brötchen bittest, dann willst du auch nicht, dass dieser dir anpreist, dass ein Brot eigentlich die viel bessere Wahl wäre.
Und es wurde ja nicht nach einem Web Framework gefragt (dann wäre es ja in Ordnung) gewesen, sondern direkt nach einem PHP Framework.


Man reagiert bei den Ruby-Jüngern eventuell auch etwas stärker, weil diese jedes mal ihren Senf dazugeben müssen, wenn man stattdessen auch RoR oder andere Frameworks nutzen könnte. Interessanterweise kommen diese Einwände aber fast nur aus der Ruby-Ecke, nur mal so als Denkanstoß ;)
 
Zurück
Oben