Sehr interessantes und gutes Video. Ich habe in der Uni Objektorientierte Programmierung gelernt und komme damit auch am besten klar. Jetzt habe ich mich entschieden, das ich mich in der Webentwicklung weiterbilden möchte. Aus diesem Grund beschäftige ich mich aktuell mit Angular (und scheine damit die richtige Entscheidung getroffen zu haben). Mit HTML, CSS und Javascript habe ich mich schon etwas befasst, bin aber bei weitem noch kein Meister. Alles was UI Entwicklung und Design angeht ist leider in meinem Studium nur sehr rudimentär behandelt worden. In den meisten Fällen ist es da auf Konsolen Anwendungen hinausgelaufen (und das kann ich mittlerweile ganz gut ...).
Da hast du alles wieder gut auf einen bzw. 4 Nenner gebracht. Man könnte natürlich auch eine Entscheidungsmatrix mit noch mehr Kriterien erstellen. Für mich persönlich ist aber schon entscheidend wer hinter einem Framework steht und wie sich die Community entwickelt. Das schlimmste ist doch auf einen Zug aufzuspringen, der früher oder später auf einem Abstellgleich landet.
Also wir hatten ein Design System auf Basis von LitElement und WebComponents zusammen mit einem Designer erstellt, dokumentiert/visualisiert in Storybook, Gepackt mit Webpack. Das Ziel war, dass wir die Komponents weiterhin sowohl für die legacy Sharepoint Aspx Seiten verwenden konnten als auch für neue Blazor Apps, oder falls Blazor Probleme gemacht hätte, wir auch auf andere Frameworks switchen hätten können. Vorteile: Designer konnte Js/CSS/Hmtl und Entwicker und Designer haben am selben Code gearbeitet auch da Lit extrem lightweight ist. Nachteile: Zwar war die integration Problemlos, aber wir haben trotzdem oft wrapper um die komponents gebraucht um z. B. in Blazor Two-Way bindings zu realisieren. Nicht schreibende Komponents konnte man direkt verwenden. Auch hatte man nur mit diesen Wrappern instellisense. Durch Wrapper/Verschiedene Technologien gab es dann doch einen Gewissen Overhead. Würde es aber grade für ein Designsystem mit Basiskomponenten immer wieder machen, da Webcomponents ja nicht abgekündigt werden und jede technologie mehr oder weniger Support hat! Für eine Komplette Anwendung würde ich aber NOCH immer noch zu einem Big Player Framework greifen
[gr] Danke für Deinen ausführlichen Kommentar und Deine Einschätzung. Interessant, von jemandem zu lesen, der größere Erfahrung mit Web-Components hat.
Sehr gutes, informatives Video, wie so viele Videos auf diesem Channel. Aber aus meiner Sicht ist Angular kein JS-zentriertes sondern mehr wie Vue ein HTML-zentriertes Framework, da auch hier eigene HTML-Attribute verwendet werden, um beispielsweise Schleifen oder Bedingungen aufzubauen. Für alle JSX-Fans empfehle ich mal ein Blick auf SolidJS. Ich finde, dass es viele sinnvolle Konzepte verfolgt und dazu auch noch einen immensen Performance-Vorteil gegenüber den "alteingesessen" Frameworks bietet. Im Endeffekt ist es aber eh meist eine Präferenzentscheidung. Ein Vue-Fan wird sich vermutlich meist für Vue entscheiden, während ein React-Fan sich für React entscheiden wird. Wichtig ist, dass man mit beiden Frameworks bzw. Libs zum Ziel kommt.
[gr] Danke für Dein Lob und Dein Feedback 😊 Das mit Angular stimmt … da war ich zugegebenermaßen etwas zwiegespalten, wie ich das einsortieren soll, und ja, es hat seine eigenen proprietären Attribute. Insofern hätte man es auch eher bei Vue einsortieren können. Aber das war ja auch ein bisschen das Ziel: Nicht zu sagen, nimm X, weil Y, sondern ein paar Kriterien zu nennen, eben weil man nicht alle so im Detail kennen kann 😉 Solid.js sagt mir gar nichts, müsste ich mir mal angucken. Und Deinem letzten Absatz kann ich nur zustimmen: Es ist eher selten, dass jemand das Framework so ganz grundlegend wechselt. Die meisten bleiben dann doch lange bei dem, was sie einmal nutzen, eben weil - wie Du ja auch schon sagst - man am Ende mit allen zum Ziel kommt, halt auf die eine oder andere Art.
Sehr informatives Video. Danke dir! Polymer wäre eigentlich nicht mehr zu erwähnen. Es war nur ein Testschritt und ist dann in Lit übergegangen. Ich arbeite mit WebComponenten, bzw. Lit, und bin happy. Als jemand der mit OOP aufgewachsen ist, ist die Isolation des Inneren natürlich wunderbar (besonders natürlich im Falle von CSS). Sonst kann ich mich auch nicht beklagen. Die Unterstützung der IDE (vs code) ist auch ok. (Ich glaube ich bräuchte da mal ein konkretes Bsp um dein Argument nachzuvollziehen) Das mit der Auswahl aufgrund der Verbreitung ist immer so eine Sache. Niemand weis was morgen ist und wohin es sich entwickeln wird. Auch vue, angualar und react fingen mal klein an. Ich denke nach den vielen Jahren die diese Frameworks bereits auf dem Buckel haben ist eine Neuentwicklung, wo die gemachten Erfahrungen einfließen, mal angebracht. Lit ist ja auch von google und macht das recht schön. Es ist zB nicht mehr zwangsläufig in TS, eher minimalistisch, keine erzwungene "File-Hell" oder eigenen HTML Attribute und als Ökosystem bedient es sich für Erweiterungen auch gern bei den Großen. Ich kann leider nur wenig im näheren Vergleich zu den Großen sagen, da mir da einfach die Erfahrung fehlt. Aber nachdem ich nun bald 2 Jahre mit Lit gearbeitet habe (allerdings allein) bin ich immernoch sehr zufrieden und bereue die Entscheidung nicht.
[gr] Das mit Polymer und Lit war mir gar nicht bewusst, danke für die Erklärung dazu! Vielleicht stehe ich Web-Components auch zu kritisch gegenüber, zumal ich mir natürlich auch nicht alle vier Wochen wieder auf's Neue angucke, was sich so alles getan hat. Wäre mal ein Thema für einen Livestream, um sich das mal wieder live anzugucken, um zu schauen, wie da der Stand der Dinge ist …
@@thenativeweb Ja, ist doch klar. Woher willst du denn auch alles wissen? :) Wenn du willst kann du mir auch mal die kritischen Punkte nennen und ich schau nach Lösungen.
Höre zum ersten Mal von Lit 🤭. Danke, wieder etwas gelernt. Allgemein finde ich dass web Frontend Entwicklung immer noch ein big pain in the a** ist, trotz - oder vielleicht gerade wegen - der vielen Frameworks ist.
In Angular kann auch im funktionalen Stil programmiert werden. Voraussetzung dafür ist dass man die Zustandsverwaltung (State management) mit RxJs realisiert. RxJs Observables sind im Grunde "pure functions" und mit den RxJs Operatoren wird eine Zustands-Aenderung Pipeline erstellt die ausgehend von einer Datenquelle das gewünschte Result über die Pipeline transformiert (mehrere Funktionsaufrufe hintereinander - Result von F1 wird zum Input für F2). In Angular wird die ChangeDetection Strategy einer Komponente auf PushStrategy gestellt und die Async Pipe im Template eingesetzt, die die Zustands-Aenderung Pipeline startet und auch wieder beendet wenn die Komponente entladen wird.
Ist euch ein Licht aufgegangen? Dies Video erscheint in einem neuen Licht. Irgendwie wirkt es alles etwas überstrahlt und wenig kontrastreich. Die Beleuchtung ist schon überall ausreichend - oder mehr als ausreichend. Dadurch verblassen einige Farben im Hintergrund und Golo erscheint "erleuchtet" - was hier allerdings auch zum Inhalt und zum Frontend-Thema passt. :)
[gr] Ja, das funktioniert. Bootstrap liefert ja letztlich auch "nur" ein SASS-File, was Du von Hand einbinden musst (in Dein SASS- oder SCSS-File). Guck mal unter react-bootstrap.github.io/getting-started/introduction#sass, da ist das auch noch mal beschrieben 😊
Der Vergleich React vs. Angular konzentriert sich ganz auf den Aspekt FP vs. OOP. Das ist zwar interessant, aber imho nebensächlich. Der wesentliche Punkt ist, dass Angular eben anders als React ein *Framework* ist. Eine der Konsequenzen daraus ist, dass es sehr klare Leitplanken vorgibt. Mein Team hat eine strategische Entscheidung für Angular getroffen, nicht weil wir OOP für uneingeschränkt super und besser als FP halten, sondern weil wir eben ein echtes Framework wollten. Unsere Ansicht nach macht es das leichter, den richtigen Weg ans Ziel zu finden, und skaliert so besser nach oben. Zugegebenermaßen ein Nachteil ist, dass es umgekehrt nicht gut nach unten skaliert und sich für kleinere Projekte oft zu schwerfällig anfühlt.
- React: für Javascript Einsteiger und für kleinere bis mittlere JS Apps. - Angular: für grosse JS Projekte und Projekte in Unternehmen - Blazor: das neue Silverlight von Microsoft? - Webplatform: ist und bleibt Html, CSS und Js. Daran ändert auch ein Webassebly nichts - Web Komponenten: Neben dem UI ist das State management zentral bei der App Entwicklung - State management gehört in ein Framework - Angular: ist nicht nur Objektorientiert. RxJS und Typescript sind die Grundlagen für moderne funktionale Programmierung. Grosse Teile einer Angular App werden funktional programmiert.
Sehe ich nicht ganz so. Auch HTML (W3C ) und Co müssen mit der Zeit gehen. Web-Components, haben kein State Management, was nicht bedeutet, dass es nicht noch kommt. WebAssambly hat Potenzial, was oft in Demos gezeigt wird, darum würde ich Blazor nicht so abhacken. Auch wird Blazor immer angenehmer zu schreiben. Ob React nicht für große Projekte zu nehmen ist, das glaube ich nicht. Sehe beide Frameworks eher ebenwürdig. Würde das eine nicht vor oder unter dem anderen stellen (An deinem Kanal kann man sehen das du Angular mehr magst). So hat jeder seine Vorlieben.
Ja, also ich würde mir wünschen, wenn allgemein deutlicher herausgestellt würde, dass es letztendlich persönliche Präferenzen sind, welche den Ausschlag dafür geben, welches Framework man verwendet. Die grundlegenden Möglichkeiten sind nämlich überall gleichermaßen gegeben.
HTML oder JS-zentriert: Manchmal denke ich, wir kommen eigentlich nicht voran in der Software-Entwicklung: Schon zu Zeiten von Servlets, dann JSPs und schließlich JSF hat man entweder HTML vor Augen und kann kaum Code erkennen, oder man hat Code vor Augen und hat kein Gefühl mehr für HTML.
Ich gucke seit Jahren hin und wieder, ob sich was getan hat. Und muss jedes Mal feststellen: nope, same shit another day :). Wird gefühlt sogar eher schlimmer - jeden Tag gibt's ein neues Framework 🙈
Du hast in dem Video "Warum Vue.js?" gesagt: "Wenn man daran glaubt das WebComponenten die Zukunft darstellen." Ich finde der Ansatz ist falsch. "Mit welcher Technologie möchtest du in Zukunft entwickeln?" muss die Frage lauten. Immerhin generieren wir als Entwickler, also als Konsumenten von Technologien, die Nachfrage für Diese. Eine gute Technologie oder Idee wird nicht weiterentwickelt, wenn sie niemand nutzt, und Feedback, Verbesserungen, Erweiterungen usw. generiert. Schlechte Technologien konnten sich nur halten weil die Leute daran festgehalten haben. Ich weis schon wie das mit der Gewöhnung ist. Besser man gewöhnt sich an Veränderung. ;) Und ja, als (introvertierte) Entwickler ist es oft schwer sich da durchzusetzen. Gerade wenn man dann die (extrovertierten) PM's hat, die zwar seit über 10 Jahren nicht mehr mit Technologien gearbeitet haben, dann aber doch entscheiden... Entwickler sind die Technologieexperten und müssen so auftreten!
[gr] Das stimmt schon irgendwo - wobei natürlich nicht einfach nur deshalb etwas sinnvoll ist, weil jemand sagt "ich will!" 😉 (Das wolltest Du damit aber IMHO auch nicht ausdrücken.) Man muss halt am Ende die richtige Balance finden aus passendem Paradigma, Verbreitung, Zukunftssicherheit & Co. Und dass da die technisch informierten Personen (mit-)entscheiden sollten, sollte eigentlich eine Selbstverständlichkeit sein (und ja, ich weiß, dass es das oft leider nicht ist …).
Das React kein Framework ist, ist richtig, aber in 99% der Fälle wird React als Framework verwendet. Bestes Beispiel Next.JS. Selbst Vite oder CRA bietet eine Menge an Framework Funktionen (abgesehen vom Routing in dem Fall)
" Wie ist das genau mit grösse der libraries? " minimierte frameworks? Lightwieght also, bleibt wohl der eigenen Recherche übrig :D Bzw, wo deiner Meinung nach geht ma hin mit WebGl? Node? ... Angular? React?
[gr] Der Punkt dabei ist (leider), dass das ja auch schwankt. Gerade die Bundlesize kann in sechs Monaten ganz anders aussehen, insofern halte ich persönlich das nur bedingt für einen aussagekräftigen Indikator für die Entscheidung für oder gegen ein Framework.
17:10 Niemals wurden treffendere Worte gesprochen. Wirklich perfekt auf den Punkt an der Stelle.
[gr] Vielen Dank 😊
genial, Tolle Arbeit an der Recherche ;) , wirklich fein, " die goldenen Mitte aufgegriffen " Liebe Grüsse aus Österreich
[gr] Vielen Dank - und liebe Grüße zurück 😊
Sehr interessantes und gutes Video. Ich habe in der Uni Objektorientierte Programmierung gelernt und komme damit auch am besten klar. Jetzt habe ich mich entschieden, das ich mich in der Webentwicklung weiterbilden möchte. Aus diesem Grund beschäftige ich mich aktuell mit Angular (und scheine damit die richtige Entscheidung getroffen zu haben). Mit HTML, CSS und Javascript habe ich mich schon etwas befasst, bin aber bei weitem noch kein Meister. Alles was UI Entwicklung und Design angeht ist leider in meinem Studium nur sehr rudimentär behandelt worden. In den meisten Fällen ist es da auf Konsolen Anwendungen hinausgelaufen (und das kann ich mittlerweile ganz gut ...).
[gr] Freut mich, dass Dir das Video gefallen und es Dich in Deiner Entscheidung bestärkt hat 😊
Viel Erfolg weiterhin 🦄
Da hast du alles wieder gut auf einen bzw. 4 Nenner gebracht. Man könnte natürlich auch eine Entscheidungsmatrix mit noch mehr Kriterien erstellen. Für mich persönlich ist aber schon entscheidend wer hinter einem Framework steht und wie sich die Community entwickelt. Das schlimmste ist doch auf einen Zug aufzuspringen, der früher oder später auf einem Abstellgleich landet.
[gr] Danke schön 😊
Also wir hatten ein Design System auf Basis von LitElement und WebComponents zusammen mit einem Designer erstellt, dokumentiert/visualisiert in Storybook, Gepackt mit Webpack. Das Ziel war, dass wir die Komponents weiterhin sowohl für die legacy Sharepoint Aspx Seiten verwenden konnten als auch für neue Blazor Apps, oder falls Blazor Probleme gemacht hätte, wir auch auf andere Frameworks switchen hätten können. Vorteile: Designer konnte Js/CSS/Hmtl und Entwicker und Designer haben am selben Code gearbeitet auch da Lit extrem lightweight ist. Nachteile: Zwar war die integration Problemlos, aber wir haben trotzdem oft wrapper um die komponents gebraucht um z. B. in Blazor Two-Way bindings zu realisieren. Nicht schreibende Komponents konnte man direkt verwenden. Auch hatte man nur mit diesen Wrappern instellisense. Durch Wrapper/Verschiedene Technologien gab es dann doch einen Gewissen Overhead. Würde es aber grade für ein Designsystem mit Basiskomponenten immer wieder machen, da Webcomponents ja nicht abgekündigt werden und jede technologie mehr oder weniger Support hat! Für eine Komplette Anwendung würde ich aber NOCH immer noch zu einem Big Player Framework greifen
[gr] Danke für Deinen ausführlichen Kommentar und Deine Einschätzung. Interessant, von jemandem zu lesen, der größere Erfahrung mit Web-Components hat.
Sehr gutes, informatives Video, wie so viele Videos auf diesem Channel.
Aber aus meiner Sicht ist Angular kein JS-zentriertes sondern mehr wie Vue ein HTML-zentriertes Framework, da auch hier eigene HTML-Attribute verwendet werden, um beispielsweise Schleifen oder Bedingungen aufzubauen.
Für alle JSX-Fans empfehle ich mal ein Blick auf SolidJS. Ich finde, dass es viele sinnvolle Konzepte verfolgt und dazu auch noch einen immensen Performance-Vorteil gegenüber den "alteingesessen" Frameworks bietet.
Im Endeffekt ist es aber eh meist eine Präferenzentscheidung. Ein Vue-Fan wird sich vermutlich meist für Vue entscheiden, während ein React-Fan sich für React entscheiden wird. Wichtig ist, dass man mit beiden Frameworks bzw. Libs zum Ziel kommt.
[gr] Danke für Dein Lob und Dein Feedback 😊
Das mit Angular stimmt … da war ich zugegebenermaßen etwas zwiegespalten, wie ich das einsortieren soll, und ja, es hat seine eigenen proprietären Attribute. Insofern hätte man es auch eher bei Vue einsortieren können. Aber das war ja auch ein bisschen das Ziel: Nicht zu sagen, nimm X, weil Y, sondern ein paar Kriterien zu nennen, eben weil man nicht alle so im Detail kennen kann 😉
Solid.js sagt mir gar nichts, müsste ich mir mal angucken.
Und Deinem letzten Absatz kann ich nur zustimmen: Es ist eher selten, dass jemand das Framework so ganz grundlegend wechselt. Die meisten bleiben dann doch lange bei dem, was sie einmal nutzen, eben weil - wie Du ja auch schon sagst - man am Ende mit allen zum Ziel kommt, halt auf die eine oder andere Art.
Sehr informatives Video. Danke dir!
Polymer wäre eigentlich nicht mehr zu erwähnen. Es war nur ein Testschritt und ist dann in Lit übergegangen.
Ich arbeite mit WebComponenten, bzw. Lit, und bin happy. Als jemand der mit OOP aufgewachsen ist, ist die Isolation des Inneren natürlich wunderbar (besonders natürlich im Falle von CSS). Sonst kann ich mich auch nicht beklagen. Die Unterstützung der IDE (vs code) ist auch ok. (Ich glaube ich bräuchte da mal ein konkretes Bsp um dein Argument nachzuvollziehen)
Das mit der Auswahl aufgrund der Verbreitung ist immer so eine Sache. Niemand weis was morgen ist und wohin es sich entwickeln wird. Auch vue, angualar und react fingen mal klein an.
Ich denke nach den vielen Jahren die diese Frameworks bereits auf dem Buckel haben ist eine Neuentwicklung, wo die gemachten Erfahrungen einfließen, mal angebracht.
Lit ist ja auch von google und macht das recht schön. Es ist zB nicht mehr zwangsläufig in TS, eher minimalistisch, keine erzwungene "File-Hell" oder eigenen HTML Attribute und als Ökosystem bedient es sich für Erweiterungen auch gern bei den Großen.
Ich kann leider nur wenig im näheren Vergleich zu den Großen sagen, da mir da einfach die Erfahrung fehlt. Aber nachdem ich nun bald 2 Jahre mit Lit gearbeitet habe (allerdings allein) bin ich immernoch sehr zufrieden und bereue die Entscheidung nicht.
[gr] Das mit Polymer und Lit war mir gar nicht bewusst, danke für die Erklärung dazu!
Vielleicht stehe ich Web-Components auch zu kritisch gegenüber, zumal ich mir natürlich auch nicht alle vier Wochen wieder auf's Neue angucke, was sich so alles getan hat. Wäre mal ein Thema für einen Livestream, um sich das mal wieder live anzugucken, um zu schauen, wie da der Stand der Dinge ist …
@@thenativeweb Ja, ist doch klar. Woher willst du denn auch alles wissen? :)
Wenn du willst kann du mir auch mal die kritischen Punkte nennen und ich schau nach Lösungen.
Höre zum ersten Mal von Lit 🤭. Danke, wieder etwas gelernt. Allgemein finde ich dass web Frontend Entwicklung immer noch ein big pain in the a** ist, trotz - oder vielleicht gerade wegen - der vielen Frameworks ist.
In Angular kann auch im funktionalen Stil programmiert werden.
Voraussetzung dafür ist dass man die Zustandsverwaltung (State management) mit RxJs realisiert.
RxJs Observables sind im Grunde "pure functions" und mit den RxJs Operatoren wird eine Zustands-Aenderung Pipeline erstellt die ausgehend von einer Datenquelle das gewünschte Result über die Pipeline transformiert (mehrere Funktionsaufrufe hintereinander - Result von F1 wird zum Input für F2).
In Angular wird die ChangeDetection Strategy einer Komponente auf PushStrategy gestellt und die Async Pipe im Template eingesetzt, die die Zustands-Aenderung Pipeline startet und auch wieder beendet wenn die Komponente entladen wird.
Ist euch ein Licht aufgegangen?
Dies Video erscheint in einem neuen Licht. Irgendwie wirkt es alles etwas überstrahlt und wenig kontrastreich.
Die Beleuchtung ist schon überall ausreichend - oder mehr als ausreichend. Dadurch verblassen einige Farben im Hintergrund und Golo erscheint "erleuchtet" - was hier allerdings auch zum Inhalt und zum Frontend-Thema passt. :)
[gr] Wir haben eine andere Kamera als sonst genutzt und es ist die Hauptlichtquelle ausgefallen. 😕
Lieber Golo, ist es möglich mit React.js im selben Projekt sowohl react-bootstrap als auch scss zu verwenden? (alles Node.js Basis versteht sich)
[gr] Ja, das funktioniert. Bootstrap liefert ja letztlich auch "nur" ein SASS-File, was Du von Hand einbinden musst (in Dein SASS- oder SCSS-File). Guck mal unter react-bootstrap.github.io/getting-started/introduction#sass, da ist das auch noch mal beschrieben 😊
Der Vergleich React vs. Angular konzentriert sich ganz auf den Aspekt FP vs. OOP. Das ist zwar interessant, aber imho nebensächlich. Der wesentliche Punkt ist, dass Angular eben anders als React ein *Framework* ist. Eine der Konsequenzen daraus ist, dass es sehr klare Leitplanken vorgibt. Mein Team hat eine strategische Entscheidung für Angular getroffen, nicht weil wir OOP für uneingeschränkt super und besser als FP halten, sondern weil wir eben ein echtes Framework wollten. Unsere Ansicht nach macht es das leichter, den richtigen Weg ans Ziel zu finden, und skaliert so besser nach oben. Zugegebenermaßen ein Nachteil ist, dass es umgekehrt nicht gut nach unten skaliert und sich für kleinere Projekte oft zu schwerfällig anfühlt.
Gibt auch react Frameworks: Next oder Remix.
Super Video!
[gr] Vielen Dank 😊
- React: für Javascript Einsteiger und für kleinere bis mittlere JS Apps.
- Angular: für grosse JS Projekte und Projekte in Unternehmen
- Blazor: das neue Silverlight von Microsoft?
- Webplatform: ist und bleibt Html, CSS und Js. Daran ändert auch ein Webassebly nichts
- Web Komponenten: Neben dem UI ist das State management zentral bei der App Entwicklung
- State management gehört in ein Framework
- Angular: ist nicht nur Objektorientiert. RxJS und Typescript sind die Grundlagen für moderne funktionale Programmierung. Grosse Teile einer Angular App werden funktional programmiert.
[gr] "React: für Javascript Einsteiger und für kleinere bis mittlere JS Apps." - Du meinst, so was wie zum Beispiel Facebook? 😉
Sehe ich nicht ganz so. Auch HTML (W3C ) und Co müssen mit der Zeit gehen. Web-Components, haben kein State Management, was nicht bedeutet, dass es nicht noch kommt.
WebAssambly hat Potenzial, was oft in Demos gezeigt wird, darum würde ich Blazor nicht so abhacken. Auch wird Blazor immer angenehmer zu schreiben.
Ob React nicht für große Projekte zu nehmen ist, das glaube ich nicht. Sehe beide Frameworks eher ebenwürdig. Würde das eine nicht vor oder unter dem anderen stellen (An deinem Kanal kann man sehen das du Angular mehr magst). So hat jeder seine Vorlieben.
@@thenativeweb Nicht jeder ist ein Facebook Developer!
Und auch die grosse Facebook App ist nicht absturzsicher (wie man heute Nacht erfahren hat)
@@hansschenker Ich glaube nicht, dass das an React lag. Da die Seiten nicht erreichbar waren, gehe ich eher von einem Fehler auf Netzwerk-Ebene aus.
Ja, also ich würde mir wünschen, wenn allgemein deutlicher herausgestellt würde, dass es letztendlich persönliche Präferenzen sind, welche den Ausschlag dafür geben, welches Framework man verwendet. Die grundlegenden Möglichkeiten sind nämlich überall gleichermaßen gegeben.
HTML oder JS-zentriert: Manchmal denke ich, wir kommen eigentlich nicht voran in der Software-Entwicklung: Schon zu Zeiten von Servlets, dann JSPs und schließlich JSF hat man entweder HTML vor Augen und kann kaum Code erkennen, oder man hat Code vor Augen und hat kein Gefühl mehr für HTML.
[gr] Ja, das ist durchaus eine Frage, die ich mir auch immer wieder mal stelle …
Ich gucke seit Jahren hin und wieder, ob sich was getan hat. Und muss jedes Mal feststellen: nope, same shit another day :). Wird gefühlt sogar eher schlimmer - jeden Tag gibt's ein neues Framework 🙈
[gr] Immerhin inzwischen nur noch jeden Tag - vor zehn Jahren war das gefühlt alle zehn Minuten 😉🤣
Ich entwickle seit 25 Jahren. Viele Firmen bevorzugen Angular.
Du hast in dem Video "Warum Vue.js?" gesagt: "Wenn man daran glaubt das WebComponenten die Zukunft darstellen."
Ich finde der Ansatz ist falsch. "Mit welcher Technologie möchtest du in Zukunft entwickeln?" muss die Frage lauten. Immerhin generieren wir als Entwickler, also als Konsumenten von Technologien, die Nachfrage für Diese. Eine gute Technologie oder Idee wird nicht weiterentwickelt, wenn sie niemand nutzt, und Feedback, Verbesserungen, Erweiterungen usw. generiert.
Schlechte Technologien konnten sich nur halten weil die Leute daran festgehalten haben. Ich weis schon wie das mit der Gewöhnung ist. Besser man gewöhnt sich an Veränderung. ;)
Und ja, als (introvertierte) Entwickler ist es oft schwer sich da durchzusetzen. Gerade wenn man dann die (extrovertierten) PM's hat, die zwar seit über 10 Jahren nicht mehr mit Technologien gearbeitet haben, dann aber doch entscheiden... Entwickler sind die Technologieexperten und müssen so auftreten!
[gr] Das stimmt schon irgendwo - wobei natürlich nicht einfach nur deshalb etwas sinnvoll ist, weil jemand sagt "ich will!" 😉
(Das wolltest Du damit aber IMHO auch nicht ausdrücken.)
Man muss halt am Ende die richtige Balance finden aus passendem Paradigma, Verbreitung, Zukunftssicherheit & Co.
Und dass da die technisch informierten Personen (mit-)entscheiden sollten, sollte eigentlich eine Selbstverständlichkeit sein (und ja, ich weiß, dass es das oft leider nicht ist …).
@@thenativeweb Jeder npm download ist ein "Ich möchte" :)
Das React kein Framework ist, ist richtig, aber in 99% der Fälle wird React als Framework verwendet. Bestes Beispiel Next.JS. Selbst Vite oder CRA bietet eine Menge an Framework Funktionen (abgesehen vom Routing in dem Fall)
Hammer erklärt. Hätte gerne noch mehr zu svelte gehört.
[gr] Danke schön 😊
Zu Svelte kann ich derzeit leider nicht allzu viel sagen, aber vielleicht ändert sich das in Zukunft ja noch …
" Wie ist das genau mit grösse der libraries? " minimierte frameworks?
Lightwieght also, bleibt wohl der eigenen Recherche übrig :D
Bzw, wo deiner Meinung nach geht ma hin mit WebGl?
Node? ... Angular? React?
[gr] Der Punkt dabei ist (leider), dass das ja auch schwankt. Gerade die Bundlesize kann in sechs Monaten ganz anders aussehen, insofern halte ich persönlich das nur bedingt für einen aussagekräftigen Indikator für die Entscheidung für oder gegen ein Framework.
Was gerade so richtig rauskommt ist Compose for Web. Statt JavaScript, Kotlin.