JS Module Server

Loading Javascript
Szabolcsi-Tóth Szabolcs
Senior Frontend Developer at Ustream.
@_Nec
nec@shell8.net

Loading Javascript
These slides are
not about:
detailing defer/FIF js
embedding on site
or putting the js after the
body or in the head
These slides are
supposed to be
about:
detailing why static js
loading, packaging and
building leads to nowhere
on the long run
and a possible solution

Inline scripting
● Quick sandboxing
● Small demos
● Learning
● Testing http://www.flickr.com/photos/pfly/399346124/

Javascript Files
● Separate code from markup
● Serve assets from a server
http://www.flickr.com/photos/seiho/2183406722/

Code organization
Webapp complexity
increases
Loadtime becomes
an issue :(
Use of functions,
classes, modules
Codebase grows
http://www.flickr.com/photos/chiotsrun/4390949664/

Code compilation / build
Much less http requests
Tools:
● concatenation
● uglify / yuicompressor
http://www.flickr.com/photos/halfbisqued/2353845688/

Compile all the js that the
current page might need:
Several smaller files
Compile all js that we need:
One huge file
Create js groups according to
page needs

One huge file
page needs
What is the problem with that?

Take any page, coded, optimized, built,
deployed

Uh-Oh.. The Product / UX / Design division
enters the room!

The new killer feature, that saves us!
Click here to
close

The given feature is used on the page,
or
The visitor might use it on the page
"the current page might need"
One page gets n+1 new feature:
The js compiled group for that page grows even more
heavy
Do we really need it onLoad?
Lots of unused code, that waits for the user:
overhead, slows load time.

Async loading!
Load only the most necessary js onLoad!
Then, for every feature the user wants,
load the js runtime.
http://www.flickr.com/photos/thenationalguard/8029811025/
● Feature based code, not page based
code
● Small lag in UX, but faster page start
● Loose module coupling, better code

One huge file
page needs
And what is the problem with that?

Dependency handling
The problem with predefined js
groups:
http://www.flickr.com/photos/wongjunhao/2761709029/
● add js by planned use
(add a feature, that can be used)
● add js by failsafe use
("this might come handy" or "make sure to have
this")
● group is built at deploy

Dependency handling
The group is created for a
planned usage
The group contents has nothing
to do with the real functioning
site or app

Dependency handling
Let the js codebase define it's own
dependency
Here come the modules!
AMD
(Asynchronous Module Definition)
Designed for the
web
CommonJS
Designed for the
server (nodejs)

Dependency handling
AMD structure
define (
// optional, used in build code
'moduleName',
// dependencies
['modules/Module1', 'modules/Module2'],
// module definition
function (module1, module2) {
});

Async loading + Modules
Module loader
a javascript utility, that:
● handles module definitions and
requirements
● loads modules from a remote
server
require.js, curl.js, etc
http://www.flickr.com/photos/redux/4298421692/

Require.js example
Every dependency starts a new request
Lots of requests - not very good

Need fewer requests?
Introduce async packaging!
Request and load packaged javascripts
async, instead of each file.
But how will the client know of the
available package list?

Possible solution:
expose the built package list, and contents
to the client
Why not?
In case of a large codebase, this can be an
uncomfortably large amount of data. Also,
exposes the whole codebase to the client.

Another problem with pre-built packages,
prepared for async load:
Overlapping dependencies are inevitable
Pack_1 Pack_2 Pack_3
Foo.js Foo.js
Bar.js Bar.js
Either package every common
dependency, every time it's needed...

Overlapping dependencies...
Or put those commons to the page
onLoad
Pack_1 Pack_2 Pack_3
Pack_onLoad Foo.js Bar.js
Codebase at onLoad starts grow fast,
getting slower pageload :(

So...
Either we have lots of
requests
Or big files, with massive
redundancy and
duplicated code.
Pack_1
Pack_2
Pack_3
Foo.js
Foo.js
Bar.js
Bar.js

Are we keep circling around the
same issue?

JS Module Server
Time to rethink the way of
serving javascript instead of
loading it as a fully static asset.
Put the dependency handling to
the server side.
http://www.flickr.com/photos/alca_impenne/4295937972/

JS Module Server
Credit where it's due!
Malte Ubl & John Hjelmstad
http://www.youtube.com/watch?v=mGENRKrdoGY
Two guys at Google/Gmail

JS Module Server
Request just one module, the
server finds it's dependencies,
packs and serves.
/js/+app/Foo.js
On the client side, we keep track
of what modules have been
requested already.

JS Module Server
At the next requested module, we
tell the server which modules
were requested already
(note: not all the received, just the requested)
These are "subtracted" from the
request
/js/+app/Bar-app/Foo.js

JS Module Server
/js/+app/Bar-app/Foo.js
The server takes the requested module
dependencies, and subtracts all those, that
have been served for the client already.
The new package only contains code
that haven't been loaded by the client.

JS Module Server
/js/ +app/Bar - app/Foo.js
No redundant modules.
app/Bar
class/Lorem
class/Ipsum
class/Sit
...
app/Foo
class/Lorem
class/Sit
class/Dolor
...
app/Bar
class/Ipsum
...

JS Module Server
Providing solution for:
" lots of requests "
Thinking in feature-oriented code, instead of the page-
oriented code, these async loads can refer to only the
requested feature. One request per feature.
" big files, with massive redundancy and duplicated code "
Only that code is packaged, that haven't been served
already.

JS Module Server
Additional gains
● full i18n support (can require groups by locale)
● cacheable urls
● sourcemap support (via uglify2)
● the full codebase is loaded by the
server, it can run tasks on it, debug
output, etc. (strip all console.* for example)
● could handle CSS later (with supporting
preprocessors like SASS/LESS)

JS Module Server
● Parallel requests
(add a counter-callback parameter,
which determines the right parse order
for the module loader, like JSONP)
● Handle browser cache properly
(this one is a tricky one, but we're on
the way. Changing the url is 100% sure,
but If-Modified-Since would be nicer)
Things to be done

JS Module Server
Things to be done
● Put it to production
(soon on Ustream)
● Open source it
(soon on GitHub)

JS Module Server

More Related Content

What's hot (20)

Viewers also liked (6)

Similar to JS Module Server (20)

More from Szabolcs Szabolcsi-Tóth (6)

Recently uploaded (20)

JS Module Server