The document discusses script loading techniques. It analyzes the limitations of existing approaches like using <script> tags and document.write(). It also reviews past script loaders like LABjs and argues for a standardized general script loader. Such a loader should support parallel loading, ordered execution, and work across all browsers without hacks or exceptions. Future areas of focus could include preloading, modules, and leveraging new browser capabilities through standards.

1. The Once and Future
Script Loader
Kyle Simpson
@getify
http://getify.me

2. <script>

3. Why not just combine all your files?
• different pages, different scripts
• cacheability
• parallel loading
• on-demand/lazy-loading

4. concat vs. parallel?
BOTH

5. document.write()

6. document.write()
Must
Die!

7. Performance

8. IE7-, FF3-, Opera

9. IE8, FF3.5/3.6, Chr 14-

10. IE9+, FF4+
Script Loaders

11. comparing DOM-ready times across loading techniques

12. <script> tags also suck because...
• browser-specific scripts
• conditional loading/URLs
• event handling

13. WTF Loader
document.write("<script src='...'></sc"+"ript>");

14. Surely we can do better!?

15. XHR?

16. Making progress... but not there yet

17. What's hard about script loading?

18. A general script loader should...
• load any script, at any time, from
anywhere... except document.write()
• have performance at or better than
<script> in modern browsers
• equivalent behavior in all browsers

19. A general script loader should also...
• avoid: hacks, UA sniffing
• feature-detect
• have as few exception-cases as possible

20. General script loader feature creep...
• trying to handle document.write()
• loading CSS
• dependency management
• delaying DOM-ready

21. Script loading requires...
• loading many scripts in parallel
(race to finish loading ASAP)
• ensuring execution order (not ASAP)

22. LABjs

23. LABjs: performance
script loader

24. LABjs: performance
script loader

25. What was wrong with LABjs?
• ugly source code
• lots of hacks
• exception cases
• brittle (not future proof)

26. LABjs 2.0
• readable source code
• "future proof " feature detects
• fewer exception cases
• better performance
http://labjs.com

27. Anyone can write a loader!
(and many devs have)

28. https://spreadsheets0.google.com/spreadsheet/ccc?key=tDdcrv9wNQRCNCRCflWxhYQ

29. Loaders are competing
more on APIs than on
features or performance

30. They're also copying
each other (good and bad)

31. But, can their
functionality be
trusted?

32. Testing is much harder than
most realize

33. What should a
loader do?

34. Real Preloading
http://wiki.whatwg.org/wiki/Script_Execution_Control

35. IE4+ ftw?

36. Ordered Async
async=false
FF4+, Chr 12+, IE10p2+, Webkit/Safari, Opera (soon!)
http://wiki.whatwg.org/wiki/Dynamic_Script_Execution_Order

37. How?
1. try real preloading
2. try ordered async
3. try same-domain XHR
4. fall back on "cache preloading"

38. Competition is good, only if
community is educated

39. Browsers do not yet give us
what we really need

40. Co-opetition is much
healthier for the
community

41. W3C, WHATWG
http://wiki.whatwg.org/wiki/Category:Proposals

42. W3C, WHATWG
http://ygp.go.ly/script-preloading
http://odq.go.ly/load-error-events

43. We'll accomplish more if we
work together

44. Future, The Script Loader

45. Preloading
(deferred execution)

46. Modules
(CommonJS, AMD, etc)

47. Native Modules
(ES-Harmony?)

49. "Script Loader of my dreams"

50. What else?
• timeouts
• load abort
• error handling
• load priority

51. And now for something
completely different...
Questions?

52. Kyle Simpson
@getify
http://getify.me
http://wiki.whatwg.org/wiki/Category:Proposals
http://labjs.com