Hej dedlfix,
Wieso sollte man zwei unterschiedliche Arbeitsweisen haben: eine für Intranets eine andere für öffentliche Anwendungen?
Ich habe sogar noch mehr Arbeitsweisen. Jeder Fall sollte nach seinen Anforderungen behandelt werden und nicht nur nach Schema F.
Hmm - da reden wir wohl aneinander vorbei. Mein Schwerpunkt ist ja Barrierefreiheit. Ich müsste erst mal überlegen, wie ich mein html aufbauen muss, damit es Barrieren hat. Ich gewöhne mir schlicht an, Code auf eine bestimmte Weise zu schreiben. Oft weiß ich nach Jahren gar nicht mehr warum ich etwas so mache. Wie ich es mache, ich verlass mich aber darauf, dass ich mir mal was dabei gedacht habe, als ich es mir so angewöhnt habe.
Ich kenne keine Agentur, die das so macht. Aber ich habe mehrere kennengelernt, die sagen, für ein Intranet ist das nicht unbedingt nötig (aber auch da wäre es schön, unser internes Netz stottert ganz schön, seit 400 Mitarbeiter die großzügigerere telearbeitsregwlung angenommen haben, die Nächste Ausbaustufe ist mal wieder fällig).
Die Webanwendung ist dann einer von vielen Aspekten. Die Größe von Framework-Code spielt dabei vermutlich eine geringere Rolle. Das muss pro Sitzung lediglich einmal übertragen werden, wenn überhaupt.
Anzunehmen. Oder auch 400 mal.
Vielleicht auch mehrmals täglich? Keine Ahnung, was bei einer webanwendung im Gegensatz zu einer Website gecacht wird.
Als Frontender ist mir an schlankem sauberen Code auch noch aus einem anderen Grund gelegen. Er ist besser zu verstehen.
Und dann wird im wilden weiten Web genauso geklotzt, wie im Intranet. Weil es zu aufwändig und teuer wäre eine Anwendung jetzt ganz anders als auf die gewohnte Weise zu bauen.
Eben deswegen ist das Schema F nicht für alle Situationen geeignet.
Gut, dass du das so siehst. Vielleicht bewerbt ihr euch mal auf unsere nächste Ausschreibung. 😉
Und dann kann man sich durch fremden Code kämpfen, der eben aus drölf zusammengeklatschten Web-Downloads besteht von backendern zusammengefriemelt, die von Frontend so viel Ahnung haben, dass sie gerade mal die Farben angepasst haben.
Schade, eine solche Arbeitsweise bekommt man aber nicht durch den Verzicht auf Frameworks geregelt.
Die bekommst du gar nicht geregelt, da kannst du nur weiter dran rummurksen bis es wie gewünscht aussieht… 😟
Und selbst wenn muss ich mich dann erst einlesen und stelle oft fest, dass da mit Kanonen auf Spatzen geschossen wurde, weil ein mächtiges Tool genommen wurde, nur um Tabellen nach bestimmten Spalten sortieren zu können, wofür es hunderte kleiner, funktionierender JS-Lösungen gibt.
Passiert auch. Es kommt aber oft günstiger, wenn man was bekanntes nimmt, statt Komponenten vieler Hersteller.
Wie ich schon sagte: günstig in der einmaligen Erstellung, teuer womöglich im Dauerbetrieb.
Wenn du nur Intranet machst, mag auch das nicht stimmen. Keine Ahnung ob bei einer internen Anwendung die meist viele Jahre läuft. Da Dinge wie Kosten für Strom, Kühlung oder ähnliches schon eine Rolle spielen können oder ob das vernachlässigt werden kann.
Od3r wie viel Aufwand es ist, so etwas zu patschen und zu pflegen…
Aber das Riesen-Framework für alle Fälle setzt die Agentur immer ein - weil man es halt kennt.
Das schöne an den Kendo/Telerik-Komponenten ist, dass man recht einfach auch nur diejenigen inkludieren kann, die man braucht und nicht andersherum aus dem großen Paket alles rauswerfen muss, was man nicht braucht. Dann würde wohl auch zu viel drinbleiben. Am Anfang weiß man noch nicht, was man braucht und lässt erstmal alles drin, am Ende hat keiner mehr Zeit und den exakten Überblick, was man doch alles verbaut hat.
Ja, genau so was bekomme ich ständig.
Als Nutzer des Webs habe ich aber das Gefühl, dass alles immer fetter wird (im Sinne von übergewichtig)…
Lässt es sich vermeiden?
Für mich als Frontender: ja.
Da ich im Monat nicht mehr koste, als externe an drei Tagen, habe ich auch kein schlechtes Gewissen, wenn ich mir für eine gute Lösung Zeit nehme.
Marc
Ceterum censeo Google esse delendam