Vor kurzem wurde ich gebeten, eine kleine Sitzung dazu zu halten. Ich würde sagen, ich bin für die Beantwortung dieser Frage nicht qualifiziert, genauso wie jede einzelne Person. Wenn Sie wirklich fundierte Antworten auf diese Frage benötigen, würden Sie wahrscheinlich aggregierte Daten aus Umfrageergebnissen vieler Entwickler heranziehen.
Ich bin jedoch *ein wenig* qualifiziert. Abgesehen davon, dass ich diese Seite betreibe, was erfordert, dass ich jeden Tag über Frontend-Entwicklung nachdenke und mich mit vielen Gesprächen über Frontend-Entwicklung beschäftige, bin ich selbst ein aktiver Entwickler. Ich arbeite bei CodePen, das ein ziemlicher Tummelplatz für Frontend-Entwickler ist. Außerdem spreche ich jede Woche im ShopTalk Show mit einer Vielzahl von Gästen darüber und reise auf Konferenzen, die sich größtenteils auf Frontend-Entwicklung konzentrieren.
Also lassen Sie mich einen Versuch wagen.
Nochmal, Haftungsausschlüsse
- Dies ist nicht umfassend
- Dies sind nur lose Vermutungen
- Ich bin nur ein Kerl
Benutzererwartungen steigen.
Dies ebnet den Weg
Die Anforderungen an Websites steigen. Entwickler werden gebeten, sehr komplizierte Dinge sehr schnell zu bauen und sicherzustellen, dass sie sehr gut und sehr schnell funktionieren.
Neues JavaScript ist da.
So fabelhaft jQuery für uns auch war, für neue Entwicklungen ist es vorbei. Und ich meine nicht nur, dass uns ES6+ jetzt zur Verfügung steht, obwohl das stimmt. Wir haben uns damit in Schwierigkeiten gebracht, indem wir zu direkt mit dem DOM gearbeitet und es wie einen Datenspeicher behandelt haben. Wie ich anfangs sagte, steigen die Erwartungen der Benutzer und damit die Komplexität. Wir müssen diese Komplexität bewältigen.
State ist das große Konzept, wie wir besprochen haben. Websites werden durch die Überlegung gebaut, welcher State verwaltet werden muss, und dann werden die richtigen Stores für diesen State erstellt.
Die neuen Frameworks sind da. Ember, React, Vue, Angular, Svelte, was auch immer. Sie unterstützen die Idee, mit State, Komponenten zu arbeiten und das DOM für uns zu verwalten.
Jetzt können sie in Bezug auf Geschwindigkeit, Funktionen und API-Schönheit konkurrieren.
TypeScript scheint ebenfalls ein langfristiger Gewinner zu sein, da es mit allem kompatibel ist und Stabilität sowie eine bessere Editor-Erfahrung für Entwickler bietet.
Wir bauen keine Seiten, wir bauen Systeme.
Styleguides. Designsysteme. Pattern Libraries. Diese Dinge werden zu einem Standardbestandteil von Webprojekten. Sie werden wahrscheinlich zum Hauptergebnis. Ein System kann alles Notwendige erstellen. Das Konzept der „Seiten“ verschwindet. Komponenten werden zusammengesetzt, um das zu erstellen, was Benutzer sehen. Dieses Zusammensetzen kann von UX-Experten, Interaktionsdesignern, sogar vom Marketing übernommen werden.
Neues JavaScript unterstützt dies sehr gut.
Die Grenze zwischen Native und Web verschwimmt.
Was ist besser, Sketch oder Figma? Wir beurteilen sie nach ihren Funktionen, nicht danach, dass die eine eine native App und die andere eine Web-App ist. Sollte ich die native Slack-App oder TweetDeck-App verwenden oder einfach einen Tab öffnen? Es ist sowieso identisch. Manchmal ist eine Web-App so gut, dass ich wünschte, sie wäre nativ, nur damit sie ein Symbol in meinem Dock hat und eine persistente Anmeldung bietet, daher verwende ich Dinge wie Mailplane für Gmail und Paws für Trello.
Ich benutze regelmäßig Apps, die meiner Meinung nach native Apps sein müssten, aber sich als genauso gut oder besser im Web erweisen. Allein wenn man sich Audio-/Video-Apps ansieht: Skype hat eine voll funktionsfähige App, Lightstream ist ein vollwertiges Livestreaming-Studio und Zencaster kann mehrspurige hochwertige Audioaufnahmen machen. All das geschieht direkt im Browser.
Das sind nur Beispiele für *gute Arbeit* im Web. Die Webtechnologie selbst macht hier ebenfalls enorme Fortschritte. Service Worker geben uns wichtige Dinge wie Offline-Fähigkeit und Push-Benachrichtigungen. Web Audio API. Web Payments API. Das Web sollte die dominante Plattform für den Aufbau von Apps werden.
Benutzer werden Dinge nutzen, die gut sind, und nicht überlegen oder sich darum kümmern, wie sie erstellt wurden.
URLs sind immer noch ein Killer-Feature.
Das Web hat das wirklich gut hinbekommen. Eine universelle Möglichkeit zu haben, direkt zu einer bestimmten Sache zu springen, ist unglaublich. URLs machen Suchmaschinen möglich, möglicherweise eine der wichtigsten menschlichen Erfindungen überhaupt. URLs machen das Teilen und Lesezeichensetzen möglich. URLs sind eine faire Spielwiese für Marketing. Jeder kann eine URL besuchen, es gibt keinen Gatekeeper.
Leistung ist ein wichtiger Faktor.
Die Toleranz für schlecht funktionierende Websites wird sinken. Jeder wird erwarten, dass alles nahezu sofort funktioniert. Seiten, die das nicht tun, werden peinlich sein.
CSS wird viel modularer werden.
Wenn wir Stile schreiben, werden wir immer eine Wahl treffen. Sind das globale Stile? Lecke ich absichtlich diesen Stil über die gesamte Website? Oder schreibe ich CSS, das spezifisch für diese Komponente ist? CSS wird zwischen diesen beiden geteilt. Komponentenspezifische Stile werden gekapselt und mit der Komponente gebündelt und bei Bedarf verwendet.
CSS-Präprozessoren werden langsam verschwinden.
Viele der Killer-Funktionen von Präprozessoren haben es bereits in CSS (Variablen) geschafft oder können besser durch fortgeschrittenere Build-Prozesse (Imports) gehandhabt werden. Die Werkzeuge, die wir letztendlich zur Modularisierung und Kapselung unseres CSS verwenden werden, sind immer noch, in gewisser Weise, CSS-Präprozessoren, sodass sie die Arbeit der verbleibenden Notwendigkeit der Präprozessoren übernehmen könnten. Von den Standard-Präprozessoren der aktuellen Generation denke ich, dass wir am meisten Mixins vermissen werden. Wenn natives CSS Mixins (@apply) und Extends (@extend) implementieren würde, würde dies die Abschaffung der heutigen Präprozessoren beschleunigen.
Gut in HTML und CSS zu sein, bleibt entscheidend.
Die Art und Weise, wie HTML aufgebaut wird und wie es im DOM landet, wird sich weiter ändern. Aber Sie müssen immer noch wissen, wie gutes HTML aussieht. Sie müssen wissen, wie Sie HTML so strukturieren, dass es für Sie nützlich, für Benutzer zugänglich und für die Gestaltung geeignet ist.
Die Art und Weise, wie CSS im Browser landet und wie es angewendet wird, wird sich weiter ändern, aber Sie müssen immer noch wissen, wie man es benutzt. Sie müssen wissen, wie Sie Layouts erstellen, Abstände verwalten, Typografie anpassen und geschmackvoll sein, wie wir es immer getan haben.
Build-Prozesse werden wettbewerbsfähig.
Da die Leistung so wichtig ist und es so viele Möglichkeiten gibt, klug mit der Leistung umzugehen, werden wir Innovationen bei der Bereitstellung unserer Codebasen für die Produktion sehen. Tools wie webpack (Tree Shaking, Code Splitting) leisten hier bereits viel, aber es gibt noch viel Raum, damit automatisierte Tools Magie auf die Auslieferung unseres Codes an Browser wirken. Optimierung der ersten Ladevorgänge. Auslieferung von Assets in der Reihenfolge ihrer Kritikalität. Entscheidung, was wohin und wie gesendet wird. Nichts wird ausgeliefert, was nicht verwendet wird.
Mit der Weiterentwicklung der Webplattform (z. B. Client Hints) werden sich die Build-Prozesse und Best Practices wie immer weiterentwickeln.
du sagtest
Das Konzept der „Seiten“ verschwindet.
dann sagtest du, bezüglich URLs
Eine universelle Möglichkeit zu haben, direkt zu einer bestimmten Sache zu springen, ist unglaublich.
wenn Seiten verschwinden, springen wir wohin?
Einige Kompositionen von Komponenten. Wenn Sie das eine „Seite“ nennen möchten, in Ordnung, aber ich denke, Sie wissen, was ich meine. Jede Ansicht ist keine fest verankerte Photoshop-Komposition mehr, die ins Web gebracht wird (und so abgerechnet wird), insbesondere im Hinblick auf die Zukunft.
Wenn man diese Idee etwas erweitert, kann man sehen, wie eine URL zu einem Identifikator für den State werden könnte. Wenn der State die Komposition von Komponenten definiert und URLs per Prinzip auf ein bestimmtes Stück Information verweisen müssen.
In der Abstraktion können Sie es als „Knoten“ (gemäß Elements of UX von JJG) oder als „Ansicht“ bezeichnen.
Ich glaube, das grundlegende Ziel des Webs ist es, Informationen zu teilen.
Ich stelle fest, dass Menschen auf ihren Handys hauptsächlich Informationen konsumieren (abgesehen vom Teilen von Bildern und kleinen Kommentaren).
Menschen an ihren Schreibtischen erstellen hauptsächlich Inhalte.
Abhängig von Ihrem Kontext können Sie Ihre Terminologie zwischen Seiten und Ansichten ändern.
Per Definition ist eine Seite durchsuchbar, während die Suche nach einer Ansicht keinen Sinn ergibt. Daher ist der HTML/CSS-Code, den Sie für jeden tendenziell produzieren, unterschiedlich.
Ich denke, die meisten Ihrer oben genannten Punkte gelten für Webanwendungen.
Sie springen zu einem bestimmten Zustand des Erlebnisses. Soll es eine statische seitenähnliche Benutzeroberfläche oder ein Zustand einer Online-Anwendung sein. Der Punkt ist, dass Sie keine Sache (=== Seite) als Lesezeichen speichern, sondern Informationen (=== State), die Sie später in Ihrem Browser wiederherstellen möchten.
Wir werden zu einer Ressource springen. Die Ressource muss keine Seite sein. Ich denke, das ist es, was gemeint ist. :)
Ich denke, Chris spricht von einer RESTful-URL-Struktur, bei der der Zustand eines Systems in der URL dargestellt wird. Das ist tatsächlich eine sehr gute Praxis.
Schauen Sie sich https://www.slideshare.net/landlessness/teach-a-dog-to-rest für einige sehr interessante Einblicke und Heuristiken an.
Tolle Frage. Ich persönlich liebe, wie PJAX in all das passt: Erstellen Sie eine flache CSS + HTML-Website, und dann handhabt JavaScript das dynamische Laden des Inhalts, während die URL und der Verlauf aktualisiert werden. Schauen Sie sich Barba.js an!
Guter Punkt! Danke für die Tipps
Die „System“-Obsession schadet vielen Projekten/Menschen, finde ich. Es macht Spaß, mit Spielzeug zu spielen, aber irgendwann muss man realistisch sein, was man liefert.
Wenn Sie *eine sichtbare Webseite* erstellen, brauchen Sie wahrscheinlich kein System. Sie brauchen wahrscheinlich eine HTML-Datei und eine CSS-Datei.
Ich denke, der Punkt ist, dass man nicht jedes Mal ein System bauen sollte, wenn man eine Seite baut. Das ist, als würde man jedes Mal das Rad neu erfinden, wenn man ein Fahrrad bauen will.
Die „Systeme“ sollten da sein, um sie jedes Mal zu nutzen, wenn man eine sichtbare Webseite liefern muss, und für wie viele Male Sie oder jemand anderes diese Webseite mit Überarbeitungen, Änderungen, Aktualisierungen usw. neu liefert.
Es ist die ultimative Demokratisierung des Webs für alle und geschieht seit Jahren (siehe jedes CMS, jede GUI oder jeden Site-Builder, die es je gab).
So wie Squarespace und ähnliche Unternehmen die Gestaltung und Entwicklung von grundlegenden Websites durch Templating verwalten, wird es neue Produkte geben, die dies für komplexere SaaS-Produkte tun. Ich denke, wir steuern auf eine Zukunft zu, in der es Designer und UI-Ingenieure gibt, die in einer GUI arbeiten, und Software-Ingenieure, die die Dinge bauen, die die Dinge bauen.
Ich bin also anderer Meinung als die Schlussfolgerung, dass HTML- und CSS-Kenntnisse lebenswichtig sein werden (langfristig betrachtet), aber ein Designgefühl. Es wird wahrscheinlich weniger Bedarf an hybriden Designer/Entwicklern geben, da die Notwendigkeit für diese Art von Fähigkeiten abnimmt, wenn die UI-Schicht abstrahiert wird. Ingenieure müssen spezialisierter sein, um die Komplexität der Arbeit an Dingen wie KI und massiven vernetzten Infrastrukturen im großen Maßstab zu verstehen.
Du hast geschrieben
„Benutzererwartungen steigen.“ und
„Was Websites tun sollen, steigt. Entwickler werden gebeten, sehr komplizierte Dinge sehr schnell zu bauen und sicherzustellen, dass sie sehr gut und sehr schnell funktionieren.“
Ich glaube nicht, dass *Benutzer* all dies verlangen. Kunden denken vielleicht, dass Benutzer skriptlastige Multifunktions„Systeme“ wollen, aber ich bezweifle, dass dies auf empirischen Beweisen beruht.
Ich möchte einfach eine Nachricht lesen oder etwas nachschlagen. Ich möchte keine ausgefallenen Ausklappmenüs, sich verformenden Videofenster und Dutzende von skriptbasierten Tracking-Widgets. Ich wette, das wollen Leute.
Gah! Ich meinte „Ich wette, nur wenige Leute wollen das.“
Sie denken an die falschen Dinge.
Vor Jahren fanden Sie zum Beispiel beim Betrachten einer Website zum Kauf von Konzertkarten vielleicht Informationen, um die Abendkasse anzurufen. Jetzt erwarten Sie jedoch Sitzpläne, Echtzeitdaten über verfügbare Plätze und die Möglichkeit, auf der Website auszuchecken.
Vor Jahren ließ Sie Ihre Bank vielleicht einloggen und Ihren Kontostand sehen, aber jetzt möchten Sie die Posten durchsuchen und nach Datum filtern, oder sofortige Guthabenüberweisungen zwischen Ihrem Spar- und Girokonto vornehmen, eine neue Debitkarte bestellen, in Echtzeit mit jemandem chatten, der Ihnen *erklären* kann, warum eine bestimmte Gebühr abgelehnt wurde, usw.
Das ist die Art von Komplexität, an die Chris wahrscheinlich gedacht hat. Und es ist nicht nur die Benutzeroberfläche, die komplex wird, sondern auch alle Backend-Dienste und Daten, die benötigt werden, um solche Dinge überhaupt zu ermöglichen.
Das ist ein fairer Punkt, vorausgesetzt, der Kontext beschränkt sich auf informative Websites.
Das Wachstum der Anwendungsentwicklung im Web ist, glaube ich, worüber Chris hier hauptsächlich spricht – nicht nur UI-Gimmicks.
Der Wunsch, benutzergenerierte Inhalte einzubeziehen, wächst, und die Fähigkeit, das Frontend des Stacks zur vollständigen Unterstützung ausgefeilter PWAs zu nutzen, ist ein Ansatz, der immer beliebter wird.
Nein. Leute gehen nicht einfach online und sagen: „Ich möchte Single-Page-Anwendungen, die in der angesagtesten JavaScript-Bibliothek/-Framework geschrieben sind.“ Ich würde Ihnen völlig zustimmen… aber…
Leute erwarten diese Dinge, ob sie es zugeben oder nicht. Leute erwarten sofortiges Laden. Leute erwarten, dass Anwendungen sich auf eine bestimmte Weise verhalten. Das sind reale Daten. Das sind reale Beweise. Konversionen steigen (oder fallen) allein aufgrund der Geschwindigkeit Ihrer Website. UI/UX werden immer wichtiger. Sie möchten vielleicht nur eine Nachricht lesen, aber die meisten Leute wollen mehr als das. Sie wollen Echtzeit. Sie wollen AR/VR im Browser. Sie wollen schnell und sofort. Wenn Sie nicht glauben, dass das der Fall ist, haben Sie das Thema nicht ausreichend recherchiert.
„So fabelhaft jQuery für uns auch war, für neue Entwicklungen ist es vorbei.“
jQuery war vielleicht beliebter, als es das verdiente, oder wurde eingesetzt, wenn es nicht das beste Werkzeug war, aber das bedeutet nicht, dass es „vorbei“ sein wird oder sein sollte. Wie Sie zu Beginn sagten, Daten sind immer besser.
https://trends.google.com/trends/explore?date=all&q=jquery,ember,react,ember,vue.js
https://insights.stackoverflow.com/trends?utm_source=so-owned&utm_medium=blog&utm_campaign=trends&utm_content=blog-link&utm_term=state-of-mobile&tags=jquery%2Cember.js%2Creactjs%2Cangularjs%2Cvue.js
Es gibt definitiv einen Rückgang von seiner frühen Dominanz, aber meine Interpretation ist, dass die Zukunft eine Mischung aus Frameworks/Bibliotheken sein wird. Ich denke, jQuery wird einen Platz an diesem Tisch haben, und das ist keine schlechte Sache.
So sehr ich jQuery auch liebe, was Chris sagt, ist, dass die Zukunft die Übernahme von Entwicklungsmustern beinhaltet, die grundlegend mit jQuery unvereinbar sind.
jQuery ist wie ein treuer alter Videorekorder: Es mag immer noch der beste Videorekorder sein, den man für Geld kaufen kann, aber heutzutage benutzen die Leute Blu-rays. Und selbst der beste Videorekorder kann diese nicht abspielen. (Hinweis: Diese Analogie geht vielleicht an Leute verloren, die zu jung sind, um sich an Videorekorder... oder jQuery zu erinnern ;))
„jQuery ist wie ein treuer alter Videorekorder: Es mag immer noch der beste Videorekorder sein, den man für Geld kaufen kann, aber heutzutage benutzen die Leute Blu-rays.“
Laut Google Trends und SO Insights ist jQuery immer noch sehr dominant. Ich glaube nicht, dass die Aussage, dass jQuery in 10 Jahren die gleiche Größe wie Vue oder Ember haben wird, zu gewagt ist. Wenn überhaupt, ist sie optimistischer für Vue und Ember als für jQuery. Abseits von Konferenz- und Podcast-Kreisen werden immer noch großartige Dinge mit jQuery gemacht.
Außerdem benutze ich seit fast 10 Jahren keine Blu-ray mehr, Streaming wäre vielleicht die bessere Metapher zu diesem Zeitpunkt ;)
Sie liegen vollkommen richtig, was URLs angeht.
Und das ist einer der (mehreren) Gründe, warum ich Dinge wie Google AMP so frustrierend und regressiv finde. Bei dem Streben nach einem würdigen Ziel brechen sie Dinge, die bereits funktionieren – und mit meinem Aluhut auf dem Kopf sieht es transparent so aus, als ob es motiviert ist, den Zugriff auf und den Fluss innerhalb des Webs besser kontrollieren zu wollen.
Keine Gatekeeper FTW. URLs für immer!
Chris, ich weiß, du bist nur ein Kerl: aber ich denke, du hast absolut Recht. Vor allem in Bezug auf Benutzererwartungen, State und Modularität.
Ich frage mich, ob Sie befürchten, dass React, Vue usw. zu den Dingen werden, die wir in 10 Jahren bereuen werden, auf denen wir aufgebaut haben?
…und das sage ich als jemand, der *wirklich* Spaß daran hat, mit diesen Systemen zu arbeiten.
Im Sinne von „Resilient Web Design“ à la Jeremy Keith?
Ich bezweifle das irgendwie. Es zwingt uns, in JSON-basiertem State zu denken und zu arbeiten, was meiner Meinung nach bleiben sollte. Es ermutigt auch dazu, diese Daten von APIs zu erhalten, was ebenfalls ein guter Plan zu sein scheint, der bleiben sollte.
React, Vue und ähnliche sind nur ein schneller Einstieg in das, was die Webentwicklung nativ werden sollte, auch ohne Frameworks. Mit dem Shadow DOM und jeder Komponente von Web Components, die richtig auf der Webplattform implementiert ist, kann man sagen, dass diese Systeme die Zukunft der Webentwicklung sind.
Ich denke, es ist wichtig, zwischen dem Bauen von Web-Apps und Web-Seiten zu unterscheiden. Offensichtlich gibt es viel Überschneidung zwischen den beiden, aber wenn Sie Marketing-Seiten für Unternehmen erstellen, wird Ihr Werkzeugkasten viel kleiner. Zum Beispiel sind Build-Tools und Präprozessoren immer noch sehr wichtig und nützlich, aber Dinge wie State Management werden weniger wichtig, wenn nicht sogar in vielen Fällen völlig unnötig.
Es scheint, dass die meisten Innovationen von Web-App-Entwicklern angetrieben werden (was großartig ist), während Webseiten-Entwickler neue Technologien und Methoden sorgfältig auswählen müssen, damit sie nicht mit einem über-entwickelten Endprodukt dastehen.
Das Argument, dass „Über-Engineering“ schlecht ist, überzeugt mich nicht. Wenn mich „Über-Engineering“ eines Projekts 2 Stunden kostet und mir so viele nette Funktionen bietet (die im Laufe der Zeit die Entwicklung beschleunigen), warum dann nicht über-engineeren?
Sobald man gelernt hat, in React & Co. zu arbeiten und wie webpack funktioniert, wird die Implementierung des Toolchains trivial.
Also sage ich, machen Sie weiter mit dem Über-Engineering.
@Jared
Aber Über-Engineering wird niemals nur 2 Stunden kosten. Sie brauchen die anfängliche Zeit, um alles einzurichten (die ursprünglichen Dinge, die es ermöglichen, Dinge in nur zwei Stunden zu tun).
Und wenn Sie neue Entwickler einstellen, gibt es zusätzliche Einarbeitungszeit, eine steilere Lernkurve, mehr Hürden bei der Suche nach den richtigen Kandidaten usw. Dies variiert natürlich je nach Ihrem Unternehmen (arbeiten Sie als Einzelner Freiberufler? Eine Agentur oder ein Startup mit wenigen bis einem Dutzend Ingenieuren? Ein Großunternehmen mit Hunderten bis Tausenden von Ingenieuren?).
In meinem jetzigen Job haben wir etwa 20 Ingenieure, die sich Komponenten teilen. Selbst etwas so Triviales wie eine zusätzliche Stunde Arbeit, um etwas zu tun, hat einen Multiplikator von 20x, daher müssen Kompromisse immer abgewogen werden.
All das gesagt, argumentiere ich nicht, dass Tooling schlecht ist. (Wir haben persönlich ein sehr kompliziertes Build-System gegen einen sehr einfachen Entwicklungslebenszyklus getauscht, und das funktioniert wunderbar… bis das Build-System auf ein Problem stößt und es ein paar Entwickler mehrere Tage kostet, es herauszufinden, und dann die Ergebnisse mit allen anderen UI-Ingenieuren teilen müssen).
Ich sage nur, dass man nicht naiv den Ansatz verfolgen kann, dass mehr Tooling und Systeme immer gut sind, und die Annahme, dass etwas immer nur 2 Stunden dauert, ist eine schlechte Denkweise. :)
Ich glaube nicht, dass ich das angedeutet habe. Ich glaube, Sie gehen fälschlicherweise davon aus, dass modernes Tooling „niemals nur 2 Stunden kostet“. Natürlich gibt es Schulungen und Einarbeitung. Ich arbeite seit einiger Zeit mit React und Webpack und kann eine statische Website in 30 Minuten zum Laufen bringen.
Sicherlich haben Sie Schulungsbudgets für Ihr Team? Wir haben regelmäßige Besprechungen, um unseren Stack zu besprechen und Feedback zu erhalten. Das sind natürlich Entwicklungskosten.
„Neue und kompliziertere als ich derzeit damit zurechtkomme“ mit „Über-Engineering“ zu verwechseln, ist falsch.
Sicherlich kann ein Shop immer noch ein SASS-basiertes Gulp/Grunt-System betreiben und großartige Produkte liefern, aber es ist nicht schlecht, kurz innezuhalten und zu fragen, ob das Tooling verbessert werden könnte.
Und sobald Sie den Dreh raus haben und Webpack und HMR schmecken, werden Sie sich wie ein neuer Entwickler fühlen.
Auch wenn sich das Web jeden Tag schnell verändert, ist es beruhigend zu wissen, dass grundlegendes HTML und CSS auch heute noch für die Erstellung von Websites unerlässlich sind und es so wichtig ist, mit diesen beiden Sprachen Schritt zu halten.
JavaScript dominiert das Web jedoch, und ich bin gespannt, was jQuery ersetzen wird. Etwas wird irgendwann seinen Platz einnehmen müssen.
Ich denke, die Build-Verarbeitung verschwindet. ES6-Klassen funktionieren einfach so.
CSS hat Variablen.
Dinge, die nicht zu SSR gelangen.
all das klingt seltsam für mich. ich habe gelernt, dass HTML in die HTML-Datei gehört, CSS in die CSS-Datei. Klassennamen sollen das Element beschreiben und nicht die Eigenschaften. Nun, mit all diesen Frontend-Frameworks sieht es so aus, als wäre das nicht mehr so. Selbst wenn man CSS-Klassen wie p50 für einen Abstand von 50 Pixel verwendet. Deshalb kehren viele Leute zu den Wurzeln zurück oder verwenden einfach Susy.
dasselbe mit den modularen JavaScript-Hypes wie React. Es ist schrecklich, das CSS wieder von diesen Dateien zu trennen, auch wenn es am Anfang nett klingt.
ich denke, all das sollte zurück zu den Wurzeln gehen, woher es kommt. Ja, die Leute, die das Endprodukt nutzen, kümmern sich nicht darum, wie es gemacht ist, aber die Leute, die weiter an dem Produkt arbeiten werden, kümmern sich darum. Und wenn diese Leute, die diesen High-End-Bullshit gemacht haben, ein Unternehmen verlassen haben oder diese Technik aus der Zeit gefallen ist – erklären Sie dem Kunden die Situation.
nur weil etwas gerade angesagt ist – denk ein bisschen nach.
Ich denke, Ben hat genau ins Schwarze getroffen. Webanwendungen sind eine Sache und Websites sind eine andere Sache. Ich denke, der Großteil dieses Artikels trifft den Nagel auf den Kopf für Webanwendungen und ist für Websites nicht so zutreffend. Zum Beispiel ist eine saubere, fast Plugin-freie WordPress-Seite mit einem Spritzer jQuery für einige Slider und andere interaktive Komponenten immer noch eine der einfachsten Möglichkeiten, eine einfache Broschürenseite für einen nicht-technischen Kunden zu erstellen. React, Angular, Vue und jede andere "aktuelle" Webanwendungs-Technologie ist für eine Seite wie diese selten anwendbar (und wenn doch, kann sie nur in einem bestimmten Bereich der Seite geladen werden, z. B. mit Angular, um eine Art Visualisierungs-App auf einer ansonsten statischen Seite zu erstellen).
Ich stimme zu. Dieser Artikel muss oben eine große Klarstellung enthalten, dass sich diese Kommentare auf Webanwendungen und nicht auf Websites beziehen.
Ich stelle fest, dass ich nach etwa 18 Jahren Website-Entwicklung *weniger* Arbeit leisten muss und Dinge weniger kompliziert haben möchte als früher.
Ich benutze Frameworks, die HTML/CSS/JS einfacher bearbeitbar, zugänglicher machen, nicht weniger. React, Angular usw. sind für Apps. Ich kann buchstäblich eine komplett neue Seite auf Knopfdruck online haben. Ich muss nichts kompilieren. Eine Website ist nur Inhalt auf URLs. Sie *sind* nur Seiten.
Eine Webanwendung ist ein völlig anderes Tier als eine Website, und die Zukunft von Websites ist sicherlich nicht dieselbe wie die von Webanwendungen.
SASS wird ersetzt werden, jQuery wird durch eine kleinere Bibliothek ersetzt, die dieselben einfachen Dinge tut (oder jQuery wird gekürzt). Und Slider und Galerien werden keinen dedizierten React-Programmierer benötigen, um sie zu erstellen. Aber höchstwahrscheinlich werden Komponenten verwendet.
Ich werde der Spielverderber sein und vorhersagen, dass React sich in eine Ecke manövrieren wird, um die Bedürfnisse von Facebook zu erfüllen, zum Nachteil aller anderen, und dann wird es das Prototype.js der Frameworks werden. Google wird Angular genauso verkrüppeln.
Aber Websites werden noch lange Zeit HTML, CSS und etwas JS sein, um die Dinge aufzupeppen. Vielleicht kommt etwas Neues, aber ich bezweifle, dass es die Grundlagen ändern wird.
Eine Seite ist immer noch eine URL für eine Website... vielleicht aber nicht für eine Webanwendung.
Relevant: https://css-tricks.de/poll-results-sites-vs-apps/
Ich stimme Ihnen bei den meisten Ihrer scharfen Beobachtungen zu, mit Ausnahme von zweien
CSS-Präprozessoren werden nicht per se verschwinden. Sie werden einfach langsam in allgemeine Build-Pipelines integriert, die universelle Syntaxbäume für verschiedene Sprachen in einem effizienten Prozess abstrahieren: Denken Sie an Babel, aber nicht nur für JavaScript. Sobald sich Entwickler fragen, warum sie mehrere Engines ausführen sollten, um im Grunde die gleiche Aufgabe zu erledigen, wird bald eine Lösung gefunden. Außerdem werden sich zukünftige Build-Prozesse stärker auf die Produktleistung als auf die Entwicklererfahrung konzentrieren.
Die Grenze zwischen nativ und Web wird aus Benutzersicht nur verschwimmen. Für den Entwickler wird es keinen Sinn ergeben, eine 40+MB Laufzeitumgebung (am Beispiel von Electron) zu liefern, um 2MB Code auszuführen, anstatt einer 5MB nativen App, die performanter sein wird als die Webanwendung. Nur wenn sich mobile und Desktop-Betriebssysteme auf ein gemeinsames Format für Webanwendungen einigen, das eine einfache Installation überall ermöglicht, dann werden Webanwendungen native Apps ersetzen.
Wo passen Frameworks wie Foundation und Bootstrap in all das? Werden sie mit jQuery weggeworfen oder werden sie sich an diese Frameworks anpassen?
Ich habe festgestellt, dass diese Frameworks aufgrund von Dingen wie Flexbox, Grid, CSS3 im Allgemeinen und der Dominanz von Mobilgeräten (mit modernen Browsern) und sich automatisch aktualisierenden Browsern (Evergreen) weniger nützlich sind als früher.
Bootstrap ist zu CSS wie jQuery zu JS? Keine perfekte Analogie. Aber ich sehe sicherlich viele Seiten, die Bootstrap verwenden, und denke, es ist eine nützliche Fähigkeit, aber wo ich arbeite, haben wir Normalize, fast alle Shims/Shivs weggeworfen und unser eigenes konformes CSS-Framework erstellt, das auf allen modernen Browsern funktioniert.
Es ist sauber, leicht, einfach zu handhaben und wir können es mit der Zeit wachsen und trimmen. Die anderen Frameworks sind im Vergleich dazu jetzt ein enormer Overhead.
Aber ich habe festgestellt, dass Entwicklungsteams, die sich nur auf eine Seite konzentrieren müssen (wie eine riesige Unternehmenswebsite), eher Bootstrap/Foundation verwenden und davon profitieren als Webdesigner, die regelmäßig neue Websites erstellen.
Hauptsächlich, weil HR, wenn man Leute einstellt/entlässt, leicht sagen kann: "Kennst du Bootstrap?"
… aber man muss trotzdem wissen, wie man es benutzt.
Welche Rolle spielt WebAssembly in der Frontend-Entwicklung in der kommenden Zukunft?
Ich glaube, eine riesige Rolle. Sehen Sie, was TJ dazu unten zu sagen hat. Denken Sie daran, TJ war ein Kernmitarbeiter von Node.js und hat viele der Bibliotheken/Tools erstellt, die wir heute verwenden. Der Kerl ist einfach ein Genie. Ignorieren Sie auch einfach den Go vs Node-Kram. Er spricht in diesem Beitrag über WebAssembly.
https://medium.com/@tjholowaychuk/go-blows-away-node-in-pretty-much-every-way-3b412b5050d8
„Wenn man diese Idee ein wenig erweitert, kann man sehen, wie eine URL zu einem Identifikator für den Zustand werden könnte. Wenn der Zustand die Zusammensetzung von Komponenten definiert und URLs prinzipiell auf ein bestimmtes Stück Information verweisen müssen.“
Wenn man darüber nachdenkt, sind das genau das, was URLs/URIs *sind*. Sie sind ein Uniform *Resource* Locator/Identifier.
Können die Leute ihre Anwendungen nicht einfach serverseitig ausführen, über Web-Sockets ausliefern und fertig sein? Oder noch besser: Sie über das X11-Protokoll ausliefern und den Browser komplett umgehen. Denn es ist nicht so sehr "das Web", sondern eher: "JavaScript-Programme, die über HTTP ausgeliefert werden".
Scherz beiseite: Oft scheint es mir, dass Webentwickler und ihre direkten Kunden in einer Art alternativer Universumsblase leben, in der wirklich jeder Highspeed-Verbindungen hat und einmal im Jahr auf einen neuen High-End-Computer aufrüstet. (Dadurch tragen sie zum globalen Elektroschrott bei.) Währenddessen beschweren sich Durchschnitts-Joe und -Jane über all die langsamen, unresponsive Websites da draußen.
Ist es wirklich notwendig, dass das einfache Hochladen eines Bildes auf eine sogenannte hochmoderne Website mehr Systemressourcen in Bezug auf Prozesszeit und Speicherverbrauch benötigt als das Ausführen von Photoshop?
Das lässt mich von einer neuen Bewegung träumen: Ich nenne sie die "Zurück zum Web!"-Bewegung. Es ist eine Bewegung, bei der Leute etwas als "Webseite" bezeichnen, wenn sie nur die Kontaktdaten, Produktinformationen und ein Bestellformular eines Unternehmens liefert. Und bei der die Leute generell am Modell festhalten: "HTML für Inhalt, CSS für Präsentation, JavaScript (in Maßen) für Interaktion".
Ich stimme zu, dass wir Systeme bauen. Aber diese Systeme sollten Module *zur Kompilierzeit* zusammenstellen. So entsteht eine schnelle, schlanke und reibungslose schöne Webseite. Sass (oder ein noch leistungsfähigerer Nachfolger) wird bleiben. In Zukunft wird es zum Schreiben vollwertiger CSS-Compiler verwendet werden. Bibliotheken wie True werden dabei helfen.
Ja, bitte. Wie können Leute 1,5 MB JS für eine Seite akzeptieren, die so einfach ist wie ein Absatz Text? Unfassbar. Die "Zurück zum Web!"-Bewegung ist ein Teil meines https://radogado.github.io/natuive/#showcase
Mit freundlichen Grüßen.
Du hast viele davon wirklich auf den Punkt gebracht! Designsysteme, Kundenerwartungen – darüber denke ich in letzter Zeit intensiv nach. Design gerät zunehmend in den Bereich des Engineerings und könnte bis zu einem gewissen Grad teilautomatisiert werden. Das ist sowohl beängstigend als auch tatsächlich sehr befreiend, da es Designern ermöglicht, sich mehr auf das ganzheitliche Design des Systems als auf die Benutzeroberfläche zu konzentrieren.
Eine Sache, die mich im Designbereich wirklich beunruhigt, ist, dass sich die meisten Designs jetzt auf Produkte und Anwendungen konzentrieren und nicht auf das, was wir als traditionelle "Storefront"-Websites bezeichnen würden. Komplizieren wir den Prozess für eine traditionelle Website? Ich glaube nicht, aber es ist erwähnenswert.
das ist wie 'Popmusik', selten eine lange Lebensdauer. Vor ein paar Jahren "Lazy Load" "lade nur, was du brauchst". Jetzt Webpack (und andere) "hole alles in einem Ladevorgang". Auch DAMALS musstest du nur manuell eine CSS- und eine JS-Datei herunterladen und ablegen, JETZT ein Projekt initialisieren, Abhängigkeiten installieren, Abhängigkeiten herunterladen, transpilieren-kompilieren-
minifizieren-injizieren-usw. Abhängigkeiten. Denk mal darüber nach :) "React" ist jetzt populär, wie "Angular" vor ein paar Jahren, wie jQuery vor ein paar Jahren... nun, manchmal (wie in Phil Nelsons Antwort) brauchst du nur eine HTML-Datei mit CSS.
Eine sanfte Erinnerung
Dies ist eine Motherf*cking Website.
Als Designer war ich Teil eines großen Webprojekts, das mit React erstellt wurde.
Was ich an diesem Hype um Frameworks immer noch nicht verstehe, ist das
Warum jubeln plötzlich alle über diese Frameworks, wenn sie schlecht darin sind, Markup/Inhalt/Styling zu trennen. Jahrelang haben alle Web-Gurus gepredigt, dass Trennung der Schlüssel ist. Aber jetzt nicht mehr?
Da wir hier Sachen vorhersagen: Ich sage voraus, dass React eine Technologie sein wird, die zutiefst bereut werden wird, wegen des riesigen Durcheinanders, das es zwischen JavaScript und einfachem HTML verursacht.
Ich stimme Ihren Kommentaren zu React zu, auch wenn sie andere Entwickler verärgern werden. Ich arbeite gerne damit und manche Dinge, die man damit erreichen kann, sind echt cool, aber für mich fühlt es sich so dreckig an, Markup, Inhalt und Styling an einem Ort zu haben…
Ein Argument in diesem Bereich ist, dass Sie, wenn Sie Ihre Codebasis entlang von HTML/CSS/JS-Linien aufteilen, tatsächlich nichts entkoppeln. Das CSS, das Sie schreiben, ist immer noch vom HTML abhängig, und das JS könnte sowohl das HTML als auch das CSS beeinflussen. Selbst wenn Ihr Code in verschiedene Dateien aufgeteilt ist, sind sie funktionell alle eng miteinander gekoppelt und voneinander abhängig.
React verwirft dieses Paradigma für ein neues Konzept, bei dem der gesamte Code für eine 'Komponente' in derselben Datei lebt, und diese Komponenten sind klein und wiederverwendbar. Die Trennung von Belangen ist also immer noch irgendwie vorhanden, aber die 'Belange' sind nicht unbedingt Markup, Stil, Verhalten, sondern eher einzelne Stücke von vollwertiger Benutzeroberfläche und Funktionalität.
Ich verstehe die Idee, und sie fühlt sich eine Weile lang ziemlich eklig an, wenn man anfängt, React zu benutzen, aber wenn man sich daran gewöhnt hat, fängt es an, viel Sinn zu machen.
Das heißt, ich denke, diese Idee hat in den nächsten Jahren mehr Raum zur Entwicklung, wir könnten einige sinnvollere Paradigmen aufkommen sehen.
Ich möchte noch hinzufügen
Die Aufteilung HTML/CSS/JS ist im Wesentlichen nur relevant, um eine Codebasis im Laufe der Zeit einfach zu pflegen und zu erweitern (da sie alle immer noch funktional voneinander abhängig sind).
Reacts Methode, Komponenten zu komponieren, sieht und fühlt sich ziemlich seltsam an, aber man könnte argumentieren, dass sie diese Aufgabe noch einfacher macht, da wir nicht zwischen 3 verschiedenen Orten springen müssen, um eine Sache zu schreiben, und wir keine Klassennamen usw. über drei Dateien hinweg abgleichen müssen, da alles, was mit dem zu tun hat, woran wir arbeiten, an einem Ort ist.
Vielen Dank für Ihre Antwort, was Sie über die Korrelation der verschiedenen Dateien sagen, ist absolut richtig.
Es ist nur eine logische Trennung; wenn ich HTML oder JS baue, kümmere ich mich nicht um den Stil, nur um die Namen.
Wenn ich JS-Logik baue, kümmere ich mich nicht um die HTML-Struktur und so weiter.
Ich habe gerade das, was ich im Moment brauche, zur Hand.
Ich habe immer noch Knockout-Projekte, die so gebaut sind wie Ihre React-Logik (von der ich zugegebenermaßen nicht viel weiß), alles in einer Datei, Two-Way-Binding gemischt mit HTML; Zuerst war es seltsam, dann wurde es so sauber und so kurz; dann wurde es immer schwieriger zu pflegen.
Oh, und ein Albtraum zum Debuggen.
Ich werde es vielleicht später noch einmal versuchen, zumindest wenn eine der Bibliotheken der klare Marktsieger sein wird, wie es vor Jahren mit jQuery/MooTools/Yui/etc. der Fall war.
Im Moment scheint Angular die Dominanz zu haben, aber die Dinge ändern sich sehr schnell.
Deshalb braucht man progressives Design.
Wenn Ihr HTML von Ihrem CSS und JavaScript abhängt, dann ist etwas falsch.
Jede ist eine Ebene, die das Benutzererlebnis bereichert, aber kein Muss ist.
Das Aufteilen von Code in verschiedene Dateien fügt sicherlich einen gewissen Overhead hinzu, aber dann werden Sie auch Komponenten in ihre eigenen Dateien aufteilen.
Ich finde die Komponenten-Hierarchie starrer als die HTML/CSS-Organisation, zu der Sie vielleicht kommen.
Ja, 100% stimme ich zu, es ist sehr starr. Verstehen Sie mich nicht falsch, die Art und Weise, wie React Dinge tut, ist sehr vorschreibend und kein Ersatz für irgendetwas, es nähert sich dem Problem der Trennung von Belangen auf eine andere Weise, die interessant erscheint. Ich bin im Moment mehr von der Idee angetan, React oder Vue für kleinere, weniger folgenschwere Dinge wie 'Widgets' in traditionellen oder WordPress-Websites zu verwenden.
jQuery als Vergangenheit zu bezeichnen, halte ich für wirklich falsch.
Es ist ein Werkzeug, und in vielen Kontexten ist es das beste Werkzeug.
Ich habe Angular, React und vor Jahren Knockout ausprobiert und benutze sie in kleinen Projekten, wo sie die Entwicklung wirklich beschleunigen; aber wenn die Dinge groß und kompliziert werden, schlägt meiner Erfahrung nach nichts eine klare Kenntnis von Qualität und Fehlern von grundlegendem JavaScript, Klassen und Modulen mit einfachen Konventionen (und ohne externe Bibliotheken) sowie die Trennung von Inhalten (page.html, page.css, page.js) und das jQuery-Werkzeug für den DOM-Aufbau und die Interaktion.
Oh, und Less/Sass für CSS.
Meine persönliche Erwartung ist, dass HTML, CSS und JavaScript zunehmend nur noch Kompilierungsziele für bessere Sprachen werden. Das geschieht schon seit vielen Jahren mit Dingen wie TypeScript, CoffeeScript, LESS/SASS und so weiter. In meinem aktuellen Frontend-Job schreibe ich schon lange keine reine HTML-, CSS- oder JavaScript-Zeile mehr, da wir bessere Technologien (wie ClojureScript) verwenden, die einfach in diese Sprachen kompiliert werden, die Browser verstehen.
Ich stimme fast allem zu, was in diesem Blogbeitrag gesagt wurde, aber das Einzige, was meiner Meinung nach fehlt, ist die Tatsache, dass *JavaScript* als *Plattform* oder *Ziel* zum Kompilieren aus anderen Sprachen sehr relevant sein wird. Das haben wir bereits erfolgreich mit Sprachen wie *ELM*, *ClojureScript*, *Scala.js* usw. gesehen. Ich denke, das wird sehr wichtig sein, denn obwohl JavaScript mit jeder Version besser wird, ist es immer noch eine relativ fragile Sprache und viele Leute mögen sie nicht wegen dessen, daher sind Alternativen, wie wir sie schon immer für die Backend-Entwicklung hatten, definitiv ein großer Gewinn.
Ich habe diesen Tippfehler gefunden: „aber man muss trotzdem wissen, wie man es benutzt“