PHP Warum ist PHP so verhasst?

###Zaunpfahl### schrieb:
Mit PHP ist es halt so das einige Dinge nicht möglich sind weil die Sprache das (noch) nicht bietet.

Ich brauch aber auch nicht jedes Bullshitfeature in einer Sprache das muss ich echt mal so sagen. Teilweise ist das doch echt nur noch Buzzwordbingo für Nerds, wenn ich so ein Sprachfeature in 2 Jahren ein oder zweimal sinnvoll nutzen kann dann brauche ich das im Endeffekt auch nicht... Php geht da schon den richtigen Weg in dem es mit jedem Majorrelease sinnvolle Features bringt und auch mal alte Zöpfe abschneidet und Stück für Stück erwachsen wird.
 
foo_1337 schrieb:
@KitKat::new() ich bin da selbst zu wenig drin (ich halte mich von allem was mit Frontends zu tun hat fern), aber der Tenor ist da oft, dass man dennoch auf viele js Module zurückgreifen muss, weil es einfach noch sehr viel nicht gibt.
Du kannst ja quasi alle Rust-Crates nutzen, die du sonst auch hast. Wenn das Framework einen guten Grundstock bietet (Components, Routing, Setup, etc.), ist da gar nicht mehr so viel rum.
Dann geht's eher um ungewöhnlichere Sachen.
 
Zuletzt bearbeitet:
Guyinkognito schrieb:
Ich brauch aber auch nicht jedes Bullshitfeature in einer Sprache das muss ich echt mal so sagen.
Naja das ist aber auch ziemlich subjektiv und individuell. Aus dem Grund gibts doch auch soviele Sprachen.
Welche Sprachen haben denn etwas um Webtechnisch etwas zu erstellen.
Java, Kotlin, Python, Javascript, Typescript, PHP, Ruby und sonstige die ich nicht kenne oder vergessen habe. Am Ende kann man mit denen in einer gewissen Schnittmenge überall das selbe machen.

Ob man dann so Features zur Entkapselung wie private, protected... braucht kommt immer auf die Umgebung an. Rein funktionell (praktisch) hat das überhaupt keinen nutzen es dient nur dazu die Programmlogik implizit besser zu beschreiben und darüber indirekt mit anderen Entwicklern zu "kommunizieren". Wenn man einfach immer alles public macht dann läuft das Programm ja genauso. Dieses und viele andere Features dienen doch nur genau dem Zweck. Und genauso (ich nenns jetzt mal so) elegant kann man auch mit Programmiersprachen schreiben die die Features überhaupt nicht haben man macht dann eben eine Konvention über Kommentare o.ä. (praktischer ist es natürlich wenn es in die Sprache integriert ist).

Da hat halt jeder seine eigene Meinung. Außerdem gibt es auch schon lange nicht mehr DEN Entwickler (wenn es den überhaupt einmal gab). Es gibt soviele verschiedene Arten von Entwicklern, Bastlern, Programmierern wie es unterschiedliche Menschen gibt und jeder macht irgendwas auf seine Art besonderes und trägt etwas dazu bei. Am Ende muss man sich und das besonders als Entwicklerteam irgendwie in der Mitte treffen und einig werden um voran zu kommen.
Es gibt vielleicht "besser" und "schlechter" aber ziemlich sicher nicht das "beste".
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Piktogramm
###Zaunpfahl### schrieb:
Deswegen würde ich jedem Anfänger empfehlen, außer diejenigen die mit Komplexität überhaupt kein Problem haben, mit etwas einfacherem wie PHP, Python, Javascript anzufangen.
Das "Problem" bei Sprachen wie PHP ist, das sie zwar unzweifelhaft den Einstieg einfacher machen aber halt auch dem Nutzer es sehr einfach machen sicherheitskritische Fehler einzubauen. Und wenn man etwas in einer Webanwendung nicht haben will, dann sind das Sicherheitsprobleme. :-)

Daher ist das mit dem einfach immer so eine Sache. Einfach im dem Sinne man kriegt schnell ne Lösung hingeschludert die irgendwie auch funktioniert, da gebe ich Dir recht.

Sobald das ganze aber solide sein soll ist es dann doch wieder aufwändiger und man braucht doch wieder tieferes Wissen. Mag sein das PHP auch dann noch einen Vorteil hat, aber der Abstand zu anderen Lösungen ist deutlich kleiner.
Von daher ist es immer auch so ein wenig gefährlich mit der vermeintlichen Einfachheit von PHP oder von mir aus auch Javascript zu argumentieren.
 
###Zaunpfahl### schrieb:
Ist es denn wirklich soviel schwieriger in anderen Sprachen sicherheitskritische Webanwendungen zu bauen wenn man überhaupt keine Ahnung hat?
Das nicht. Also wenn, dann ist ja eher der umgekehrte Fall interessant. Also schützt mich eine Sprache davor allzuviel Unfug zu bauen.

Ich denke da zum Beispiel an Ruby wo Variablen die mit Werten aus potentiell unsicherer Quell (Usereingaben) mit tainted markiert werden was verhindert das Du damit direkt gefährliche Sachen (z.B: eval!) machen kannst.
Du musst also die Eingaben zwingend behandeln. Das schützt Dich zwar immer noch nicht davor, das Du sie auch korrekt behandelst. Aber es schützt Dich davor versehentlich zu vergessen Eingabewerte zu verifizieren.

Oder auch Sachen wie starke und am besten sogar noch statische Typisierung. Auch das verhindert viele grundsätzliche Sicherheitsprobleme.

Die Sprache ist also schon eine Unterstützung. Auch wenn am Ende des Tages es auch ganz wesentlich auf den Programmierer ankommt. Selbst die "beste Sprache" kann einen nicht vor allem beschützen.
Und wie gesagt: Mir ist lieber irgendjemand der PHP und sein Handwerk wirklich beherrscht macht dann was mit PHP als jemand der der sich nicht auskennt und dafür Sprache XYZ nimmt auch wenn Du "auf dem Papier" besser/sicherer ist.
 
  • Gefällt mir
Reaktionen: GroMag und ###Zaunpfahl###
PHP ist nicht verhasst. Es gibt halt nur ab und an Möchtegern-Programmierer, die eine "Meinung" haben.
 
Ich hab die letzten Jahre meine Backends mit Laravel / mySql programmiert - hatte aber auch keine andere Möglichkeit vom Arbeitgeber...
Seit einer Woche schaue ich mir Nodejs / express mit MongoDb an und.. naja was soll ich sagen.
Sowohl bei dem einen als auch beim anderen brauch man meiner Meinung nach erstmal eine vernünftige Projektstruktur - das ist aber auch bei jeder Sprache der Fall.

Meine Frontendgeschichten habe ich bisher mit Angular bzw. über die Template Engine blade aus Laravel erstellt.
Größter Unterschied für mich ist einfach der Start eines Projektes.

Installier Laravel und installier mal Node.js. In Laravel hast du bereits eine gewaltige Projektstruktur vorgeben wovon man meist nur einen Bruchteil von brauch. In Node hat man... nichts.
Es fängt mit der package.json an, hier definiert man sein start script und anschließend legt man sich selber seine Projektstruktur an. Mir persönlich ist die Schreibweise in Javascript auch angenehmer als in php.

Sowohl in Node als auch in Laravel unterscheide ich immer zwischen Models/Controller/Services/Routes.

Mit mongoDb hab ich mich noch nicht soweit beschäftigt aber ich hoffe, dass es besser gelöst ist als in Laravel. In Laravel muss man sehr auf die Reihenfolge bei der Erstellung einer Tabelle achten und dies geschieht anhand des Timestamps einer Tabelle. Bei größeren Projekten mit vielen Verknüpfungen wird es schnell unübersichtlich - außer man lässt jegliche Normalisierung außen vor und arbeitet komplett ohne ForeignKeys, dann ist es egal.
 
Ich finde ja diesen ganzen Framework-Schlonz doch manchmal recht nervig. Man ist nicht selten damit beschäftigt, das wie man bestimmte Sachen in dem Framework hinbekommt als mit der Sache selbst.
Manchmal kommt man in die Situation das man glaubt man braucht das Framework, bis man dann bestimmte Sachen mal selbst from scratch implementiert und man dabei merkt, das das doch nicht so schwer ist wie man immer befürchtet hat. :-)

Ich will damit nicht gegen die ganzen Frameworks argumentieren. Man sollte halt nur aufpassen und gucken, wann ein Framework Hilfe ist und wann es zur Belastung wird.

Als die größte Hürde empfinde ich überhaupt erst mal ein passendes Framework zu finden was zu einem (also der eigenen Arbeitsweise und zu dem was man überhaupt machen will) passt. Es ist ja meist nicht damit getan, das man einfach mal ne Comparision querliest. Oftmals merkt man das erst, wenn man mit dem Framework arbeitet. Das heißt, das ganze wird sehr schnell sehr aufwändig.

Dann gibts ja noch diverse Randbedingungen zu beachten. Man will ja auch nicht auf ein Framework setzen, was vielleicht nächstes Jahr schon wieder out ist und keinerlei Support mehr erfährt und solche Geschichten.
Oder Kompatibilitätsbreaks die es bei manchen Frameworks auch gerne mal gibt.
 
  • Gefällt mir
Reaktionen: ###Zaunpfahl###, netzgestaltung und GroMag
Für die meisten kleineren Sachen nutze ich auch kein einziges Framework. Für manches ist jquery dann zwar noch drin aber das wars dann auch schon.
Nutzung von Frameworks würde ich nur bei größeren Sachen bevorzugen weil es einem die Arbeit dann schon vereinfacht und man muss ja nicht mit jedem Projekt das Rad neu erfinden.
 
-Rayz- schrieb:
und man muss ja nicht mit jedem Projekt das Rad neu erfinden.
Auf das kommt es denke ich drauf an. Man sollte die Frameworks entsprechend gut kennen um entscheiden zu können ob die jetzt da auch das Mountenbike haben und nicht das CityBike, weil wenn nicht wirds wie von @andy_m4 schon beschrieben blöd und wäre anders durchaus flexibler.


-Rayz- schrieb:
Installier Laravel und installier mal Node.js
Ähm? Irgendwie ist mir das zu durcheinander. Also wenn dann müsstest du schon PHP vs. NodeJs oder ggf Laravel vs NestJs machen meiner Meinung nach.
 
Das Thema Framework hat man doch bei jeder Sprache mehr oder weniger oder? Wenn man für jedes kleine Projekt ein Framework benutzt dann hat man eben den Overhead der bei einem Framework mitkommt, auf der anderen Seite ist dann jedes Projekt immer gleich aufgebaut und man weiß immer wo man suchen muss bei Fehlern und wo man ansetzen muss bei Erweiterungen.

Wäre es dann nicht Sinnvoll das man immer nur Frameworks verwendet? Das würde dann doch alles viel einfacher machen und alles vereinheitlichen.

Zum eigentlichen Thema: Ja, ich gebe zu "hassen" ist vielleicht etwas übertrieben - aber man sieht auch wieder wie schön man damit Leute triggern kann ;) klar jeder möchte "seine" Sprache die er mehr oder weniger komplett beherrscht vierteiligen. Weil hier viele schreiben damit viel Murks mit PHP gemacht wird, das kann doch auch bei jeder anderen Sprache passieren die anfängerfreundlich ist oder nicht?

Ich sehe viel mehr das Problem bei JavaScript bzw. NodeJS und alle Frameworks die es so gibt, an jeder Ecke, jeder Blog, jeder YouTuber macht Werbung dafür und das man damit der nächste Top-Web-Entwickler werden kann. Dauert wahrscheinlich nicht mehr lange dann gibt es WYSIWYG-Editoren für JavaScript/NodeJS und jeder kann seine App zusammenklicken.
 
Also ich habe lange das Frontend mit jQuery als Abhängigkeit dabei gehabt, auch weil ich mein eigenes Theme pflege und somit auch altlasten mitziehe.

Aber die Libs sind immer weniger geworden. Mordernizr ist raus, Throttled scroll ist mit passiven Events nicht mehr nötig usw usf. neue Abhängigkeiten hab ich nicht wieder aufgebaut, dh es wird immer mehr plain JS daraus.

Das Theme kann ich als statische HTML Seite genauso umsetzen wie mit WordPress und zuletzt hab ich das in Drupal eingebaut (was Themetechnisch ein haufen Mist ist). Wenn ich ein Framework wählen würde ist mir derzeit das WP Backend am liebsten denn die Template API ist sehr umfangreich und ausgezeichnet Dokumentiert.

Bei Mustache oder Velocity oder Handlebars oder auch Smarty sowie Liquid oder Twig fühlt es sich immer recht rudimentär an. Am besten läuft dabei noch Liquid wobei es bei vielen Engines auch um die Umsetzung bzw die Datenverfügbarkeit geht.

Das ist mit Twig zb bei Drupal besonders katastrophal. Es gibt keine Referenz sowie in jedem Template andere Variablen und Daten und niemals alle. Es gibt aber auch Umsetzungen wo das besser zu funktionieren scheint.

Mit PHP als Template Sprache kann ich zumindest noch was dazu bauen um zu Daten zu gelangen.
 
Zuletzt bearbeitet:
netzgestaltung schrieb:
Das Theme kann ich als statische HTML Seite genauso umsetzen wie mit WordPress und zuletzt hab ich das in Drupal eingebaut (was Themetechnisch ein haufen Mist ist). Wenn ich ein Framework wählen würde ist mir derzeit das WP Backend am liebsten denn die Template API ist sehr umfangreich und ausgezeichnet Dokumentiert.

Ist bei mir ähnlich obwohl WordPress jetzt kein Framework im klassischen Sinne ist.

WordPress ist vor allem dann eine schlechte Wahl wenn Mehrsprachigkeit mit vielen Sprachen unterstützt werden muss.
 
Polylang fehlt mir die Erfahrung (liegt wohl daran, dass ich noch eine Lifetime Lizenz für unendlichProjekte von WPML habe).

WPML ist super für 2-3 Sprachen nutze ich beinaher bei jeder Webseite (Schweiz ist halt Mehrsprachig). Haben aber auch ein Projekt mit 14 Sprachen und dort macht WPML definitiv keinen Spass mehr. Die Webseite wird super träge (Frontend ist eh Litespeed Cache) aber auch das Backend wird zur Katastrophe sowohl von Übersichtlichkeit wie auch von Geschwindigkeit.
 
Hi,

bei so vielen Sprachen würde ich wohl eher für jede Sprache eine separate Instanz nutzen und damit ein Multisite Setup wählen und die Sprachauswahl voranstellen. Macht in meinen Augen - egal in welchem System - keinen Sinn derartig viele Sprachen mit einem einzigen System abzubilden, zumal es dann auch von den Benutzern, die die Inhalte pflegen, absolutes Chaos wird.

VG,
Mad
 
  • Gefällt mir
Reaktionen: netzgestaltung
@Madman1209 klar würde ich auch so machen. Das Projekt ist halt 2 sprachig gestartet da hat WPML Sinn gemacht und inzwischen einfach gewachsen. Im späteren Herbst kommt eh ein komplett Umbau / Neubau der Seite dann kann man sich da neue Methoden überlegen - jetzt einfach laufen lassen. ^^
 
Ich arbeite schon seit Jahren mit Polylang, das funktioniert sehr zuverlässung und mein WP Theme ist auch schon damit kompatibel gebaut. Daher würde ich mehrsprachig derzeit mit Polylang umsetzen. Wenn es ein anderes System sein soll und mehrsprachig würde ich das dahingehend aussuchen damit das direkt integriert ist. Bei WPML (wie zb auch ACF, da nehm ich lieber JCF) sind mir zu viele kommerzielle Erweiterungen unterwegs.

Meine häufig genutzten Plugins hab ich hier aufgelistet, da dies die Installation beschleunigt:
https://profiles.wordpress.org/netzgestaltung/#content-favorites

E: aber mehr als 3 Sprachen machen so wirklich nicht viel Sinn.
 
sh. schrieb:
Wäre es dann nicht Sinnvoll das man immer nur Frameworks verwendet? Das würde dann doch alles viel einfacher machen und alles vereinheitlichen.
Kommt drauf an.
Wenn das Framework auf meine Sachen die ich mache gut passen spricht nichts dagegen.
Manchmal sind die Aufgaben aber auch recht unterschiedlich. Und dann kommst Du schnell in die Bredouille.

Wenn Du ein Framework hast, was sehr allgemein und flexibel gefasst hast, dann hast Du schnell das Problem, das auch einfache Sachen unnütz kompliziert werden. Hast Du ein Spezifischeres Framework dann kommst Du schnell in Probleme, wenn die Sachen machen musst die nicht in die Philosophie des Frameworks passen.

In letzteren Fall dann zu sagen, dann nehm ich halt immer das jeweils passende Framework ist auch schwierig, weil Du Dich dann in verschiedene Frameworks einarbeiten musst was dann Reibungsverluste mitsich bringt.

Wie so oft ist es halt wirklich insgesamt am einfachsten, wenn man sich spezialisiert. Spezialisierung bedeutet auf der anderen Seite aber auch, das man sich extrem abhängig macht.

Kurzum: Eine pauschale Antwort auf die verschiedenen Problematiken gibt es nicht. Es ist aber trotzdem nicht verkehrt sich diese Problematiken mal bewusst zu machen.
 
  • Gefällt mir
Reaktionen: netzgestaltung

Ähnliche Themen

Zurück
Oben