Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
I've seen the future
Search
Henrik Joreteg
May 07, 2014
Technology
1
180
I've seen the future
Talk I gave for JS group in Jönsköping, Sweden. May 7, 2014
Henrik Joreteg
May 07, 2014
Tweet
Share
More Decks by Henrik Joreteg
See All by Henrik Joreteg
SeattleJS May 14, 2015
henrikjoreteg
1
990
The Evolution of the "Web App" - FluentConf 2015
henrikjoreteg
6
1.1k
BackboneConf 2014
henrikjoreteg
3
440
A Single Page Story – http://ffconf.org/
henrikjoreteg
12
1.6k
Making WebRTC Awesome, CascadiaJS 2013
henrikjoreteg
9
2.1k
EdgeConf 2013 - Realtime/WebRTC Intro Talk
henrikjoreteg
1
160
WebRTC - JSConf Brazil 2013
henrikjoreteg
10
1.2k
getUserMedia();
henrikjoreteg
1
170
The State of Realtime at &yet
henrikjoreteg
6
410
Other Decks in Technology
See All in Technology
Building Products in the LLM Era
ymatsuwitter
10
4.4k
Datadogとともにオブザーバビリティを布教しよう
mego2221
0
130
飲食店予約台帳を支えるインタラクティブ UI 設計と実装
siropaca
6
1.4k
WAF に頼りすぎない AWS WAF 運用術 meguro sec #1
izzii
0
460
地方拠点で エンジニアリングマネージャーってできるの? 〜地方という制約を楽しむオーナーシップとコミュニティ作り〜
1coin
1
130
データの品質が低いと何が困るのか
kzykmyzw
6
1k
家電アプリ共通PF "Linova" のAPI利用とPostman活用事例ご紹介
yukiogawa
0
130
Developers Summit 2025 浅野卓也(13-B-7 LegalOn Technologies)
legalontechnologies
PRO
0
150
第13回 Data-Centric AI勉強会, 画像認識におけるData-centric AI
ksaito_osx
0
360
Bounded Context: Problem or Solution?
ewolff
1
210
開発者が自律的に AWS Security Hub findings に 対応する仕組みと AWS re:Invent 2024 登壇体験談 / Developers autonomously report AWS Security Hub findings Corresponding mechanism and AWS re:Invent 2024 presentation experience
kaminashi
0
190
FastConnect の冗長性
ocise
1
9.6k
Featured
See All Featured
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Automating Front-end Workflow
addyosmani
1367
200k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
27
1.9k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
How STYLIGHT went responsive
nonsquared
98
5.3k
Testing 201, or: Great Expectations
jmmastey
41
7.2k
Speed Design
sergeychernyshev
25
780
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
29
2.2k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
8
270
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
20
2.4k
Transcript
I’ve seen the future @HenrikJoreteg
JAVASCRIPT APPLICATIONS
WAIT?!
SERVER? COMMAND LINE? BROWSER?
WEB APPLICATIONS
WAIT?!
WHAT IS A WEB APP REALLY?
THE WEB HAS AN
RAILS/.NET/DJANGO
None
1. REQUEST
1. REQUEST 2. PROXY/MIDDLEWARE
1. REQUEST 2. PROXY/MIDDLEWARE 3. HANDLER
1. REQUEST 2. PROXY/MIDDLEWARE 3. HANDLER •DATABASE CALL
1. REQUEST 2. PROXY/MIDDLEWARE 3. HANDLER •DATABASE CALL •TEMPLATING
1. REQUEST 2. PROXY/MIDDLEWARE 3. HANDLER •DATABASE CALL •TEMPLATING •RETURN
HTML
THAT’S A WEB APP!
WAIT?!
None
GMAIL?
GMAIL? FACEBOOK?
GMAIL? FACEBOOK? EVERNOTE?
GMAIL? FACEBOOK? EVERNOTE? DROPBOX?
GMAIL? FACEBOOK? EVERNOTE? DROPBOX? TALKY.IO?
THE WEB HAS CHANGED
"But, I’m not building Facebook"
None
1. HTML INTERFACE
1. HTML INTERFACE 2. API
1. HTML INTERFACE 2. API 3. iOS APP
1. HTML INTERFACE 2. API 3. iOS APP 4. ANDROID
APP
AS SOON AS THERE IS MORE THAN A SINGLE WEB
INTERFACE?
SOMETHING GREATER THAN A WEB APP
SO WHAT?
IT CHANGES YOUR ARCHITECTURE
LET’S TALK SCIENCE!
COMPUTER SCIENCE
#1 SEPARATION OF CONCERNS
#2 ENCAPSULATION
SO HOW DID WE DO?
1. REQUEST 2. PROXY/MIDDLEWARE 3. HANDLER •DATABASE CALL •TEMPLATING •RETURN
HTML
MAYBE NOT PERFECT…
…BUT IT GETS BETTER
…BY WHICH I MEAN WORSE
WE SEND JAVASCRIPT!
None
1. CODE WITH OUR CONTENT
1. CODE WITH OUR CONTENT 2. AJAX TO FETCH MORE
DATA
1. CODE WITH OUR CONTENT 2. AJAX TO FETCH MORE
DATA 3. WE DO TEMPLATING AGAIN!
None
4. JSON API
4. JSON API 5. DASHBOARD APP
4. JSON API 5. DASHBOARD APP 6. SUPPORT TOOL APP
4. JSON API 5. DASHBOARD APP 6. SUPPORT TOOL APP
7. MOBILE WEB APP
None
WHAT IS THE ALTERNATIVE?
HOW DO WE SEPARATE CONCERNS?
API SERVERS SPEAK DATA
CLIENTS DO PRESENTATION
MOST CAPABLE UBIQUITOUS RUNTIME ON THE PLANET
WE SHOULD STOP TREATING IT LIKE A DUMB DOCUMENT RENDERER…
WEB APP iOS APP Mobile Web App HTML RSS JSON
MAIN HTML INTERFACE JSON HTML PUBLIC API JSON FEED READERS 3RD PARTIES JSON ADMIN INTERFACE HTML
iOS CLIENT DASHBOARD JS CLIENT MAIN JS CLIENT 3RD PARTY
CLIENT SERVICE INTEGRATION JSON SESSION API SERVICE API(s) REDIS RIAK SOLR SERVICE API(s) SERVICE API(s) SERVICE APIs
WHAT DO WE GAIN?
EASIER TO DISTRIBUTE WORK TO A TEAM
EASILY BUILD CLIENTS FOR NEW PLATFORMS
ISOLATE PERFORMANCE ISSUES
WAY EASIER TO: TEST
WAY EASIER TO: MAINTAIN
WAY EASIER TO: SCALE
WAY EASIER TO: SECURE
SOLVE SCALING ISSUES AT THE EXACT BOTTLENECK
EASILY BUILD VARIATIONS OF YOUR CLIENTS
A/B TESTING ANYONE?
SERVE CLIENT APPLICATION FROM STATIC SERVERS
WORK ON A CLIENT LOCALLY AGAINST PRODUCTION API
"That’s a nice theory, but how?"
SEND THE APP ITSELF TO THE BROWSER INSTEAD OF THE
RESULT OF RUNNING IT
"You have to send the browser HTML!"
THE ENTIRE HTML FOR AND BANG: GET https://andbang.com/*
SO HOW DO WE BUILD THIS WAY?
{{ DO A DEMO, HENRIK! }}
HOT NEW JAVASCRIPT FRAMEWORK OF THE WEEK!
HOW DO YOU PICK?
WHERE DO YOU START?
andyet.com
~27 DEVELOPERS GOBS OF JS APPS REALTIME APPS
HOW WE DECIDED WHAT TO USE:
GOALS
1. BUILD GREAT APPS GOALS
1. BUILD GREAT APPS 2. QUICKLY GOALS
1. BUILD GREAT APPS 2. QUICKLY 3. WRITE JAVASCRIPT GOALS
1. BUILD GREAT APPS 2. QUICKLY 3. WRITE JAVASCRIPT 4.
HIGH LEVEL OF CONTROL GOALS
1. BUILD GREAT APPS 2. QUICKLY 3. WRITE JAVASCRIPT 4.
HIGH LEVEL OF CONTROL 5. INSANELY MODULAR/FLEXIBLE GOALS
1. BUILD GREAT APPS 2. QUICKLY 3. WRITE JAVASCRIPT 4.
HIGH LEVEL OF CONTROL 5. INSANELY MODULAR/FLEXIBLE 6. NOT TOO ABSTRACT GOALS
FOUR BIG PROBLEMS TO SOLVE:
1. FETCHING/STORING STATE
2. RENDERING HTML
3. BINDING STATE TO DOM
4. CLIENTSIDE ROUTING
A FEW SPECIFIC FRAMEWORKS:
AngularJS
1. easy to start AngularJS
1. easy to start 2. logic mixed into HTML AngularJS
1. easy to start 2. logic mixed into HTML 3.
you’re learning Angular, not JS AngularJS
1. easy to start 2. logic mixed into HTML 3.
you’re learning Angular, not JS 4. highly abstracted AngularJS
Ember
1. Lots of decisions made for you Ember
1. Lots of decisions made for you 2. Everything is
"ember" as a base Ember
1. Lots of decisions made for you 2. Everything is
"ember" as a base 3. Lack of flexibility Ember
None
Backbone
1. Basic building blocks Backbone
1. Basic building blocks 2. Extremely flexible Backbone
1. Basic building blocks 2. Extremely flexible 3. You have
to solve more problems Backbone
We made HumanJS:
1. Backbone as a base We made HumanJS:
1. Backbone as a base 2. Stricter Models We made
HumanJS:
1. Backbone as a base 2. Stricter Models 3. Conventions
for binding to views We made HumanJS:
HumanJavascript.com
What’s next?
Shh…
AMPERSAND.js
None
1. Un-frameworky non-framework
1. Un-frameworky non-framework 2. Backbone ripped apart
1. Un-frameworky non-framework 2. Backbone ripped apart 3. Individual npm
modules
1. Un-frameworky non-framework 2. Backbone ripped apart 3. Individual npm
modules 4. Insanely flexible
None
5. Clear starting point
5. Clear starting point 6. CommonJS + Browserify
5. Clear starting point 6. CommonJS + Browserify 7. Directory
of "sanctioned" modules
5. Clear starting point 6. CommonJS + Browserify 7. Directory
of "sanctioned" modules 8. IE9+ only
WE’RE BUILDING APPS WITH IT ALREADY
ampersandjs.com
QUESTIONS?
THANKS! @HenrikJoreteg