Du möchtest das Video an jemanden weiterleiten, die oder der aber lieber liest? Dann findest Du den passenden Artikel zum Video bei Heise Developer: www.heise.de/blog/Vanilla-Web-Der-Frontend-Trend-2024-9611002.html
Endlich sagt es mal einer, danke. Es ist echt ein Krautergarten an Frameworks und jeden Tag kommt ein neues um die Ecke. Ich hoffe sehr, das sich WebComponents durchsetzen werden.
Du sprichst mir aus der Seele. Toll dass das mal jemand so deutlich und verständlich sagt. Wäre toll wenn die Frameworkeritis mal so langsam wieder verschwindet und Vanilla wieder zum "Normal" wird.
Im Prinzip hast du Recht, web components etc. pp koennen bereits sehr viel out of the box. Und man koennte auch eine Menge mit Vanilla JS machen. Aber: im 'echten' Leben, zumindest bei mir, habe ich weder Zeit noch Budget, einen Haufen Integrationen neu zu schreiben. Meta Frameworks bringen ja nicht nur die Komponenten mit sich. Man bekommt auch Routing, Authentication, Image Optimization.... und eine grosse Infrastruktur von bestehenden Projekten und Erweiterungen. Und im Regelfall ist es dem Kunden ziemlich egal, welche Technik(en) ich benutze - es muss schnell gehen und es muss funktionieren. Und ob ich da 100kb JS hinterherlade ist in den meisten Faellen spaetestens dann egal, wenn der Kunde sein 10mb PNG Logo auf die Seite geknallt hat....
Sehe ich genauso. MIch nervt dieses ganze Setup auch, aber es bringt auch sehr viel Nutzen mit. Man kann sicherlich eine SPA auch in Vanilla schreiben, aber da muss ich alle Bestandteile eines Frameworks selbst entwickeln, wenn man sie benötigt und dabei produziert man evtl. fehlerhaften Code, den nur selten jemand überprüft. Ein Fehler im Routing von Vue wird sicherlich schneller ans Licht kommen, als der in meiner Anwendung.
Dieser eine zusättliche 100kb Download mal da und mal da pro request wird mit der Durchsetzung von Cloud immer wichtiger werden. Egal wie schnell das Internet sein wird, die Webseiten in Cloud werden nach Speicherplatz, Datenverkehr und CPU Zeit etc. abgerechnet. Außerdem man verliert seine Entwicklerfähigkeiten, indem man immer mehr Frameworks, Libs etc. verwendet. Man ist nur noch API Consumer und Anwendungsbastler. Ich habe viele Entwickler gesehen, die super mit einem Framework umgehen aber händisch überhaupt nicht in der Lage sind eine Klasse zu schreiben. 😂
@@hugochavez6170 Muss man halt je Projekt abwaegen. Bei einem Microservice machen 100kb schon was aus. Bei meinem Beispiel einer Asset-lastigen Webseite eher nicht. Zudem werden die JS hoffentlich zumindest teilweise gecachet. Was die Entwicklerfaehigkeit angeht: das mag korrekt sein, aber in meiner Arbeitsrealitaet ist es so, dass der Kunde fuer eine Loesung bezahlt, nicht fuer Eleganz. Geilen Code muss ich in privaten Projekten zaubern (die nie fertig werden), im Tagesgeschaeft gilt: schnelle Loesungen, Standardisierung, Effizienz. Und es ist halt leider weder effizient noch hilfreich, bei grundlegenden Komponenten auf 'not invented here' zu setzen. So jedenfalls meine Erfahrung.
@@hugochavez6170 Das schon richtig. Es will dir aber keiner bezahlen. Du kannst natuerlich private Zeit in das Kundenprojekt stecken soviel du willst - du musst es danach aber auch entsprechend supporten, denn es ist ja jetzt alles 'aus der Manufaktur'. Sowas heb ich mir fuer meine privaten Experimente auf.
Danke fur das tolle Video! 😊 Ich muss echt sagen, dass es gerade dieser overhead ist, welcher mich von all diesen Frameworks fern hält. Ich mach jetzt nicht unglaublich viel im Frontend und genau deshalb ist es mir wichtig, dass minimalistisch zu halten. Ich sehe eben nicht den großen Vorteil für meinen regulären Anwendungszweck. Und da macht es mir Vanilla sehr viel leichter. Schön zu sehen, dass ich mit meiner bescheidenen Sichtweise, nicht ganz alleine da stehe 😊
Oh, da bist Du definitiv nicht alleine! Ich würde mal behaupten, dass selbst viele UI-Entwickler:innen mit dem Status Quo nicht wirklich glücklich sind, aber es halt hinnehmen, so nach dem Motto "ist halt so". Aber mit dem Status Quo muss man sich ja nicht zufrieden geben 😉
Vielen lieben Dank 😊 Was HTMX angeht - damit werde ich so gar nicht warm … da lernt man unterm Strich IMHO doch nur das *nächste* proprietäre Framework bzw die *nächste* proprietäre Syntax.
@@thenativewebschade, ich finde gerade im Zusammenspiel mit Go und dem go template package erhält man einen schmalen aber dennoch mächtigen Techstack für die Webentwicklung.
Vielen Dank für dieses Video. Ich dachte schon nur mir würde es so gehen, dass Webentwicklung keinen Spaß mehr macht. Hab schon über die tausend Frameworks den Überblick verloren, die man kennen und können muss.
Digga du sprichst mir aus der seele. Das ist was ich an golang so mag. Die Sprache ist geschmacksache. Aber die Philosophie der Sprache sollte man sich wieder aneignen.
„Momentum“ ist das richtige Wort. Ich hab mich seit Jahren schon von Frameworks verabschiedet weil JS selber eigentlich schon ausgereift ist. Da haben mich die Kollegen erst mal mit langen Gesichtern angeschaut, aber jetzt haben wir ein fertiges Frontend und alle erkennen die Vorteile davon keinen Build-Prozess mehr zu haben. Ergänzende Info: Unsere Firma liefert Hard- und Software aus bzw. gibt diese vor. Somit ist neuzeitliches JS sogar erwünscht.
Hallo Golo, schön dass du das Thema mal ansprichst. Ich als meistens Backend Entwickler (in Odoo) streife das Frontend nur am Rande. Ich habe diesen Wildwuchs beim Frontend und den wöchentlichen Erscheinungs- Zyklus neuer Frontends ohnehin nie verstanden, und fragte mich insgeheim, ob das anderen Leuten nicht auch so geht, wusste es nicht, weil nie darüber gesprochen wird... Wege aus dieser Sackgasse wären hilfreich.
Ich halte nicht so viel von Web Components. Habe auch schon Erfahrung mit Lit gesammelt. Die Idee ist gut, die Umsetzbarkeit eher ätzend und man stößt halt ständig an Grenzen. Deswegen haben Frameworks nach wie vor ihre Berechtigung. Aber klar, die Komplexität ist schon absurd hoch mittlerweile. Ich finde es auch besser, möglichst einfache und native Lösungen zu finden. Das heißt zum Beispiel kein CSS-Framework wie Failwind zu benutzen. Unnötiger Overhead. Und statt React lieber Svelte nutzen weil das ein Compiler ist der entsprechend Vanilla Code ausliefert mit einer viel geringeren Bundle Size, außerdem ist die Syntax erfrischend einfach und es macht Spaß damit Anwendungen zu schreiben. Auch weil es so einfach ist im Vergleich zu React zum Beispiel. Ich finde es auch für viele Anwendungen überzogen gleich eine Komponenten Bibliothek einzusetzen. Wenn man einen Button haben will, kann man halt einfach einen HTML Button nutzen und den mit CSS stylen. Habe dazu mal was getweetet jetzt mit dem Hashtag #vanillaweb. Wird nicht der letzte sein. Die Idee finde ich nämlich auch super.
Du hast State Management garnicht erwähnt. Das ist immerhin ein Hauptgrund, warum es Frontend Frameworks gibt. Ich wäre schon zufrieden, wenn es Svelte oder Solid schaffen würde zum neuen Standard für die nächsten 10 Jahre zu werden, aber die Vorherrschaft des überkomplexen React kann auf absehbare Zeit nicht angegriffen werden.
Das nenne ich mal einen spannenden Start in das Jahr 2024 :D Die neue Beleuchtung ist übrigens super! Und habt ihr vielleicht schon mal getestet, wie die Aufnahme wirkt, wenn die Kamera noch zwei oder drei Zentimeter höher positioniert ist, so das man mit Golo „auf Augenhöhe“ kommuniziert?
Dieses Thema treibt mich auch schon seit geraumer Zeit um. Ich habe zu der Zeit angefangen, als es absolut in Ordnung war ein wenig PHP, HTML, JavaScript und CSS in eine einzige Datei schrieb und darauf achtete, dass diese Datei wegen allgemein fehlender Bandbreite so klein wie möglich sein musste. Heute ist alles kompliziert und aufgeblasen. Ich sage nicht, dass das alles keine Daseinsberechtigung hat. Aber bitte ... wo soll das hinführen? Für jeden kleinsten, abstrahierten Bereich einen Experten einstellen? Eine einzige Person kann das alles gar nicht mehr leisten, um am Ende eine tatsächlich optimal funktionierende Anwendung zu entwickeln. Ein Blick in aktuelle Projekte lässt einen schier verzweifeln. Was man heutzutage als Entwickler alles leisten soll. Natürlich sind das oft die feuchten Träume von Personalern. Aber man muss sich mal vor Augen halten, wie groß der Umfang des Know Hows für eine Person sein muss, um wirklich gutes Know How in den spezialisierten Frameworks darstellen zu können.
Konkret gerade noch nichts, aber das kann sich schnell ändern … das hängt im Wesentlichen davon ab, ob wir damit weitere Experimente machen und wenn ja, wie die so verlaufen.
War ein tolles Video, sehr spannend und gleich geteilt. Das mit den Webcomponents und dem Shadow Dom war mir bekannt, hatte ich vor einer Weile auch in einem Microservice-Blogartikel im Bezug auf Microfrontends drüber geschrieben. Das CSS jetzt selbst geschachtelt werden kann, war mir neu! Danke ❤ Ich habe in einem anderen Kommentar bereits gelesen, dass du mit HTMX nicht ganz warm wirst, aber ich finde das im Bezug auf Frameworks eine sehr positive Entwicklung. Es gibt auch keinem Buildstep ❤ und man kann es einfach per CDN reinladen. Funktioniert auch mit allen Technologien die du beschreibst und so werde ich es mal in den kommenden Projekten ausprobieren. Ansonsten bin ich bei allen Themen ganz bei dir 😊! Wir müssen diesen Overhead abbauen!
Sehr guter Ansatz! Mich nervt dieser Overhead auch extrem. Habe deshalb z.B. auch gerade bei einem Projekt Tailwind entfernt und setze auf natives CSS. Würde mich freuen, wenn man wieder auf "Standards" setzt. Ich schreibe Webapplikation im Produktionsumfeld wo kein Internet vorhanden ist. Diese Anwendungen müssen dann einfach und auch in ein paar Jahren noch ohne "Spezialwissen" eines Framewokrs gewartet werden können. Man muss heutzutage eh schon mehrere Programmiersprachen können, da ist jedes Spezialwissen welches man für ein Framework einsparen kann eine Erleichterung.
Wobei Tailwind auch nur CSS-Klassendefinitionen sind die man auch direkt vom CDN beziehen kann, ohne Build-Schritt. Das ist relativ Vanilla. Für mich ist es mehr Overhead mir Klassennamen überlegen zu müssen und noch eine separate CSS-Datei verstehen zu müssen statt direkt beim HTML sehen zu können wie was gestyled ist, das mentale Modell für Tailwind ist für mich persönlich zugänglicher und leichter verständlich als das von reinem CSS.
Ein wenig oder auch ein wenig mehr JavaScript braucht es ohnehin für Components, da ist es kein Problem, das Template beim Initialisieren zu fetchen, ist ein Dreizeiler. Im Template werden die Styles dann ganz normal über
Hallo Golo, zurzeit versuche ich mit Jekyll und Github Pages einen kleinen Blog zu erstellen, aber nachdem ich dieses Video gesehen habe, habe ich mich dazu entschlossen es mit plain HTML, CSS & JavaScript zu versuchen. Danke für die Idee!
Ich kann dir da großteils zustimmen und ich kann auch persönlich da nichts mehr mit der "modernen Webentwicklungswelt" anfangen. Seit ein paar Jahren habe ich mich in die Blazor-Welt geflüchtet und das war für mich eine akzeptable Alternative die auch mehr von Unternehmen akzeptiert wird als wenn man sagt, dass man Plain Web / Vanilla Web programmiert. Nachteile: - Compiler nötig - Vendor-Lock-In Vorteile - Kein weiteres Tooling nötig als den Compiler - Durch Hot Reload keine Wartezeit bis die Änderungen sichtbar sind - Kein NPM / Node / NVM nötig - Keine extra Linting-Library nötig - Formating via editorconfig - Kein extra Framework für Testing nötig - Komponenten die nicht so sperrig aufzubauen sind wie die mit JavaScript - Größter Vorteil für mich persönlich: Entwicklung Großteils in C# anstatt JavaScript - Nur eine Technologie zusätzlich nötig statt ein Sammelsurium an verschiedensten Dingen die zusammengeklebt werden müssen. Es ist sicherlich nicht perfekt weil man die zwei Pillen an Nachteilen schlucken muss, aber es ist mMn. ein kleines Stück näher dran am Optimum als Vanilla Web.
Ich würde mich nicht auf Microsoft verlassen. Blazor könnte jederzeit in der Zukunft eingestellt werden, da die Mehrheit der Frontendler gar keinen Bock auf C# haben. Mit Generics kommen sie schon an ihre Grenzen.
Sehr cooles statement. Als das video startete und Du von "overhead" bzw. der "Einfachheit" gesprochen hast, die es ohne all diese Tools und Frameworks gäbe, musste ich nur denken. Hm der hat vermutlich nicht begriffen, dass all dieses tooling Ziele verfolgt und dass wenn man es weglässt möglicherweise weniger Komplex auf dieser Ebene ist, man jedoch bei debugging und Möglichkeiten stark eingeschränkt ist. Ggf. sogar sehr an Entwicklungsgeschwindigkeit verliert. Allerdings stimme ich zu, dass man das ganze immer mal wieder hinterfragen muss und schauen muss warum man es tut und ob es heutzutage nicht bessere gar native Möglichkeiten gibt. Jedoch ist eines der Hauptprobleme, dass wenn man bereits ein komplettes Ökosystem innerhalb eines Unternehmens zusammen mit einem Frontend Team aufgebaut hat, dann ändert man sowas einfach nicht mehr so ohne weiteres. Die Kosten sind einfach zu hoch, der Nutzen immer noch nicht klar (erst durch das eigentliche tun fällt auf, ob das alles so einfach machbar ist) und somit ist das Risiko viel zu hoch. Wenn man jedoch ein Projekt neu startet und das Budget es erlaubt, sollte man es in Erwägung ziehen. Vielen dank für die Inspiration! Das letzte mal, als ich mich ernsthaft mit den nativen Webcomponents beschäftigt habe ist lange her.
Gibt es eine Webseite, wo das alles mit Links übersichtlich zusammengefasst ist? Danke 🌺 (Ich finde "Vanilla Framework" oder "Vanilla JS" - das Gegenteil von dem hier vorgestellten…)
Leider nein. Die einzelnen Konzepte müsstest Du jeweils googlen. Dass Du zu dem Begriff "Vanilla Web" nichts findest, liegt daran, dass wir uns den für diesen Videotitel ausgedacht haben (also vielleicht verwendet den noch jemand anderes, aber uns ist das zumindest nicht bewusst).
Sehr interessant. Den Tipp, sich die Technologien anzuschauen, nehme ich gerne auf. Aber sag mal ist das auf dem Schreibtisch Tomatensaft? Ein Eistee wäre durchsichtiger. Das Glas schaut auch nicht nach einem Trinkglas aus. 😅
Ich fühle so sehr 😅 Ich bin Jahrgang 1975 und mache das ganze schon seit über 30 Jahren. Ich bin bei 3:42 und stimme dir zu 100 % zu. Danke für deine Videos, ich denke wir sehen viele Dinge sehr ähnlich und ich bin froh hier bei vielen Themen "Bestätigung" zu bekommen. Wir werden ja seit Jahren von einer Technologie/Lib/Framework zur/zum nächsten "getrieben". Aber mir macht mein Job trotzdem noch Spaß und man wird ja mit der Zeit ruhiger ;)
@@thenativeweb Puh, das wurde 2002 geschrieben und trifft noch heute genau den Punkt. Wir haben uns schon eine eigenartige Branche ausgesucht. 😅 So beständig was den Menschen und die Psyche betrifft und so sehr im Wandel was die Technologie und Herausforderungen betrifft.
@@romvits35401976 hier und aus gleichem Grund bei golang…. Der Artikel hat mich echt umgehauen… hätte auch von heute sein können… bis auf die Screenshots 🤗
Hallo, Golo! Wunderbares Video, ich bin der Meinung, dass uns Tools das Leben vereinfachen sollten und das in den letzen Jahren nicht mehr der Fall gewesen. Ich würde mich freuen, weiterführende Links oder Videos zu den unterschiedlichen Themen zu sehen. Weiter so und danke für die Videos
CSS kann man auch in den web components async reinholen oder man schreibt einen pre load im html head, und der browser holt es sich, wenn benötigt, also wenn component mounts.
Ein großes Problem was ich mit Web Components nicht in den Griff bekommen habe (eventuell hab ich sie auch falsch benutzt) ist dass bei mehrfacher Verschachtelungen von Komponenten die tiefer liegenden Komponenten für einen sichtbaren Moment keine Styles hatten weil diese noch von Server gefetcht werden mussten. Und das trat sogar schon lokal beim Entwickeln auf. Habe allerdings auch Parcel als Bundler für typescript und das importieren von HTML und CSS verwendet (ansonsten keine Abhängigkeiten). Weiterhin fehlt dann was für Databinding oder statemanagement. Aber es hört sich so an als könnte man sich das nochmal angucken. P.S. Man kann mit den großen Frameworks auch gegen Custom Elements „kompilieren“ wodurch man eigene Elemente auch überall einbinden kann
Der Effekt nennt sich FOUC (siehe de.wikipedia.org/wiki/Flash_of_Unstyled_Content). Wenn Du danach in Verbindung mit Web-Components suchst, solltest Du fündig werden … 😉
Sehr informatives Video. Da ich euren Kanal schon länger verfolge kannte ich in der Tat schon das ein oder andere Vanilla Toolkit, aber nicht alles. Wahrscheinlich haben die Vanilla Tools einfach das Problem, dass keiner für diese wirbt, weil sie keinem "gehören" und vermarket werden müssen. Und btw. ich dachte auch jetzt kommt der HMTX Zug auch durch diesen Bahnhof. Aber zum Glück war das nicht der Fall, weil einen echten mehrwert von HTMX sehe ich bisher nicht.
Grundsätzlich bevorzuge ich es auch Overhead zu vermeiden, wenn es auch ohne zusätzliche Tools umsetzbar ist. Es macht keinen Sinn Tools zu nutzen nur weil sie gerade in Mode sind("der Geist der Schwachen geht mit jedem Trend"). Wenn ich vorher gewisse Tools aufsetzen muss, die mir hinten raus aber wieder Zeit einsparen, dann werde ich das auch weiterhin so machen. Für mich war immer Voraussetzung mit möglichst wenig Aufwand, ein top Ergebnis mit dem mein Kunde und ich selbst zufrieden sind zu erreichen. Das spart Kosten, macht das Produkt günstiger, ich freue mich dass ich mehr umsetzen kann und der Kunde weniger löhnen muss für meine Leistung. Ich sehe den Zweck des Videos und die Argumentation macht auch Sinn, aber ich frage dich ernsthaft, wann hast du im Tech-Space mal erlebt dass sich etwas zurück entwickelt?!
Super Video! Allerdings scheint die Info-Card für's Lit-Video zu fehlen!? Und eine Suche Eurer Videos nach Lit ergibt keinen direkten Treffer... Oh, noch was: Was haltet Ihr von Remix? Ist zwar ein Framework, doch hat er sich die maximale Nutzung bestehender Standards auf die Fahnen geschrieben.
Klar kannst Du auch Svelte nutzen - nur sind Web-Components dort halt eher wieder ein After-Thought, sprich: Man muss es erst mal passend konfigurieren. Aber grundsätzlich: Use the right tool for the job.
Hallo, Interessantes Video. Bestätigt mein Vorgehen mit meinem eigenen, proprietären Framework (Naja, wohl eher eine Sammlung von Abstraktionen und eine API) mit welchem ich Intranet Lösungen entwickle und verkaufe. Es basiert auf Standard Webcomponents, Lit-Html, JS Proxies und ja, Typescript ist auch dabei :) Arbeite damit schon seit 3 Jahren. Falls sich nun die Leute fragen wie man das mit der "Reactivity" mittels Vanilla Web löst, das habe ich mit Standard JS Proxies gelöst. Abonniert!
Frohes neues Jahr :) Wow, bis auf die Custom Elements kannte ich glaube ich nichts. Bezüglich der TypeScript Sache: sind bei ECMAScript nicht mal native Typen im Gespräch gewesen? Das fände ich persönlich echt spannend. Mal sehen was das Jahr für die Web Entwicklung so bringt ;)
Ja, aber daraus wurde leider nichts … das war als Teil von EcmaScript 4 geplant: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE--yEbAQ2Px_0.html Seither ist der einzige Vorschlag in die Richtung das Proposal von Microsoft, Typannotationen in JavaScript einfach zu ignorieren: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-7fNFbJDdDuA.html
Genau *das* habe ich auch seit Jahren gesagt (also das mit "dieses Jahr ist das Jahr von Web-Components"), aber bislang war deren Erfolg sicherlich noch überschaubar … aber das muss ja nicht so bleiben 😉
Ich setze bereits seit es Lit v2 public gibt auf genau das Konstrukt. Klar, es gibt dann diverse Meldungen im TypeScript Compiler und so ganz ohne den Build- bzw. Kompiler-Schritt kommt man nicht aus, wenn man Lit mit TypeScript nutzt. Da gibt es dann mit den Decorators doch viel Erleichterung.
Mein Gedanke hier ist, wenn ich lit via CDN (o.ä.) einbinde ... dann kann ich auch gleich wieder react o.ä. direkt einbinden. Ja, ich bin dann daran gebunden, aber falls ich tatsächlich einmal einen Wechsel des Frameworks durchführen will, kann ich mit Technologien wie Astro o.ä. ein Inselprinzip verfolgen. Dann kann ich auch schrittweise eine neue Technologie einführen bzw. kombinieren. lit3 wird auch irgendwann veraltet sein und ich habe erst wieder eine Abhängigkeit, die ich genauso wie eben auch react loswerden will.
Hey Golo, danke wieder für das tolle Video. Ich dachte dein "Frontend-Trend für 2024" wird HTMX sein da es ja gerade so ein grossen Hype hat. Hoffentlich kommt irgendwann auch ein "tutorial" über Webcomponents/Lit" :)
Bestimmt … 😊 Mit HTMX konnte ich mich bislang nicht anfreunden - letztlich lernt man da wieder eine proprietäre Syntax, und das hat mich eher abgeschreckt.
Ja da hast du recht, es ist wieder eine proprietäre Syntax. Ich hatte eines unserer firmeninternen Tools von Vue auf HTMX migriert um HTMX besser zu lernen. Ich muss sagen es hat mich schon beeindruckt. Man kann dann halt ohne ein Frontend-Framework, vieles gleich im Backend mit einem templating engine implementieren und braucht nicht die ganze Backend-Logik zu duplizieren. Falls man aber viele dynamische Komponenten braucht, dann reicht HTMX halt nicht aus.
Grüß aus HaHa. Ich hab mal in HTMX reingeschaut, und mir ist das Konzept "UI-is-the-State", sehr positiv entgegengekommen. Ich habe "Hallo Welt!" in der Webpage eingegeben, und dann ... Gab es mir ein nettes "Hallo Du." zurück. Ahhh verda..t war wieder dieser AI-Prompter. Männo, Frau und Diverso. Das ist mir als Fachinformatiker viel zu hoch. Mich würde es auch interessieren was Meister Joda Roden zum HTMXen wohl sagen wird. "Wech X'n..", kam aus dem Monitor. 🤩 Lieber grüße an alle und happy HTML-Kompostieren ähh ich meinte Komponieren. 😝
Wir nutzen nur die Möglichkeiten von htmx, Zeug partiell nachzuladen. Eben genau deshalb, um die Anwendung im Backend zu halten. Entwicklungsgeschwindigkeit ist unmenschlich. So wie vor 20 Jahren, gefühlt. :)
Falls das bei Euch ein wirtschaftlich spannendes Thema werden sollte, und ihr jemanden brauchen könnt, für den heute wirklich so gar nichts neues dabei war, der schon gesamte Anwendungen ohne irgendwelche Dependencies realisiert hat und dabei die beteiligten Java-Entwickler zu Frontendlern ausgebildet hat, und der dieses Thema schon für mehrere Unternehmen evaluiert und verargumentiert hat, pingt mich mal an. :)
Habe schon länger die Frameworks geditched, Vanilla Stack rocks. Vor allem dieser Mythos du schreibst ein MVP schneller mit nem Framework stimmt einfach nicht.
Ich verwende nur sass „extra“ weil ich sonst keine Möglichkeit finde mixins zu erstellen. Ansonsten bin ich absolut deiner Meinung. Weniger ist mehr und vieles ist meiner Meinung nach überflüssig.
1:28 deshalb bin ich aus der Web Entwicklung raus. 😅 hat mich voll genervt. Jetzt bin ich iOS Entwickler. Ist natürlich auch nicht perfekt, aber nervt mich nicht so krass, wie der aktuelle Stand der Web Entwicklung.
ich entwickle bereits seit 2016 nur in vanilla js. hab den trend oder gar die notwendigkeit für frameworks wie react, angular oder aber auch typescript oder sowas jquery nie verstanden und auch nie gebraucht. würde mich freuen wenn man wieder davon ab kommen würde.
Entwickelst du nur Webapps oder auch Webseiten in VanillaJs. Ich bin seit Jahren Freund von VanillaJs, doch Programmiere trotzdem in Frameworks, da die meiner Sicht nach immer gefragt sind und keiner mehr Wert auf das schlichte javascript legt. Ich weiß auch nicht, wie ich mich damit positionieren soll, da dadurch meiner behauptung nach, auch der Aufwand für ein Projekt steigt. Würde gerne deine Meinung dazu wissen und wie du/ihr es an Kunden verkauft
@@zFreshx Ich entwickel webapps und webseiten nur ausschließlich mit nativem js. Ich weiß gar nicht wie leute behaupten können dass da der aufwand steigt. ich finde das gegenteil ist der fall. ich hab eben keine riesen lernkurve weil ich keine tausend abhängigkeiten schaffe und vor allem sind es diese abhängigkeiten und updates von packagemanagern und entwicklungsumgebungen die so einen hohen aufwand da rein bringen, dass das vorne und hinten nicht lohnt. ich bin froh dass meine firma die selbe philosophie hat wie ich und wir alles nativ und selber entwickeln und mit so wenig beiwerk wie möglich. wirklich viele sachen sind sehr schnell mit websocketd, python oder bash, html css und CGI gebastelt. (wir nutzen aber klar auch mal tomcat, apache oder nginx - je nach einsatzzweck) die notwendigkeit für frameworks ist einfach nicht gegeben. sie bringen keinen vorteil, weil alles nativ möglich ist zu entwickeln. jedes problem lässt sich nativ lösen. und vor allem schafft man sich keine tausend versionsabhängigkeiten und eine klare und einfache wartbarkeit. ich weiß, dass solche firmen mit solchen simplen philosophien wirklich selten sind.. wahrscheinlich weil es sich nicht so fancy verkaufen lässt.. aber es entspricht einfach genau meinem grundgedanken.
@@zFreshx entschuldige, habe deinen kommentar bis jetzt nicht gesehen. ich entwickel größtenteils eher plugins und microservices für ein generisches informationssystem das auf model-driven-development basiert. wir nutzen da keinerlei frameworks oder anderen schnickschnack. vorallem auch wegen der sicherheitsrichtlinien für kritische infrastruktur, müssen wir besonderen wert auf einfallstore und schadcode legen. jeder externe code den wir verwenden würden, wäre ein sicherheitsrisiko. der aufwand jeden externen code jedes mal zu prüfen, wäre katastophal. abgesehen davon, bietet vanillaJS alle funktionen die jedes andere framework bietet, wozu also der overhead. unnötig und mmn. benutzen die leute frameworks, weil ihnen arbeit abgenommen wird, die sie ohne das framework gar nicht hinbekommen würden, weil sie nicht wissen wie es geht. das framework basiert doch auch nur auf vanillaJs, ergo, kann man sich das gleich sparen.
In diesem Kontext würde mich mal eine Meinung vom Profi bzgl. Frameworks wie z.B. Shiny for Python (o.ä.) interessieren. Ich persönlich (kein Vanilla-Web Profi) finde den Ansatz für überschaubare Projekte ziemlich gut und effizient.
Webentwicklung war mal leichtgewichtig aber auch total krebsig :D Klar ist der ganze Müll um das Projekt herum nervig, aber ich persönlich bin gottfroh für Typescript, React, jsx/tsx und yarn. wenn das ganze jetzt noch smooth zu wasm kompiliert in zukunft, dann sind wir wirklich in der Zukunft angekommen. Statisch kompilierte Sprachen sind geil. Aber ich garantiere dass ich nie mehr freiwillig eine vanilla-js application bauen werde. Vorher werd ich python entwickler.
Ja bitte! Ich komme auch aus der Zeit komplett ohne Frameworks und es ging - da würde ich auch gern wieder zurück. Ich werde mir Lit nochmal ansehen und schauen, ob ich es aus Go heraus orchestrieren kann. Ich stelle mir hier eine Art Interface/Struct Konzept vor, dass wiederum auf Frontend Lit und CSS Struktur auf Basis der von dir angesprochenen Browserfeatures umsetzt. Vielleicht ist das ein Weg … es ist wieder Zeit zum rum fummeln und hacken :) Vanilla Web FTW! Ja bitte :) Und Typescript - Ich hatte schon mal ein eslint plug-in geschrieben, welches JS type coercion sichtbar macht und damit einen der größten JS killer zahnlos machte - wenn wir den Entwickler vielleicht mehr solche Tools an die Hand geben könnte, wäre Typescript vllt gar nicht mehr notwendig.
Und ja, es gibt sehr viele Webentwickler denen man mal nahelegen sollte das sie mit den damaligen Einschränkungen von Beispielsweise Geocities mal eine Website hochziehen sollen. Wenn ich mich recht entsinne war das anderthalb oder zwei MByte für die gesamte Seite, mehr nicht. Kein CGI, hatten wir nicht. Und trotzdem sind da schöne Dinge bei rum gekommen die ich mir lieber ansehe wie so manche CSS+JS+Ajax Hölle von Heute.
Danke für die tollen Videos? Vanilla Web, Lit und WebComponents ist okay. Trotzdem arbeite ich lieber mit Blazor Wasm. Hierzu würde ich mich auch über ein Video freuen. Gruss
Vanilla Web tolles Buzz Word, spricht mich voll an. Wir nutzen Angular, Typescript, Linter, SCSS und einiges davon nervt mich sehr. Würde mir wünschen das die angesprochenen Alternativen auch so zugänglich sind, das man gerne sagt "Cool, das setze ich gerne ein". Thema TypeScript und den Zwang jeden Furz zu typisieren, ist für mich unnötiger Nonsens, der den Code nur massiv aufbläht. Aber mit der Meinung, stehe ich gefühlt recht alleine da.
Wenn ich mit plain JS irgendwas baue, dann krieg ich nach etwa 1 Stunden nen Wutanfall und wechsel auf Typescript. Die komplett fehlende Typisierung ist einfach ein Fehlschritt der Geschichte. Wenn man in Typescript bestimmte Dinge nicht typen will, kann man auch eifnach "strict" abschalten, implicit any erlauben oder halt auch explicit any hinpacken. Für mich aber überhaupt kein Grund von Typescript wegzugehen. Das Typsystem spart mir entweder 5 millionen unit tests oder 5 millionen überflüssige Bugreports.
Ich bin mit diesen ganzen Frameworks recht spät zusammen gekommen. Ich habe früher mit js und html oder eben auch php ohne diesen ganzen Framework Schnickschnack groß geworden. War etwas perplex, wieso holt man sich sooooo viele Module und Abhängigkeiten ins Projekt? Offensichtlich habt Ihr euch alle komplett verirrt. 😂 😉
Starkes Video und eine starke meinung dazu. sprichst mir ein wenig aus der Seele, Danke für die denkanstöße. mich würde in diesem zusammenhang noch stateHandling interessieren. Weil es kommt doch schonmal vor das zwischen Komponenten gewisse Abhängigkeiten bestehen können bzgl ihrer unterschiedlichen Status und wie sie da zusammenspielen.
Das geht mir auch so … die API ist gruselig. Und das fand ich so schön an Lit, das packt nämlich einen IMHO sehr guten Abstraktionslayer drüber. Und das hat sich dann doch, finde ich, sehr gut angefühlt.
@@thenativeweb Ich finde die API absolut nicht gruselig. Es ist alles da und auch nicht schwer zu implementieren, wenn man sich erstmal ein paar Best Practices erarbeitet hat. Der Abstraktionslayer ist in meinen Augen nicht nur nicht nötig, sondern absolut schädlich. Du verlierst eine ganze Latte an Vorteile, die der Verzicht auf Frameworks mit sich bringt. Ich hab schon mehrfach für Unternehmen Dinge ausführlich evaluiert wie "Stencil vs lit vs Vanilla". Wäre spannend sich dazu mal auszutauschen.
@@thenativeweb Jip, das hatte ich bereits vor eurem Live Coding mal ganz kurz überflogen, weil ich wissen wollte, wie das implementiert ist. Für private Zwecke werde ich es auch weiterhin ab und zu nutzen, allerdings im Berufsalltag ist man oft gebunden.
