Skip to content

Commit

Permalink
Optische Verbesserungen
Browse files Browse the repository at this point in the history
  • Loading branch information
Bernd Schimmer committed Jan 29, 2024
1 parent b860679 commit 42da2a0
Showing 1 changed file with 45 additions and 30 deletions.
75 changes: 45 additions & 30 deletions src/docs/blog/2024/2024-01-25-Evolution-der-Webentwicklung.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -15,52 +15,68 @@ ifndef::imagesdir[:imagesdir: ../../images]

== Vom Code zum Klick: Meine Reise durch die Evolution der Webentwicklung

In diesem persönlichen Rückblick tauchen wir ein in die faszinierende Welt der Webentwicklung – von den frühen Tagen des manuellen Codings bis hin zu den modernen Technologien, die heute den Standard setzen. Begleitet mich auf meiner Reise durch die Zeit, in der sich HTML, CSS und JavaScript von Grund auf verändert haben und entdeckt, wie sich die Herausforderungen und Lösungen in der Webentwicklung im Laufe der Jahre gewandelt haben. Von den ersten Schritten mit einfachen Tools bis hin zu den komplexen Frameworks und Methoden von heute – dies ist eine Geschichte von Innovation, Lernen und ständiger Weiterentwicklung.
In diesem persönlichen Rückblick tauchen wir ein in die faszinierende Welt der Webentwicklung – von den frühen Tagen des manuellen Codings bis hin zu den modernen Technologien, die heute den Standard setzen.
++++
<!-- teaser -->
++++
Begleitet mich auf meiner Reise durch die Zeit, in der sich HTML, CSS und JavaScript von Grund auf verändert haben und entdeckt, wie sich die Herausforderungen und Lösungen in der Webentwicklung im Laufe der Jahre gewandelt haben. Von den ersten Schritten mit einfachen Tools bis hin zu den komplexen Frameworks und Methoden von heute – dies ist eine Geschichte von Innovation, Lernen und ständiger Weiterentwicklung.

=== Zuerst ein paar Meilensteine der Webentwicklung tabellarisch zusammengefasst:

1. 1991 erste Webseite mit HTML
2. 1995 PHP und JavaScript
3. 1996 CSS
. 1991 erste Webseite mit HTML
. 1995 PHP und JavaScript
. 1996 CSS

------------- bis hierhin kaum automatisiertes Deployment möglich (z. B. über FTP)
4. 2000 SVN
5. 2003 Wordpress (Joomla/Typo3 etc.)
6. 2005 GIT
[start=4]
. 2000 SVN
. 2003 Wordpress (Joomla/Typo3 etc.)
. 2005 GIT

------------- Versionierung
7. 2006 jQuery und AWS
8. 2008 Static Site Generators (SSG)
9. 2009 Node.js
10. 2010 NPM und AngularJS
11. 2011 Bootstrap CSS
12. 2012 Webpack, TypeScript
13. 2013 Docker, https://react.dev[React] und Server Side Rendering
[start=7]
. 2006 jQuery und AWS
. 2008 Static Site Generators (SSG)
. 2009 Node.js
. 2010 NPM und AngularJS
. 2011 Bootstrap CSS
. 2012 Webpack, TypeScript
. 2013 Docker, https://react.dev[React] und Server Side Rendering

------------- automatisierte und idempotente Deployments möglich
14. 2014 Vue.js, CSS-in-JS
15. 2015 PWAs (100% seit 2022)
16. 2016 https://nextjs.org[Next.js], Angular (4+)
17. 2020 https://vitejs.dev[Vite]
18. 2022 Generatoren für Frontend/Backend Kombinationen https://refine.new[refine.new], https://redwoodjs.com[RedwoodJS], https://blitzjs.com[Blitz.js]
19. 2023 Ende des Internet Explorers
20. 2023 React Server Components
[start=14]
. 2014 https://vuejs.org[Vue.js], CSS-in-JS
. 2015 PWAs (100% seit 2022)
. 2016 https://nextjs.org[Next.js], https://angular.io[Angular] (4+)
. 2020 https://vitejs.dev[Vite]
. 2022 Generatoren für Frontend/Backend Kombinationen https://refine.new[refine.new], https://redwoodjs.com[RedwoodJS], https://blitzjs.com[Blitz.js]
. 2023 Ende des Internet Explorers
. 2023 React Server Components

Mehr Details und ausführlichere Infos gibt es unter anderem auf:
- https://designmodo.com/history-website-building/[designmodo.com: The Short History of Website Building]
- https://dev.to/snickdx/a-brief-history-of-the-web-part-4-194b[Nicholas Mendez: A "Brief" History of the Web Part 4]
- https://www.viget.com/articles/what-even-are-react-server-components/?token=PFnI6MT715nmYK0BZzQEiRsYQ7w_x5SP[Nick Telsan: What Even Are React Server Components]
- https://jessedit.tech/articles/react-server-components/1-background/?ck_subscriber_id=1652261910[Jesse Pence: React Server Components]

- https://designmodo.com/history-website-building/[designmodo.com: The Short History of Website Building]
- https://dev.to/snickdx/a-brief-history-of-the-web-part-4-194b[Nicholas Mendez: A "Brief" History of the Web Part 4]
- https://www.viget.com/articles/what-even-are-react-server-components/?token=PFnI6MT715nmYK0BZzQEiRsYQ7w_x5SP[Nick Telsan: What Even Are React Server Components]
- https://jessedit.tech/articles/react-server-components/1-background/?ck_subscriber_id=1652261910[Jesse Pence: React Server Components]

=== Meine ersten Erfahrungen mit dem Internet

Wenn ich mich an die Anfänge meiner Tätigkeit erinnere, haben wir HTML, CSS, PHP und jQuery mit BBedit selbst geschrieben, gespeichert und manuell per FTP auf Server hochgeladen. Das Beste, was es damals gab, war das Programm Transmit, mit dem einzelne Ordner synchronisiert werden konnten. Alles war sehr fehleranfällig, ohne Versionierung und daher schwer bis gar nicht testbar – nur manuell. jQuery-Plugins wurden mit Abhängigkeiten zu unterschiedlichen jQuery-Versionen benutzt, die nicht unbedingt kompatibel waren. Man musste jedes Mal hoffen, dass die Webseite noch funktionierte, nachdem man Code hinzugefügt hatte. Was mich immer am meisten geärgert hat, war ein Flackern, sobald das JavaScript geladen wurde und über das PHP-gerenderte HTML noch extra DOM-Elemente legte.
Die folgenden Probleme sind meiner Meinung nach die größten beim klassisch gerenderten Web: Wann ist der DOM fertig, wann ist das JS geladen und wird ausgeführt, wer hat bei intensiven Seiten „das Sagen“ – das Frontend oder das Backend (Routing, Views)?

Die folgenden Probleme sind meiner Meinung nach die größten beim klassisch gerenderten Web:

- Wann ist der DOM fertig geladen?
- Wann ist das JS geladen und wird ausgeführt?
- Wer hat bei intensiven Seiten „das Sagen“ bzgl. Routing und Views – das Frontend oder das Backend?

=== Wie wurden Webseiten 2014 gebaut?

Nach meinem Studium habe ich in Hamburg bei AboutYou in einer IT-Agentur gearbeitet, die nach Scrum ihren Arbeitszyklus gestaltet und schon damals diverse Tools zum Bauen des Frontends benutzt hat. Da die Tools alle am Anfang ihres Lebenszyklus waren, mussten mindestens drei Package-Manager und Erweiterungen installiert werden, bevor die Webseite gebaut werden konnte. Gebaut? Ja, das war die Zeit, in der Grunt und Webpack eine moderne und strukturierte Frontendentwicklung ermöglicht haben. Vorbei waren die Zeiten mit unterschiedlichen Encodings und Zeilenumbrüchen. Was für ein Gefühl es war, lokal einen Befehl in der Kommandozeile aufzurufen und die zu entwickelnde Webseite auf dem eigenen Gerät zu sehen – heute Standard. Hier lernte ich zum ersten Mal Package-Manager und Versionierung kennen. Und noch ein Thema kam auf: IDEs für Webentwicklung. Bisher war der beste Freund der Inspektor im Browser, eine lokale, beim Entwickler stattfindende Überprüfung oder Unterstützung konnten bis dahin nur die „richtigen“ Programmiersprachen und die dazugehörigen teuren IDEs (z. B. IntelliJ) bieten. Mit Atom gab es eine IDE, die schnell startete, sich nur um Websprachen kümmerte und über Plugins erweiterbar war. Jetzt gab es Autovervollständigung für HTML/JS/CSS und über Webpack konnten alle Dateien optimiert, komprimiert und kombiniert werden.

=== Wie ist der Stand heute?

Sehr gut! Viele Probleme der Vergangenheit sind verschwunden (Internet Explorer existiert nicht mehr, schlechte Kompatibilität der Browser) und es gibt eine Reihe von Möglichkeiten, Frontends mit Frameworks zu bauen, die alle ihre Vor- und kleinen Nachteile haben. Z. B. hat sich Visual Studio Code als Nachfolger von Atom zum (kostenlosen) Standard für Webentwicklung mit noch mehr Möglichkeiten zur generellen Verbesserung gemausert. Frontend-Frameworks gibt es viele (und es kommen immer mehr dazu) – durchgesetzt haben sich aktuell React, Angular, Vue.js und Svelte.
Sehr gut! Viele Probleme der Vergangenheit sind verschwunden (Internet Explorer existiert nicht mehr, schlechte Kompatibilität der Browser) und es gibt eine Reihe von Möglichkeiten, Frontends mit Frameworks zu bauen, die alle ihre Vor- und kleinen Nachteile haben. Z. B. hat sich Visual Studio Code zum kostenlosen Nachfolger von Atom für die Webentwicklung mit noch mehr Möglichkeiten zur generellen Verbesserung gemausert. Frontend-Frameworks gibt es viele (und es kommen immer mehr dazu) – durchgesetzt haben sich aktuell React, Angular, Vue.js und Svelte.

=== Wie helfen moderne Frontends bei der Performance?

Expand All @@ -72,8 +88,7 @@ Der Client fragt den Server an und erhält HTML, JS und CSS sowie den Login-Stat

=== Wie baue ich Frontends?

Mein Lieblings-Javascript-Framework ist React. Eine gute Übersicht über andere JS-Frameworks und was sie unterscheidet, findet ihr z. B. auf themer.dev[https://themer.dev/blog/the-single-most-important-factor-that-differentiates-front-end-frameworks].
Von dieser Seite kommt folgendes Zitat: „Reacts change detection paradigm is straightforward: the application state is maintained inside the framework (with APIs exposed to the developer for updating it) so that React knows when to re-render.“ Und was heißt das jetzt? Nicht mehr der Browser oder das Backend entscheiden, auf welcher URL was passiert, sondern das Frontend. Und wenn im Frontend eine Aktion ausgelöst wird, entscheidet auch das Frontend, was passiert. Das heißt nicht, dass es kein Backend gibt oder dass z. B. Validierung nur auf der Frontendseite passiert. Sicherheit im Web sollte der wichtigste Aspekt sein.
Mein Lieblings-Javascript-Framework ist React. Eine gute Übersicht über andere JS-Frameworks und was sie unterscheidet, findet ihr z. B. auf https://themer.dev/blog/the-single-most-important-factor-that-differentiates-front-end-frameworks[themer.dev]. Von dieser Seite kommt folgendes Zitat: „Reacts change detection paradigm is straightforward: the application state is maintained inside the framework (with APIs exposed to the developer for updating it) so that React knows when to re-render.“ Und was heißt das jetzt? Nicht mehr der Browser oder das Backend entscheiden, auf welcher URL was passiert, sondern das Frontend. Und wenn im Frontend eine Aktion ausgelöst wird, entscheidet auch das Frontend, was passiert. Das heißt nicht, dass es kein Backend gibt oder dass z. B. Validierung nur auf der Frontendseite passiert. Sicherheit im Web sollte der wichtigste Aspekt sein.

=== Bevor ich mit einem neuen Projekt anfange

Expand All @@ -82,7 +97,7 @@ Was sich für mich als Erfolgsrezept herausgestellt hat: Sich am Anfang eines Ne
=== Abschließend ein paar Wünsche an das Frontend, welches ihr baut:

- Macht die Webseite responsive (Probiert eure Webseite mit unterschiedlichen Geräten in unterschiedlichen Auflösungen aus)
- Räumt euren Header-Bereich auf und nutzt z. B. https://realfavicongenerator.net[ealfavicongenerator.net], um für alle ein schönes Favicon zu zaubern
- Räumt euren Header-Bereich auf und nutzt z. B. https://realfavicongenerator.net[realfavicongenerator.net], um für alle ein schönes Favicon zu zaubern
- Nutzt Komponenten die Accessability mit eingebaut haben (z. B. https://blueprintjs.com[Blueprint], https://mantine.dev[Mantine] oder https://rsuitejs.com[React Suite])
- Macht den Google Lighthouse Test und behebt die wichtigsten Probleme
- Macht nur eine PWA, wenn offline-Inhalte essenziell sind oder ihr eine richtige App ausliefert
Expand Down

0 comments on commit 42da2a0

Please sign in to comment.