<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/feed.rss.xml" type="text/xsl" media="screen"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Marvin Luchs</title>
    <description/>
    <link>https://speakerdeck.com/luchsamapparat</link>
    <atom:link rel="self" type="application/rss+xml" href="https://speakerdeck.com/luchsamapparat.rss"/>
    <lastBuildDate>2021-04-21 10:43:42 -0400</lastBuildDate>
    <item>
      <title>Warum bauen wir Single-Page Applications und was kommt als Nächstes?</title>
      <description>Angular, React oder vielleicht doch Vue.js? Die erste Frage in vielen Projekten ist nicht, ob eine Single-Page Application (SPA) der richtige Architekturansatz ist, sondern nur noch, mit welchem Framework man sie umsetzt. Mit der blinden Entscheidung für eine SPA gehen wir unbewusst eine ganze Reihe von Kompromissen ein, die nicht immer im Sinne des Projekts oder der Endanwender sind. Wie sind wir an den Punkt gelangt, an dem wir andere Optionen gar nicht mehr in Betracht ziehen? Um diese Frage zu beantworten, werfen wir einen Blick zurück auf die Evolutionsschritte vom klassischen Server-Side Rendering (SSR) hin zum reinen Client-Side Rendering (CSR) einer Single-Page Application. Dabei betrachten wir die Vor- und Nachteile anderer Ansätze, die wir auf dieser Reise zurückgelassen haben, und wagen einen Blick in die Zukunft, in der die Grenzen zwischen SSR und CSR zunehmend verschwimmen.</description>
      <media:content url="https://files.speakerdeck.com/presentations/9a33042c43744d9d8bb59392044efed4/preview_slide_0.jpg?18033392" type="image/jpeg" medium="image"/>
      <content:encoded>Angular, React oder vielleicht doch Vue.js? Die erste Frage in vielen Projekten ist nicht, ob eine Single-Page Application (SPA) der richtige Architekturansatz ist, sondern nur noch, mit welchem Framework man sie umsetzt. Mit der blinden Entscheidung für eine SPA gehen wir unbewusst eine ganze Reihe von Kompromissen ein, die nicht immer im Sinne des Projekts oder der Endanwender sind. Wie sind wir an den Punkt gelangt, an dem wir andere Optionen gar nicht mehr in Betracht ziehen? Um diese Frage zu beantworten, werfen wir einen Blick zurück auf die Evolutionsschritte vom klassischen Server-Side Rendering (SSR) hin zum reinen Client-Side Rendering (CSR) einer Single-Page Application. Dabei betrachten wir die Vor- und Nachteile anderer Ansätze, die wir auf dieser Reise zurückgelassen haben, und wagen einen Blick in die Zukunft, in der die Grenzen zwischen SSR und CSR zunehmend verschwimmen.</content:encoded>
      <pubDate>Thu, 22 Apr 2021 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/luchsamapparat/warum-bauen-wir-single-page-applications-und-was-kommt-als-nachstes</link>
      <guid>https://speakerdeck.com/luchsamapparat/warum-bauen-wir-single-page-applications-und-was-kommt-als-nachstes</guid>
    </item>
  </channel>
</rss>
