1 of 15

Isomorphic Web Apps

Daniel Steigerwald

twitter.com/steida

javascript-skoleni.cz

2 of 15

Isomorphic Web Apps

  • tl;dr
  • A (very) brief history of web development
  • Benefits
  • Prerequisites
  • How?
  • Isomorphic app architecture
  • Critique
  • Anti-patterns
  • My dev experiences

3 of 15

tl;dr

Isomorphic app consists of code which can be shared between client and server.

It's not a future. It's viable pattern ready for production today.

Isomorphic web app is what you get, when you write clean & DRY code both for browser and server.

4 of 15

A (very) Brief History of web development

  • Traditional server-rendered multi-page applications (MPA)
    • Rails, ASP.NET, Nette, Django, Play...
  • Client-rendered single-page applications (SPA)
    • Angular, Ember, Backbone…

So server gives us data, and client gives us interactivity...

Of course we can mix client and server frameworks, but...

Schizophrenic Web App Development!

  • two languages
  • two dev stacks
  • two business models
  • two templates
  • two routings
  • two validations
  • two enumerations
  • two...

5 of 15

Benefits - The Best of Both Worlds

  • Performance
    • MPA - Serving fully-formed HTML is fast. Speed matters.
    • SPA - AJAX, transport data instead of HTML
  • Connection quality
    • SPA can handle client state, sync instead of save
  • Accessibility
    • MPA - screen readers needs HTML
  • SEO
    • MPA - Google will always prefer MPA. Even if Google treats them the same, SPAs have significantly slower initial page-load speed and that negatively affects SEO. To serve fully-formed HTML, developers have resorted to crazy workarounds like rendering SPAs in headless browsers and serving HTML extracted from there. Needless to say, this introduces a whole new level of complexity. (Hi Angular!)
  • Maintainability
  • UX
    • SPA - more interactivity, optimistic UI, offline first, client first, mobile first.
  • And more…

6 of 15

Benefits - The Best of Both Worlds

So choose SPA or MPA? False dilemma!

Isomorphic App.

  1. On first page load, serve real server-rendered HTML.
  2. Client-side JS app bootstraps on top of server-rendered HTML rather than bootstrapping into an empty div.
  3. From that point on, it's a client-side JS app.

7 of 15

Prerequisites

  • The same language on client and server
    • JavaScript, Dart, Clojure[Script], who else?
  • Isomorphic module loader
  • Isomorphic libraries
    • Closure Library, React.js
    • Angular, Ember, and other 243 frameworks from todomvc.com

  • Knowledge!
    • single responsibility principle
    • arguments passing (known as dependency injection)

8 of 15

How?

  • Build your own (better)
    • Not as hard as it looks, JavaScript ecosystem is friendly and mature.
    • You will learn: Times of monolithic JS frameworks are over.
      • Assemble stack exactly you need

Remember, it's granular process.

9 of 15

Isomorphic App Architecture

  • view
    • reactjs.org - I can't recommend anything else. Why React.js is the best? Ask: FB, Github, Yahoo, Mozilla, Airbnb, Reddit, Khan Academy, ClojureScript Om, Adobe Brackets…
  • router
  • stores
    • Flux versus Ember computed properties, or Backbone model events, or Angular scope hierarchies and scope events, or…
  • client/server storages
    • Completely up to you. Mongo,$.ajax, whatever.

Congrats! You have your own framework! :-)

Remember, the times of One-True-Best-Framework™ are over.

10 of 15

Critique - Bullshit

Don't use one language for everything. Use as many languages as you wish and microservices too.

11 of 15

Critique - Thoughtful

It's new, people does not know yet how to do it. I need something right now. For my purposes Nette works well. I already invested a lot in ASP.NET. Etc.

12 of 15

Anti-patterns

  • meteor.com
    • Closed ecosystem unfortunately simpler then simple. A similar story as with Angular.js
  • if (server?) { … }
    • You basically just lost control over client code size. Yeah, that code comes from Meteor.
  • Single Responsibility Principle violation
    • Client side router is and always will be different, than server side router. Don't mix responsibilities.

13 of 15

My dev Experiences

  • rerender everything is panacea
  • React state and props versus App State
  • async error handling
    • Promises Now
    • Future: Communicating sequential processes
  • offline first and optimistic UI, sync over save
  • frontend first
  • learn patterns, not frameworks

14 of 15

  • Este.js is my meta-framework
    • the state of art tools for web development
    • github.com/steida/este
    • The goal is: Not even line of my own code!

  • Songary is my sandbox
    • the place where I'm experimenting
    • github.com/steida/songary

15 of 15

Thank you!

Questions, mentoring, angel development. daniel@steigerwald.cz

https://twitter.com/steida

javascript-skoleni.cz

Happy coding!