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
210
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
1k
The Evolution of the "Web App" - FluentConf 2015
henrikjoreteg
6
1.2k
BackboneConf 2014
henrikjoreteg
3
470
A Single Page Story – http://ffconf.org/
henrikjoreteg
12
1.6k
Making WebRTC Awesome, CascadiaJS 2013
henrikjoreteg
9
2.2k
EdgeConf 2013 - Realtime/WebRTC Intro Talk
henrikjoreteg
1
200
WebRTC - JSConf Brazil 2013
henrikjoreteg
10
1.3k
getUserMedia();
henrikjoreteg
1
190
The State of Realtime at &yet
henrikjoreteg
6
420
Other Decks in Technology
See All in Technology
業務自動化プラットフォーム Google Agentspace に入門してみる #devio2025
maroon1st
0
170
いま注目しているデータエンジニアリングの論点
ikkimiyazaki
0
550
ZOZOのAI活用実践〜社内基盤からサービス応用まで〜
zozotech
PRO
0
130
20250929_QaaS_vol20
mura_shin
0
110
about #74462 go/token#FileSet
tomtwinkle
1
260
AWSのProductのLifecycleについて
stknohg
PRO
0
300
生成AIを活用したZennの取り組み事例
ryosukeigarashi
0
180
DataOpsNight#8_Terragruntを用いたスケーラブルなSnowflakeインフラ管理
roki18d
1
300
OpenAI gpt-oss ファインチューニング入門
kmotohas
2
630
Function calling機能をPLaMo2に実装するには / PFN LLMセミナー
pfn
PRO
0
750
Pythonによる契約プログラミング入門 / PyCon JP 2025
7pairs
4
2.3k
Windows で省エネ
murachiakira
0
150
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
513
110k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
188
55k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6.1k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
Designing Experiences People Love
moore
142
24k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.7k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Side Projects
sachag
455
43k
GitHub's CSS Performance
jonrohan
1032
460k
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