Mein 2020 war geprägt von der beträchtlichen Zeit, die ich mit der Analyse von Daten über die Nutzung von CSS in der Praxis verbracht habe, für das CSS-Kapitel des Web Almanac, vom HTTP Archive. Die Ergebnisse waren für mich augenöffnend. Eine Art Weckruf. Wir verbringen so viel Zeit in der Blase der neuesten Technik, dass wir den Bezug dazu verlieren, wie das Web wirklich gebaut ist. Der Großteil des Webs bevorzugt alte, stabile Technik anstelle von neuem Glanz.
CSS-in-JS? Nur 2% der Websites.
React? Nur 4%.
Service Workers? Weniger als 1%.
Houdini? Praktisch 0%.
Niemand benutzt mehr jQuery, oder? Falsch. Es kommt auf 83% aller Websites vor! Jeder nutzt Jamstack anstelle von aufgeblähten CMS, richtig, richtig? Falsch. Statische Website-Generatoren werden auf weniger als 1% der Websites verwendet, WordPress betreibt ein Drittel des Webs.
Ein Großteil des Codes, den wir gefunden haben, hätte vor einem Jahrzehnt geschrieben werden können. Wenn neue Technik ausreichend genutzt wird, um in diesen Statistiken aufzutauchen, dann oft weil der Haupttreiber eine beliebte Bibliothek oder ein beliebtes Framework ist. Effektiverweise bauen wir (Leute von Standards, Browser-Implementierer etc.) Technik für Tooling-Autoren, die diejenigen sind, die wirklich Technik für den durchschnittlichen Webentwickler bauen. Eine ziemliche Perspektive-Verschiebung, nicht wahr?
Diese Art von Daten ist ein Palliativ für all die Hochstapler da draußen, die gezwungen sind, jedes neue Feature und jede neue API zu studieren, sonst fühlen sie sich wertlos.
Danke. Das ist beruhigend.
Deshalb war der IE so schwer totzukriegen, obwohl wir dachten, niemand benutzt ihn. Da wir seit den Anfängen des Internets in der Technik sind, vergessen wir, wie es sich anfühlt, nicht technisch zu sein.
& WP nutzt jQuery, ich betreibe mein Geschäft mit WP, Perl, React usw...
Ich brauche immer noch Zeit, um meine Websites umzustellen, kürzlich habe ich WP als Headless-Backend mit React zu nutzen begonnen.
Das überrascht mich überhaupt nicht. Wenn man "mit der Fachliteratur auf dem Laufenden" bleiben muss, täglich Artikel von Ihnen, Chris Coyier, Šime Vidas usw. liest, ist es auch für erfahrene Entwickler leicht, sich in der Fülle der "neuen" Webtechnologien zu verlieren, die ständig auftauchen. Coyier zum Beispiel scheint seinen Jamstack, Eleventy und was weiß ich sehr zu mögen. Und das zu Recht, verstehen Sie mich nicht falsch! Weil Sie Jungs jeden Tag neue Dinge zum Schreiben finden müssen.
Aber vergessen wir nicht, dass Entwickler wie ich, die knapp unterhalb der Top-Experten operieren, sich mit Old-School-CMS und "Technologien von gestern" beschäftigen, die immer noch die Mehrheit der Websites im Web antreiben.
Genau! Ich arbeite im Non-Profit-Bereich und dort ist es durchweg WordPress, einschließlich Kinsta, Cloudflare, Wordfence & LetsEncrypt. Ich nutze GIT & Terminal für die armen Seelen auf Pantheon mit seiner langen Liste von Plugins mit "Problemen". Ich mag den neuen Editor X von Wix, aber nicht Wix selbst... Selbst WP ist für Joe Sixpack zu herausfordernd. Diese Organisationen brauchen, ob sie es wissen oder nicht, immer noch einen Webmaster.
Dieser Kommentar ist perfekt auf den Punkt. Was viele von uns Entwicklern oft vergessen, ist, dass wir zwar von neuen Technologien und besseren Vorgehensweisen begeistert sind, unsere Kunden aber die Endnutzer, die Laien, denen es egal ist, ob Sie React, JAMStack, Svelte, Laravel oder .Net verwenden.
Ihnen ist wichtig, dass die Website gut aussieht und ihre Geschäftskunden erreicht.
Ich neige dazu, Artikel zu ignorieren, die eine Programmiersprache oder ein Framework über ein anderes preisen. Ehrlich gesagt, bauen Sie Ihre Website aus Sand, wenn Sie wollen, solange sie gut gestaltet ist, hervorragend funktioniert und einfache und reibungslose Bearbeitungen ermöglicht.
Angular, React und Webkomponenten… Ich habe diese in den letzten vier Jahren zur Erstellung von Webanwendungen verwendet.
Ich habe sie nicht für Websites verwendet. Ich bin jedoch versucht, Next.js als statischen Website-Generator zu verwenden.
So wahr.
Außerdem sind die meisten stabilen Server/Dienste entweder PHP- oder .NET-basiert… Viel weniger sind sogar Node.js. Dafür gibt es eine völlig gute, einfache Erklärung....
Wenn man eine Blume aus dem Garten pflücken will… Man benutzt seine Hände, keinen Panzer.
Angular zum Erstellen einer Webseite zu verwenden, ist in jeder Hinsicht schlecht.
Ein Framework zum Schreiben von SQL-Abfragen zu verwenden, ist idiotisch… Benutzen Sie SQL.
Ich habe so viele Projekte gesehen, die nur "Projekte" genannt werden, weil niemand der Beteiligten etwas von den Grundbedürfnissen des Kunden wusste und seine Wünsche mit dem löste, was er kannte, anstatt dem, was der Kunde brauchte.
Frameworks, die für einfache SQL-Abfragen verwendet werden….
Frameworks, die verwendet werden, um eine einfache Tabelle zu erstellen und Ihre Werte darin einzufügen…
Frameworks, die für einfache JS-Bedürfnisse verwendet werden… Wie das Hinzufügen von Buttons und/oder Elementen im DOM.
jQuery ist großartig und macht JS extrem einfach.
TypeScript lässt Sie WISSEN, dass Sie JS und DOM nicht verstehen.
Lernen Sie HTML, es ist ziemlich einfach.
Lernen Sie CSS, das ist das Ende von HTML, keine andere Sache!!!!
Lernen Sie reines JS, denn es ist heute erstaunlich einfach.
Möchten Sie etwas mehr sein?!
Lernen Sie PHP oder NODE.JS, um das Backend Ihres Frontends zu steuern.
Vor allem aber… Verstehen Sie, dass es zwei Seiten gibt, mit so viel für jede…
Frontend – kein Angular/React oder irgendeines dieser beschissenen, schlechten Frameworks wird Ihnen helfen, das Backend zu verstehen, noch werden sie Ihnen helfen, eines zu bauen.
Backend – kein Angular/React oder irgendeines dieser beschissenen, schlechten Frameworks wird Ihnen helfen, das Frontend zu verstehen, noch wird es Ihnen helfen, eines zu bauen.
Um einen Kreis auf Papier zu zeichnen, benutzen Sie einen Bleistift auf Papier.
Üben Sie, später können Sie einen Stift verwenden.
Einen Stift vorher zu benutzen, mag funktionieren… Aber Sie werden nicht gelernt haben
alle Fähigkeiten eines Bleistifts….
Als Webentwickler im Einsatz (im Einsatz im Web?) kann ich bestätigen, dass die Prioritäten der Leute, die mein Gehalt bezahlen, sind: Funktioniert es, funktioniert das Zeug, das wir vor 15 Jahren geschrieben haben, noch, und können wir diese 3 neuen Features bis Freitag haben? Ich kann bei meinem Hauptjob nicht mit der neuesten Technik bauen. Wenn etwas stabil/unterstützt genug wird, um es zu nutzen, bin ich unglaublich dankbar für die Leute, die Zeit investiert haben, um darüber nachzudenken, zu schreiben und Demos zu erstellen. Wenn bei einer Google-Suche nur ein Spezifikationsdokument herauskäme, würden wir wahrscheinlich nie etwas Neues implementieren. Das Web der Zukunft dankt Ihnen.
Das ist großartig. Für ein kurzes Stück sagt es so viel. Ich finde es faszinierend, dass nur 4% des Webs auf React laufen, und doch könnte man denken, es seien 96%, basierend auf den dortigen Stellenangeboten.
Frontend-Angebote drehen sich so oft um die neuesten Sachen, wenn viele Unternehmen Leute brauchen könnten, die sich der Unterstützung der aktuellen/Legacy-Technik widmen.
Es kann auch sein, dass viele Stellenangebote sich um die Entwicklung interner Geschäftsanwendungen oder B2B-Cloud-/On-Premise-Apps handeln, die normalerweise nicht direkt in Suchmaschinenergebnissen aufgeführt werden.
Diese Anwendungen sind oft der richtige Anwendungsfall für die intensive Nutzung von Frameworks. Ich habe 11 Jahre als Frontend-Entwickler gearbeitet, mehrere Bibliotheken und Frameworks (JQuery, ExtJs, Backbone.js, AngularJS, React, Angular) verwendet und musste mich nie um SEO kümmern, da das Produkt nicht in Suchmaschinen gelistet war.
Es gibt ein ganzes verborgenes Web hinter dem Web.
Als jemand, der es mag, über die neuen Dinge zu lesen (und sie teilweise zu verstehen), aber am Ende PHP, MySQL und Vanilla JS verwendet, sind das Musik in meinen Ohren.
Lang lebe die Ludditen.
Houdini schien mir immer ein Wunschtraum zu sein.
Oder eine Art Trickerei?
Diese Ergebnisse sind überhaupt nicht überraschend.
Ich habe bisher keinen einzigen überzeugenden realen Anwendungsfall für statische Website-Generatoren gesehen, und Worker fallen oft in die Kategorie "cool, aber unnötig". Sicher, die meisten Entwicklerseiten reden gerne über Jamstack, aber die mangelnde Akzeptanz in der Wirtschaft/im Unternehmensbereich zeigt, dass es vielleicht nicht die erstaunliche Neuerung ist, für die viele Entwickler sie halten.
In der Zwischenzeit sind WordPress und jQuery weiterhin sowohl leicht zu erlernen als auch hoch erweiterbar und behalten ihre Popularität bei neuen und erfahrenen Entwicklern gleichermaßen.
Einen einzigen überzeugenden realen Anwendungsfall für statische Website-Generatoren? Es ist der einfachste Weg, eine Website manuell zu erstellen. Ich bin mir nicht sicher, wie Sie diesen ziemlich wichtigen Anwendungsfall übersehen haben.
Haha, nur wenn man sich Statistiken auf diese Weise ansieht, ist es richtig. Es ist, als ob eines Tages eine außerirdische Spezies die Erde besuchen, die gesamte Bevölkerung betrachten und erklären würde, dass es nur zwei Geschlechter gibt.
Wenn wir uns so auf Statistiken versteifen, sollten wir Entwickler uns eigentlich auf die Top-500-Websites im Internet konzentrieren, die den größten Teil des Umsatzes generieren, und mit diesen Tech-Stacks im Einklang bleiben.
Es gibt keinen Grund, ein Projekt mit den neuesten Frameworks zu überkomplizieren, wir sollten das richtige Werkzeug für den Job verwenden.
Die meisten Unternehmen, insbesondere die gerade erst anfangen, werden Ihnen keine 50.000 Dollar zahlen, um ihnen eine benutzerdefinierte Website auf Laravel, Vue.js oder was auch immer nächsten Monat herauskommt, zu bauen.
„Es ist, als ob eines Tages eine außerirdische Spezies die Erde besuchen, die gesamte Bevölkerung betrachten und erklären würde, dass es nur zwei Geschlechter gibt.“
Und sie hätten Recht für über 99 % der Menschheit. Kein gutes Beispiel. ;)
Ich lerne und nutze neuere Tech-Tools für lustige Nebenprojekte. Aber für die Arbeit erwartet mein Arbeitgeber Stabilität, breite Unterstützung, Wartbarkeit und schnelle Lieferung – jQuery eignet sich für all das ziemlich gut. :)
Als unerschrockener WP/JQ-Typ liebe ich das. Entwickler wie ich erledigen Dinge für Kunden, die Dinge erledigt haben müssen, und der Kunde kümmert sich im Allgemeinen nicht darum, woraus Sie es erstellt haben, solange das Geschäftsziel erreicht wird.
Ich glaube, der von Ihnen festgestellte Verlust der Perspektive entsteht hauptsächlich dadurch, dass Webentwickler-Foren und Konferenzen von einer überwältigenden Mehrheit von Unternehmensentwicklern bevölkert werden, die eine spezifische, zielgerichtete Aufgabe zu erfüllen haben. Als Freelancer greife ich, wenn ich jemanden für die Unterstützung eines Projekts benötige, fast immer auf einen anderen Freelancer zurück. Hauptsächlich, weil sie dazu neigen, die Flexibilität und die "Lass es uns erledigen"-Mentalität zu haben, anstatt ständig zu versuchen, neue Technik einzubringen.
Zu all diesen Dingen kommt hinzu, dass es definitiv etwas für Websites gibt – insbesondere für Websites kleiner Unternehmen jeglicher Art –, um eine einfache Kontinuität der Entwicklung zu gewährleisten. Wenn ein Unternehmen gutes Geld für eine Website ausgibt und der Entwickler oder die Agentur aus irgendeinem Grund aus dem Bild verschwindet, viel Glück, jemanden zu finden, der tatsächlich verfügbar, erschwinglich und zuverlässig für einzelne Projekte ist, um an Ihrer CSS-in-JS/React/Houdini/Flavor-of-the-Moment-Website zu arbeiten.
Ich bevorzuge die lösungsbasierte Herangehensweise. Es gibt keinen Grund, ein Projekt mit den neuesten Frameworks zu überkomplizieren, es sei denn, sie werden tatsächlich benötigt.
Das sind interessante Statistiken, und ich habe vor etwa einem Jahr argumentiert, dass das Bootcamp, an dem ich nebenberuflich unterrichte, MongoDB aufgeben und stattdessen MySQL lehren sollte, aus diesem Grund.
Es wäre interessant zu sehen, wie sich die Zahlen ändern würden, wenn man sie anhand des Webverkehrs verfolgen würde. Dinge wie React, PWAs und statische Generatoren könnten mehr Präsenz haben… In großem Maßstab sind sie dafür konzipiert, zu glänzen.
Einige gute Punkte wurden hier gemacht, insbesondere in Bezug auf die Verwendung von WordPress.
Aus meiner Erfahrung bei der Arbeit an Websites komme ich immer zu einem Satz von Werkzeugen, die für ein Projekt funktionieren. Eines davon ist ein Page Builder, der die Arbeit erledigt. Wie wir alle wissen, sind diese oft nicht der letzte Schrei für viele.
In Anbetracht dessen wurde mir oft vorgeschlagen, ein neues schickes Framework zu lernen. Es beginnt interessant, wird aber bald zur Plackerei. Oft schaue ich dann heimlich auf die Arbeit desjenigen, der diesen Weg vorgeschlagen hat, und sehe sehr rudimentäre Ergebnisse. Es ist, als ob die gesamte Gehirnenergie in die Implementierung des Codes geflossen ist und nicht viel für das Design übrig geblieben ist.
Verstehen Sie mich nicht falsch, ich bin sicher, dass in den richtigen geschickten Händen diese Frameworks ein Kunstwerk hervorbringen werden.
Ich sehe diese Art von Entwickler-/Framework-Schwäche im Weg, der mit dem Block-Editor in WordPress eingeschlagen wird. Der Block-Editor selbst, obwohl für viele umstritten, wird tatsächlich sehr nützlich und angenehm zu bedienen. Das Problem ist, dass der Fokus auf Full Site Editing die falsche Priorität ist, während andere Dinge übersehen werden. Zum Beispiel der Anwendungsfall der Dateneingabe, bei dem Sie im Backend ein einfaches Formular anzeigen möchten, um Daten zu erfassen, die in eine Frontend-Vorlage interpoliert werden. Sie möchten dem Benutzer keinen Freiformmechanismus für die Inhaltserstellung in Form des Block-Editors präsentieren. Damit lenken Sie den Benutzer/Kunden nur ab. Die Implementierung der Option, die Block-Editor-Oberfläche zu deaktivieren und Metaboxen mit benutzerdefinierten Feldern zu belassen, sollte mit einem einfachen Update im WordPress-Core für Beitragstypen einfach umzusetzen sein.
Der andere Fehler beim Block-Editor ist, dass er Drittanbietern ermöglicht, jeden erdenklichen Schweizer Taschenmesser-Block zu erstellen. Es wurde beobachtet, dass dies zu Bloat bei Installationen und der versehentlichen Entfernung dieser Blöcke führen kann, was eine Brutstätte für verwaisten Code ist, den der nächste Entwickler/Benutzer entschlüsseln muss.
Es wäre vielleicht förderlicher für Best Practices gewesen, wenn der Block-Editor eine Reihe von Standardblöcken für Elemente und Layouts mit einer API präsentiert hätte, in die Drittanbieter ihre eigenen Extras und Benutzeroberflächen einhaken könnten. Alle Page Builder würden sich dann daran halten. Schalten Sie den Page Builder/Theme aus oder ändern Sie ihn, und zumindest bleiben Ihr Inhalt und Ihr Layout in einem vernünftigen Zustand zurück. Das erledigt die Arbeit.
Was wir bei dem Team am Block-Editor sehen, ist viel Enthusiasmus für den Code, mit dem sie arbeiten, aber nicht genug für die Endanwendungsfälle.
Zurück zur Dateneingabe würde man sich fragen, was Automattics Plan für WooCommerce ist, angesichts der Tatsache, dass es immer noch im klassischen Bereich lebt, der bald eingestellt werden soll.
@Keith Kritselis fügte einen Punkt hinzu, der von den Erstellern in die Statistiken hätte aufgenommen werden sollen: Webseitenverkehr.
Das schließt den Kreis zur lösungsbasierten Herangehensweise, die jeder andere Kommentator erwähnt hat. Riesige Websites/Apps, die von großen Teams unterstützt werden, benötigen andere Technik als das Café um die Ecke.
Ich liebe jQuery, es bietet eine brillante Möglichkeit, in die JS-Entwicklung einzusteigen und vereinfacht so viele Aufgaben.
Ja, Vanilla JS mag schneller sein und den Ballast entfernen, aber meiner Erfahrung nach liegen Leistungsprobleme bei Geschäftsanwendungen am serverseitigen Code. Wenn ich wählen müsste, wo ich meine Bemühungen zur Leistungssteigerung fokussieren soll, dann sicher nicht beim Austauschen von jQuery gegen Vanilla JS.
Es geht nicht nur um die Anwendungsleistung, die wir berücksichtigen müssen, sondern auch um die Leistung des Entwicklers.
Das ist cool zu verifizieren, aber auch nicht überraschend. Die Frage ist, ob man "Website" als Grundlage für seine Metrik nimmt oder etwas Greifbareres wie Webverkehr oder erzielten Umsatz.
Ich wette, weltweit nutzen 4% der "Bauern" Robotik und Automatisierung, aber sie produzieren 99% der Welternährung.
React wird nur von 4% der Websites verwendet, aber welchen Anteil des Markttraffics erhalten diese Websites? Und können sie neue Ideen leichter umsetzen, weil sie React anstelle von jQuery verwenden?
Alex, dein Punkt ist auch gültig. Ich habe React einmal ausprobiert, muss aber nicht wirklich verstehen, wie es funktioniert, weil der Page Builder auf meiner Website es im Hintergrund verwendet; React ist für mich eine gekapselte Entität.
Es ist ein bisschen wie Matt Mullenwegs Aussage, dass wir JavaScript tief lernen müssen, um jetzt WordPress zu nutzen. Eine leichte Übertreibung für eine Menge Benutzer der Plattform. Ich beschäftige mich sowohl mit JS als auch mit jQuery, aber nach Bedarf, wenn es erforderlich ist. Das ist genug Tiefe für die Websites, die ich für Kunden baue, die ein Budget haben.
WordPress betreibt 30% des öffentlichen Webs. 83% der öffentlichen Apps nutzen jQuery. Es gibt viel Wiederverwendung für dieselbe Technik immer und immer wieder (was gut ist).
SPAs werden jedoch mehr hinter Authentifizierung und Logins verwendet.
Auch wenn dies einige Zahlen relativieren mag, haben Sie definitiv einen Punkt.
Ich hatte denselben ersten Eindruck, aber tatsächlich müssen wir uns diese Statistiken etwas genauer ansehen
1. Es werden alle Websites gezählt, nicht die Websites, die im letzten Jahr erstellt wurden
2. Umsatzgenerierende Unternehmen wie Amazon, Facebook, Google usw. schließen ihre Seiten von der Archivierungsroboteranalyse aus.
3. Diese Unternehmen bezahlen die Arbeit, die Frontend-Entwickler leisten. Die meisten Websites aus der Statistik werden kostenlos erstellt. Also unterschiedliche Werkzeuge für unterschiedliche Märkte, was sorgfältig interpretiert werden sollte.
Ich dachte wirklich, die Welt sei weiter fortgeschritten als das ;-)
WordPress 83%? Was zum Teufel. Ich benutze seit Ewigkeiten statische Website-Generatoren. Bin gerade von Middleman zu Gatsby gewechselt (werde nie zurückblicken). Benutze auch seit langem ein Headless CMS. Es gibt so viel Freude an einer gut verpackten Website mit guten Leistungseigenschaften.
Aber fairerweise… es ist etwas schwieriger, Gatsby/React zu meistern, als ein paar Menüs in WordPress zu klicken. Das ist also höchstwahrscheinlich der Grund, warum die Zahlen so sind, wie sie sind.
marc
„Niemand benutzt mehr jQuery, oder? Falsch. Es kommt auf 83% aller Websites vor!“
„Vorkommen“ und „benutzen“ sind zwei verschiedene Dinge. :)
jQuery ist tot. Der Leichnam ist noch da.
Toller Artikel und Kommentare ^^^ oben! Es ist schön zu wissen, dass meine Intuition und Erfahrung mit den Kommentaren so vieler erfahrener Webentwickler, aber auch mit den Statistiken übereinstimmen.
Nach Überprüfung aller neuen Website-Daten von 2020 im Web Almanac ist offensichtlich, dass die jungen Leute, die in diesen Beruf einsteigen, das Web nicht über neue Scripting-Frameworks und Toolsets verbessern, wie sie behaupten.
Die Tatsache, dass diese statischen JavaScript-Pakete für Seiten mittlerweile Skripte von durchschnittlich über 500 Kilobytes mit Thread-Zeiten von 800-8.000 Millisekunden auf ihren kleinen CPUs in unsere Handybrowser schieben, ist Wahnsinn!! Jede Anwendung benötigt also ein Megabyte an Skripten, um etwas Text auszudrucken? Der anhaltende Trend ist auch, grundlegendes CSS und HTML zu modernisieren, zu minimieren, vorzuverarbeiten und mit Polyfills zu versehen, deren Fußabdrücke bereits klein sind, und dann aber Megabytes von ECMAScript-Skripten herunterzuladen? Das erscheint bestenfalls kontraintuitiv!
Der ganze Sinn des Webs vor 20 Jahren war es, WEG von schweren Client-seitigen Anwendungen mit dicken Scripting-Abhängigkeiten und harter CPU-Belastung zu kommen und auf das leichtgewichtige Servermodell umzusteigen, wo winzige HTML-Schnipsel an den Browser gesendet und zwischengespeichert wurden. Content war früher König, nicht Skripte.
Die letzten 10 Jahre sind die jungen Leute zum alten Desktop-Modell zurückgekehrt, aber mobil mit JavaScript! Kein Wunder, dass es keine breite Akzeptanz gibt. Und ich prognostiziere, dass es keine geben wird. Wenn man sich die Statistiken ansieht, sollten wir alle erkennen, dass "alt" wieder "neu" wird. Einfache Server, die winzige Seiten mit HTML und CSS senden, sind nicht nur bandbreitenschonend, sondern auch blitzschnell. Sie existieren seit fast 30 Jahren ohne Probleme! Warum sollte man einem armen Mobilnutzer ein Megabyte an Skripten aufzwingen? Ich glaube ehrlich, die Statistiken von 2020 lehren uns, dass die Coder in Unternehmen und diejenigen, die an WordPress und älteren Frameworks festhalten, immer noch keine Geschwindigkeitsprobleme haben, keine neuen Webtools oder -modelle brauchen oder Entwicklungsschwierigkeiten haben. Ja, JQuery, PHP und .NET funktionieren immer noch und sind zuverlässig. Das ursprüngliche World Wide Web hat sich nicht verändert. HTML und CSS und Server treiben immer noch den Großteil dessen an, was online ist. Traurigerweise beweist dies, was wir vor Jahren wussten, dass "JavaScript immer noch böse ist". Und das kommt von einem Angular-Experten.
Diese neuen, schweren Client-seitigen Frameworks haben ihren Platz, verstehen Sie mich nicht falsch. In Intranets haben sie sich an den Orten, an denen ich sie verwendet habe, als hilfreich erwiesen. Aber sie sind nicht besser als eine ältere Entwicklungslösung, auf die sich ein Unternehmen heute verlässt, um eine einfache HTML-Seite mit Informationen zu liefern, die von Millionen von Menschen konsumiert werden.
Ich hoffe aufrichtig, dass die Jugend hier, die versucht, das Rad neu zu erfinden, indem sie all diese gescripteten Open-Source-Märchen-Lösungen entwickelt, versteht, dass das Web nicht kaputt war, bevor Sie mit JavaScript angefangen haben zu spielen! Sie hatten einfach nicht die Disziplin (oder das Mentoring), um zu verstehen, wie es immer funktioniert hat, bevor Sie Ihre eigenen Kaninchenlöcher gegraben haben. Aber graben Sie weiter!!