Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Welche Programmiersprache (+ Framework) für Webanwendungen?
Hallo zusammen,
wie der Titel schon vermuten lässt, möchte ich mich mit der Entwicklung von Webapplikationen beschäftigen. Im Vordergrund stehen dabei Interesse und Freude am Ausprobieren, es gibt also (noch) kein konkretes Projekt.
Leider habe ich mich in den letzten Jahren kaum mit diesem Thema beschäftigt - dementsprechend fehlt mir auch ein Überblick, was heutzutage empfehlenswert oder “cool” ist.
Daher meine Frage an euch: welche Sprache und welches Framework könnt ihr aus eurer Erfahrung heraus empfehlen? Bewertungskriterien wären für mich Mächtigkeit, Verbreitung und Lernaufwand.
Hier ein kurzer Überblick über meine bisherigen Optionen:
PHP
Damit habe ich vor ~10 Jahren meine Informatikerlaufbahn begonnen, somit sind die Grundlagen bereits bekannt. Allerdings habe ich keine Ahnung, wie viel sich seitdem verändert hat und wie gut die erhältlichen Frameworks sind.
Java + Spring MVC
Im Rahmen meines Master-Projektes durfte/musste ich damit arbeiten. Pluspunkte: geringer Lernaufwand (Java!), OOP. Nachteile?
ASP.NET
Als Werkstudent habe ich die letzten Jahre größtenteils mit C# verbracht, daher wäre das auch eine naheliegende Option.
Ruby (on Rails)
Damit habe ich mich noch gar nicht befasst, allerdings scheint das der aktuelle Trend zu sein.
Andere Alternativen: Python, …?
Für Erfahrungen und Ratschläge wäre ich sehr dankbar!
[quote=IBlubb]Ruby (on Rails)
Damit habe ich mich noch gar nicht befasst, allerdings scheint das der aktuelle Trend zu sein.[/quote]Auch wenn es der aktuelle Trend ist, habe ich bisher eher schlechte Erfahrungen mit Ruby gemacht. Dazu muss ich sagen, dass ich noch nie Software in Ruby geschrieben habe, sondern nur versucht habe bereits geschriebene Software zum laufen zu bekommen. Das ist im Prinzip relativ einfach, weil die meiste Software exakt spezifiziert, mit welchen Versionen von Paketen sie funktioniert und es ein Kommando gibt, um genau diese Umgebung herzustellen. Möchte man allerdings nicht exakt diese Version, sondern die in den Paketquellen des Betriebssystems gepflegten (und mit Sicherheitsupdates versorgten!) Pakete stattdessen benutzen kann man sich schon mal auf eine Odysee einstellen.
Ruby (on Rails) ist für mich also ein weiterer Kandidat in der Reihe “Paketverwaltung des Betriebssystems? Das können wir doch viel besser!”, die es dann dabei verkacken und einfach nur noch nervig sind. Zudem gibt es zwischen Inkompatibilitäten zwischen minor(!)-Versionen von ruby und teilweise auch einzelnen Gems, die ein ständiges migrierern der Codebasis erfordern. Noch dazu kommt die meiner Meinung nach arrogante Entwickler-Community “ruby über alles!”, “benutz halt einfach die neueste Version!”, “Warum compilierst dus dir nicht einfach selbst?”, “Installier dir doch 3 Ruby-Versionen parallel!”.
Daher meine Meinung: Finger weg. Vielleicht ist es in 10 Jahren so weit, dass man es ordentlich verwenden kann.
Von Ruby kann ich abraten, nicht unbedingt vom Programmieren her, da ist es manchmal ganz nett, wenn man auf den ausgetretenen Pfaden die Rails so vorgibt bleiben kann. Der einzige Kritikpunkt da ist eben die manchmal sehr mangelhafte Flexibilitaet, es ist oft sehr schwer bis unmoeglich eine Komponente im Framework zu ersetzen die einem nicht gefaellt oder die irgendeine Funktionalitaet die man braucht nicht kann. Wenn man beispielsweise ActiveRecord doof findet hat man verloren. Deutlich schlimmer, aber nicht unbedingt fuer den Programmierer der einmalig die Software runterschreibt, eher fuer den Nutzer und den ders pflegen darf, ist die komplett fehlende Kompatibilitaet zwischen Versionen. Es gibt vier oder fuenf gebraeuchliche Ruby-Versionen, dazu jeweils eine Rails-Version und dementsprechend darf man dann seine Anwendung an die vom Kunden gewuenschten Versionskombinationen anpassen oder alternativ eine komplett eigene Installation von allen Modulen pflegen. Die Probleme mit inkompatiblen Versionen hat man deutlich weniger in anderen Sprachen, Python ist da zwar auch boese, aber nicht ganz so. Und in Perl und Java ist die Sprache ausreichend stabil, dass man sich eigentlich nur ueber einzelne Module Gedanken machen braucht, die aber imho weniger oft durch Aenderungen Sachen kaputtmachen, einfach weils in der entsprechenden Community unerwuenscht ist (wobei es da auch wieder einzelne Gruppen gibt denen das wurscht ist wo man trotzdem wieder eine Versionshoelle kriegt, inclusive wenig hilfreichem “ja aber saug doch einfach alles aus CPAN”/“nimm doch Maven/anderemagischedinge”/etc.).
Worauf ich wert lege ist, dass man beim Entwickeln schnell kleine Aenderungen testen kann, dafuer bieten viele Frameworks wie RoR oder was ich verwende Perl Catalyst (http://catalyst.perl.org) einen kleinen Testserver, den startet man und der kriegt per inotify Aenderungen im Sourcetree mit, d.h. man speichert im vim, drueckt F5 im Browser und sieht sofort die Auswirkungen. Java ist zumindest bei den Sachen die ich bisher gesehen habe deutlich weniger komfortabel, bei Java kompiliert mans erst, packt man halt mal das .war neu und rebootet den Tomcat, was schonmal eine Gelegenheit zum Kaffeeholen sein kann (“nimm doch Eclipse, da kann man dafuer klicken” macht das auch nicht schneller).
Wie gesagt, mein persoenlicher Favorit ist Perl Catalyst. Gruende dafuer sind die (Versions-)Stabilitaet von Perl, d.h. keine allzugrossen Schmerzen was den von der Distro mitgelieferten Perl-Interpreter betrifft, die (relativ gute, aber nicht perfekte, ich bin da auch schonmal auf die Nase gefallen) Stabilitaet von Catalyst, die Sprache Perl an sich, die Flexibilitaet von Catalyst, d.h. anders als bei RoR hat man eine grosse Auswahl an Modulen die man einsetzen kann und der oben beschriebene sehr schnelle Entwicklungszyklus. Letztendlich ist aber alles Geschmackssache und du musst dir das mit deinen eigenen Kriterien alles selber raussuchen und mit allem mal rumspielen.
Was einem alle Frameworks aber nicht wirklich abnehmen sind die generellen Schmerzen die einem HTML, Javascript und die ganzen anderen clientseitigen Sauereien und Inkompatibilitaeten verursachen.
Wie wärs mit ASP.NET MVC4? Hat mir zumindest sehr gefallen, ganz schnell ziemlich gutes Zeug auf die Beine zu stellen 
Auch für Smartphones/Mobile Applikationen gut geeignet
Ich glaub es kommt vor allem drauf an, was für eine Seite du machen willst.
Pauschal würde ich wärmstens Blogofile empfehlen.
Ich hab vor einigen Jahren eine Seite mit Rails gemacht. Als dann Rails 2.0 kam, ging nichtsmehr. Hatte dann auch nicht den Nerv ewig damit rumzufrickeln.
Wenn die Seite nicht auf Linux laufen muss, dann ist ASP.NET recht angenehm.
Vor allem weil C# nunmal um Welten besser als Java ist.
PHP ist die übelste Sprache, läuft aber dafür auf jedem Billig-Webspace.
Mich wunderts sowieso, dass im Web immernoch die dynamisch typisierten Sprachen so oft benutzt werden.
Die Editoren dafür sind grausam, und Fehler merkt man erst wenns schon zu spät ist.
Liegt wohl am ehesten daran, dass Webfrickler das gewohnt sind.
Ich würde jetzt mal python mit https://www.djangoproject.com/ vorschlagen.
Python erlernt man sehr schnell und das Framework hat flüchtig betrachtet einen bequemen eindruck gemacht. Bringt glaub sogar OR-Mapper mit.
Wenn du viel Performance brauchst würde ich dir html + js vorschlagen. Der Webservice kann ja dann praktisch in jeder beliebigen Programmiersprache sein.
1 „Gefällt mir“
Tjo und ich kann einem RoR nur wärmstens empfehlen vor allem zum Einstieg wenn man was from scratch hochzieht. Das Versionschaos (vor 3.1/3.0) ist wahr aber nun obsolet. Der Sprung von 3.1 auf 3.2 war kein Problem. Und natürlich gibts Alternativen zu ActiveRecord wie z.B. DataMapper.
Im Wesentlichen ist die aktuelle Ruby/Rails Kombination 1.9.3/3.2 und dann gibts eben noch die alten Rails 2.3 Anwendungen die mit Ruby 1.8.7 laufen, alles andere ist exotisch.
Darüberhinaus gibts für so gut wie alles fertige gut funktionierende Gems und Ryan Bates zeigt auf seiner Seite railscasts.com immer wieder neue Perlen.
Und was arw zu den clientseitigen Generv meint hat man mit RoR auch nicht. Man setzt auf HAML, SASS, CoffeeScript und sprockets kümmert sich um alles (Komprimierung, Bundleling, Uglifying) und lacht über die Idioten die sich noch mit zu-Fuß zusammen-gefrickelten Skriptchaos rumplagen. Dazu kommt das alle assets, browsercache-freundlich verwaltet und ausgeliefert werden. Darüberhinaus kommt die nahtlose Integration mit Git und capistrano die das deployen der Software und die Versionsverwaltung einfach macht.
Was stimmt: Alles vor Rails 3.0 ist abfuck, seit 3.1 mit der Asset Pipeline und allem was Rails ab 3 noch so bietet ist ein Schmaus. War meine beste Entscheidung darauf gesetzt zu haben für Web-Sachen. Und was auch stimmt, man sollte sich an gewisse Rails-Konventionen halten aber die machen normal auch Sinn. Ich kann dir das Webbook http://railstutorials.org von Michael Hartl empfehlen, welches auf der aktuellsten Version 3.2 aufsetzt. Damit bist du auf der Höhe der Zeit.
Und übrigens, mit rvm und bundler ist das vermeintliche Versionschaos keines: Man weiß automatisch für jede Applikation welche Gemversion verwendet werden soll, so dass man für ein neues Projekt bedenkenlos die neuesten Versionen installieren kann ohne das man sich alte Applikationen zerschießt. Man kann dann auch die alten Applikationen Probe testen und wenns nich geklappt hat einfach ein rollback machen mit capistrano, vollkommen schmerzfrei.
Was ich aber nicht verschweigen will: Die Lernkurve am Anfang ist steil und das Erst-Setup muss man mal hinter sich bringen, aber man wird belohnt 
neverpanics Einwände kann ich aus der Praxis nicht nachvollziehen.
Mit Python und Django habe ich auch gute Erfahrungen gesammelt.
Das von neverpanic erwähnte Problem mit eigenen Paketmanagern ist bei Python auch vorhanden, was aber wohl (in beiden Fällen) auch teilweise den Distributionen zuzuschreiben ist. Ich kann hier jetzt zwar nur von Debian sprechen, welches ja nicht unbedingt für aktuelle Software bekannt ist. Immerhin sind dort auch viele Python-Bibliotheken in den Repositories enthalten, aber eben in veralteten Versionen. Hier muss man sich halt entscheiden: Alte Version über apt oder neue Version über easy_install/pip.
Mir ist jetzt nicht ganz klar, was mir dieser Satz sagen soll. Auf dem Client ist man bei Webanwendungen sowieso dazu gezwungen, HTML und Javascript zu verwenden, jetzt mal von GWT und Dart abgesehen.
Ok war evtl. nicht ganz deutlich ausgedrückt. Was ich meinte ist, dass man seine HTML Seiten möglichst statisch hält damit man wenige roundtrips ( lange im cache beim Client halten ) zum server hat. Das lässt sich mit serverseitig dynamisch erzeugten Webseiten nicht ganz so toll ausnutzen.
Deswegen der ansatz einer statischen HTML - Seite bei der alle dynamischen Inhalte mit javascript nachgeladen werden.
Das einzige was dann Last auf dem Server erzeugt ist der Webservice und der kann mit JSON schnelle und kleine Antworten geben.
Achso, ok. Da ist halt die Frage, ob diese Herangehensweise wirklich für Projekte geeignet ist, bei denen man ein entsprechendes Webframework einsetzen möchte.
Abgesehen davon bleibt natürlich die Frage, wie es bei Javascript mit der Barrierefreiheit aussieht. Ich verfolge da eigentlich immer den Ansatz, dass das meiste auch ohne Javascript grundsätzlich noch funktionsfähig bleibt.
Wow, vielen Dank schonmal für die vielen Anregungen! Ich schwanke gerade noch zwischen ASP.NET und RoR - werde mir aber auf jeden Fall mal beides anschauen.
unobstrusive JS ist das zauberwort, aber heutzutage in HTML5 after flash zeiten will man JS nicht mehr missen
Und das Geschwurbel, was er dir hier als geschnitten Brot verkaufen will ist genau der Mist, den ich angeprangert habe. RVM und capistrano sind genau die Teile, die das Mantra „ich scheiß auf die Paketverwaltung des Betriebssystems und machs selber, weil ich alles besser weiß und alles besser kann” par excellence implementieren.
[quote=izibi]Das von neverpanic erwähnte Problem mit eigenen Paketmanagern ist bei Python auch vorhanden, was aber wohl (in beiden Fällen) auch teilweise den Distributionen zuzuschreiben ist. Ich kann hier jetzt zwar nur von Debian sprechen, welches ja nicht unbedingt für aktuelle Software bekannt ist. Immerhin sind dort auch viele Python-Bibliotheken in den Repositories enthalten, aber eben in veralteten Versionen. Hier muss man sich halt entscheiden: Alte Version über apt oder neue Version über easy_install/pip.[/quote]Wenn man unbedingt neuere Versionen haben will darf man halt kein Debian benutzen (oder muss Debian testing installieren). Bei Ruby ist das Chaos aber noch eine gute Nummer größer als bei Python, wo izibi imho recht hat und die Verwirrung überschaubar ist. Nicht ohne Grund hat vor einiger Zeit der Debian-Maintainer der meisten Ruby-Pakete hingeschmissen und sich „lautstark” über die Feindlichkeit von Upstream gegenüber Paketierern beschwert…
[quote=Der Ich]neverpanics Einwände kann ich aus der Praxis nicht nachvollziehen.[/quote]Du scheinst andere Anforderungen an deine Software-Installation zu haben als ich. Wer kümmert sich eigentlich um Sicherheitsupdates deiner so (manuell) installierten Software? Wer fixt das Sicherheitsproblem in Rails 2.3.uralt, das deine alte Software haben will? Und wie kommt dieses Update zu dir aufs System?
2 „Gefällt mir“
einmal „bundle update“ löst das problem der sicherheitsupdates innerhalb eines tracks z.b. von 3.2.7 auf 3.2.8 und da sind keine Probleme zu erwarten.
Ich hab erst mit Rails 3.0 richtig RoR begonnen, weil alles davor wie ich schon sagte Murks war, daher habe ich keine Uralt-Software die auf 2.3 aufsetzt.
Wie gesagt die Einwände dazu sind berechtigt, aber ich sehe kein Problem als Frischling nun bei 3.2 einzusteigen. Ich sehe rvm und capistrano in der Hinsicht positiv.
Najaaa… früher war auch Rails 1.6(?) total aktuell, so wie 3.2 jetzt.
Das Problem hat man natürlich erst, wenn man Apps hat, die nicht die aktuelle Version verwenden.
Ja ok den Einwand verstehe ich, aber nun mal aus der Praxis gesehen (IMO): Die Webwelt ist sehr schnelllebig, Rails 2.3 und 1.x liegen nun schon ein paar Jährchen zurück, das Problem hat doch jede Sprache / Framework. Was ist mit PHP4 Anwendungen? Was ist mit ASP.NET 2.0 Anwendungen? Wenn man nicht hinterher bleibt stößt man doch automatisch auf das Problem mit Sicherheitsupdates und hoffnungslos veralteten Programmen und Versionen etc. Entweder man bezahlt einen Entwickler der die Software auf nen aktuellen Stand bringt oder lebt mit dem Umstand das es irgendwann keine Sicherheitsupdates mehr gibt, das ist nun aber kein RoR-spezifisches Problem. Oder sehe ich das falsch?
Ich persönlich bin im Moment bedient zum aktuell halten update in aptitude zu drücken und wenn sich bei Rails oder Gems was tut „bundle update“ zu drücken.
Das ist doch ähnlich wie wenn ich sagen würde: „Boah ne verwend mal kein Linux, ich hab das mal mit Kernel 2.2 damals probiert, das war vllt frickelig und nervig“ und heute funktioniert das auch für einen Durchschnitts-DAU vernünftig. Ubuntu drauf, regelmäßig die Aktualisierungsverwaltung laufen lassen wenn sie sich meldet und gut ist.
Naja, das Problem daran ist halt, dass inkompatible Versionsuebergaenge unterschiedlich haeufig vorkommen und dass Sprachen und Frameworks unterschiedlich viel Aufwand treiben um das schmerzlos zu halten. Ruby ist da halt besonders unschoen, weil so Versionswechsel haeufig sind und weil die Erfahrung aus der Vergangenheit halt zeigt, dass es niemanden interessiert wie sehr so eine Konversion weh tut. PHP4 nach 5 war dagegen viel harmloser, es war nur ein einzelner Uebergang und es gab sowohl eine geplante, ausreichend lange Uebergangsphase als auch entsprechende Hilfen. Sowas gibts halt in Ruby jaehrlich mit deutlich weniger Planung und Unterstuetzung.
Natuerlich kann man andererseits argumentieren, dass Software die oft per Hand auf die jeweils neueste Version eines Frameworks angepasst werden muss Jobsicherheit bietet. Allerdings nur, wenn man entsprechend daemliche Kundschaft hat.
Wenns bischen minimaler (oder flexibler) sein soll als ein volles Django – was ja von internationalisierung ueber ORM ueber templates und sonst noch alles mitbringt – kann ich werkzeug empfehlen fuer. Kann man dann nach belieben mit einer Template Sprache (z.B. jinja2) und einem ORM (z.B. alchemy) layer kombinieren … oder die datenbank ohne ORM ansprechen … oder keine Datenbank verwenden … oder
Funktioniert auch wunderbar mit Installation auf einem Debian stable (CentOS, sonstwas) und allen paketen aus dem Paketmanager. Gute Sache das
Wobei Werkzeug ja mehr in die Richtung HTTP-Bibliothek geht. Es dann auch noch Flask (http://flask.pocoo.org/) von den gleichen Entwicklern, dass zusätzliche Funktionen bietet.
1 „Gefällt mir“