Die Qual der Wahl

[KROKvsKROK]

Mir stellt sich eher die Frage, wer derartige Anwendung ernsthaft mit Rails oder Node.js schreiben möchte.

Mir stellt sich eher die Frage, wer bzw. wieso man JEE/APS.Net statt PHP/JS verwenden sollte?

Ich durfte einmal mit JSF (ein Teil von JEE) arbeiten. Ich würde ja sagen, dass ich in Java eigentlich ganz gut zurechtkomme, aber in JSF kam ich überhaupt nicht zurecht. Es gibt so gut wie keine Tutorials zu JSF. Die paar wenige die es gibt, erklären nur ein Hello-World Programm. Aber auch generell ist die ganze JSF-Umgebung (Eclipse-EE, Anwendungsserver, gefühlte 5478512 Bibliotheken) extrem aufgebläht. Hat man alles eingerichtet und erstellt in neues "leeres" Projekt, dann befinden sich im Projektordner bereits Dutzende von Datein. Nirgends wird halbwegs verständlich erklärt, wozu diese ganzen Datein da sind. Man nimmt es einfach als Blackbox hin. Auch die Fehlermeldungen während der Entwicklung sind fast nicht zu gebrauchen. Bei Java weiß ich sofort wo der Fehler liegt, aber bei JSF hatte ich meist nur Fragezeichen vor dem Kopf.
Überall ist dann die Rede von "Glassfisch, Hibernate Framework, Application Server, skalierte Anwendungen, Buisnessbereich, Enterprisebereich usw" dutzende Buzz-Words, aber nirgends wird mal irgendwo von 0 an beginnend erklärt.

Schaut man sich dann dagegen mal PHP an, dann fragt man sich "Wozu JEE?". In PHP habe ich 1 .php Datei und einen PHP-Server. Der PHP Server verarveitet die .php Datei und parst diese ggf. zu HTML-Code. Fertig.

Manchmal denke ich, dass dies genau der Grund ist, wieso es soviele Java-Stellen (wovon der Großteil JEE-Stellen sind) gibt, weil einfach keiner Lust darauf hat.

 

[Daaron]

Liegt vielleicht auch daran, weil viele dem Mythos aufgesetzt sind, dass PHP langsam oder ineffizient sei.

 

[carom]

Mir stellt sich eher die Frage, wer bzw. wieso man JEE/APS.Net statt PHP/JS verwenden sollte?

Wenn man wirklich von komplexen Serveranwendungen im Geschäftsbereich redet und nicht Webseiten, dann spricht eben wenig für PHP/JS und viel für Java/.NET, aus diversen Gründen.

PHP und JS sind zunächst mal Sprachen, nicht mehr, nicht weniger. JavaEE und die .NET-Plattform hingegen sind (oder enthalten) Spezifikationen einer ganzen Architektur für den Aufbau von Middleware, das ist eine ganz andere Baustelle, auf der bereits ein fettes und mächtiges Gerüst steht, das nun mal etwas Einarbeitung erfordert. Das sieht, wie du selbst sagst, auf den ersten Blick kompliziert aus, aber der ganze Stack ist ja auch nicht dafür gedacht, dass du dir damit deinen privaten Blog über Haustiere zusammenbaust. Der einzige Existenzgrund dieser Technologien ist der Aufbau von verteilten, mehrschichtigen Systemen im Unternehmensumfeld. Die "Buzzwords", wie du sie nennst, sind ganz normale Handwerkszeuge (OR-Mapper sind in objekt-orientierten Technologien das normalste der Welt und ein Application Server macht dann doch etwas mehr, als ein normaler Webserver). Des Weiteren hat sich eben ein gewisses Ökosystem drumherum entwickelt. MS und Oracle selbst als auch zig andere zertifizierte Drittfirmen leisten kommerziellen Support, was für Unternehmen wichtig ist, andere Technologien aber nicht in diesem Maße bieten.

Deine Aussage "Wozu JavaEE, in PHP habe ich nur eine Datei, die zu HTML geparst wird, fertig" ist schön, gut und richtig, hat mit der ganzen Thematik aber eigentlich nichts am Hut.

Ganz unten auf die sprachliche Ebene möchte ich eigentlich nicht hinaus, da bin ich doch etwas voreingenommen. Man wird aber nicht Bestreiten können, dass statisch typisierte Sprachen bei Anforderungen an Kritikalität und Robustheit nur Vorteile und keine Nachteile haben. Des Weiteren könnte man argumentieren, dass PHP, vor allem aber JS, doch einen leichten Mangel an strukturgebenden Maßnahmen haben, wie sie ab einer gewissen Komplexität wünschenswert sind.
Außerdem darf man nicht vergessen, dass Serveranwendungen nur zu einem gewissen Teil Webseiten sind und darüber hinaus aus einer Vielzahl von langläufigen Prozessen bestehen. Dafür wurde PHP und seine Runtime nicht gemacht, die JVM war von Stunde 0 darauf ausgelegt, selbiges gilt für Dinge wie Threading.

Nochmal: Ich habe nichts gegen PHP und JS, im Gegenteil. Aber deren Einsatzgebiet liegt im Aufbau (durchaus größerer) Webseiten, nicht bei komplexen Serverapplikationen im Unternehmensumfeld, wo die Generierung eines Web-Frontends nur einen kleinen Teil ausmacht und im Hintergrund noch eine Menge mehr passiert.

 

[KROKvsKROK]

Wenn man wirklich von komplexen Serveranwendungen im Geschäftsbereich redet und nicht Webseiten, dann spricht eben wenig für PHP/JS und viel für Java/.NET, aus diversen Gründen.

PHP und JS sind zunächst mal Sprachen, nicht mehr, nicht weniger. JavaEE und die .NET-Plattform hingegen sind (oder enthalten) Spezifikationen einer ganzen Architektur für den Aufbau von Middleware, das ist eine ganz andere Baustelle, auf der bereits ein fettes und mächtiges Gerüst steht, das nun mal etwas Einarbeitung erfordert. Das sieht, wie du selbst sagst, auf den ersten Blick kompliziert aus, aber der ganze Stack ist ja auch nicht dafür gedacht, dass du dir damit deinen privaten Blog über Haustiere zusammenbaust. Der einzige Existenzgrund dieser Technologien ist der Aufbau von verteilten, mehrschichtigen Systemen im Unternehmensumfeld. Die "Buzzwords", wie du sie nennst, sind ganz normale Handwerkszeuge (OR-Mapper sind in objekt-orientierten Technologien das normalste der Welt und ein Application Server macht dann doch etwas mehr, als ein normaler Webserver). Des Weiteren hat sich eben ein gewisses Ökosystem drumherum entwickelt. MS und Oracle selbst als auch zig andere zertifizierte Drittfirmen leisten kommerziellen Support, was für Unternehmen wichtig ist, andere Technologien aber nicht in diesem Maße bieten.

Die makrierten Stellen verstehe ich schon nicht^^

Für Fachfremde:
JEE/ASP ist für kleine Hobbyprojekte overkill. Für Hobbyprojekte wäre PHP+JS weitaus besser geeignet.
Je größer das Webprojekt wird, desto eher lohnt sich JEE/ASP, da diese besser designt sind (Typensicherheit usw) und dadurch eher Fehler vermeiden und sich besser bei großem Umfang strukturieren lassen, als es bei PHP+JS möglich wäre.

Habe ich das in etwa richtig zusammengefasst?

Außerdem darf man nicht vergessen, dass Serveranwendungen nur zu einem gewissen Teil Webseiten sind und darüber hinaus aus einer Vielzahl von langläufigen Prozessen bestehen. Dafür wurde PHP und seine Runtime nicht gemacht, die JVM war von Stunde 0 darauf ausgelegt, selbiges gilt für Dinge wie Threading.

Nochmal: Ich habe nichts gegen PHP und JS, im Gegenteil. Aber deren Einsatzgebiet liegt im Aufbau (durchaus größerer) Webseiten, nicht bei komplexen Serverapplikationen im Unternehmensumfeld, wo die Generierung eines Web-Frontends nur einen kleinen Teil ausmacht und im Hintergrund noch eine Menge mehr passiert.

Kannst du dazu vielleicht konkrete Beispiele nennen?

 

[Daaron]

Die makrierten Stellen verstehe ich schon nicht^^

Kommt mit der Erfahrung... Nach ein paar Jahren in der Tretmühle weißt du, was ein Application Stack ist.

JEE/ASP ist für kleine Hobbyprojekte overkill. Für Hobbyprojekte wäre PHP+JS weitaus besser geeignet.
Je größer das Webprojekt wird, desto eher lohnt sich JEE/ASP, da diese besser designt sind (Typensicherheit usw) und dadurch eher Fehler vermeiden und sich besser bei großem Umfang strukturieren lassen, als es bei PHP+JS möglich wäre.

Typensicherheit ist kein garantierter Pfad zum Glück, und man kann riesige Unternehmensprojekte in PHP umsetzen. Ich erinnere da immer wieder gern an Facebook... Und spätestens WENN man ein Web-Frontend hat, muss man JS verwenden, egal ob das Backend jetzt PHP, Ruby, Perl, ASP.NET oder Java ist.

Kannst du dazu vielleicht konkrete Beispiele nennen?

PHP kann im Normalfall keinen Prozess ewig als Schleife laufen lassen.
Nehmen wir mal eine recht bekannte Java-Anwendung, die effektiv nur verschiedene Web-Frontends füttert: Open Xchange...

OX in PHP würde schon daran scheitern, dass OX permanent als Daemon läuft und auf Anfragen wartet. Man kann solche Sachen nicht zweckmäßig in PHP lösen. Man könnte durchaus ne PHP CLI verwenden, die auf Sockets lauscht und... das is alles Murks.