Material UI & Co. - die versteckten Kosten von UI-Libraries // deutsch

[@florianfeilmeier1017]

Wir haben jede einzelne Komponente der externen Library gewrapped (von Anfang an). Komplexe Komponenten (wie Table und TreeView) wurden selbst gebaut. Tatsächlich war die erste ext. Library irgendwann tot und konnte recht schnell hinter den Wrappern ersetzt werden.

[@DJHightower77]

Also wenn ich ein Projekt übernehmen soll, ist es mir immer lieber, wenn eine bekannte UI-Bibliothek verwendet wurde. Die sind wenigstens dokumentiert - ganz anders, als Eigenentwicklungen oft.

[@thenativeweb]

Dann ist das Problem aber nicht die Eigenentwicklung, sondern die fehlende Dokumentation, oder?

[@DJHightower77]

Eigentlich war das nur einer der vielen Gründe, warum ich lieber ein Projekt übernehme, bei dem weit verbreitete (open-source)-Bibliotheken verwendet werden, statt Projekte, wo die Devs der Meinung waren, was Eigenes machen zu müssen. Das gilt für Bibliotheken im Backend genauso wie im Frontend. Neben der schlechtereren Doku sind das auch: - Fehlende Community - Weniger Features - Schlechtere Robustheit (weil MaterialUI & Co numal von viel mehr Personen tetestet werden)

[@tobymoby8524]

@@thenativeweb richtig, das Problem ist dann die Dokumentation. Diesen Fehler aber im Nachhinein auszubügeln ist mit immensen Ressourcenkosten und schlecht gelaunten Mitarbeitern verbunden. Gesamt betrachtet ist das sogar noch schlimmer als wenn ich ein UI Framework habe weswegen ich mein Projekt refactorn muss. Der Aufwand einer ordentlichen Dokumentation, grade wenn die regulatorisch eigentlich anders sein sollte als sie ist, ist immens! Klar sind externe Abhängigkeiten von Frameworks blöd, aber auch nur dann wenn der geschätzte Aufwand der Wartung die Ressourcen übersteigt. Eigenentwicklung hat auch immer ein ganz großes ABER.

[@kibanins]

Tailwind for the win. Ich baue mir meine eigenen Komponenten zusammen oder benutze entsprechende Templates. Keine Abhängigkeiten zu externen Bibliotheken, volle Anpassbarkeit. Die Abhängigkeit zu Tailwind selbst ist nicht so schlimm, weil sie vor allem im Build-Prozess passiert und es gibt sogar Alternativen mit dem gleichen Vokabular.

[@serpent213]

Ja, es gibt ja Frameworks auf unterschiedlichen Ebenen. DaisyUI zum Beispiel baut auf Tailwind auf, liefert Templates, macht aber letztlich keine Vorgaben, die Komponenten hab ich am Ende im eigenen Repo.

[@TheSkycro]

Mach ich mittlerweile auch so. Tailwind und eigene Komponenten. Lustigerweise hat mich tailwind erst abgeschreckt und ChatGPT hat mir das schmackhaft gemacht 😂 seitdem alles an UI mit Tailwind 😂

[@ES-cf4ph]

Arbeite im öffentlichen Dienst an einer Hochschule, tatsächlich haben wir uns auch für eine eigene Component Library entschieden mit Tailwind. Das initiale Entwickeln der Elemente war/ist zwar n Bisschen lästig am Anfang und ein paar komplexere Elemente wie Popups für Menüs fehlen noch, aber Tailwind ist so viel besser als das zurechtgebogene Bootstrap was vorher verwendet wurde

[@stentwo6479]

Ich beschäftige mich seit mittlerweile über 20 Jahren mit UI-Entwicklung. Ich unterstütze natürlich die Aussage, dass man sich Gedanken machen muss, welche Lib passend für das jeweilige Produkt ist. In der Frontend-Architektur müssen natürlich Mittel und Wege existieren, um modular zu bleiben (Stichwort "Wrapper"). Ich würde einem Kunden aber NIE empfehlen, auf eine komplette Eigenentwicklung der Komponenten zu setzen. Hier gibt es sicher auch nicht nur Schwarz/Weiss. Aber wer bspw. einen Datepicker lieber selbst entwickelt, der ... puh, weiss nicht. UIs werden immer noch viel zu sehr von eher Backend-fixierten Programmierenden entwickelt. Dass es ein Fulltime-Job ist, ein ordentliches FE zu betreuen, sehen viele nicht. Fazit: Sorry, aber bei Eigenentwicklung gehe ich nicht mit. Ich bin immer dankbar für die Expertise und die Arbeit einer ordentlichen Lib und freue mich, das Rad nicht immer wieder neu erfinden zu müssen.

[@thenativeweb]

Natürlich gibt es immer etwas zwischen den Extremen - das Problem ist halt nur, dass die meisten Unternehmen nicht verstehen, dass wenn sie sich für den kostengünstigen, aber wenig flexiblen Weg entscheiden, sie sich dann halt nicht wundern müssen, dass es dann sehr teuer wird, wenn sie dann Flexibilität haben wollen … und das passiert halt ständig. Lustigerweise haben wir im vergangenen Jahr in einem Projekt einen Datepicker selbst implementiert - funktioniert wunderbar, mit allem Schnick-Schnack, Tastaturbedienung, Accessibility, Tests, Theming-Unterstützung, … hat ein paar Tage gedauert. Und ja, klar, wäre das schneller gegangen, hätten wir einen von der Stange genommen. Dafür können wir unseren Datepicker aber exakt so anpassen, wie wir ihn brauchen, und - Überraschung - solche Fälle gab es schon. Ich bin heilfroh, dass wir *nicht* einen von der Stange genommen haben.

[@stentwo6479]

@@thenativeweb Dann würde ich euren Picker wahrscheinlich gerne nutzen, wenn ihr ihn als Lib veröffentlicht 😄 Wenn sich eine Wiederverwendbarkeit für euch als Unternehmen abzeichnet, ist es eventuell auch eine besondere Ausgangslage. Kommt also ein wenig auf die Sicht an. Danke für eure Beiträge!

[@rniestroj]

Wie kann ich dieser Antowort 50 Likes geben?

[@thenativeweb]

Danke schön 😊

[@lederstrumpfmithirschtalg]

@@thenativeweb Könntest du ein Beispiel bringen, inwiefern die Dutzenden (sicher nicht übertrieben) öffentlich verfügbaren DatePicker die Requirements nicht erfüllt haben und wie ihr zu dem Schluss gekommen seid, dass man das nicht relativ einfach mit einer OTS Lösung customizen kann?

[@ReneHartmann]

Das Problem kann auch in ganz anderen Kontexten auftreten. Es wird eine Standardsoftware oder -Library verwendet, da die aber das nicht so ganz unterstützt, was man gerne hätte, gibt es umfangreiche Eigenimplementierungen. Dann wird ein Upgrade zum Kraftakt, weil die Eigenentwicklungen auf die neue Version gehoben werden müssen. Scheint z.B. im SAP-Umfeld nicht selten zu sein.

[@rniestroj]

In meiner vorherigen Firma hatten Wir selber UI Komponenten gebaut, waren keine CSS Profis und die Anwendungen sahen so la la aus. Als ich dann die erste Anwendung mit Bootstrap gezeigt habe gab es nur riesen WOW. "Wir können plötzlich so hübsche Anwendungen erstellen?". Nie wieder lösungen Marke Eigenbau. Habe im Vue Umfeld mit Quasar und PrimeVue gearbeitet und die Anpassungsmöglichkeiten beider waren sehr gut, bei PrimeVue sogar hervorragend. Kann deine Sichtweise nicht bestätigen.

[@sebastianwei542]

Hast du schon mal mit UI / UX Experten zusammengearbeitet? Wenn du das alles in Figma vorgemalt bekommst dann musst als Entwickler nur noch nachmalen.

[@Kai-bv2yt]

@@sebastianwei542 welches Unternehmen leistet sich für eine interne Anwendung denn UI/UX Experten? Dafür ist ja wohl seltenst Geld da. Wir nutzen auf der Arbeit auch PrimeNG und gerade die darin vorhandenen Tabellen mit ihren ganzen Möglichkeiten (filter, sortieren, gruppieren, uvm.) nehmen so extrem viel Arbeit ab. Ich könnte mir nicht vorstellen, wie wir die Zeit für solche Tabellen aufbringen könnten. Dazu kommen dann noch Datepicker die wir selber niemals entwickeln würden.

[@christianhorauf9958]

Ich glaub ja ehrlich gesagt, dass das nicht nur am vermeintlichen Geldsparen liegt, warum unternehmen gerne eine UI Lib nehmen, es hat auch mit den Entwicklern zu tun. Denn wenn Entwickler oft schon eine knsppe Resource für Unternehmen sind, dann dürfte das für CSS-Entwickler gleich dreifach gelten. Wieviele Entwickler gibt es wohl die sich gerne mit den Eigenheiten von CSS herum schlagen. Auch wenn ich schon ganz phantastische Dinge gesehen habe, die mit reinem CSS gelöst wurden, fällt es mir schwer dafür all zu viel begeisterung auf zu bringen.

[@Willey1986]

Als Backend Entwickler muss ich mich doch aber auch mit SQL beschäftigen, muss MAVEN über die pom.xml konfigurieren und etwas Docker Kenntnisse können auch nicht schaden. Das ist immer kein Problem. 2 divs nebeneinander per Flexbox anzuzeigen ist dann aber zu viel des Guten.

[@ChillyHammer]

​@@Willey1986Sorry, es geht nicht um ein paar divs die nebeneinander angezeigt werden sollen. Das ist lächerlich und nicht das was mit "css Eigenheiten" gemeint ist.

[@tomtom2755]

@@Willey1986 So wie du redest hast du dich wohl auch noch nie mit Accessibility Anforderungen auseinander gesetzt...

[@matthiasbackhaus370]

Wir haben auch eine UI Library im Einsatz und haben die von uns genutzten Komponenten in custom Web Components gekapselt. Diese funktioniert wie ein interface und ermöglicht uns entweder eigene Komponenten zu entwickeln oder die Komponente der Library auszutauschen. Immernoch aufwändig aber ich muss nicht mehr tausend Formulare anpassen.

[@simitron1]

Der nachteil gillt nur bedingt für sowas wie shadcn ui. Hier werden ja die komponenten teil der codebasis und können daher direkt angepasst werden.

[@thenativeweb]

Das ist richtig - wobei das für mich auch eine andere Art Library ist als zB Material UI (nichtsdestotrotz könnte man auch das als "UI-Library" bezeichnen).

[@pinkeHelga]

@@thenativeweb Ich kenne beide Libs nicht und kann also nicht im speziellen mitreden. Ich unterscheide zwischen Bibliothek und Framework. Ein Framework bringt ein Gesamtkonzept, Architekturen mit. Eine Bibliothek liefert nur einzelne Elemente (die auch zusammenpassen, aufeinander abgestimmt sein können), die ich unmittelbar anwenden kann, ohne an eine Architektur gebunden zu sein. Bei reinen Bibliotheken sehe ich weniger Probleme. Die kann ich nach Bedarf austauschen oder durch eigene Implementationen ersetzen. Ihr könnt ja mal einordnen, welche der UIs eher Framework oder Bibliothek sind.

[@sebastianfeustel9178]

@pinkeHelga Ich glaube die Unterscheidung zwischen lib und Framework ist hier schwer zu sagen. Es ist so, dass du z.B. in React eigene Komponenten erstellst. MUI bringt halt viele dieser Komponenten mit, z.B. ein Button. Grade bei MUI setzt man dann fast ausschließlich auf die vorgefertigten Komponenten von MUI, damit es einheitlich wird. Und grade da entsteht die Abhängigkeit und ein Wechsel resultiert in sehr viel Arbeit.

[@Acronice1]

Bei uns ist Angular Material im Einsatz, anfangs war es sehr einfach eine relativ schöne Oberfläche zusammen zu stellen. Dann kamen aber neue Anforderungen dazu und so wurde immer weiter weg von der UI Library das Styling entwickelt. Wenn man an die Grenzen der Anpassbarkeit stoßt, ist man dann gezwungen ng-deep zu verwenden und bei Updates von Angular Material passt dann wieder gar nichts zusammen.

[@thenativeweb]

Das kommt mir *so* bekannt vor … leider.,

[@kalleneumann203]

Wir hängen grad auf MatUI 4 fest, genau wie im Video angesprochen. Trotzdem würde ich der Kritik an Libs von der Stange nicht zustimmen. Unser Produkt wurde tatsächlich agil entwickelt und MVPs waren in diversen Schritten wichtig. Hier macht es sehr wohl einen großen Unterschied wie schnell und mit welchen Entwicklungskosten man voran kommt. Das Argument die initialen Mehrkosten machen am Ende nicht viel aus gilt ja hier nicht, weil (auch beim besten Konzept!) anfangs völlig offen ist ob ein neues Produkt markttauglich ist. Wir rechnen jetzt mit 3 PersonenMonaten Aufwand das zu aktualisieren und das ist dann ziemlich ok, denn wir wissen jetzt dass es den Aufwand wert ist.

[@anyaplays7150]

Jeder mit mind. 10 Jahren Erfahrung in der Softwareentwicklung weiß, dass du recht hast 😄 Spätestens wenn die Frage kommt, ob alles etwas nach links oder rechts verschoben werden kann oder ob die Menüpunkte einen größeren Abstand haben können usw. und die Antwort lautet: "Das ist so vorgegeben", weißt du Bescheid. Ich nutze Bootstrap als Grundgerüst, das kann ich verbiegen, wie ich will. TailwindCSS ist auch ok. UI Elemente von Dritten bringen halt Geld für die Dritten.

[@ky-one]

Kann deinen Punkten vollständig zustimmen. Hab schon in zwei Projekten den Fall gehabt, eine vorhandene Third Party Ui lib komplett neu zu schreiben, damit sie so angepasst werden kann wie ein Designer es sich vorgestellt hat. Hab deswegen inzwischen für meine eigenen Projekte ein eigene UI lib gebaut. Allerdings kann das auch sehr teuer sein. Hab teilweise für komplexe Komponenten wie Dropdowns, Grids oder Charts schon mehrere Monate Lebenszeit investiert. Das muss sich eine Firma auch leisten wollen

[@WolfgangEgger]

Ich kann Deine Ausführungen zu 100% bestätigen. Ich habe lange für ein Unternehmen gearbeitet, in dem es mehrere Geschäftsfelder und daher Entwicklerteams gab. Einige haben Libraries und Frameworks von Drittanbietern benutzt, andere Teams haben vollständig auf Vanilla-Lösungen gesetzt. Auf lange Strecke waren die Vanilla-Teams mit weniger Manpower deutlich flexibler. Die Vanille-Lösungen haben 20 Jahre gehalten. In der gleichen Zeit mussten die Lösungen, die auf externe Technologien gesetzt haben, zwei- bis dreimal neu gebaut werden. Der einzige Vorteil, den die externen Lösungen hatten, war, dass sie moderner wirkten. Abgesehen davon denke ich, dass sich dieses Problem mit dem Einsatz von KI in der Entwicklung über kurz oder lang erledigt haben wird. Damit wird der konzeptionelle Part deutlich an Gewicht gewinnen. Die implementierende Technologie dürfte dann ohne großen Aufwand komplett austauschbar sein.

[@marcom.]

Das liegt aber an der Kurzlebigkeit der Web-UIs. Wenn ich an "echte" UI-Libraries für Desktops denke, z.B. Swing oder SWT, dann mussten wir da nicht alle paar Jahre Hand anlegen. Diese Stabilität habe ich bei Web-UIs in der Tat nicht beobachten können.

[@stefan-haas]

Ich finde da shadcn/ui cool, weil du den Code pullst und lokal hast. Damit kommst du dann nicht in die klassischen Update Migration Troubles, wie man es bei Angular Material oft sieht.

[@thenativeweb]

Ja, shadcn ist eine interessante Option, das stimmt 😊

[@dummywerfer]

Leider Alltag und öfters schon erlebt. UI/UX ist ein Thema, in welches man nicht investieren will. Weder konzeptionell noch bei der Implementierung. Und immer war es so, dass die Anpassungen des UI-Frameworks immer so viel Aufwand waren, dass man von vornherein eigene UI hätte implementieren können. Bisher ein Kampf gegen Windmühlen.

[@rappelkiste]

Bei uns aktuell genau so… MUI wurde von der firma die den ersten part angefangen hat einfach eingebaut. Erweiterungen kamen, und jetzt brauchts einen DateRangePicker, der auf einmal Geld kostet… auch manche Komponenten arbeiten nicht so wie gewünscht, also wird an- und umgebaut… echt schwierig…

[@thenativeweb]

Ja … also interessant finde ich, dass es gefühlt *immer* Material UI ist, womit man über kurz oder lang Probleme bekommt …

[@marcom.]

Als ich noch SW-Architekt bei meinem Vor-vor-Arbeitgeber war, da musste ich mich permanent gegen die Angular-Jünger verteidigen, weil wir stattdessen Vaadin eingesetzt haben. Es passte einfach viel besser zu unserem Multi-UI-Ansatz mit möglichst dünnem Frontend. Fast-forward zu meinem jetzigen AG und Projekt wird es wohl Flutter werden, weil auch hier wieder die Eignung für den Einsatzzweck im Vordergrund steht. Davon mal unabhängig bin ich ein großer Freund der Philosophie, dass UIs im Vergleich zum restlichen Code eigentlich eher kurzlebige Wegwerf-Ware sein sollten. Das geht natürlich nur, wenn man möglichst wenig fachliche Logik und Ablaufsteuerung dort hinterlegt. Daher sehe ich auch Euer Argument mit abhängig machen und mangelnder Flexibilität kritisch. Wenn Ihr das schon bei UIs so seht, was nehmt Ihr denn für das Backend alles nicht? Heutzutage nicht massiv auf Frameworks wie Spring, JPA, Message-Broker usw. zu setzen ist doch völlig illusorisch. Ob da dann noch ein weiteres fürs UI dazu kommt ist fast unerheblich, aber im Vergleich zum Rest fast am leichtesten auszutauschen. So manches Unternehmen ist halt zu blind oder faul, hier regelmäßig am Ball zu bleiben und den Technologiestack auf Vordermann zu halten. In unserem Unternehmen habe ich kürzlich eine Anwendung abgelöst, die noch auf Java 1.4 lief.

[@pinkeHelga]

Reine Bibliotheken gehen ja noch. Viel problematischer finde ich die ganzen Frameworks, die einen gleich noch in der Architekturentscheidung entmündigen. Leider findet man als Nativentwickler keinen Job mehr. Meine persönliche Erfahrung ist: Mit einem Framework kann man sehr schnell ein Projekt von Null auf 90 starten. Die restlichen 10 sind dann am Ende irgend welche Workarounds, die das Unmögliche doch noch möglich machen. Und die kosten dann mehr Zeit, als man anfangs eingespart hat. Und immer, wenn ich mich mit einem Framework auseinandersetze, stoße ich zielsicher direkt auf Bugs und unerfüllbare Anforderungen. Klar, bei Agenturarbeit setzt man natürlich auf Frameworks, die schon eine möglichst fertige Anwendung darstellen. Schnell mal Wordpress-Design erstellen und eine fertige Seite trashy rauspusten. Sind halt shoot and forget Projekte.

[@christianhorauf9958]

Ich fürchte dass dem gsnzen Frontend Thema das Shoot and Forget Mindset anhaftet, so dass ich mit meinem TDD Mindset meist auf verlorenem Posten kämpfte und jetzt mich schwer tue, im Backend zu brillieren

[@lemetwe3401]

Dafür ist standardisiert wie die Codebasis aussieht, Einarbeitungszeit ist dadurch kürzer und weniger Freiheit führt auch idR zu weniger "Müll" der fabriziert wird.

[@arcane3327]

Geht so. Es gibt noch Jobs die auch langfristig mit nativen libs arbeiten. Die findest du dann aber eher in der Industrie oder in hoch spezialisieren Unternehmen. Die shoot und forget Projekte sind eher n web Ding meiner Erfahrung nach.

[@LuckyLuggi89]

Ich bin momentan genau in dieser Situation gelandet. Das Problem ist denke ich oft dass die Programmierer die was zu sagen haben aus dem Backend Bereich kommen und es einfach hassen sich mit CSS und Ui generell zu beschäftigen. Diesen Leuten ist ui einfach auch oft nicht wichtig. Ich finde das extrem schade, weil ich glaube dass es gerade in Sachen Ui extrem viel Potential gibt sich von der Konkurrenz abzuheben. Vor einer Weile hatte ich einen Artikel zu einer neuen Bewegung in Richtung "Headless Ui" / "Unstyled Component Libraries" wie z.B. React Aria Components gelesen. Das wäre evtl. ein Mittelweg den man gehen könnte, aber ich persönlich glaube, dass einem auch hier noch zu viel vorgegeben wird. Was meint ihr dazu?

[@Willey1986]

Deckt sich mit meiner Erfahrung. Alle Seniors/Architekten bei uns kommen eher aus dem Java/Backend Bereich. Neben dämlichen Vorurteilen (Javascript ist keine richtige Sprache) fehlt auch vollkommen die Motivation sich mit dem Thema Frontend auseinander zu setzen. Da wird dann blind eine UI Lib ausgewählt weil man dann ja nichts mehr im Client tun muss. Und dann kommt der Kunde und will auf einmal ein Drop-down in einem Drop-down anzeigen was je nach Mondphase horizontal oder vertikal ausgerichtet ist. Und dann hacken diese Backend Entwickler irgendeine nicht wartbare Grütze zusammen und fühlen sich wieder bestätigt das FE = schlecht ist.

[@Leon-cm4uk]

Ich komme auch aus dem Backend Bereich, bewege mich auch mal im Frontend, aber eher im Backend und würde zustimmen. Vielen ist Frontend leider nicht so wichtig. Es ist trotzdem sehr entscheidend, dass UI schön aussieht und sich gut benutzen lässt (UX). Das sind aber Tätigkeitsfelder, die eigentlich ihre ganz eigene hohe Komplexität mitbringen und wo eigentlich viele Jahre Erfahrung benötigt wird, die jedoch meist fehlt. Das erlernt man jedoch nicht mal eben so und es braucht auch ein gewisses Auge für gutes Design und Intuition. Und das Fehlen dieser Expertise fangen viele Backend Spezialisten so ein bisschen ab.

[@ChillyHammer]

Gutes Video, alleedings, wenn jemand aus der Geschäftsführung denkt, dass ui libraries die nächsten 20 jahre halten, liegt das auch an den Entwicklern, die nicht darauf hinweisen, dass das nicht der Fall ist. Kein Geschäftsführer steckt bei einem 2 Mann Team erst mal ein halbes Jahr in die Entwicklung für custom controls, wenn man noch keine Ahnung hat, ob die Software 20, 2000 oder 20000 Abnehmer findet. Deshalb, immer ui library, wenn man dann 200k Abnehmer hat, finden sich 5 Entwickler, die ein paar Monate controls schreiben.

[@thenativeweb]

Ich kenne mehr als genug Unternehmen, in denen die Geschäftsführung überhaupt keine Ahnung von IT und / oder Entwickung hat, und diese Entscheidung einem Entwicklungsleiter übertragen / überlassen wird. Der hört zwar, was ihm die Entwickler sagen, aber er setzt es nicht durch, weil er letztlich der Geschäftsführung Rede und Antwort stehen muss, und es da halt am Ende doch so oft nur um (kurzfristige) Zahlen und nicht um (langfristige) Qualität geht. Und schon ist Material UI entgegen allen Empfehlungen und Bedenken gesetzt - und das wäre ja auch alles wunderbar so, wenn nicht nach zwei Wochen der erste Wunsch käme, ob man Designelement XYZ noch so und so anpassen könnte, weil das dann die CI/CD des Unternehmens besser widerspiegeln würde. Kurz: Ein Framework zu nehmen, weil es Kosten spart, zu Lasten der Flexibilität, und dann Flexibilität zu fordern, ist einfach dumm - aber leider zu oft Realität.

[@ChillyHammer]

@thenativeweb so kenne ich das auch. Leider hat man gegen die Geschäftsführung kaum Chancen. Gerade dein letzter Satz ist sehr zutreffend. Klar ist aber auch, dass man das gegenüber der Geschäftsführung nie genau so sagen kann.

[@thenativeweb]

Ja, das ist leider wahr… Und da merkt man dann oft auch, dass eben keine Beratung gewünscht ist, sondern - wie auch im Video erwähnt - nur jemand gesucht wird, der die vermeintlich ach so guten Ideen von außen noch mal abnickt. Gerade das ist aber etwas, wo ich denke, wo man sich als Berater wehren sollte: gutes Consulting zeichnet sich dadurch aus, dass man dem Kunden sagt, wie man die Situation einschätzt, und nicht das, was er hören möchte. Berater, die Letzteres machen, gibt es leider zu viele.

[@ChillyHammer]

@@thenativeweb absolut, ich stimme allem zu. Gut dass ihr in der Beratung da ehrlich seit. Und danke für das tolle Video. Wichtiges Thema.

[@yt7042]

Ganz ehrlich. Für jemanden der noch die IE Hochzeiten und die damaligen Cross-Browser-Inkompatibilitäten erlebt hat ist das Jammern auf hohem Niveau. Man sollte vor allem darauf achten ob das UI Framework bzw. die UI Library eine funktionierende Community hat und das Projekt auch aktiv weiterentwickelt wird. Aber eine 100% Sicherheit wird es auch da nicht geben. Und wenn das Geld dafür da ist, wäre eine Eigenentwicklung natürlich der beste, aber teuerste Weg. Schöne Woche!

[@thenativeweb]

Wieso ist es Jammern auf hohem Niveau, wenn man darauf hinweist, dass es eine dumme Strategie ist, sich für die günstigere aber weniger flexible Option zu entscheiden, dann Flexibilität zu fordern, und sich dann zu wundern, dass es überraschend teuer wird? Was hat das mit dem IE & Co. zu tun?

[@yt7042]

@@thenativeweb Das war nicht persönlich gemeint. Ich wollte damit nur ausdrücken, dass Fehlentscheidungen bei der UI Auswahl früher größere Auswirkungen hatten, da die Cross-Browser-Probleme einen frühen Wechsel erzwungen hätten, bei fehlender Unterstützung durch die Library.

[@thenativeweb]

Alles gut 😊 Trotzdem danke für die inhaltliche Erklärung 😊

[@cod3r1337]

In vielen Fällen kann sowas wie shadcn eine gute Wahl sein. Das scheint mir sowas wie das Beste aus zwei Welten (Eigenentwicklung vs. Komponentebibliothek) zu sein.

[@Microchaosmac]

Bei unsere Firma war es ein Grund eine UI Lib zu verwenden, um ein zusagen ja können wir nicht machen, da unsere Lib die wird verwenden es nicht kann. (vuetify) No joke.

[@anion21]

Spannende Argumentation. Material ist ein interessantes Beispiel. Material ist ja keine UI-Library, sondern ein solides technologieunabhängiges Design-Konzept von Google, das von wirklich professionellen Designern entwickelt wird. Wenn man sagt, man möchte das Material-Design in einer Anwendung oder gar als Corporate Design haben, gibt man das Design-Konzept damit natürlich aus der Hand, weil man vertraut, dass Material gute Umsetzungs-Konzepte für alle gängigen UI-Entwürfe bereitstellt. Und da liefert Google meines Erachtens auch ordentlich. Google hat wahrscheinlich ohnehin bessere Designer als die meisten anderen Firmen. Und dann werden irgendwelche unsupporteten Hacks der konkreten Material-Implementierung (z. B. der Material-Library für Angular) in den benutzten UI-Komponenten auch unnötig, weil sie per Definition nicht den Design-Vorgaben entsprechen. Ich würde einer Firma daher eher raten: Benutzt gänzlich ein fertiges Design, oder entwickelt ein gänzlich eigenes Design. Dieses Anpassen ist einfach kein gangbarer Weg.

[@thenativeweb]

Absolut richtig - das Problem ist nur, dass Unternehmen in 99% der Fälle folgendes wollen: Ein Design von der Stange, weil günstig und schnell, aber mit individuellen Anpassungen. Und das geht halt nicht … beziehungsweise es wird aufwändig, fehleranfällig, langsam und teuer - und dann wird gejammert. Würde ein Unternehmen von Vornherein sagen, wir nehmen das so wie es ist, und leben damit - dann ist MUI die perfekte Wahl. Aber eben auch *nur* dann.

[@Torben_Br]

Ach wenn das eine UI Framework das nicht kann, einfach ein zweites oder drittes einbauen 🙃 (alles schon gesehen)

[@florianfeilmeier1017]

Ich finde selber bauen auch bei vielen anderen Softwarekomponenten generell oft sehr sinnvoll und effizient. Reporting, Persistenz etc. Man muss es hald richtig machen. Oft wird man deshalb leider einfach belächelt, weil es irgendwelche Beispiele gibt, wo es nicht geklappt hat.

[@Tekay37]

Ich habe so ein ähnliches Problem jetzt mehrfach mit Bootstrap gehabt, wo ein button beim klick kurz extrem groß wird. Irgendein fancy Verhalten verursacht das. Meine Lösung war, die .btn css Klasse zu kopieren ohne die ganzen Extras und das Problem ist weg. Genau diese Probleme sind der Grund, warum ich immer mehr zu der Ansicht gelange, dass shadcdn der richtige Weg ist, weil man damit die Kontrolle über die Komponenten behält und trotzdem projektübergreifend eine konsistente Grundlage hat.

[@lederstrumpfmithirschtalg]

Also wer in 2025 noch auf die Idee kommt eigene UI Libs zu entwickeln, hat echt zu viel Zeit. Es gibt alles schon 1000x in jeder beliebigen Form. Alles kann massiv gecustomized werden, ist heute sehr leichtgewichtig und modular. Dinge wie Radix UI gibt es als Ableger auch für Vue (Reku). Was wir durch die versprengte Eigenentwicklung erreichen ist einfach Ressourcenverschwendung und schlechte UI Komponenten, wenn zB mal wieder jmd a11y oder Keyboard User oder Touch Devices oder oder oder vergisst. Klares Nein von mir. Da schafft sich wieder nur jmd. eine Daseinsberechtigung 🙄

[@danilosantagata9941]

Wow so treffendes Video. 🎉🎉Wir sind aktuell GENAU in der beschriebene Situation.

[@thenativeweb]

Das tut mir leid 😳

[@gronkhfp]

All das genannte habe ich innerhalb kurzer Zeit mitmachen müssen. Da werden Issues eröffnet um irgendwelche Bugs lösen zu lassen die es mit plain JavaScript nicht geben würde.

[@thenativeweb]

Ja … das stimmt leider.

[@benjay14k]

Ich würde davon absehen eine eigene UI-Library zu entwickeln. Der Aufwand ist nicht zu unterschätzen. Dann lieber auf bewährte Libraries setzen und mit sauberem UX/UI-Design starten. Unstyled UI Libraries oder shadcn sind auch eine Option.

[@thenativeweb]

shadcn & Co. sind tatsächlich eine interessante Option. Das Problem ist nicht der Aufwand, eine eigene UI-Library zu entwickeln - denn wenn Du individuelle Anforderungen hast, die nicht von Material UI & Co. abgedeckt werden, geht es halt schlecht anders. Das Problem ist die fehlende Flexibilität, die man sich einkauft. Wer damit zufrieden ist, für den ist zB MUI ein tolles Framework - wer aber nicht, der zahlt langfristig drauf.

[@sebastianfeustel9178]

Benutze auch MUI und war bis jetzt recht zufrieden. Aber die Punkte, die du ansprichst, kann ich nach voll ziehen. Ich war bei mir neulich auch sehr verwundert, als meine IDE anzeigte, dass Grid deprecated ist. Was ist deine Meinung zu shadcn/ui? Hier wird ja nicht die lib geladen, sondern der Quellcode der einzelnen Komponenten mit in das Projekt eingebaut und kann angepasst werden.

[@MonsterWriter]

Gerade Material UI sehe ich schon fast als UI Komponenten Framework. Wenn einem die vorhandenen Komponenten nicht zusagen kann man basierend auf den design Tokens die MUI mitbringt seine eigenen Komponenten bauen (bestimmt kann man auch die vorhanden tokens erweitern). Auch kann man eigene Themes erstellen. Bzgl. Flexibilität stimme ich nicht zu. Natürlich muss man sich einarbeiten aber das ist auch ein Vorteil, einmal eingearbeitet, kennt man einen systematischen weg UI Komponenten zu erstellen. Dieses Wissen ist dann auch übertragbar in andere Unternehmen (was nicht der Fall ist wenn man alles komplett selbst baut). Hinzukommen accessibility features die bei selbst gebauten Komponenten oft auf der Strecke bleiben. Das Risiko bei größeren Versionsprüngen abgehängt zu werden besteht natürlich. Hier gebe ich dir Recht.

[@Sourcer3r]

Bislang habe ich noch keine UI Library verwendet (alles Handarbeit), bin bei einem neuen Prototypen spaßeshalber mal shadcn (Svelte flavour) eingeworfen. Bislang können weder der Designer noch ich meckern.

[@thenativeweb]

shadcn ist da, finde ich, eine interessante Ausnahme - es ist ja auch viel weniger "Framework" als Material UI. Im Prinzip ist das ein Baukasten für die Eigenentwicklung, und damit eine ganz gute Grundlage.

[@Sourcer3r]

@@thenativeweb shadcn impliziert die Verwendung von Tailwind. Da konnte ich letzte Woche ganz gut erkennen, wie schnell die Community auf das TW 4 update reagiert hat. Ein paar sed's für die eigenen Komponenten, kurz die Konfiguration angepasst und das update war dann auch schon erledigt. 😉

[@jogibear9988]

Die Probleme hat man doch bei allem. Auch bei der Programmiersprache, dem Framework, .... Alles wird irgendwann eingestellt oder nicht weiterentwickelt....

[@thenativeweb]

Darum geht es nicht. Es geht darum, dass ich mich von zwei Optionen bewusst für die weniger flexible entscheide (weil billiger), dann aber kurz darauf nach Flexibilität rufe, und mich dann beschwere, weil es unerwartet teuer oder unmöglich wird …

[@dominik4496]

Ich baue auch fast alles selbst Vanilla JS und CSS for the web! Außerdem haben wir doch jetzt KI.

[@rudxde]

Hm, sehe ich nicht ganz so, klar sollte man vorher klären, was man benötigt. Aber - Es ergibt meiner Meinung nach wenig sinn, das Rad hier für jedes Unternehmen neu zu erfinden. Klar, wenn man im B2C ist, und einem die UX sehr wichtig sollte man eher auf eigene UI Komponenten setzen. Ein Konzern wird auch auf eigene UI komponenten in form einer inhouse library setzen. Als Mittelständler sollte man sich aber fragen, ob man am ende jede kustomization, die die ui library aufbohrt benötigt. Weil, am ende sind gute selbst entwickelte UI Komponenten nicht so trivial zu entwickeln wie im Video erwähnt.

[@ChristianBehrends]

Weise Worte

[@thenativeweb]

Danke schön 😊

[@Ferdii256]

Ich würde bei deiner Auffassung nicht so ganz mitgehen. Die Probleme, die die Verwendung fertiger UI Libs mit sich bringt, sind definitiv da. Aber eigene Controls zu bauen halte ich für eine gleichermaßen schlechte Idee. Der Overhead ist einfach zu groß und die Qualität von dem selbstgeschriebenen multi-select Dropdown mit Autocompletion am Ende definitiv geringer, als etwas, das von der Community entwickelt und weitreichend in Produktion eingesetzt wird. Optimal wäre imo oftmals eine Art "headless" UI Library, die alle Komponenten mit ihrer Funktionalität bereitstellt und dann auf möglichst einfache, intuitive Art und Weise custom Styling ermöglicht. Sicher gibt es schon etwas in die Richtung - bin auf Empfehlungen gespannt!

[@bsdooby]

Tcl/Tk for the win…

[@thenativeweb]

Haha 😊

[@bsdooby]

@ Tk hat sich, für einfache lokale UIs, seit ca. 30 Jahren mit konstanter API Plattform unabhängig bewährt…

[@programmieren3197]

Vielleicht sollten wir versuchen libs zu schreiben die anpassbar sind. Ich habe zum Beispiel neulich eine für einen Calendar gesehen, in der eigene UI Elemente für jeden einzelnen Tag mitgeben konnte wenn man das wollte.

[@rudolfstepan2651]

Ich benutze aktuell lit web components. Schlank u Leichtgewichtig.

[@martinaigner9119]

Jep! Get wrapped!

[@buzzeins]

Shadcn und gut ist.

[@Georg-y7j]

Die Erfahrung mag dir Recht geben. Aber wie ist es mit der philosophischen Sicht auf die Dinge. Sollten wir 10 Millionen Jahre nach dem Herabsteigen vom Baum wieder zum generellen DIY zurückkehren? Spezialisierung und Normung sind dazu da, die Produktivität nach vorn zu bringen. Was wäre, wenn in der Welt der Nuts and Bolts auch alle wieder anfangen sich ihre Muttern selbst zu schmieden? Und es geht nicht nur um die funktionierende Form, sondern auch um die Materialien. Dein Hinterrad wird mit einer 0,83 Zoll Kokusnuss-Schraube fixiert ?? Die genannten Probleme sind Luxusprobleme. In der IT-Welt läuft alles schief. Alle Normen werden regelmäßig zerstört. Das manifestiert sich schon in den Programmiersprachen. Das manifestiert sich in den Abstraktionsebenen. Und - was immer du unter Technologie verstehen willst - auch. Wo liegt der Nutzen, wenn ich, um ein paar Felder zu füllen, drei getrennte Sprachen brauche. ( ... und dann "wegen der Dokumentation!!!" noch die inhaltlichen Anforderungen in eine menschliche Fremdsprache übertrage. ) Die Bekleidungsindustrie zeigt es: Bei allen Möglichkeiten, die man hätte, beschränkt man sich auf ein vernüftiges Maß an Kleidungstypen (Hüte, Jacken, Hemden ..) aus "langweiligen" Stoffen in doch recht schmalbandigen Konfektionen. Ohne Probleme kann man für großen Aufwand soweit von der Norm abweichen wie man will. Häufig kann man den Klamotten ihr Entstehungsjahrzehnt ansehen. Trotzdem funktionieren sie meist gleich. Trotzdem muß man keine Produkte aus Rinderdung oder Leberwurstdarm erwarten. Also geht hin zu den Bibo-Maker und klopft denen auf die Pfoten. Wünscht euch aber nicht nur schöne APIs sondern noch besseres Funktionieren. ... und kämpft für eine akronymarme Welt.

[@thenativeweb]

Es geht hier ja gerade darum, dass Unternehmen zwar die kostengünstige, normierte Lösung von der Stange kaufen - und sich dann beschweren, wenn sie individuelle Anpassungen haben wollen, dass das nicht geht, oder sehr teuer wird. Natürlich ist es nicht Sinn der Sache, immer alles von Grund auf wieder neu zu machen, zum hunderttausendsten Mal, aber ich muss mich halt vorher entscheiden, was ich will: Den Standard, den ich dann auch günstig bekomme, der aber eben zu Lasten der Individualität und Flexibilität geht, oder die Individuallösung, die mir Freiheit bietet, aber halt teurer ist. Beides in einem gibt es nicht - das wäre Cherry-Picking, und das funktioniert selten.

[@ahmadumar9387]

deswegen TailwindCSS nutzen :)