Warum es gut ist das eigene Boilerplate zu haben und zu pflegen aber warum das nicht der Weg für dich sein muss. Mein Boilerplate besteht zu vielen Teilen aus Ideen anderer. Das ist OK für mich, da man das Rad auch nicht neu erfinden muss wenn andere ein Problem schon elegant gelöst haben. Wie immer kann ich an der Stelle nur Danke ans webdevs.xyz Team sagen und speziell an die Abteilung Kittn.

Wenn ich kurz zusammenfassen darf bzw. die letzten zwei drei Jahre Revue passieren lasse, began der Weg für mich in die „moderne“ Frontend-Entwicklung in der Tat mit Codekit. Dafür wurde ich oft belächelt aber ich denke der Einstieg mit dem Tool ist nach wie vor sehr gut vor allem wenn man Designer ist und somit eher Quereinsteiger. So ein GUI kann schon manchmal ganz nett sein für gewisse Dinge um sie auch besser zu verstehen.

Doch wenn man in einem Team arbeitet — zu dieser zeit bei FORK — kann man nicht immer machen was man will und muss aufeinander Rücksicht nehmen und sich unterordnen. Codekit war gut wenn ich alleine Projekte auf dem Tisch hatte aber mit den anderen Developern zusammen? Ne, die konnte ich sicher nicht von Codekit überzeugen was natürlich vollkommen OK ist.

Es kamen also Projekte mit Middleman und Jekyll was dann für mich so der Anfang war mit den ganzen Package Managern etc. in Berührung zu kommen. Gemocht hab ich das sicher nicht da es einfach böhmische Dörfer waren. Aber andererseits wusste ich auch, dass ich dadurch lernen würde und die nächsten Schritte gehen werde.

Nach und nach probierte ich mich dann daran kleine Boilerplates zu bauen um mir neue Projekte etwas einfacher von der Hand gehen zu lassen. Das war alles allerdings nicht so das gelbe vom Ei und nicht wirklich SMART.

Vor etwa zwei Jahren hab ich dann erste Versuche in YEOMAN unternommen und ich sag mal: „YO“, das taugt. Das war dann auch der Startschuss für das dhBoilerplate. Ja, über den Namen kann man streiten. Entweder man findet Zeit um sich einen coolen Namen zu überlegen oder man verbindet es einfach mit seinem Namen. Zweites war einfacher und nun ist es halt wie es ist. Wie ich schon Eingangs habe anklingen lassen wäre es mir alleine wohl nicht möglich gewesen das Boilerplate + Generator auf die Beine zu stellen. Aber alle fangen mal an und als Developer kann man grundsätzlich ja nur Interesse daran haben, wenn sich Leute tiefer eingraben und lernen wollen.

Was ist denn Yeoman?

Mit meinen eigenen Worten erklärt ist Yeoman die Grundlage eines jeden Projekts. Im Grunde übernimmt Yeoman das Grundsetup vom Projekt und richtet das eigentliche Boilerplate soweit es geht automatisch ein. Durch starten von YO wird man durch einen Prozess geführt wo man als User ein paar Fragen beantworten muss und ein paar Projektdetails eingeben muss wie z.B.: Projektname, WordPress oder Craft CMS, soll jQuery genutzt werden usw. anhand dieser Fragen baut Yeoman das Boilerplate dann zusammen und dann kann es auch schon losgehen. Danach ist Yeoman wieder raus aus dem Projekt. Das ist SMART und funktioniert jetzt über die Jahre außerordentlich gut.

Das Boilerplate

Im Grunde sind hier eine Menge Sachen drin die sich bewehrt haben und die man immer wieder braucht in Projekten. Mein Ziel ist es aber das ganze dennoch schlank zu halten und nicht alles reinzupacken was man mal brauchen könnte. Denn je größer so ein Boilerplate wird, desto mehr Zeit frisst es auch, dass ganze zu pflegen und mehr Bausteine heißt meist auch mehr Komplexität. Ich versuche den Spagat zu schaffen zwischen einfach und dennoch genug Funktionsumfang.

Herzstück des ganzen sind aktuell sicher der ganze Sass Part sowie der Craft CMS Part. Prototyping und WordPress ist auch mit drin aber das ganze bekommt im Moment weniger Aufmerksamkeit. Man muss halt Prioritäten setzen. Aber Inhaltlich möchte ich gar nicht mehr drauf eingehen. Wer mehr wissen will soll es einfach ausprobieren.

Lohnt es sich ein eigenes Boilerplate zu pflegen

Vielleicht nicht wenn man ehrlich ist. Oder die bessere Antwort: Es kommt drauf an. Die Frage ist eher was hat man damit vor und wie sehr möchte man selbst die Hand drauf haben was das gute Stück kann und was es nicht kann. Genau hier liegt der Punkt für mich und deswegen muss ich es auch mit einem Ja, es lohnt sich beantworten. Wenn ich allein an die letzten paar Monate zurückdenke, wie oft ich da Sachen über den Haufen geworfen habe da wir in Projekten merkten, dass ein andere Weg vielleicht besser funktionieren würde. Und nutzt man jetzt ein Boilerplate von jemand anderem ist man da natürlich deutlich eingeschränkter. Was jetzt aber auch gar nicht schlecht sein muss aber es ist halt ein anderer Weg den man dann geht. Mir würde wie gesagt einfach die Freiheit fehlen Sachen ständig anzupassen und zu überdenken.

Warum öffentlich?

Darüber hatte ich mir keine großen Gedanken gemacht. Vieles davon ist wie gesagt von anderen Entwicklern die ihre Sachen auch öffentlich zur Verfügung stellen und so sehe ich da auch. Wenn es Leute nutzen und Ihnen weiterhilft ist das doch was tolles. Ich werde jetzt nicht das ganze für andere umbauen im großen Stil. An erster Stelle steht klar der eigenen nutzen des Boilerplates. Wem gewisse Sachen nicht so zusagen der geht halt weiter und nutzt ein anderes. Das ist OK und auch gut so. So mache ich das und so sollte es auch jeder andere machen.

Also so ein eigenes Boilerplate kann super sein aber es erfordert auch etwas pflege. Sachen die man in Projekten lernt wieder zurückzuspielen, Dependencies aktuell halten, testen usw. All das sollte man mit auf dem Schirm haben. Wenn man die Zeit aufwenden kann und will ist es sicher nicht von Nachteil Herr über den eigenen Werkzeugkoffer zu sein.

Das eigene Boilerplate?!