Stimmt es, dass heutige Programmierung nur noch aus Frameworks zusammenschustern besteht?

Nein. Sicher gibt es Anwendungen, wo nicht viel passiert außer Framework laden, Eingaben annehmen, in eine DB speichern und wieder ausgeben. Es gibt aber sicher eine Menge Anwendungen die deutlich komplexer sind.

An Frameworks ist per se auch nix Schlechtes. Man muss das Rad nicht immer wieder neu erfinden. Es gibt nun einmal viele Funktionalitäten, die man in so gut wie jeder App eines bestimmten Typs hat.

Manchmal macht ein Framework Sinn. Manchmal fertige einzelne Komponenten, die man selbst verdrahtet, manchmal auch eine Eigenentwicklung.

Ja, je nach Anwendung wirkt das dann eher wie Softwareintegration und Softwarekonfiguration, als Softwareentwicklung.

Nein, definitiv nein. Programmierung besteht nicht aus einem Zusammenschustern von Frameworks, sondern ist weitaus mehr und vielschichtiger, als es vielleicht auf den ersten Blick aussehen mag. Frameworks und Bibliotheken sind vereinfacht heruntergebrochen auch nur Werkzeuge von vielen, die einem die Arbeit erleichtern, Entwicklungsprozesse beschleunigen und/oder für einheitliche Strukturen sorgen.

Framework ist nicht gleich Framework und aus manchen wird effektiv nur ein Bruchteil von dem verwendet, was einem darüber bereitgestellt wird. Es geht häufig um gleichbleibende und wiederkehrende Abläufe, Funktionen oder sonstige Vorgaben, die sich mithilfe eines Frameworks schneller/einfacher implementieren lassen. Sei es beim Prototyping, bei der Umsetzung von besonderen Features oder das Handling und die allgemeine Verknüpfung von und mit Daten sowie Datensätzen.

Gerade in der Softwareentwicklung gibt es sehr viel Bewegung und gerade in diesem Berufsfeld ein ständiges Lernen mit dazugehört. Schlussendlich hängt es auch stark von der verwendeten Sprache, den gestellten Anforderungen und von einem selber ab, wie viel von einem Framework tatsächlich in ein Projekt einfließt. Ein Stack aus dutzenden Frameworks heißt am Ende des Tages nicht, dass man sie auch zu jeder Zeit einsetzt und im vollen Umfang verwendet. Wie ich bereits schrieb, sind es bloß kurz- oder längerlebige Werkzeuge wie die Sprachen selbst.

Frameworks ja.
Zusammenschustern nein.

Man muss nicht ständig das Rad neu entwickeln, die eigene Logik muss man natürlich immer noch selber schreiben. Es wird also effizienter und stabiler, weil es Frameworks gibt, die viel Arbeit abnehmen, eine lange Evolution hinter sich haben und ausführlicher getestet wurden.

Böse Zungen würden die Eingangsfrage wohl bejahen. Im Grunde genommen besteht das Problem in der gewerblichen Programmierung darin, kostengünstig funktionierende Produkte zu entwickeln und wartbar zu machen. Über großen Programmiercode die Übersicht zu behalten ist auch so eine Kunst.

Bei der Verwendung von Content-Management-Systemen zur Realisierung von Webseiten wird auch ein erheblicher Overhead an Daten mitgetragen, um die Seite auszuwerfen. Kleinere Agenturen können sich damit erhebliche Arbeit sparen.

Frameworks helfen dabei, mit weniger Handgriffen lauffähigen Code zu generieren. Allerdings gibt der Programmierer auch Kontrolle über schlanken Code ab.

Ich bin noch ein Romantiker des puren handgeschriebenen Codes (prinzipiell). Aber in der schnelllebigen Wirtschaftswelt heutzutage ist das illusorisch zu erwarten, dass man kostendeckend so arbeiten kann.

Der Eindruck stellt sich in der Tat ein. Man könnte einwenden, dass viele Programmierumgebungen letztlich auch Frameworks sind. Aber spätestens bei Frameworks wird halt "jedes Jahr eine neue Sau durchs Dorf getrieben".

Eine durchdachte Framework-Implementierung für Standardprobleme ist gleichwohl wohl besser als individuelle Schnellschüsse. Es ist kompliziert.