Ich starte zum Thema der GUI ein neues Thema, da gibt es viel Diskussionsbedarf und es geht alles in einem riesigen Thema unter.
Jede Veränderung (auch gulp) macht es natürlich komplexer auf die eine oder andere Weise. Entweder im Build oder im Projektaufbau. Das Einsparungspotential mit webpack wäre jedenfalls ähnlich hoch (oder sogar höher) wie bei Arduino als Komponente.
Ist also eine Frage von Prioritäten und auch natürlich Skills im Projekt. Wenn webpack bisher niemand erfolgreich eingesetzt hat macht es keinen Sinn das zu probieren, dann wird nur der Code unmaintainable.
Gleichzeitig werden Leute mit Erfahrung in webpack von Monofiles eher abgeschreckt. Ist einfach die Frage, wie man (mittel)große Projekte organisiert – entweder vertikal im Editor und man scrollt sich einen Wolf oder in Ordnern und Dateien und man muss verstehen/rausfinden, was wo liegt.
Es wäre eine Möglichkeit. Ich finde die GUI prinzipiell funktionial aber nicht sonderlich modern und enorm schwer zu maintainen für Einsteiger. Das kommt sicher auch aus der Geschichte, dass es einfach immer weiter gewachsen ist im Korsett des Monofiles. Das ist okay, es gab aber auch schon mal einen Vorschlag mit anderer Gruppierung, anderem Aufbau, der hat mich persönlich einfach mehr angesprochen. [1][2]
Da muss aber dann auch ein System existieren, das alle Versionen die im Umlauf sind serven kann. Also mittels Content-Hashes oder Versionsnummern, sonst hast du breaking changes bei Boxes mit älterer Firmware, wenn CSS oder JS mal Version-Updates bekommen – wie jetzt gerade zB.
PS: das wär mit webpack part of the deal
Alternativ zu den filenames könnte man natürlich auch API-development-standards anwenden und sagen, es darf keine breaking changes geben. Find ich persönlich aber bei Webdevelopment keinen gangbaren Weg, das macht Upgrading quasi unmöglich.
PS: Ich hab den Titel nochmal angepasst, die Diskussion dreht sich ja eher um die Philosophie von Relaunch vs. KISS
Die jetzige GUI ist funktional und das Design ist historisch gewachsen.
Man könnte dann das ganze Responsive aufbauen und eventuelle neue Features schon mit berücksichtigen.
Das ist (gefühlt) ein Riesending. Ich hatte mir das mal im jugendlichen Leichtsinn angeschaut, jedoch bin ich schnell an meine Grenzen gestoßen und wenn ich eure Diskussionen nachverfolge sehe ich noch viele Lücken bei mir (gemessen daran, wie oft ich google bemühen muss)
Fraglich ist, ob man das organisiert bekommt. Schließlich handelt es sich hier um ein Hobbyprojekt und die Funktionalität ist ja gegeben.
Es wär eben ein größeres Hobbyprojekt im Hobbyprojekt für Leute, die eher was mit Frontend/Webentwicklung anfangen können als mit C++ (da zähl ich mich z.B. dazu) und auch Spaß an modernen UIs haben
Das Schöne wär ja, dass es einigermaßen abgekoppelt wäre und auch mal ein Jahr dauern kann. So könnte es inkrementell einfach immer mehr Features bekommen bis es am aktuellen Stand ankommt.
Es sollte nur glaub ich mehr als eine Person dran werkeln, sonst wird es einerseits mit der Motivation schwierig und andererseits wird man als lonesome warrior gerne betriebsblind und macht mehr Quatsch als wenn andere mitreden – vorallem bei so größeren Dingen.
Entsprechend soll das eine Art Aufruf sein an alle, die sich da auch gerne sehen: Ein bissl Features ausarbeiten, welche das wären und wie das alles am geschicktesten angeordnet wäre, eine Roadmap/Backlog und dann gehts ans Programmieren
@trainbird Habe das Thema noch nicht ganz geblickt, meinst Du im Thread-Titel nicht eher „Eine neue GUI“? Das wäre allerdings schon eine Mega-Aufgabe die schon einmal mangels Zeit gescheitert ist!
Vorteile von Webpack für die bestehende GUI sehe ich eher nicht da wir die Ressorcen bereits optimiert (GZIP-komprimiert) ausliefern. Man würde wohl nur 2-3 Request einsparen und hätte zusätzliche Build-Abhängigkeiten. Aber das könnte man natürlich mal ausprobieren…
Ich würde von Webpack abraten. Webpack bringt eine zusätzliche Hürde für neue UI-Entwickler und macht das sich einarbeiten nicht einfacher.
Und soweit ich sehe, wird webpack i.d.R. dazu benutzt, alles in eine einzelne Datei zu packen. Alle momentan extern gehosteten Dateien belegen ca. 900 kBytes! Haben wir den Platz dafür im Flash? Falls ja, könnten wir alles ins Flash legen, ich gehe aber davon aus, dass das zu gross ist.
Mein Vorschlag ist, wie schon erwähnt, alle CSS und alle JS Dateien in je eine Datei zu mergen (z.b. mit grunt-concat). Dann hätten wir 2 neue Dateien. An der HTML-Datei würde sich nahezu nichts ändern → es bleibt einfach.
Für die Versionierung können wir einen Hash über die beiden Dateien legen und als Dateinamen verwenden. Die beiden Dateien können dann entweder auf der SD-Karte abgelegt werden oder online verfügbar gemacht werden (Je nach Präferenz des Anwenders). Wie ich schon gezeigt habe, unterstützt HTML einen Fallback für die Links auf CSS und JS-Seiten, da müsste am HTML-FIle nichts angepasst werden. (Falls es von der Latenz zu gross wird, könnten wir das aber auch zur Buildzeit vorgeben lassen).
Zum Online bereitstellen gibt es wiederum mehrere Varianten:
Die gemergten Dateien direkt im Gitrepo ablegen und via Github-Raw-Links bereitstellen. Da diese Dateien sehr selten ändern, wäre das ein pragmatischer Ansatz. Bei neuen Versionen (= neuer Hash) einfach die neuen Dateien hinzufügen und die alten nicht entfernen. Dadurch bleiben wir abwärtskompatibel.
Über den Buildprozess mergen lassen und auf einer Github-Page bereitstellen. Es ist etwas mehr Konfigurationsaufwand, aber ich aber auch schon gemacht. Eine Herausforderung dabei bleibt das weiterhin bereitstellen der alten Versionen.
Das UI finde ich übrigens ganz ok so wie es jetzt ist. Ein Redesign ist ein grosser Aufwand und bringt wenig Benefit. Ich von meiner Seite werde da kaum Zeit investieren. Falls das doch jemand anpacken möchte ist mein Vorschlag mit den 2 Dateien kein Problem. Einfach neue Dateien schnüren und fertig.
Wir könnten das Ganze auch noch weiter optimieren:
Im HTML Header kann man angeben, dass die Verlinkten Dateienfür eine bestimmte Zeit gecached werden sollen. Dadurch ist der Load des MCUs nur beim ersten Laden erhöht.
Wir könnten im UI eine Funktion einbauen, welche die nötigen Dateien auf Wunsch automatsch herunterläd und im MCu ablegt.
Ich wollte anfangs nur die Diskussion entwirren, weil sich die Themen im anderen Thread massiv überlagert haben. Dann ist ein bisschen der jugendliche Leichtsinn mit mir durchgegangen und ich hab zu träumen begonnen
Hab den Titel nochmal angepasst
Genau, das ist gescheitert, weil die API erst in Entwicklung war und es nur einen Einzelkämpfer gab, der dann keine Zeit mehr hatte. Drum möchte ich sowas auch nicht einfach mal alleine starten, sondern mal abchecken ob es andere Interessierte gibt.
Und zur Klarstellung der Begrifflichkeiten und Technologien: Es geht nicht darum mit webpack zu starten, sondern darum, ein Framework wie React, Svelte, Vite oder sonstiges zu verwenden. Die verwenden im Hintergrund natürlich webpack. Aber das zu 98% ideal vorkonfiguriert. Ich greif da – wenn überhaupt – für ein paar Detaileinstellungen ein.
Wenn ich über webpack als Startpunkt kommen würde – vergesst es, die Doku ist so sautrocken und kompliziert, da steig ich auch als eingefleischter Fan aus
Vorteile von webpack aka React/Svelte/...
Bundling funktioniert out of the Box. Es wird ein Bundle für den Application Code gemacht und ein vendor.hash.js für die Bibliotheken. Da sich die selten ändern, kann der Cache dafür quasi unendlich lang sein.
Mittels Treeshaking wird unerreichbarer Code einfach ausgespart. Das wären so ungefähr 95% jQuery und 75% bootstrap (um nur die größeren beiden der aktuellen Abhängigkeiten zu nennen), die da nicht geliefert werden müssen.
Es ist möglich Klassen/Templates für die Komponenten zu erstellen und einfach wiederzuverwenden. Modals, Buttons, Tabs, … das alles braucht dann nur noch eine Referenz zu sein. Code Duplication wird dadurch minimiert, Fehler durch Copy+Paste ebenso.
Ich kenn mich mit PlatformIO nicht so gut aus, aber ich denke es wäre auch machbar, dass man zur Build-Zeit Tabs ausspart, wenns die config erlaubt. Also etwa Bluetooth, FTP, MQTT, was den Build nochmal kleiner machen würde.
Der Hund am „mal ausprobieren“ ist, dass es ein kompletter Relaunch ist. Vom bisherigen Code ist da nicht viel verwendbar, weils wie ein Umstieg von C auf Java ist. Und die Entscheidung, welches Framework (React, Svelte, Vite, …) ist da auch ein definierender Faktor. Wenn heute für React entschieden wird und morgen dreht sich der Wind Richtung Svelte, dann wirds wieder ein Relaunch
Man merkt es vielleicht: Ich bin auch nicht ganz glücklich mit dem Dilemma und kann sowohl einem Relaunch als auch dem Dabei-Bleiben was abgewinnen.
Plain HTML ist für Einsteigende freundlicher als ein massives Framework.
Kleine Dateien und klare Struktur sind besser zu warten als ein 2700-Zeilen-Monolith.
Vielleicht gibt es ja im Bereich grunt-concat eine Möglichkeit, ein paar Teile aus dem Monolithen auszulagern und nur für den Build zusammenzustoppeln? Also dass etwa CSS und JS in eigenen Files wohnen und dann in die respektiven <style/> und <script/> tags wandern. Auf den ersten Blick wirkt es möglich
Ich bin momentan gerade daran, mit GULP die CSS- und JS-Dateien zu jeweils einer Datei zu packen. Momentan noch von Hand, aber mein Ziel ist, dass wir das auch automatisiert machen können im buildprocess. Leider zieht das aber einige Abhängigkeiten mit sich (NPM, Node.js, Grunt, …)
Werde vermutlich heute abend einen PR dafür bereitstellen.
Für später schwebt mir die Idee vor, dass das UI beim ersten mal laden (und via Tools-Tab) die Option anbietet, die Dateien einmalig online zu ziehen, damit man danach ohne Internetverbindung auskommen kann.
Ketzerische Frage: Wie viel benutzt ihr denn das Webinterface und wofür? Ich finde es eigentlich seit der API-Umstellung ziemlich feature complete. Npm plus Pakete ist schon ne heftige Abhängigkeit.
Sehr gute Frage, da kommen wir der Sache schon näher
Ich benutz es momentan oft um die Tags einzurichten und Musik rauf zu spielen. Also vmtl derweil noch öfter als das Zielpublikum die Tags verwendet
Und ich bin einfach ein bissl pedantisch bei Usability und denk mir immer, dass es soviel Potential hätte. Weil aktuell greift der Rest der Family da nur mit Feuerzange dran an die UI.
Entschuldigung, ich habe mich wohl etwas unklar ausgedrückt.
Bis gerade eben war mein Verständnis, dass man JS- und insbesondere CSS-Dateien nicht einfach aneinanderhängen kann, da sie Vererbungen enthalten können.
Deshalb gibt es ja auch diese komplexen Tools wie Grunt.
DieErwähnten Abhängigkeiten wären übrigens nur für den Build-Prozess. Auf die Firmware und das WebUI hätte das keinen Einfluss.
Nun habe ich aber doch mal noch einen Test gemacht und einfach mal alle JS- resp. CSS-Dateien dumm aneinandergehängt. Und es scheint zu funktionieren! Zumindest sehe ich keine Errors im Log und das UI funktioniert auch ohne Probleme.
Ich werde also mal diesen Ansatz weiterverfolgen. D.h., es hat keine zusätzlichen/neuen Abhängigkeiten.
Man muss hald auch immder den Aufwand und Ertrag anschauen. Für die meisten Anwender ist wohl das agtuelle UI mehr als ausreichend.
Nachdem ästhetisches Empfinden ganz klar subjektiv ist ist auch der Ertrag sehr individuell behaupt ich mal
Das klingt ja schon mal gut!
Ich hab heute verzweifelt gesucht aber nicht um die Burg rausgefunden, wie die minification weiß, wo sie hin speichern soll/wie man an den Parameter OUTPUT_DIR kommt bzw woher der Rest der Kette weiß, dass jetzt die min-Files genommen werden sollen anstatt der originalen. Sonst hätt ich auch der Ästhetik halber die min files (die ja build sind) aus dem src-Ordner (der ja die sources beinhalten sollte) in irgendeinen Ordner von pio oder so geparkt.
Das passiert on the fly, direkt im RAM.
Die Datei wird eingelesen., minifiziert und dann direkt ins header-file geschrieben.
Zeile 96f in processHtml.py
Aber kann man die Ausgabe der .min-Files fürs Debugging irgendwie verhindern? Gibts dafür irgendein Flag oder so?
Die Dateien werden offenbar auch irgendwo im Buildprozess mal gelöscht, sonst würden sie nicht neu gebuildet werden. Kann der Check, ob die minifizierten Dateien noch nicht existieren jemals negativ ausfallen?
Seit der Umstellung auf API könntest du doch auch einfach ein lokales Interface auf einem anderen Computer starten und dann darüber managen, oder? Dann würde das gar keinen Platz mehr belegen, und man kann erstmal die UX implementieren, wie sie „sein kann“, als Prototyp.
Das management.html hatte das bisher nicht voll unterstützt, aber mit der Version im dev ist das nahezu vollständig möglich, siehe Anleitung zuoberst in der Datei. ich arbeite eigentlich nur so, spart viel Zeit.
Lediglich einige spezielle Aktion wie der Firmware Upload gehen (zur Zeit) nicht.
Klar, Entwicklung würd ich so beginnen. Wurde auch in der damals von @sonovice so gemacht. Die Arbeit bleibt aber dieselbe und darum auch die Frage, ob ich das alleine machen würde
Und in Summe möchte ich ja vor allem auf mobilen Endgeräten gut bedienbar werden, weil bei uns nicht dauernd PCs am laufen sind.
