Moin!
Ohne auch nur annähernd alles überblicken zu können, meine ich folgendes feststellen zu können: die Fähigkeit zu "coden", also tatsächlich Backend- und Frontend-Scripte von Grund auf zu entwickeln und zu schreiben, ist immer weniger gefragt, da diese Fertigkeiten mittlerweile in Frameworks gegossen der Allgemeinheit zur Verfügung stehen. (Analog kann man ja auch niemanden mehr mit tabellenlosem Design und sauberem CSS beeindrucken.)
Wenn das mit den Frameworks und der damit einhergehenden immer stärkeren Abstrahierung wirklich wahr wäre - warum gibt es dann immer noch Programmiersprachen wie C, in denen man sich jeden winzigen Fitzel im Zweifel immer wieder selbst definieren muß, und in denen man wirklich nur sehr wenig Unterstützung auf dem Basic-Level für typische Aufgaben hat?
Frameworks können sicher sehr nett sein. Aber sie coden nicht für einen. Sie designen keine User-Interfaces, sie erstellen keine Datenbanken, sie optimieren keine SQL-Querys, sie machen kein Feintuning im Code.
Das eigentliche Entwickeln wird immer weniger eine Dienstleistung sein, die kleine Agenturen wie die, in der ich arbeite, anbieten können bzw. sollten, denn es haben sich extrem fähige Entwicklergruppen gebildet (prominentes Beispiel: Google, Zend), die es besser und schneller können. Gefragt wird künftig immer mehr sein, daß man mit vorhandenen Frameworks schnell saubere und gute Lösungen entwickeln kann.
Gefragt wird sein, was Kunden nachfragen. Ehrlich gesagt habe ich noch keinen Kunden erlebt, der bei mir "eine Website mit Framework X" bestellt hat. Kunden, die einfach nur eine Webseite mit Y drauf haben wollen (setze für Y Dinge wie "Kontaktformular, Webshop, News, Newsletter,...") hingegen sind die Norm.
Und für die Kunden wird dann ein passendes Angebot gestrickt. Wenn sich der Einsatz eines CMS rechnet (hinsichtlich Aufwand, Bearbeitungsanforderung etc.), gibts ein CMS (das kann man ja durchaus auch als Framework bezeichnen), sind die Anforderungen "kleiner", gibt's eben angepaßt auf die Situation nur entsprechende Module (im Prinzip aus der Schublade, einen Formmailer beispielsweise hat man üblicherweise mal irgendwann so weit entwickelt, dass man ihn universell, mit nur geringen Anpassungen, überall verwenden kann - also auch eine Art Framework).
Insofern wird auch der Part der "Informationsarchitektur" immer wichtiger gegenüber dem Programmieren, insbesondere wenn man "IA" weiter faßt und auch die Planung der Anwendungslogik mit einbezieht.
Das mag sein, aber das ist ja auch weit außerhalb der Zuständigkeit eines Frameworks, sondern erfordert immer menschliche Intelligenz.
Ich weiß nicht, ob Ihr versteht, was ich meine. Zur Verdeutlichung noch ein Beispiel, das mich selbst schmerzt: meine eigene Javascript-Bibliothek (http://www.a-doelling.de/), die noch gar nicht so alt ist und die ich selbst vor kurzem noch für etwas geradezu Revolutionäres gehalten hatte, ist, wenn man sich im Web umschaut, mittlerweile nicht nur ein alter Hut, sondern vollkommen überflüssig.
Für wen überflüssig? Für dich selbst? Warum dieses? Immerhin kennst du die Interna der Bibliothek doch vermutlich sehr gut, kennst also ihre Stärken und Schwächen, die möglichen Einsatzgebiete etc., und kannst sogar selbst für die Wartung des Codes einstehen, im Gegensatz zu Fremdbibliotheken, an denen der Autor evtl. das Interesse verliert, die Weiterentwicklung einstellt, und sich auch kein interessierter Nachfolger findet.
Ich habe sehr viel Arbeit in diese Bibliothek investiert, sehr viel dabei gelernt - das ist für mich selbst gut. Aber wirtschaftlich gesehen wäre es zumindest jetzt sinnvoller, keinen Aufwand mehr in diese Klassensammlung zu investieren, sondern sich stattdessen mit einer der sich als Quasi-Standard etablierenden JS-Frameworks zu befassen (z.B. "Prototype").
Wenn du heute den Auftrag für eine Website erhalten würdest, welcher den Einsatz entweder deiner JS-Lib oder eines dir noch unbekannten anderen JS-Frameworks rechtfertigen würde - welche Wahl würdest du da treffen? Du würdest doch höchstwahrscheinlich dein eigenes Produkt einsetzen. Und es, falls noch die eine oder andere Funktion fehlt, in diesem Punkt erweitern, anstelle dich erst einmal komplett neu in ein fremdes Framework einzuarbeiten, bei dem du komplett von Null anfängst. Einfach weil das die wirtschaftlichere Entscheidung ist.
Denn JS-Frameworks gibt es, wenn man genau hinschaut, dann doch weit mehr als nur eines. Das bedeutet: Mit der Entscheidung, eines der vielen zu nutzen wird auch die Gefahr eingekauft, dass genau dieses veraltet, nicht weiter gepflegt wird, sich als technische Sackgasse entpuppt, oder sonst negative Nebenwirkungen birgt. Murphy halt.
Umgekehrt: Egal welches Framework du wählst, andere Frameworks werden immer irgendwie attraktiver aussehen, weil sie Dinge erlauben, die dein benutzes Framework nur umständlich oder gar nicht hinkriegen. Du auf den ersten Blick also mit deiner Wahl die schlechtere Alternative ausgesucht hast. Was du zu dem Zeitpunkt ja noch nicht abschätzen kannst: Das andere Framework hat vermutlich auch ganz andere Probleme bzw. Pferdefüße. Ist beispielsweise deutlich ressourcenhungriger, oder langsamer, oder komplexer, oder schwieriger zu erweitern, es fehlen vielleicht Funktionen, die du bisher kanntest, es nutzt vielleicht auch eine komplett andere Abstrahierungssichtweise auf die Aufgabe - in jedem Fall wäre ein Transfer von einem zum anderen Framework ein Aufwand, der erst einmal nur viel kostet (Zeit für dich, und damit Geld), ohne dass er irgendeinen Funktionsvorteil für den Endbenutzer bringt, und ohne dass damit alles besser würde.
Das, was wir in der Agentur, in der ich arbeite, zum großen Teil tun, also komplette Anwendungen selbst zu schreiben, ist nichts anderes als vertane Zeit, scheint mir. Es bringt weder mich selbst als Entwickler noch meinen Arbeitgeber als Firma in irgendeiner Weise weiter.
Was heißt denn "weiterbringen"? Kommt kein Geld in die Kasse? Denn darum geht es doch in erster Linie.
Was den technischen Fortschritt angeht: Frameworks können natürlich helfen, nervige Standardaufgaben programmiertechnisch elegant und simpel zu lösen, so dass man sich auf das wirklich wichtige, nämlich die zu erstellende Funktionalität, konzentrieren kann. Dazu muß man das Framework allerdings erst einmal beherrschen. Und das klappt nur dann, wenn man bereit ist, dafür Zeit zu investieren.
Da solch einen Zeitaufwand aber in der Regel niemand bereit ist zu bezahlen, denn produktive Arbeit für den Kunden ist es eher nicht, man wird es also kaum abrechnen können (auch weil die Konkurrenz Preisdruck macht - denn neue Frameworks bieten sich typischerweise bei neuen Projekten, und damit neuen Kunden an, und die ködert man häufig auch über den Preis), und Mitarbeiterfortbildung auf Firmenkosten (allein die dafür draufgehende Zeit steht ja nicht für Kundenprojekte zur Verfügung) ist auch eher kritisch, weil das nur nebenbei, in Leerlaufzeiten, realisiert werden kann. Und ohne Projekt, in dem man die praktische Eignung testen kann, macht das sowieso keinen Spaß.
Nimm die Frameworks als das, was sie sind: Werkzeuge, die man einsetzen kann, wenn man glaubt, dass sie einen Vorteil bringen. Ich sehe nirgendwo einen Zwang, Frameworks einsetzen zu müssen. Ich sehe vielmehr, dass es deswegen so viele verschiedene Frameworks gibt, weil viele verschiedene Programmierer genau diesen Schritt selbst getan haben, nämlich ein Werkzeug zur Bewältigung ihrer alltäglichen, nervigen Aufgaben zu schaffen, auf das sie selbst immer wieder zurückgreifen. Einige Frameworks haben es dann geschafft, sowohl technisch so gut strukturiert zu sein, dass sie einen hohen Grad von Wiederverwendbarkeit aufweisen und so für andere nutzbar waren - und weiterhin wurden sie dann dank passender Lizenz auch noch in einem großen Kreis potentieller Anwender bekannt und wurden tatsächlich benutzt.
Es ist klar, dass zur Erstellung solcher Frameworks ein hohes Fachwissen aufgrund solider Ausbildung gehört, und dass man auch entsprechend viel Zeit hineinstecken können muß. Daraus resultiert, dass die meisten "Frameworks", die einfach nur mal zusammengestrickt wurden, um ein und dieselben Probleme einmalig dauerhaft zu erledigen, sich vermutlich nicht für die breite Masse an Anwendern eignen, weil sie zu speziell konzipiert oder technisch zu unflexibel geschrieben wurden.
Du erlebst also gerade den Konflikt zwischen deiner eigenen gefühlten Unzulänglichkeit und den überstrahlenden Positivbeispielen der bekannten Programmierpersönlichkeiten, die auf ihrem Level unerreichbar scheinen.
Wenn ich dir sage, dass die auch alle nur mit Wasser kochen - hilft das? :)
- Sven Rautenberg
--
"Love your nation - respect the others."