Revision 584: Solid.js & SolidStart

Transcript

[0:00] Ich hatte das Gefühl, SolidJS sei letztes Jahr zum ersten Mal aufgetaucht, aber das stimmt nicht.
Nee, also ich glaub, das erste Mal hat's 2020 auf Hacker News schon mal so eine kleine Runde gemacht.
Und 2021 kam dann schon die Version 1.0. Am Anfang hat man auch gemerkt sozusagen, bevor sie so richtig ihre eigene Identität gefunden hatten, haben sie auch noch so gesagt, okay, wir schauen, dass man möglichst einfach von React rübergehen kann, Templates selber, also mit dem JSX-Teil.
Aber fällt dir eine UI-Komponenten-Bibliothek ein, die ebenfalls schon stabil wäre für Solid?
Hattet ihr mal eine gesehen? Letztes Jahr hattet ihr so ein Solid Summer of Code?

[0:45] Music.

[1:10] Revision 584, vorbeischauen. Hier findest du eine Community aus über 80 TrainerInnen, welche gemeinsam Material erstellen, sich gegenseitig unterstützen und weiterbilden, um möglichst nachhaltige und hochqualitative Weiterbildungsangebote zu schaffen. Es gibt sowohl Intensivschulungen über mehrere Tage, als auch Masterclasses, welche durch über einige Monate unterstützen.
Bist du auf der Suche nach einer qualitativen Weiterbildung im Bereich Webentwicklung?
Oder möchtest du dich selbst als Trainerin einbringen?
Dann bist du bei workshops.de genau richtig. Schau einfach mal vorbei für alle Informationen.
Workshops.de Wir freuen uns auf dich!

[2:28] Bevor ich sage, wer alles an Bord ist, möchte ich mich einmal im Namen des Teams beim Hannes

Revision 584: Solid.js & SolidStart

https://workingdraft.de/584/

[2:37] bedanken, der seinen Beitrag bei Patreon vor kurzem verdoppelt hat von 2,50 Euro auf 5 Euro.
Vielen Dank, freuen wir uns sehr. Und ihr wisst ja, wir stecken das alles in die Audio-Nachbearbeitung und in unsere Software-Abos, die wir so am Laufen haben. Genauso, vielen Dank.
Und jetzt zu den hier anwesenden Personen. Da hätten wir zum einen die Vanessa.

[3:07] Hallo. Ich bin der Shep und wir haben wieder einen Gast, und zwar den Bernd Kaiser.
Hi. Bernd, du warst noch nicht bei uns und deswegen würden wir dich mal fragen, ob du dich vorstellen magst.
Ja, klar, gern. Ich bin der Bernd. Ich komme aus Erlangen, bin Softwareentwickler hauptberuflich und auch schon ziemlich lang dabei hier im Web-Podcast. Also, ich habe, denke ich, alle Webzeiten mitgenommen von, na gut, den Musik nicht, aber vom Netscape bis jetzt mit den verschiedenen Varianten, wie man vorgegangen ist und kann sozusagen sagen, ich habe alles mal gesehen und auch mal probiert zu machen, je nachdem wie gut oder schlecht. Und genau, jetzt bin ich Softwareentwickler bei Innovex hier in Erlangen und mache auch in der Freizeit gern hier bei solchen Aktivitäten mit. Bin seit.

[4:01] Diesem Jahr im Jason Craft Camp, Organisationsteam, wo ich die Vanessa auch auf dem Camp fest, er kennengelernt habe. Und ja, jetzt freue ich mich hier eingeladen worden zu sein.

[4:12] Genau, die Vanessa, die war ja sehr geschäftstüchtig, die hat ja nicht nur was gelernt und neue Leute kennengelernt auf dem JS Craft Camp, sondern auch die ein oder andere Person verhaftet, die mit interessanten Themen im Gepäck aufwarten kann. Das war beidseitig.
Beidseitig. Ja, super. Und der Name der Revision gibt es schon her.
Heute wollen wir über Solid.js sprechen.
Was ja irgendwie, vielleicht kann man das so als die eine der beiden Framework-Säule bezeichnen, die aktuell durchs JavaScript-Dorf getrieben wird.
Also so ein bisschen auf dem Hype-Train unterwegs ist. Was ist denn die andere?
Und Quick wahrscheinlich einsortieren, so, oder?

[5:06] Ich würd auch sagen, sind die beiden neuesten, die dazugekommen sind, sozusagen, was da losgeht.
Und man würd auch sagen, ihr hattet ja letztens eine Folge über Signals.
Ich würd schon sagen, dass durch Solid Jazz dieser ganze Signal-Hype noch mal so in die nächste Runde getrieben wurde.
Jetzt nicht, dass es damit aufkam, ne?
Muss man auch sagen, da ist der Solid Creator auch immer ganz offen, dass er sich halt von vielen, vielen Frameworks hat inspirieren lassen über viele Jahre, aber ja, ich mein, man sieht ja jetzt.
Auf einmal hat Angular Stickness das erste Mal geführt, dass seit Angular was passiert ist, seit Gedenken.
Dann Project hat sie eingeführt, ich hab auch was gelesen hier.
React denkt drüber nach, dass es vielleicht irgendwie irgendwann mal kommen könnte.
Ist natürlich sehr unverbindlich, aber es hat auf jeden Fall ein bisschen was gestartet und es war gefühlt so auf einmal in aller Munde.
Während man es 2021 sozusagen vielleicht mal von gehört hatte noch, ging es dann 2022 langsam los und dieses Jahr kennt man es, sage ich jetzt mal.

[6:10] Also für mein Gefühl würde ich auch sagen, dass Solid.js so das Thema Signals irgendwie auf den Tisch gebracht hat.
Also selbst wenn sich der Ryan Carnito, glaube ich heißt er ja, der das gemacht hat, selbst wenn er sich hat inspirieren lassen, ich meine letztlich ist das ja schon immer so, dass man immer so ein bisschen auf, Dingen aufbaut, die es schon mal irgendwo gegeben hat, aber vielleicht hat er es einfach sozusagen dann formvoll endet.
Aber ich würde sagen, Solid JS, oder das ist ja schon so das Ding, mit dem Solid JS auftrumpfen konnte.

[6:49] Ja, und jetzt haben natürlich, oder versuchen viele, dem nachzueifern, weil es ja auch eine sehr elegante Lösung für ein Problem ist, und ich denke mal, da sprechen wir auch heute noch mal drüber, oder?
Ja, bestimmt. Ich glaube, Kanyato ist es. Kanyato, okay.
Aber ich bin mir auch immer nicht so ganz sicher.
Genau, und der arbeitet bei eBay, richtig? Nee, hat bei eBay gearbeitet, früher.
Der ist jetzt mittel, also da war eben, ich weiß nicht, kennt ihr Marco.js?
Hab ich schon mal gehört, ja. Das ist, mit dem Framework von eBay wird sozusagen die eBay-Seite gerendert, damit es halt super schnell und überall auf allen Devices und so weiter da ist.
Und da war er früher im Core-Team, als er noch bei eBay gearbeitet hat.
Aber hat dann von Netlify sozusagen das Angebot bekommen, das er nicht ablehnen konnte, dass er sich halt jetzt hauptberuflich um Solid JS und das ganze Ökosystem außenrum kümmert.
Also es ist jetzt, glaube ich, seit diesem Jahr, Anfang diesen Jahres oder Ende letzten Jahres bei Netlify und entwickelt hauptberuflich sozusagen an Solid JS.
Okay.

[8:02] Ja, über Netlify müsste man ja auch mal nochmal sprechen. Die richten sich ja auch ein bisschen neu aus, hat man das Gefühl.
Aber lasst uns bei Solid.js bleiben.
Also, ich hatte das Gefühl, Solid.js sei letztes Jahr zum ersten Mal aufgetaucht, aber das stimmt nicht. Solid.js stammt aus 2021, richtig?
Nee, also ich glaub, das erste Mal hat es 2020 auf Hacker News schon mal so eine kleine Runde gemacht, weil der Ryan, der ist so ziemlich performanceoptimiert gewesen und der hat dann so einen Benchmarkings gemacht und hat die verschiedenen Frameworks miteinander verglichen und hat es halt geschafft, dass Solid JS hier bei vielen Sachen sehr, sehr, sehr gut dastand und damit kam es dann sozusagen auf die Landkarte.
Und 2021 kam dann schon die Version 1.0.

[8:57] Also während sich's davor noch relativ schnell und viel geändert hat, ich glaub, die hatten 25 oder 26 Point-Releases bevor der 1.0, geht's seitdem ein bisschen langsamer zu und ein bisschen stabiler.
Das sind ja eigentlich gute Nachrichten. Ja, auf jeden Fall.
Ich hab's auch über die Version hinweg verwendet, und man muss schon sagen, ist schon immer relativ wenig gebrochen.
Also, die haben jetzt nicht wirklich SemVer verwendet, muss man dazu sagen, weil so ein oder zwei Kleinigkeiten haben sie dann doch zwischen den Point Releases verändert.
Aber im Großen und Ganzen waren das dann so Sachen, gut, ich hatte keine Riesen-Apps, aber das war dann so in zwei bis drei Minuten durch, wenn man das neue Konzept verstanden hatte.
Und da hat man das halt überall angepasst.
Ich bin einmal über Sapper gestolpert, oder Sapper von Svelte, was dann mal eingestampft wurde, mehr oder weniger.
Bei Vue läuft's jetzt bei mir recht gut, weil ich da bei einer App erst wieder neu angefangen hatte mit Vue 3.
Also ich mordte nie dieses Vue 2, 7 auf Vue 3.
Es kam mir in der Theorie auch irgendwie nie so tragisch vor.
So nach dem Motto, ja, es gibt halt irgendwie keine Mixons mehr und das ein bisschen umstellen.
Aber hab dann doch auch eher Geschichten gehört, dass es nicht ganz so schön war.
Und wahrscheinlich auch einer der härteren Breaking Changes war.

[10:16] Ich habe gerade bei den Blog-Artikel auf Dev.to noch offen von Ryan von Solid.js official release, the long road to 1.0. Er fing anscheinend mal an im August, am 21. August 2016, mit dem ersten Commit und dann ist es langsam entstanden.
Ja, hieß es auch noch Framework.
Genau, das Framework. Das Repository-Framework.
Aber wie gings du dann weiter nach den ersten stabilen Versionen?

[10:53] Vielleicht kann man das nochmal kurz charakterisieren. Also, als Templating-Engine setzen die, glaube ich, auch auf JSX, richtig?
Genau. Also, ist auch JSX-basiert.
Passiert. Und am Anfang hat man auch gemerkt, sozusagen, bevor sie so richtig ihre eigene Identität gefunden hatten, haben sie auch noch so gesagt, okay, wir schauen, dass man möglichst einfach von React dann sozusagen rübergehen kann, wenigstens mit dem, mit den Templates selber, also mit dem JSX-Teil. Deswegen gab es am Anfang zum Beispiel das Class und ClassName, wie man es so aus React kennt. Und irgendwann hat er gemeint, nee, eigentlich wollen wir nur Class haben, so wie in der eigentlichen HTML-Welt gedacht ist. Und dann hat man so gesehen, gesehen. Im Laufe der Zeit wurde dann auch die eigene Identität gefunden. Das war dann sozusagen so ein Breaking Change, der jedenfalls über das TypeScript Enforcement dann mal rüberkam, während es über JavaScript selber noch länger beides parallel ging. Hat er dann irgendwann mal gemeint, ja, nee, wir machen es jetzt mal zu. Ist ja auch super einfach anzupassen. Und solche Sachen hat man gesehen. Aber Ansicht, das ist auch das, mir an.
Was mir sehr gut gefallen hat, das nicht wieder probiert wurde, ein neues drittes System oder viertes System sozusagen, also wieder irgendeine Loader-File daneben zu erstellen, weil es hat mich damals ans Weltsehr abgehalten.
Weil am Anfang sind die Tools einfach nicht so gut, ne? Und JSX hingegen hat einfach jeder Editor.

[12:15] Ziemlich gut TypeScript eingebaut, alles, ne?
Und das merkt man schon.
Ja. Und was hat dich denn initial überhaupt zu dem Framework gezogen?
Also war's dann einfach so ein bisschen Neugierde und Forscherdrang?
Oder war's dann auch tatsächlich so, dass du vielleicht in einem aktuellen Projekt mit React gearbeitet hast und vielleicht auch so, sagen wir mal, an bestimmte Grenzen gestoßen bist und du gesagt hast, ich guck mir das an, inwiefern oder was hinter den Versprechen von Solid.js steckt, und nachdem das ja sozusagen hier mit diesen Benchmarks so ein bisschen hausieren gegangen ist, sag ich jetzt mal.
Genau, das war eigentlich mehr Neugier.

[13:03] Jetzt nicht unbedingt der Neat im Projekt, auch wenn man sagen muss, dass man im React, ja schon ziemlich aufpassen muss, was die Performance angeht, dadurch, dass halt sozusagen die Komponente und alle ihre Kinder wirklich immer neu gerendert werden.
Und da auch schon selber halt auf, sagen wir mal, nicht so starken Devices, auf Handys und so in Probleme gelaufen bin mit größeren Apps, und ja, das hat mich ja dann der Performance-Teil schon ein bisschen interessiert, aber noch viel interessanter fand ich so die Reactivity, also von wegen, ja, React heißt zwar so, ist aber eigentlich so gar nicht so reaktiv eigentlich, und dann kamen ja irgendwann die Hooks, das war schon cooler zu schreiben, aber diese ganzen Hook-Regeln, also ich bin da ständig reingelaufen, das, ah, okay, jetzt werden nicht gleich viele Hooks ausgelöst, oder dein Dependency Array hast du irgendwie nicht gescheit aufgestellt, weil du immer wieder nicht dran gedacht hast, dass das ja eigentlich ein Array im Array ist, und dann hier JavaScript Eigenheiten, nein, nicht Eigenheiten, also das halt bei Reference oder sozusagen nicht verändert wird, so was reinschlägt, und ich hab mir gedacht, ja, es muss ja eigentlich auch irgendwie einfacher gehen, und dann durch Swage halt das erste Mal draufgekommen, aber leider von Swage halt ein bisschen abgeschreckt gewesen, am Anfang wegen dem schwächeren Tooling, sagen wir mal so 2020 rum.
Und dann halt, ja, mal schauen, was gibt's denn noch so?

[14:24] Und genau, du hast es auch gerade gesagt, bei React ist es so, dass wenn Komponenten aktualisiert werden, dann werden zwangsläufig auch immer alle Kind-Knoten, die unter dieser Komponente hängen, mitaktualisiert.
Das ist dann, je nach Konstellation kann das eben auf die Performance gehen.

[14:45] Und das ist dann ein Aspekt, den Solid ganz anders anpackt, richtig?
Genau. Bei Solid wird's im Normalfall, man kann's auch, wenn man sich speziell dafür entscheidet, dass man's anders haben möchte, dann geht's darum, es wird immer nur der Teil vom Element im DOM ausgetauscht, der sich wirklich verändert hat.

[15:09] Und es wird sozusagen von oben bis nach ganz unten getrackt.
Und dann, wenn ich also relativ weit oben was verändere, aber die Kinder der Komponente keine neuen Daten bekommen haben, dann bleiben die einfach so, wie sie sind.
Also, es ist sehr, sehr lokal. Und was ich auch mitbekommen habe, weil wir hatten ja vorhin auch schon die anderen JSX-Frameworks, so wie QUIC, erwähnt, ist es sozusagen, da ist es noch präziser, ne?
Bei QUIC gibt's ja diese Stufe mit diesem Dollarzeichen, ne, sozusagen, wenn da die Signals losgehen und so.
Wegen dieser Resumability, sowas gibt's bei Solid nicht. Da ist es wirklich so, es wird so eng wie möglich, eingegrenzt und dann nur geupdatet.
Und deswegen hat es auch so gute Performance-Werte. Dafür hat aber Solid dann nicht das Problem wie bei Quick, dass es dann immer so wirklich ad hoc vielleicht noch was runterladen oder erst ausfüllen muss.
Sondern eigentlich ist ja schon der, ein ganzer Code dann schon vorhanden.
Weil Quick wirbt ja auch eben damit, dass immer erst das geladen und geparst wird, sobald man es tatsächlich braucht.
Und man kann die Prioritäten vergeben, Zum Beispiel der Add-to-Card-Button ist wichtiger als der Watch-Button.
Das heißt, vielleicht ist der noch vorgeladen, aber das andere nicht.
Aber da mache ich mir auch immer so ein bisschen die Sorge, ob das dann nicht irgendwie sich langsam anfühlt, wenn ich erst einmal was passe, sobald ich draufklicke.
Klingt mir jetzt so, als hätte Solid das Problem nicht, weil das ganze JavaScript ist trotzdem schon gepasst.
Es wird nur sehr performant im DOM ausgetauscht.

[16:37] Genau, also, ich weiß nicht, ob es bei Quick ein Problem ist, oder eher ein Feature, ne, mit dieser Resumability, und dass es einfach da ist, und alles super snappy direkt funktioniert.
Das ist im Solid JS normalerweise nicht so.

[16:52] Deswegen, ja, ich weiß nicht, ob das ein Problem ist, ne. In Solid muss halt alles geladen werden, es gibt eine kleine Runtime, die hat ein paar Kilobyte, und wenn die da ist, dann funktioniert's, ne.
Und in Quick hingegen, kriegst du halt da in HTML meistens schon Quick, ohne Quick City macht ihr eh, so wie ich das verstanden hab, nicht wirklich Sinn.
Das ist jedenfalls so mein Feeling, ich hab noch nicht genug damit gearbeitet, um es wirklich abschließend bewerten zu können, aber bei Solid ist halt auch so, ähm, man kann's halt auch für so eine klassische Single Page Application verwenden, oder das war sozusagen auch die erste Idee, wo es herkam.

[17:31] Und der Schlüssel zu der Performance von Solid.js ist eben die Tatsache, dass Signals verwendet werden, oder?
Ich denke, Signals sind das Mittel zum Zweck, um nur diese möglichst kleinen Punkte zu updaten im DOM.
Also es gibt kein Wie-DOM, es muss nicht gedifft werden, sondern ich verändere wirklich den DOM selber.
Okay, das macht Solid auch, also ähnlich wie Projekt, glaube ich.
Oder ist das bei Projekt mittlerweile anders gewesen? Die haben ja zumindest mal zeitweise auch kein VDOM benutzt, sondern haben direkt im echten DOM rumhantiert.
Bei Projekt weiß ich es gerade nicht. Bei Swage ist es zum Beispiel auch so.
Die haben dann sozusagen noch mal eine geringere Runtime und erzeugen noch mehr durch ihren Compiler, noch mehr Codes sozusagen, der das DOM direkt verändert für die Komponente.
Ja. Und ähnlich ist es bei SolidJS. Mh.

[18:30] Genau, also, wie DOM haben ist ja nicht unbedingt, auch wenn das früher so verkauft wurde, aber das ist ja gar nicht unbedingt so performant.
Im Zweifelsfall ist es sogar mehr Arbeit.
Ja, also, ich hätte jetzt auch so mitbekommen, dass jetzt ist der Trend wieder davon weggegangen ist.
Also, wenn man halt sieht, der Browser macht das ja alles schon.
Und wenn ich es schaffe, meinen DOM so aufzubauen, dass ich wirklich einzelne Sachen gezielt ersetzen kann, mit welchen Mitteln auch immer, dann ist das halt schön, weil da muss ich gar nicht so viel diffen, weil es interessiert mich eigentlich gar nicht, was die anderen Komponenten so machen.
Ich muss ja wirklich nur über meinen Teil vom Element, sage ich jetzt mal, das eingehangen wird, Bescheid wissen, wann sich was geändert hat, eine Abhängigkeit, und dann alles neu rendern und berechnen, falls ich so abgeleitete Signals habe, nenne ich es jetzt mal. Ja.
Okay. Du hast gesagt, ähm, dass, äh, SolidJS irgendwann dann sozusagen seinen eigenen JSX-Flavor auch, ähm, entwickelt hat.
Der nicht hundertprozentig deckungsgleich ist mit dem Original.
Und das betrifft aber dann auch Kontrollstrukturen in den Templates.
Das hast du auch in der Vorbesprechung gesagt, richtig?

[19:49] Also die Kontrollstrukturen, die könnte man auch so umsetzen wie in React, also wenn ich jetzt sage, ich habe ein Array, ich habe eine Liste, mache dort ein Map drauf, um dann neue JSX-Elemente zu erstellen, oder...

[20:02] Das könnte ich schon machen, aber davon würde absolut abgeraten.
Genauso vom Tenery, dafür gibt es eigene Solid-JS-Build-In-Komponenten, nenne ich sie mal.
Show und For sind, denke ich, die klassischen. Diese sorgen nämlich dafür, dass da gezielt geupdatet wird.
Nämlich nur, wenn sich was verändert hat. Also, stellen wir uns vor, wir haben eine Liste mit Sachen, die wir rendern möchten. Jedes Element wird als Unterkomponente gerendert.
Wenn ich dann die von Solid mitgebrachte Forelement verwende, dann wird halt da auch wirklich nur gezielt das geupdatet, was sich verändert.
Wenn ich das jetzt selber mit einem .map machen würde, dann halt eben nicht. Und deswegen wird immer darauf hingewiesen, dass man sehr drauf achten sollte, dass man die mitgebrachten Komponenten dafür verwendet. Also die Control-Flow-Komponenten.

[20:55] Das klingt schon super stark. Weißt du, ob das dann auch wirklich noch so granular funktioniert, dass ich eventuell, ich hab ein ganzes Objekt, das hat eine ID, und das Objekt selber hat dann nochmal eine Liste an Items.
Und aus Gründen ändert sich die ID dieses Objekts, aber die Liste ändert sich nicht.
Ist es dann so klug, zu wissen, dass sich tatsächlich auch die Liste des Objekts nicht geändert hat?
Oder müsstest du es dann vielleicht schon noch klüger implementieren, dass es gar nicht mehr von dem Objekt irgendwie abhängig ist, sondern wirklich nur die Liste runtergebe?
Ich denke, wenn du die Liste in die Vorkomponente übergeben hast, Also über die Liste iterierst, dann ist es zu klug, weil dann ist die andere Abhängigkeit nicht da.

[21:44] Bei View-Komponenten weiß ich's auf jeden Fall, dass es eben da auch schon davor gewarnt wird, dass es durchaus wichtig ist, welche Properties ich jetzt an die Kind-Komponente runtergebe.
Dass es einen Unterschied macht, gebe ich nur den Titel runter oder gebe ich das ganze Objekt runter und verwende eben einfach nur den Titel im Template.
Denn wenn sich da halt an dem Objekt was ändert, wird entweder die Komponente neu gerendert oder sie haben mittlerweile auch jetzt da was Kluges rein. Aber ich weiß doch, dass man früher immer gewarnt wurde, oder hey, gebt doch einfach mal nur den Titel runter, dann rendert sich das nicht neu.
Kann man ja auch immer einfach ausprobieren, einfach mal in so einem unupdated Lifecycle-Hook in eine Konsole locker reinzuhängen.
Dann weiß man ja, was da passiert ist. Ansonsten, ähm, gibt's da die restlichen flexiblen Sachen, die man jetzt so beim Entwickeln bräuchte?
Auch ist das stabil. Also hab ich irgendwie, ähm, die ganzen Event-Händler, habe ich einen Store dabei?

[22:44] Und was man noch so alles im Frontend braucht, kann ich das CSS leicht benutzen? Ist das gescoped?
Da können wir mit dem CSS anfangen. Da hat SolidJS jetzt nichts selber mitgebracht.
Ich denke, das wird aber deswegen gemacht worden sein, weil Vite, also SolidJS ist ja, wie ich würde mal sagen, bis auf NextJS und Angular nutzen so alle Vite mittlerweile, zum Bilden und mit VEED kann man ja sehr einfach sein CSS scopen und auf ein Modul und das wird hier verwendet.

[23:21] Was sonst noch mitbringt, es gibt extra Stores. Man muss aber auch dazu sagen, die Signals, die man ansetzt, die sind nicht auf eine Komponente gebunden, zwingend.
Also die kann ich sozusagen in meine Komponente koppeln, so dass sie von außen von niemand anders benutzt werden können, aber ich könnte sie auch in eine extra Datei legen und dann die Signals aus der Datei importieren.
Was es auch gibt, ist Kontexte zum, ja, Art Dependency Injection, genauso wie bei REC, kann man sich das eigentlich vorstellen, um Sachen an die Kinder weiterzugeben.
Genau, also ich denke, das meiste sollte da sein, was man so gewohnt ist.

[24:04] Gibt es gewisse Stolpersteine, wo du schon drüber gestolpert bist?
Oh ja, man muss aufpassen, dass man die Reaktivität nicht zerstört.
Da kann ich das schönste Beispiel bringen, das sind die Props einer Komponente.
Wenn man sich jetzt als React-Entwickler, wenn ich hier sage, okay, das ist meine Komponente, die hat diesen Typ und dann packe ich ja normalerweise meine Props hier mit Destructuring immer direkt schon aus.
Dass ich jetzt nicht das Objekt habe, Props, sondern hole mir schon direkt raus Name, Titel und so weiter.
Wenn ich das bei Solid.js mache, dann geht's kaputt.
Bei Vue jedenfalls. Genau. Also dadurch, dass die Props dann auch über Signals dargestellt werden und Signals halt immer diese Exocess brauchen, also das sind so Proxys dazwischen geschalten, damit das eben weiß, wer von ihm liest, wer sozusagen drauf observed.

[24:56] Muss man halt drauf achten, dass man die nicht auspackt.
Genauso ist es, wenn ich jetzt an meinem Kind nur einige Properties aus meinem kompletten Props-Objekt weitergeben möchte, dann gibt es eine extra Funktion für, die heißt Split Props, Gegenteil, Merge Props, wenn ich noch was hinreinpacken möchte, ne?
Also, ganz klassisch, Merge Props brauche ich, wenn ich halt Defaults habe, ne?
Für eine Komponente, die ich dann sozusagen damit initialisieren möchte.
Das ist halt nicht so einfach wie bei React, dass ich es einfach reinschreibe, ne?
Weil da passiert halt Magie, sozusagen, diese Signals-Magie, die dazwischen geschalten wird.
Und da muss man schon aufpassen, aber das Gute ist, es gibt relativ gute Solid-JS-ES-Lint-Regeln, wenn man die anmacht, dann sagen die einem, wo man, wenn man auf die Signals falsch zugreift, man halt eben nicht überall die Signals einfach so verwenden darf, wie man möchte, ne, man muss halt gucken, ist das jetzt zum Beispiel ein JSX, dann kann ich immer von Signals-Wesens kein Problem, oder brauche ich vielleicht einen Create-Effect, muss ich es noch in so eine Hilfsfunktion packen, die aufgerufen wird.
Da gibt es schon so ein paar Sachen, aber wenn man sich den Linte anmacht, dann...

[26:02] Wird man da sehr schnell auf die Finger gehauen. Kann ich jedem nur empfehlen, unabhängig von welchem Framework auch immer, wenn ich ein neues Framework mache, schaue ich erst mal, gibt's da Linter? Es ist egal, ob das jetzt in, hier JavaScript-Frameworks sind, oder irgendwelche Backend-Sprachen.
Immer gucke ich, hey, gibt's da noch irgendwelche Linter? Hilft mir da noch jemand?
Ja.
Hast du zufällig spontan ein Beispiel, wie man das jetzt implementieren würde, wenn du eine, du hast eine Komponente, so eine Basic-Komponente, die nur ein Input-Feld hat.
Und du willst quasi ...
Einen Wert runtergeben und den auch updaten. Weil jetzt klingt das gerade so, wenn du von der Property den Wert verwenden willst, aber jetzt auch im Input-Feld verändern möchtest, dass vielleicht jetzt der Linter sagt, ja, du kannst mir jetzt hier gar nicht die Property-Value reingeben, weil ich darf die ja nicht verändern, das ist ja meine Property, und die ist nicht veränderbar.
Sondern man müsste die dann vielleicht erst irgendwie zwischenspeichern und eine andere wieder hochgeben.
Ich stelle es mir nur gerade kompliziert vor, deswegen ist die Frage, wie würde man denn ein Inputfeld implementieren?

[27:11] Das ist gar nicht so kompliziert, weil ein Signal ist immer ein Accessor.
Wenn ich eins jetzt stelle, kriege ich ein Accessor zurück und eine Setter Function.
Wenn ich jetzt zum Beispiel möchte, dass die Komponente unten drunter auch das Signal verändern kann, über ein Input-Feld, dann gebe ich doch zum Beispiel den Setter runter, ne.
Könnte natürlich den Setter auch nochmal in nochmal in der Function, äh, wie sagt man, einkapseln, ne, um es sozusagen nochmal ein bisschen davor zu dekoppeln, damit ich es dann auch einfacher testbar machen kann und so, ne. Einfach so eine, nochmal eine Setter-Function, die dann einfach die richtige Setter-Function aufruft, aber das ist eigentlich nicht so kompliziert. Und wie gesagt, ich könnte auch Stores verwenden, die dann so gezieltes Updaten von größeren Objekten einfacher machen, ne, da könnt ihr euch vorstellen, da ist das Produce von immer schon eingebaut, das ich direkt verwenden könnte, oder sie haben auch so einen Pass-Syntax, um mir es einfacher zu machen, irgendwelche Unterobjekte anzusprechen.
Okay. Also spricht aus deiner Sicht jetzt nichts dagegen, auch einfach den Setter runterzureichen?

[28:21] Genau. Also ich würde es vielleicht nochmal kapseln, damit es ein bisschen entkoppelt ist, Aber je nachdem, wenn das jetzt noch was Kleines, Einfaches ist, dann kann ich auch sagen, ja gut, gebe ich halt einfach den Setter direkt rein.
Ist ja auch nicht viel mehr. Kann ich genauso gut testen, dass der aufgerufen wird, wenn ich meinen eigenen Setter mache.
Weil so ein Setter ist ja einfach nur, gibt den Wert rein und gibt halt nichts zurück, ne?

[28:45] Du hast vorhin erwähnt Quick City, was ja so ein bisschen sozusagen das serverseitige, Paket ist, also oder das Next.js von Quick.
Und da gibt es ja dann SvelteKit für Svelte und so weiter und so fort.
Und es gibt es aber auch für Solid.js.
Und das heißt Solid Start, richtig?
Genau. Also, ich glaub, heutzutage, ohne ein Metaframework, braucht man gar nicht mehr auftauchen in dem Game.
Ja, Metaframework nennt man das.
Genau, so hab ich das jedenfalls verstanden, dass jetzt grade die Zeit der Metaframeworks begonnen hat.
Und aktuell sind sie auch, so wie ich das verstanden hab, dabei, Solid Start Reduction Ready zu bekommen.
Ist noch nicht so weit.
Da sind sie jetzt grad noch dabei. Und ... Und da ist auch die Frage, ich meine, kennt ihr Astro?

[29:46] Mhm, natürlich. Das Framework. Und da gab es jetzt, ich weiß nicht, was da hinter der Stand ist, sie haben auf jeden Fall evaluiert, ob sie jetzt Solid Start nicht auf Astro drauf aufbauen, weil sie gemerkt haben, diese ganzen Adapter zu schreiben, für irgendwo was hin deployen, ob das jetzt Netlify, wie wir schon hatten, Verzell, AWS und Co. ist, dieses Ganze immer selber zu machen, das ist ganz schön aufwendig. Wäre doch schön, wenn man so eine Plattform schon hätte und dann seinen Router nur mehr oder weniger, seinen Kleinzeit-Router nur mehr oder weniger draufsetzt.
Weiß ich nicht, was da der Stand ist.
Das wollten sie mal evaluieren, aber das ist so grad so das Ziel an Solid Start zu arbeiten.
Ja, macht natürlich auch in dem Kontext, dass der Ryan jetzt bei Netlify ist, Sinn, weil ich glaube, die entwickeln sich ja so ein bisschen zu so einem Vercell-Konkurrenten, hat man so das Gefühl.
Hier so die Themen Jamstack und so, mit denen die früher immer viel ...
Bei denen irgendwie ganz oben aufgehangen waren, die davon ...
Distanzieren sie sich jetzt ja grade so ein bisschen oder gehen da ein bisschen weg.
Und ich hab das Gefühl, dass sie so ein bisschen mehr in Richtung sich entwickeln, was halt Vercell auch macht grade.
Und da ist natürlich dann wichtig, dass man da auch die so eine serverseitige oder serverless-seitige Teil von einem Framework hat.

[31:11] Ja, das würde ich auf jeden Fall unterschreiben. Also, für mich hat so ein bisschen das Gefühl, The Race for the Edge oder so, nenne ich es jetzt mal, ne?
Also, ob es jetzt Vercel, Cloudflare, Netlify, also sagen wir mal, die nicht Riesen-Cloud-Anbieter wie AWS, Azure und Google, sondern halt hier, sag ich mal, die zweite Garde oder so, die probieren halt jetzt mit ihren ganzen Edge-Runtimes, jeder hat seine eigene JavaScript-Edge-Runtime mit noch niederrührigen Startzeiten Und jeder möchte so ein bisschen bei diesem Spiel mitspielen.
Und ja, dann brauchst du halt auch ein Framework, was supergut integriert ist, um dorthin zu deployen.
Das sehe ich genauso wie du, da hat das Rennen begonnen. So würde ich das sehen.

[31:54] Und das heißt dann aber auch, dass Solid Start ... Also, in welchem Reifegrad liegt das jetzt gerade vor?
Also, ich hätte jetzt rausgehört, das gibt's.
Aber in so einer irgendwie Alpha- oder Beta-Version. Und jetzt wird nochmal eben geschaut, ob man das nochmal vor der 1.0 nochmal ein bisschen umkrempelt auf Astro.

[32:19] Genau. Ich kann dir nicht sagen, wie sehr sich intern da die Konzepte noch verändern werden.
Also, ich hab's Anfang des Jahres auf einem Meetup mal vorgestellt, Solid Start, und da hab ich dann auch mal so eine Mini-App mit implementiert und hat sich sehr so angefühlt wie Remix, ne, also so mit diesen Loadern, dann so Forms, die du abschicken kannst, ob jetzt mit JavaScript oder ohne JavaScript, halt dann, dass es halt dann so wie früher ist, okay, ich hab kein JavaScript, dann mach ich einfach mein Form-Sub mit, dann kriegt ihr das neue Ergebnis zurückgeladen.
Da gab's, glaub ich, auch genau vor allem ja so ein Drama, weil irgendwie die License im Source-Code, weil es eigentlich mehr oder weniger von Remix kopiert war, nicht richtig drin stand und so, Und dann gab's ein Twitter-Drama, dann wurde sich entschuldigt.
Und die Remix-Leute sind ja da immer ein bisschen speziell, was ich so mitbekommen hab.
Und ja, das geht, denke ich, in die gleiche Richtung. Aber sie sind ja noch nicht bei 1.0 angekommen.
Deswegen habe ich das jetzt auch noch nirgendwo im Projekt oder so eingesetzt, weil man weiß ja einfach nicht, wie sehr sich das noch verändern wird.
Und das schreiben sie auch direkt, wenn man auf ihrer Startpunkt-Solid-Seite ist, dass, ja, wir sind halt in der Beta.
Und da gibt es halt noch keine Stabilitätsgarantien, das ich vielleicht nicht einmal ändern würde.

[33:38] Ja, aber das würdest du bei Solid JS nicht sagen, vermutlich.
Also, wenn man jetzt nur auf eine kleinzeitige Anwendung aus ist, dann würdest du schon sagen, ist das production-ready, oder?
Auf jeden Fall. Also, auch dadurch, was ich gesehen habe, was es jetzt für Veränderungen gab in den letzten 1,5 Jahren, wo ich sozusagen mal mehr den Fokus drauf hatte, dass das zwar nicht immer 100 Prozent kompatibel war zwischen den Versionen, aber der Update-Pfad, das war dann eher so, okay, fast semi-automatisch das anzupassen.
Man musste ein neues Keyword dazu, weil sie halt dann auch im Laufe der Zeit die TypeScript-Integration viel besser gemacht haben, da haben sie da nochmal ein bisschen was vorbereitet, weil ich als großer TypeScript-Fan war dann auch ganz happy, dass das jetzt mal vorangetrieben wurde, also das letzte Release ist Can't Type This, war irgendwie Ende März, glaube ich, Und da haben sie halt TypeScript noch mal wesentlich verbessert.
Und da sind sie eigentlich schon relativ stabil. Und sehe ich im Moment keine Probleme, das einzusetzen für Single Page Applications.

[34:48] Ja. Da noch die Frage, also, du hast ja gesagt, die Changes sind eher gering.
Also, das Migrieren, das geht eigentlich relativ gut vor der Hand.
Gibt's, also gibt's da noch unterstützende Werkzeuge, die denn irgendwie beim Migrieren helfen?
Bei mir war es tatsächlich Typescript, das einfach gesagt hat, ja, hier passt der Type nicht mehr.
Dann habe ich halt mal kurz in die Release-Notes geschaut, und dann hieß es, ah, ok, es ist jetzt nicht mehr automatisch keyed, sondern schreibst halt noch das Wort dazu, weil sie es halt schon für die nächste Version vorbereitet hatten, dass dann per Default sozusagen unkeyed ist, um die Performance zu maximieren, weil, kann ich Beispiel geben, hier die Show-Komponente, von der wir schon gesprochen hatten, die sagt halt, ich zeig das an, wenn's truthy ist, ne?
Und wenn du dann, wenn du keine Funktion reingegeben hattest, sozusagen, die dann aufgerufen werden sollte, wenn's, wenn's wahr ist, dann hattest du halt den TypeScript-Check nicht drin, ne?
Dann hat er immer noch gesagt, das könnte ja auch undefined sein, obwohl du in dem Case warst, wo es halt eigentlich immer da sein muss, ne?
Wenn du es verwenden möchtest, ne? Beim Objekt jetzt zum Beispiel.
Und da haben sie halt dann irgendwann eingebaut, dass das halt auch, Ich hoffe, das Video hat euch gefallen.

[36:03] Wenn ja, dann lasst doch ein Abo da. Und lasst mir gerne ein Abo da.
Direkt geht, mit diesen Funktionen, und zwar ohne, dass du es immer neu rendern musstest.
Und wenn ihr noch mehr Videos sehen wollt, dann schaut mal hier oben.
Also, am Anfang, wenn du wirklich TypeScript haben wolltest, hast du sozusagen Performance-Hit bekommen, Dann könnt ihr auch noch dieses Video hier draufklicken. Und wenn ihr noch mehr Videos sehen wollt, weil dann hat er gesagt, immer wenn sich hier was verändert hat, dann hat sich komplett innen wurde es ausgetauscht, dann schaut auch hier oben. Und dann sehen wir uns beim nächsten Mal wieder.
Also wie bei React, und das ist ja eigentlich das, was sie nicht haben wollten am Anfang.
Wenn du kleine Apps hast, kann es dir mehr oder weniger egal sein, aber es kann ja nicht so die Sache sein.
Und das haben sie dann auch eingesehen, dadurch, dass immer mehr Leute SolidJS verwendet haben, und vor allem vielen größeren Playern, sag ich mal, sobald du mehr Leute an einem Projekt hast.
Typescript ist ja Leuten wichtig heutzutage.
Und ja, deshalb haben sie jetzt hier mal die Lücke geschlossen, dass es da keine Nachteile mehr gibt, wenn du das einsetzt. Und ja, fand ich zum Beispiel auch gut.
Und hatten es ja auch schon kommuniziert vorher, wo es hingehen sollte und so.

[36:53] Du hast ja gesagt, die, oder wir haben ja eben darüber gesprochen, dass Solid aus validen Gründen auch in so ein bisschen seinen eigenen Weg bei den JSX oder in seinem JSX-Dialekt geht.
Wie sieht das denn aus mit dem Ökosystem? Also das React-Ökosystem ist ja total groß, man kann da total viel irgendwie sich von Dritten holen und einhängen in sein Projekt.
Das ist wahrscheinlich, da muss man so ein bisschen wahrscheinlich auch aufpassen, wenn man aus der React-Welt Dinge in sein Solid-Projekt reinholt, oder?
Und wenn dem so ist, also entwickelt sich da ein, also mehr Richtung Solid-Freundlichkeit.

[37:47] Ja, so eine normale React-Komponente, die könntest du in Solid gar nicht verwenden, ne?
Also, wenn jetzt jemand was für React schon sozusagen fertig gemacht hat, ne, irgendwelche Hooks oder irgendwelche kompletten React-Komponenten, das ist halt einfach inkompatibel.

[38:04] Dadurch, dass Solid halt so ein ganz anderes Konzept hat, ne, ich hab kein VDOM, ich hab keine React-Runtime, die mitgeliefert wird.
Es entwickelt sich halt ein eigenes Ökosystem aus und um. Also, es gibt die Leute, die die Form Library, also alles, was man halt aus React auch kennt, fängt halt an zu entstehen, und zum Beispiel halt am Anfang gab es noch keine so großen Component Libraries, ne, dann ist man halt eher über den Weg gegangen, okay, Tailwind Integration hatte Solidstone immer eine ganz gute, ne, dann hat man halt seine Tailwind Component Library verwendet, und hat halt da einfach den JSX-Code kopiert, den ja viele hatten, und musste ihn halt dann vielleicht anpassen, wenn irgendwo Classname war, oder man hat ihn halt selber erstellt übers HTML.
Dadurch, dass es ja sehr ähnlich ist.
Aber es ist ein neues System auf jeden Fall. Und gibt's natürlich viel, viel, viel, viel, viel, viel, viel, viel, viel weniger als in der React-Welt.
Aber es ist ja auch nur zu erwarten. Ich mein, man bedenkt, wie lange jetzt React sozusagen die King on the Hill war, ne? King of the Hill.
Ja. Da muss man in den ersten bisschen reinkommen. Ich weiß auch nicht, wie's bei Svelte aussieht.

[39:07] Das hinkte ja auch irgendwie lange hinterher und hinkt wahrscheinlich auch immer noch, was so die Auswahl angeht, einfach durch weniger Zeit am Markt.
Ja, also ich denke nicht, dass es im Moment irgendwas gibt, was ähnlich verbreitet ist wie React.
Also nicht mal dieselbe Größenordnung. Ich habe vor ein paar Monaten mal so gelesen, hier sind die Top 10 Millionen Seiten, davon sind irgendwie...

[39:41] Sieben Millionen mit jQuery und WordPress. Und dann danach kommt irgendwie auf Platz zwei kommt dann irgendwann React mit 900.000.
Und alle anderen, alles unten drunter, alle anderen Frameworks zusammen, kommen nicht mal an die Hälfte.
Oder, also, das zeigt halt wie krass.

[40:02] Also selbst wenn man sich nur diese Seiten anschaut, zeigt das halt wie krass verbreitet React ist im Vergleich zu den anderen.
Ja, ich meine, hier in Deutschland haben wir ja noch die Angular-Welt, die auch sehr verbreitet ist, gerade im Corporate-Bereich.
Aber es ist, was ich so bekomme, auch oft ein deutsches Phänomen.
Ja, stimmt. So ein bisschen das Typo 3 unter den Frontend-Frameworks. Ja.
Aber ich würde nochmal zurück zu Solid kommen, denn du meintest, es hat den Store ja schon dabei.
Mhm. Ist der vom Gefühl her so wirklich First-Party integriert, dass du jetzt gar nicht wirklich mitbekommst, dass du was anderes verwendest, sondern sagst einfach nur, du importierst kurz das Store-Modul?
Oder könnte das so was werden wie das große React, Redux, MobX-Drama, dass es mal gab, dass sich die Leute nicht entscheiden konnten, was jetzt das coole Restore-Management ist.
Also, kann ich mir nicht vorstellen, da der Store, der kommt ja mit, ne, von... Okay, der kommt mit.
Der kommt mit, und der ist halt ziemlich, dadurch, dass sozusagen immer das Produce von immer noch eingebaut ist, schon direkt, also.

[41:16] Das kann ich halt super easy machen, um meinen Store anzupassen, und ich kann halt auch so viele Stores haben, wie ich möchte, also, das gleiche Prinzip wie Svelte, ich...
Man hat nicht unbedingt einen großen Store, wo alles drin ist, sondern einen Store anzulegen, das ist halt nicht so viel Aufwand.
Und was ich auch mal gesehen habe, man könnte sogar irgendwie Redux integrieren und so.
Habe ich mal gesehen, dass die gemeint haben, dass wenn man so externe Store-Management braucht, dann lässt sich das auch irgendwie anflanschen an ihren Store.
Aber das muss ich dazu sagen, da habe ich mal gelesen, habe mir gedacht, nee, das brauche ich eh nicht, weil das ist mehr als gut genug.
Kann so viele Stores haben, wie ich möchte, kann sie hinlegen, wo ich möchte, kann mir meine Funktionen außenrum machen, weil es halt keine Einschränkungen gibt, es sind einfach JavaScript-Funktionen, mehr oder weniger, was ich da zurückbekomme, und ja, kann ich importieren, exportieren, wie ich möchte.
Ja, gut, kann vielleicht auch immer ganz spannend werden, wenn man entweder migrieren möchte von einem Framework auf das andere, oder man sagt jetzt, man hat eine sehr große bestehende React-Applikation, aber den Teil möchte man aus diversen Gründen mit Solid machen, ob das jetzt im Store wirklich dann eine gute Idee ist, der Redux wiederzuwenden, ist eine Frage, aber generell ist es ja immer gut, wenn es eine Art adaptives Verhalten gibt, dass ich die Sachen auch mal mischen kann, wenn notwendig ist.
Ich find's sehr gut, dass wenn man hier bei SolidJS draufgeht auf die Beispiele, dass sie tatsächlich gleich mit TypeScript starten.

[42:43] Und was mir hier schon sehr positiv auffällt, ist, dass TypeScript hier so ganz nett dabei ist.
Das ist jetzt nicht dieses ...

[42:52] Erschlagen werden von Klassen und Enums und komplizierten Konstrukten, die sehr Typescript-lastig sind, sondern es ist eher, wie es mir so vorkommt, eben diese Unterstützung, die einfach so ganz nett ist, hier sind deine Properties, das ist eine Color, das hat halt einen String als Typen, und der Title ist ebenfalls ein String, oder hier hab ich eine Funktion.

[43:13] Bekommt die nur den Parameter und returned void oder undefined oder ähnliches.
Was mir auffällt, ist, es ist was Ähnliches, was jetzt viele, glaub ich, auch so ein bisschen das Problem bei Vue 3 auch immer noch haben.
Nachdem ja von Vue 2 auf Vue 3 wurde das ja sehr schön schlank mit der Script Setup, Syntactic Sugar, sehr viel Boilerplate rausgeschmissen.
Aber irgendwie ist es noch bei diesen Properties und Default States ähnlich, ähm, einfach Boilerplate-lastig.
Dass ich, man muss mir erst mal einen Typen schreiben, dass ich eben read-only ColorString bekomme, da muss ich meinen Default-Wert Color irgendwas angeben, und dann muss ich ja noch den Kontext hier, wie Sie es gerade nennen, noch erstellen.
Stört dich das manchmal, oder sagst du, das ist doch vollkommen egal, da kann man sich ja um die zehn Zeilen stören eigentlich keinen Menschen?
Also, ich denke auch, in Solid musst du es nicht machen. Also, du hast ja schon gesagt, ich glaube, dass TypeScript dir nicht so ins Gesicht springt, liegt daran, der Rinder ist kein so Typescript-Mensch.
Das ist zwar alles in Typescript geschrieben, weil er halt mehr oder weniger wusste, die Editor-Unterstützung, die muss halt da sein, das erwarten die Leute heutzutage, aber der ist schon so lange im JavaScript-Game, also, er sagt auch immer, seit über 20 Jahren.
Deswegen hat's jetzt auch irgendwie 2, 3 Jahre gedauert, bis der Typescript mal so richtig nachgezogen hat, weil es war nie so die Priorität, also die ganzen Beispiele im.

[44:41] Im Tutorial hier und so, die kannst du auch als JSX machen, ne, also nicht als TSX.
Und deswegen wird da auch sehr viel inferiert, ne, wenn du es jetzt nicht explizit austypest, dann inferiert das halt der TypeScript Compiler, weil der ist ja ziemlich gut darin, ne.
Deswegen musst du das gar nicht schreiben, ne, und dein Signal, das hat halt immer einen Default-Wert, wenn ich also Signals verwende, ne, und dann bei der Erstellung von meinem Signal gebe ich es halt an, oder beim Store gibt es halt auch so einen Weg, wie man halt seinen initialen Wert belegt, und dann Ja, wenn du halt den Type nicht manuell hinlegst, dann inferiert er den halt, und dann ist das für den auch okay.
Also, das kann man halt je nachdem, wie serious man das selber braucht oder entscheidet, ne, wenn's jetzt ein großes Projekt ist, okay, dann mach ich's halt ausführlicher, und wenn nicht, dann merk ich's sozusagen schon, wenn ich's falsch verwende, wenn ich's verändere, weil der TypeScript-Compiler ja noch da ist.

[45:30] Ja, ich frag mich immer bei der Performance, gerade im VS Code, ob's nicht performanter wäre, wenn ich selber den Typen schon mal angebe, bevor TypeScript selber herausfinden muss, was kommt da eigentlich am Ende der Funktion raus.
Hab ich mal gehört, ich bin mir nicht sicher, falls das irgendjemand weiß, wird mich das sehr interessieren, ob ich den Typen angeben muss, oder ob's auch sehr performant selbstständig rausgefunden werden kann, wenn man das möchte.
Ähm, hat einer von euch Erfahrungen?
Shep, ich weiß, du bist in deiner JavaScript-Welt, ich brauch dich gar nicht fragen.
Nee, mich brauchst du nicht fragen. Ich hätte aber geantwortet, dass das wahrscheinlich der Peter weiß.
Oder natürlich der Stefan.
So, die beiden, das sind doch hier die TypeScript-Nerds. Ja, die machen das komplizierte TypeScript, von dem ich immer spreche.
Nicht das Nette. Die haben Probleme, die sie ohne TypeScript gar nicht hätten.
Sie reden zumindest. Irgendjemand muss hier drüber sprechen.
Sie machen sicher dann auch selber drüber. Lustig, dass das merkwürdige Probleme sind.

[46:30] Ich muss aber auch sagen, ich probiere es schon immer erst mal, den Type selber hinzuschreiben für mich, weil dann ist es mir einfach klarer, auch sozusagen die Edge-Cases, möchte ich da vielleicht null und undefine sind halt in JavaScript einfach nicht dasselbe, ne?
Also, es gibt halt so Sachen, wenn ich mir das dann genau hinschreibe, und mir ist dann klar, was jetzt hier an dieser Stelle erlaubt ist und was nicht, weil zum Beispiel, wenn wir jetzt sowas wie ein State haben, dann bin ich immer so, ich würde immer gerne explizit dieses null drin stehen haben, weil wenn ich mir den State irgendwann mal anschaue, wie auch immer, dann sehe ich halt, okay, da ist jetzt nichts gesetzt, ne, weil wenn das Property einfach nicht da ist, ne, oder undefined ist ja das Gleiche, dann weiß ich nicht, ob vielleicht irgendwas fehlt, ne, das ist aber so meine persönliche Präferenz.
Und bei den kleinen Applikationen habe ich auch keinen Unterschied gemerkt, ne, ob ich das jetzt hinschreibe oder nicht, aber ich kann mir schon vorstellen, dass das beim inferieren schon mehr zu tun hat. Ich sehe das immer, wenn die generischen Geschichten mit ins Rennen kommen, ne, dieses komplizierte TypeScript, von dem ihr gesprochen habt, ne, Da merkt man das dann schon ein bisschen.
Deswegen könnte ich mir das vorstellen, aber das ist jetzt auch nur reinste Spekulation. eure Profis fragen.
Ich bin tatsächlich auch der Fan davon, das hinzuschreiben, genau wegen dem Gleichen, was du gesagt hast, wegen diesen undefined und null return-Werten.
Weil ich dann ...

[47:49] Schon möchte, dass es im Projekt gleich behandelt wird. Und für mich bedeutet null was ganz anderes, als wenn's undefined wär.
So ein typischer Stolperstein, den ich immer wieder sehe, ist, wenn man ...

[48:01] So ein optional chaining macht. Gut, das hat mit TypeScript gar nicht so viel zu tun.
Aber dass ich sage, in meinem Objekt, durch die Items durchgehen.
Und jetzt nehme ich den Key äh, Color Punkt Name.
Und wenn der ungleich das ähm, keine Ahnung, gelb ist, dann mach rot. Allerdings, wenn man da optional Chaining macht und dann ist das undefined, ist das auch ungleich rot. Äh, oder.

[48:27] Ungleich gelb. Also da gibt's auf jeden Fall das Problemchen. Hat man jetzt zwar mit null und undefined beides, aber ich mag's trotzdem, wenn man da unterscheidet.
Ich krieg die Kurve zurück zu äh, Solid. Ich sehe, neben Store haben die noch Formvalidierungen und CSS-Animationen, in-house mit drinnen. Das haben sie bei ihren Beispielen drin.
Hast du damit schon gearbeitet?

[48:49] Nee, mit CSS Transformation, äh, mit Transitions, meinst du jetzt, ne?
Oder was heißt das? Ja, sie schreiben CSS-Animationen hin, die Solid Transition Group.
Okay, nee, damit habe ich noch nicht gearbeitet. Das ist, ähm, das ist, äh, Nee, heute hatte ich mir das noch nicht angeschaut, das war… Ich bin nicht so der absolute Designer, ich bin immer froh, wenn das dann immer jemand anders macht, die Pixel-Perfect- und kreative Phase.
Deswegen… Aber das klingt ja so nach Grundrüstzeug, ne? Auch dieses, so ein Formularbaukasten, Router, Store, so, und dann ist, man hat mal alles beisammen, was man so braucht, ne?
Im Grunde. Bis man einen Date-Picker braucht. Bis man einen Date-Picker braucht, ja.
Dann muss man ganz schnell los, man hat Termine. Haben wir so klein Dropdowns, oder?
Perfekte Date-Picke. Aber gut. So haben wir das früher gemacht, das ging immer. Es geht heute noch.
Und dann schön mit dem Native Select. Geht doch eigentlich eh besser, wenn wir bei iOS und Android dann den Native Selects haben.
Aber dieses Light-Geschichte erzählen wir hier, glaube ich, auch einfach seit vielen Jahren, dass wir oft als Frontend-Developer sehr komplizierte Sachen und Features schreiben müssen, was wahrscheinlich auch so Firmen dann immer gut Geld kostet, bis wir irgendwann mal damit fertig sind, damit wir dann irgendwas gebaut haben, was eine eigentlich furchtbare UX hat.

[50:13] Ja, Mai, aber ist so, Hauptsache, wir haben keinen grauen Hintergrund bei Dropdown-Feldern.
Du hast gemeint, du hast, ähm, das Solid Start würdest du vielleicht jetzt noch nicht in Production einsetzen, weil es eben offiziell noch Beta ist.
Du hast gesagt, im Projekt. Hast du denn SolidJS tatsächlich in Projekten bei der Firma drin?
Oder sind das deine Side-Projects? Genau, meine Side-Projects sind aktuell in der Firma. Habe ich es nicht bei einem Kunden.
Aber wenn sich da meine Single-Page-Application anbietet, dann ist es jetzt auf jeden Fall...

[50:49] Wo ich das ohne Probleme vorschlagen könnte, ne? Das ist natürlich immer ein bisschen so der Hintergrund, wer arbeitet noch so mit dran, wie ist der Scope, aber ich seh jetzt nicht, dass SolidJS in nächster Zeit verschwindet.
Also hier Knock on Wood, ne, dass ich jetzt hier nicht irgendwie den Doom eingeleitet hab, aber das seh ich einfach nicht, und das ist halt schon ziemlich ziemlich verbreitet, und das ist halt auch, einfacher teilweise, ne? Und vor allem bei, wir haben den Kunden, da gibt's Projekte, die laufen halt auf sehr schwacher Hardware und so, und da ist halt so das Allerwichtigste immer die Disziplin in React, ne, mit Create Memo und möglichst wenig Re-Rendering und so weiter, da wird dann so viel Zeit reingesteckt, und deswegen, gerade wenn ich dann hier so eingeschränkte Projekte hab, also viel auf alten Mobile-Geräten laufen muss, oder auf einem Fernseher und so weiter, dann Würde ich auf jeden Fall vorschlagen, weil da sehe ich halt einfach den Performance-Gewinn eindeutig sofort, dass es mir das Leben enorm leichter machen könnte.
Und gibt es auch eine Art Anwendung, also die dann auch auf schnellen Geräten sehr profitieren würde? Also so ein, weiß nicht, sind es vielleicht irgendwie Dashboards mit vielen Tabellenzeilen oder so, also, kannst du das auch charakterisieren, was sich, äh, also, was so wirklich.

[52:19] Sich aufbringen würde?
Ja, wenn du halt viele Level hast, die nach unten gehen, und dann gezielte Updates hast, also, sagen wir mal vor, wo sie immer super dastehen bei den Benchmarks, ähm, gerade im Vergleich zu React oder Angular, wo diese Katastrophal darstanden, ich hab ganz viele, ganz, ganz viele Rows in der Tabelle.
Und das muss geändert werden.
Und das ist halt eine Katastrophe, wenn du sozusagen alles wegschmeißen musst, ne?
Und stelle dir vor, du hast ein paar indirektes Level nach unten, und genau, also sagen wir, du hast halt, oder du hast komplexen State, ne, der oben und unten verwendet wird, und dann, dann ist es mir eigentlich egal, weil es wird halt eigentlich nur das Element geupdatet, ne?
Und bei React werden halt dann vielleicht 2, 3, 4.000 Elemente zusätzlich noch geupdatet, ne?
Ja. Und wenn du die dann nicht memorized hast, dann stehst du halt da, ne? Und dann geht dir die, Dann geht die Applikation in die Knie. Mhm.

[53:14] Ja. Ja, super. Dann, glaube ich, haben wir ja schon sehr viele Dinge abgedeckt.
Was wir aber noch nicht, worüber wir noch nicht gesprochen haben, ist, wenn jetzt ein Hörerin oder ein Hörer entweder ein passendes Szenario hat oder ein passendes Projekt oder Neugiede, wo startet man?
Also, ist die Doku gut? Würdest du die empfehlen?
Ja, also das Tutorial kann ich auf jeden Fall empfehlen, das ist auch schön interaktiv gestaltet.
So eine Art Playground, da gibt es dann ein Konzept, wird erklärt, und dann kannst du so eine Mini-Aufgabe lösen.
Und das wird alles im Browser direkt gemacht.
Das ist auf jeden Fall schön für die einzelnen Punkte, ob es jetzt der Store ist, oder Heidi Cygnus an sich, oder meine hier Control-Flow-Komponenten.
Damit kann man mal, kann man mal reinschauen.
Und was sie auch haben, ist, sind so Starter-Templates, ne? Ich glaub, ja, auf GitHub, solidjs, slash Templates direkt, also ist ziemlich, ziemlich easy, äh, sich zu merken.
Und.

[54:22] Ja, da gibt's dann halt mit TypeScript, mit Tailwind oder mit Vitest gleich, das ist alles schon da, alles, wo du's brauchst.
Okay, super. Werden wir auf jeden Fall dann auch alles verlinken.
Aber Vanessa, du hast noch Fragen. Genau, in der Zwischenzeit hab ich übrigens kurz gegoogelt, es gibt auch schon einen SolidJS Datepicker, der ist natürlich schon am Start, den braucht man anscheinend in jedem Framework.
Was es in jedem Framework mittlerweile auch so gibt, sind die UI-Component-Libraries, also irgendwie Chakra und, ich glaub, Beautify bei Vue.
Ähm, persönlich war ich nie ein großer Fan davon, eben weil man sonst zu fest an das Design davon gebunden ist.
Aber das lag auch immer nur daran, dass ich immer sehr spezifisches Designs umsetzen musste.
Und da war Tailwind natürlich immer ganz super. Du hast schon gemeint, Bernd, dass Tailwind ...
Wird gut unterstützt. Aber fällt dir eine UI-Komponenten-Bibliothek ein, die ebenfalls schon stabil wäre für Solid?
Ich hatte da mal eine gesehen, letztes Jahr hatte sie so ein Solid Summer of Code.

[55:28] Aber ich muss sagen, ich hab bis jetzt immer Daisy UI verwendet. Ach, das geht?
Ja, genau. Ach Quatsch, das ist ja nur Tailwind. Genau, das ist ja gar nicht Anview gebunden. Ja, Daisy, super.
Wir müssen über Daisy reden, wer jetzt gerade nicht weiß, was das ist.
Also, ich hab das, das war für mich immer gut genug. Und ich glaube, die haben aber auch daran gearbeitet, dass es jetzt noch so solid spezifische Sachen gibt.
Aber mir hat Daisy immer gelangt. Aber ich wollte mir das auf jeden Fall auch mal anschauen, weil da ist bestimmt noch Luft nach oben, gerade wenn man es mit den Schäden bei React oder so ausgesprochen, bin mir nicht ganz sicher, wo sich dann super um die Accessibility und alles gekümmert wurde und so.
Da gibt es bestimmt noch was zu tun. Aber wenn du auch Daisy kennst, dann weißt du ja, damit kann man ja schon relativ viel reißen.
Ja, ich würde es tatsächlich auch gar nicht als UI, vielleicht hab ich es anders verwendet, aber ich hab von Daisy auch immer einfach nur CSS-Klassen verwendet.
Das sind ja keine Komponenten, mit denen ich gearbeitet hab.
Ich hab ja nicht irgendwie Daisy-Input-Komponente verwendet, sondern ich hab eben die CSS-Klasse verwendet, wie Input, Input Bordered und hat er dann den Style einfach drauf.
Das hat jetzt mit Accessibility ja auch noch nicht viel zu tun.
Die müsste ich ja selber noch hinzufügen.
Also ich dachte, dass Daisy auch irgendwie so...

[56:54] Ja, also, deutsch-schweizisch sind eigentlich CSS-Komponenten, ne?
Aber es gibt halt mehr jetzt nicht nur irgendwie den Style, sondern auch, dass ich halt meinen Button hab, ne?
Als einfachstes Beispiel. Oder eine Bubble oder was weiß ich.
Wahrscheinlich so Tailwind-UI-mäßig, oder?
Genau. Es ist quasi das traditionelle CSS-Komponentenbasiert für Tailwind-User.
Weil ich glaube, niemand von uns würde jetzt großartig widersprechen, dass man nicht so eine Gruppe an CSS-Klassen noch zusätzlich braucht.

[57:23] Ja. Den Fight fangen wir jetzt gar nicht erst an. Ich wollte, also mir ist dann jetzt noch der Einfall gekommen, wie sieht's mit der Verträglichkeit mit Web-Components aus?
Das ist ja bei React eher schlecht, aber ich denk mal, bei Solid wird das wahrscheinlich auch in Ordnung sein, oder?
Weil ich kam halt darauf, weil natürlich, wie wir gerade darüber gesprochen haben, so neues Framework.
Jetzt muss ja dann jedes, muss ja quasi alle Komponenten müssen dann noch mal neu aufgegossen werden dieses Framework. Und da ist ja eigentlich immer schon, bestand ja immer schon der Wunsch, das mal abzuwälzen auf Web Components, und die kann man dann irgendwie an alle diese Frameworks dran stöpseln, und muss das Rad nicht immer neu erfinden, und Accessibility nicht immer neu erfinden, und so weiter.
Ja, da muss ich sagen, ich hab's mal ausprobiert. Im Single-Page-Application-Fall, das war jetzt war jetzt nicht besonders stressig, konnte man einfach einbinden, aber ich bin mir nicht sicher, wie es ist mit dem Server-Side-Rendering, das ist ja das Problem, das viele Web-Components haben, gerade wenn du eben auf irgendwelche Browser-API-Sachen zugegriffen hast, dann gehen ja deine Probleme los, und deswegen, ich denke, je mehr jetzt die Meta-Frameworks sich durchsetzen, desto mehr werden sich die ganzen Web-Components jetzt noch anpassen dürfen.

[58:44] Das ist so ein bisschen mein Feeling.
Genau, aber da sind wir ja fein raus bei Solid, weil Solid Start ist ja noch nicht ready for Primetime.
Und dann, yay, brauchen wir uns da erst mal nicht kümmern.
Noch. Noch, ja. Alles klar, danke.

[59:03] Du hattest noch eine Frage, oder, Vanessa? Mhm. Wir hatten jetzt schon ein bisschen über Solid versus React gesprochen.
Solid vielleicht performanter, React riesiges Ökosystem.
Das ist der bekannte große Vorteil. Würdest du denn jetzt gerade Solid oder Svelte bevorzugen?
Du hattest vorhin noch gemeint, Svelte war damals ein bisschen noch problematisch, das hat ja diesen Loader da dabei und das war noch irgendwie in einem früheren Status. Aber Aber wenn du es heute vergleichst, wie würdest du Solid und das Feld vergleichen?

[59:40] Ja, also ich... Performance-technisch sind sie sich, denke ich, ziemlich ähnlich, was es angeht.
Bei Svelte ist es halt so, dadurch, dass die Runtime noch viel kleiner ist, das ist halt super, wenn du eine ganz, ganz kleine App hast oder so, dann musst du halt weniger Code ausliefern.
Aber sobald du mal ein paar Komponenten hast, ist die Svelte-App schon größer als die Solid-App.
Also, wenn es dir auf deine Größe angeht, dann würde ich wahrscheinlich zu Solid.js greifen.
Auch von der Performance sind sie ein bisschen besser, aber für den normalen Flight, denke ich, nimmt sich das nicht viel.
Und ja, ich persönlich bin nicht so der Fan von ihrer Lodafile, aber ich denke, das ist was, was halt so persönlich ist.
Ähm, es ist, ähm, Bevorzugung, ne, weil mittlerweile haben sie das ja mit, also auch TypeScript war am Anfang best-of-the-world, finde ich ganz schwierig, irgendwie es richtig zu importieren, weil hast ja dann nur dein Import-Type gebraucht und so weiter, aber das ist mittlerweile besser geworden, aber ich denke es immer noch nicht so gut, wie der JSX-Support, den halt einfach jeder Editor und TypeScript selber mitbringt, ne, das darf man auch nicht vergessen.
Deswegen, ich würde im Moment auch zu Solid greifen, aber wir haben zum Beispiel für die, für's JS-Craft-Camp die Seite in Svet neu gemacht, in Svet-Kit, und war auch eine gute Developer Experience.

[1:01:05] Die User Experience war auch gut. Ja, gut.
Alles klar, ich wäre durch mit meinen Fragen. Danke, Chef, dass du auf mich reagiert hast, mit meiner Händchen winkend.
Bernd, gibt es noch irgendein Thema, was du ansprechen möchtest, was wir jetzt bei den Fragen noch nicht besprochen hatten?

[1:01:24] Und du darfst auch shameless Dinge pluggen, wenn du welche hast. Das sowieso.
Ich kann sagen, was ich zum Beispiel, ich habe mit Solid mal einen wirklich einfachen JSON-Web-Token-Explorer geschrieben, dann auch gleich mit Tauri kombiniert.
Ich habe gehört, da habt ihr euch auch drüber unterhalten.
Und für sowas ist es für mich im Moment, ok, wenn ich so eine App habe, so eine kleine, die auch wirklich irgendwo vielleicht direkt mitgeliefert wird, da ist im Moment für mich SolidJS the way to go.
Und ja, kann ich jedem nur empfehlen, sich das mal anzuschauen, mal ein bisschen mit rumzuspielen und zu sehen, ob es einem taugt.
Mir ging es so und ich würde im Moment auch wieder dazugreifen und bin gespannt, wie sich das entwickelt. Gerade noch mit Solid Start. Genau.
Ansonsten, wenn jemand mit dir Kontakt aufnehmen will, Fragen hat, Ideen hat, Feedback hat, Wir würden deine Social Präsenzen verlinken bei uns in den Shownotes und ihr könnt uns aber auch immer eine E-Mail schreiben, einen Comments at workingdraft.de oder ihr hängt mit uns zusammen in unserem super duper Community Slack ab.
Auch dort findet ihr den Link auf unserer Seite.
Genau und wir bedanken uns bei dir Bernd. Vielen Dank, dass du da warst und uns so schön was über Solid erzählt hast und von deinen Erfahrungen damit.

[1:02:51] Herzlichen Dank für die Einladung. Dann werden wir vielleicht nochmal, haben wir in der Vorbesprechung gesagt, nochmal eine Folge vielleicht mit dir über Taubi machen.
Da haben wir zwar in der letzten Revision auch ein bisschen drüber gesprochen, hast du ja gerade gesagt, aber das war nur ein Teil von vielen.

[1:03:11] Ja, gerne. Und es würde sich glaube ich lohnen, dann nochmal eine dedizierte Folge aufzunehmen. Das machen wir dann.

[1:03:17] Genau, dann natürlich auch der Aufruf an die Hörerschaft.
Über irgendwelche von diesen Mitteln und Wegen, die Shep gerade aufgezählt hat, erreicht ihr uns.
Und könnt gerne mal fragen, was euch für Tauri interessiert.
Auch noch mal, was euch zu Solid interessiert.
Auch noch mal, was euch zu Quick interessiert. Oder was euch generell interessiert.
Was euch generell interessiert sowieso. Aber wenn ihr eben noch mal explizit Fragen an Tauri schickt, haben wir jetzt eben gleich hier die Möglichkeit, das dann in der nächsten Episode oder in einer der nächsten Episoden dann aufzuarbeiten. Ich möchte an dieser Stelle schon mal teasern, weil wir haben ja gerade ungefähr August, je nachdem, wer hier, wann diese Episode gehört werden kann. Und wir haben uns als gute Deutsche schon vorbereitet auf den Winter und als Weihnachten Und ich kann schon mal versprechen, es wird wieder eine traditionelle Ausblick in das neue Jahr Episode geben für alle unsere neuen Frameworks, wo wieder der Joe zu uns kommen wird. Da freuen wir uns auch schon sehr.
Vielleicht schaffen wir da nochmal ein bisschen Licht in diesen Frontend-Framework-Tunnelwald und hoffen vielleicht eher, dass manche eher verschwinden. haben wir dann nur noch zehn neue. Bis dahin.
Klingt sehr gut und ich glaube, wir werden erst im September released, aber das ist ja auch noch weit vor Weihnachten.

[1:04:44] Ist noch weit vor Weihnachten. Das ist die Wiesn-Zeit.

[1:04:50] Ja, dann. Dann trefft ihr euch vielleicht da. Und genau. Aber benehmt euch. Nicht zu viel trinken.
Nee, nee, das letzte Mal Wiesn habe ich eine Mandelentzündung bekommen. Das war kurz vor Corona. Seitdem war ich nicht mehr da.
Ja, okay. Also, vielen Dank. Wenn die Firma zahlt, dann gehe ich vielleicht schon. So, ehrlich.
Ja, klingt nach einem Plan. Dann Savi und Innovex-Treffen auf den Wiesen, gesponsert.
Wir sagen vielen Dank, Bernd. Liebe Grüße nach Erlangen.
Gerne. Danke, Vanessa. Und danke den Hörerinnen und Hörern fürs Zuhören. Bis nächste Woche.
Ciao, ciao. Tschüss. Ciao.

[1:05:33] Music.