Tach!
Wenn ich die Funktionalität des Frameworks in derselben Qualität nachprogrammiert habe, habe ich nur Zeit verbraucht.
und eventuell etwas dabei gelernt. Und etwas für das eigene Selbstwertgefühl getan.
Für mich reicht es, die Funktionalität zu verstehen und mir einzubilden, das in Grundzügen auch hinzubekommen.
An dieser Stelle schreie ich spontan dazwischen: Doch, und zwar erheblich. Denn meistens nutzt man von einem großen Framework nur einen Bruchteil. Im besten Fall schleppt man den restlichen Code nur als Ballast mit - im ungünstigsten Fall muss man die Teile, die man eigentlich nicht braucht, trotzdem "versorgen", weil das ganze Framework in sich vernetzt ist.
Modularisierung und Tree Shaking existiert in modernen Systemen. Das sollte in der Argumentation gegen die Systeme berücksichtigt werden.
Vor allem dann nicht, wenn das Framework Mechanismen wie Treeshaking mitbringt und alles nicht benötigte für den Produktivbetrieb rausschüttelt.
Ist denn das heutzutage der Regelfall? Denn ich habe das zwar schon hin und wieder gelesen; mein Eindruck ist aber, dass es sich dann um eine rühmliche Ausnahme handelt.
Ich kann nicht für alle Systeme sprechen, weil ich genausowenig die Zeit habe, mich in alle einzuarbeiten, wie ein eigenes zu entwerfen. Ich gehe davon aus, dass die anderen Systeme ebenfalls WebPack oder ein ähnliches System verwenden oder unterstützen, um wettbewerbsfähig zu bleiben.
Frameworks pauschal zu verteufeln, bringt nichts. Bei der Entscheidung für eine bestimmte Technik sind viel mehr Kriterien zu berücksichtigen.
Ja. Zum Beispiel eine Abschätzung: Wie groß ist der Aufwand, a) sich in ein Framework einzuarbeiten, das in Frage kommt (und wie gut ist die Doku?), oder b) den relevanten Teil davon selbst zu programmieren?
Ja. Punkt a) ist beim zweiten mit diesem Framework realisierten Projekt bereits größtenteils erledigt.
Bei mir fiel die Entscheidung dann meist zugunsten von DIY. Das hat dann gleich den weiteren Vorteil, dass man seine eigene Implementierung genau kennt, auch ihre Grenzen bzw. ihre Fehlertoleranz oder ihre Schwächen. Das ist bei fremden Code nicht in dem Umfang gegeben.
Bei eigenem Code muss ich den ständig weiterentwickeln, um nicht technisch zurückzubleiben. Diese Zeit habe ich nicht. Bei einem extern entwickelten und gepflegen System passiert das ohne mein Zutun (oder auch mit, wenn ich einen Fehler melde) parallel zu meinen Projekten. Auch werden im Idealfall dort Fehler von viel mehr Augen entdeckt als bei meinem Closed Source System. Mein System für die Öffentlichkeit bereitzustellen, ist auch nicht die Lösung. Es muss sich am Ende denselben Argumenten stellen, wie sie anderen Systemen entgegengebracht werden. Dazu kommt noch der Supportaufwand.
dedlfix.