Tweet
Tweet

Slide 1

Slide 1 text

What’s wrong with Single-Page Apps (and what to do about it) Stefan Tilkov
 [email protected]
 @stilkov JavaScript Days 2019, Berlin "Science Museum, ceiling" by Elecé is licensed under CC BY 2.0

Slide 2

Slide 2 text

@stilkov Annoying your app users in 10 easy steps

Slide 3

Slide 3 text

@stilkov 1.
 Forbid the use of the back and forward buttons

Slide 4

Slide 4 text

@stilkov 2.
 Send them to the home page when they hit “refresh” …

Slide 5

Slide 5 text

@stilkov 3.
 … or at least ensure the browser pops up a warning window

Slide 6

Slide 6 text

@stilkov 4.
 Make sure they can’t open a second browser window

Slide 7

Slide 7 text

@stilkov 5.
 Let them see UI decoration and ads first, content last

Slide 8

Slide 8 text

@stilkov 6.
 Make sure they can’t bookmark or send a link

Slide 9

Slide 9 text

@stilkov 7.
 Don’t let Google index anything

Slide 10

Slide 10 text

@stilkov 8.
 Show users a picture of your app – it’s surely better than nothing

Slide 11

Slide 11 text

@stilkov 9.
 Disable assistive technologies. Who needs a screen reader, anyway?

Slide 12

Slide 12 text

@stilkov 10.
 Ensure non-functioning JavaScript gives them a blank page

Slide 13

Slide 13 text

@stilkov History repeating … CORBA Web WS-* REST

Slide 14

Slide 14 text

@stilkov What’s the client side analogy?

Slide 15

Slide 15 text

@stilkov 1) in the SOAP/WSDL sense “Web app”2) 2) built as a careless SPA “Web service”1) > Uses HTTP as transport > Ignores HTTP verbs > Ignores URIs > Exposes single “endpoint” > Fails to embrace the Web > Uses browser as runtime > Ignores forward, back, refresh > Does not support linking > Exposes monolithic “app” > Fails to embrace the browser

Slide 16

Slide 16 text

@stilkov The web-native way of distributing logic Process Flow Presentation Domain Logic Data Server Client > Rendering, layout, styling
 on an unknown client > Logic & state machine on server > Client user-agent extensible via
 code on demand

Slide 17

Slide 17 text

@stilkov HTML & Hypermedia • In REST, servers expose a hypermedia format • Option 1: Just invent your own JSON-based, incomplete clone • Option 2: Just use HTML • Clients need to be RESTful, too • Option 1: Invent your own, JS-based, buggy, incomplete implementation • Option 2: Use the browser

Slide 18

Slide 18 text

@stilkov A great REST hypermedia API is very similar to a simple, server-sided rendered web application

Slide 19

Slide 19 text

@stilkov What does SPA even mean?

Slide 20

Slide 20 text

@stilkov State Business Logic Routing Rendering Logic Look & Presentation Logic Server Client HTML

Slide 21

Slide 21 text

@stilkov State Business Logic Routing Rendering Logic Look & Presentation Logic Server Client JSON

Slide 22

Slide 22 text

@stilkov State Business Logic Routing Rendering Logic Look & Presentation Logic Server Client JSON JSON API JSON Client

Slide 23

Slide 23 text

@stilkov State Business Logic Routing Rendering Logic Look & Presentation Logic Server Client JSON JSON API JSON Client

Slide 24

Slide 24 text

@stilkov Single Page Apps – Why Routing? Solution:
 Store some app
 state in the URI! Bookmarks? Deep links? Reload?

Slide 25

Slide 25 text

@stilkov State Business Logic Routing Rendering Logic Look & Presentation Logic Server Client JSON JSON API JSON Client

Slide 26

Slide 26 text

@stilkov State Business Logic Routing Rendering Logic Look & Presentation Logic Server Client JSON JSON API JSON Client (Pre-)Rendering Logic Routing HTML

Slide 27

Slide 27 text

@stilkov Prerendering

Slide 28

Slide 28 text

@stilkov Hydration How to simulate readiness? What about Events (Clicks etc)? How to match server-side HTML to client-side DOM?

Slide 29

Slide 29 text

@stilkov State Business Logic Routing Rendering Logic Look & Presentation Logic Server Client JSON JSON API JSON Client (Pre-)Rendering Logic Routing HTML

Slide 30

Slide 30 text

@stilkov Special case: Searchability No Hydration needed

Slide 31

Slide 31 text

@stilkov State Business Logic Routing Rendering Logic Look & Presentation Logic Server Client JSON JSON API JSON Client (Pre-)Rendering Logic Routing HTML Hydration

Slide 32

Slide 32 text

@stilkov State Routing Rendering Logic Look & Presentation Logic Server Client JSON JSON Client (Pre-)Rendering Logic Routing HTML Hydration Business Logic JSON API State Business Logic Same functionality,
 different languages!

Slide 33

Slide 33 text

@stilkov State Routing Rendering Logic Look & Presentation Logic Server Client JSON JSON Client (Pre-)Rendering Logic Routing HTML Hydration Business Logic JSON API State Business Logic Much, much more JavaScript

Slide 34

Slide 34 text

@stilkov

Slide 35

Slide 35 text

@stilkov Everyone has JavaScript, right? All your users are non-JS while they're downloading your JS If they're on a train and their net connection goes away before your JavaScript loads, then there's no JavaScript. Did the HTTP request for the JavaScript complete? Does the corporate firewall block JavaScript? Does their ISP or mobile operator interfere with downloaded JavaScript? Does their browser support the JavaScript you’ve written? Do your users get the JavaScript?

Slide 36

Slide 36 text

@stilkov The cost of JavaScript in 2019

Slide 37

Slide 37 text

@stilkov What’s the alternative?

Slide 38

Slide 38 text

@stilkov ROCA: Resource-oriented Client Architecture http://roca-style.org

Slide 39

Slide 39 text

@stilkov ROCA RESTful Server-side HTML (SSR) Application logic only on server No duplicated logic on client + No application logic on client! Client-side (self contained) JavaScript components =

Slide 40

Slide 40 text

@stilkov Client Side Logic is generic Presentation logic only. It enhances HTML HTML CSS Content Layout JavaScript Presentation logic

Slide 41

Slide 41 text

@stilkov Progressive Enhancement A web page needs to work without graphical elements, CSS and JS This ensures our page will even work under unfavorable circumstances We also lay the foundation for accessibility Does not mean that everything needs to work without CSS and JavaScript It means that the fundamental functionality of our web page relies on HTML only Every thing that goes beyond that is seen as an enhancement

Slide 42

Slide 42 text

@stilkov $('.multiselect', context).each(function() {
 $(this).multiselect({
 selectedList: 2,
 checkAllText: "Alle",
 uncheckAllText: "Keinen"
 }).multiselectfilter({label:"",
 width:"200px"});
 });

 Project
 
 DISCOVER
 IMPROVE
 MAGENTA
 ROCA
 ROCKET
 


Slide 43

Slide 43 text

@stilkov http://rocair.herokuapp.com http://roca-airways.herokuapp.com

Slide 44

Slide 44 text

@stilkov Components

Slide 45

Slide 45 text

@stilkov Browser Platform Component Application JavaScript Framework Component Component Component

Slide 46

Slide 46 text

@stilkov Browser Platform Application JavaScript Framework Component Component

Slide 47

Slide 47 text

@stilkov Browser Platform Component Component Component Component Application Component

Slide 48

Slide 48 text

@stilkov Component 
 
 Browser Platform Component Component Component Application

Slide 49

Slide 49 text

@stilkov Component Browser Platform Component Component Component Glue Code Application

Slide 50

Slide 50 text

@stilkov $("input.date").datepicker();

Slide 51

Slide 51 text

@stilkov
  • About …
  • Discussion

lorem ipsum dolor sit amet

…
    …
$(".tabs").tabs();

Slide 52

Slide 52 text

@stilkov
  • About …
  • Discussion

lorem ipsum dolor sit amet

…
    …
$(".tabs").tabs();

Slide 53

Slide 53 text

@stilkov
  • About …
  • Discussion

lorem ipsum dolor sit amet

…
    …
$(".tabs").tabs(); Unobtrusive JavaScript

Slide 54

Slide 54 text

@stilkov Component Browser Platform Component Component Component Glue Code HTML JS CSS HTML JS CSS HTML JS CSS HTML JS CSS ✓ Progressive Enhancement

Slide 55

Slide 55 text

@stilkov Component Browser Platform Component Component Component Glue Code HTML JS CSS HTML JS CSS HTML JS CSS HTML JS CSS ✓ Progressive Enhancement Progressive enhancement is not about dealing with old browsers, it's about dealing with new browsers. — Jeremy Keith (@adactio)

Slide 56

Slide 56 text

@stilkov
  • About …
  • Discussion

lorem ipsum dolor sit amet

…
    …
$(".tabs").tabs();

Slide 57

Slide 57 text

@stilkov
  • About …
  • Discussion

lorem ipsum dolor sit amet

…
    …
$(".tabs").tabs();

Slide 58

Slide 58 text

@stilkov
  • About …
  • Discussion

lorem ipsum dolor sit amet

…
    …
$(".tabs").tabs();

Slide 59

Slide 59 text

@stilkov
  • About …
  • Discussion

lorem ipsum dolor sit amet

…
    …
$(".tabs").tabs(); Custom Elements

Slide 60

Slide 60 text

@stilkov Component Browser Platform Component Component Component Glue Code

Slide 61

Slide 61 text

Why the hate? @stilkov

Slide 62

Slide 62 text

@stilkov General benefits

Slide 63

Slide 63 text

@stilkov Classic, server-side rendered web applications are much simpler, use less bandwidth, scale better, are more resilient, and a good match for most user needs

Slide 64

Slide 64 text

@stilkov Many single-page apps are built carelessly and improve developer experience (if at all) at the cost of decreased usability and architectural complexity

Slide 65

Slide 65 text

@stilkov Large-scale benefits

Slide 66

Slide 66 text

@stilkov Any sufficiently complicated JavaScript client application contains an ad hoc, informally- specified, bug-ridden, slow implementation of half a browser. (Me, with apologies to Phillip Greenspun) Why choose a monolith if you don’t have to?

Slide 67

Slide 67 text

@stilkov In-page Cross-page JavaScript method calls Links & redirects Shared abstractions & frameworks Micro-architecture Common language runtime HTTP HTML 5 JS platform Standard Browser

Slide 68

Slide 68 text

@stilkov Sometimes, JS-centric applications/SPAs are the right choice, but very rarely for every part of your system

Slide 69

Slide 69 text

@stilkov If you’re a fan of single page apps,
 at least build more than one • Don’t reinvent browser integration features • Accept some inefficiency • Trade-off for framework independence • Avoid modularity à la Java EE, OSGi etc.

Slide 70

Slide 70 text

@stilkov Use your favorite SPA framework – when it’s appropriate. Stick to basic, simpler stuff, when it’s sufficient – likely, most of the time.

Slide 71

Slide 71 text

@stilkov Stefan Tilkov @stilkov
 [email protected]
 Phone: +49 170 471 2625 innoQ Deutschland GmbH Krischerstr. 100 40789 Monheim am Rhein Germany Phone: +49 2173 3366-0 innoQ Schweiz GmbH Gewerbestr. 11 CH-6330 Cham Switzerland Phone: +41 41 743 0116 www.innoq.com Ohlauer Straße 43 10999 Berlin Germany Phone: +49 2173 3366-0 Ludwigstr. 180E 63067 Offenbach Germany Phone: +49 2173 3366-0 Kreuzstraße 16
 80331 München Germany Phone: +49 2173 3366-0 @stilkov That’s all I have.
 Thanks for listening!

Slide 72

Slide 72 text

@stilkov www.innoq.com OFFICES Monheim Berlin Offenbach Munich Hamburg Zurich FACTS ~150 employees Privately owned Vendor-independent SERVICES Strategy & technology consulting Digital business models Software architecture & development Digital platforms & infrastructures Knowledge transfer, coaching & trainings CLIENTS Finance Telecommunications Logistics E-commerce Fortune 500 SMBs Startups