AJS — Asynchronous Templating in Node

3,821 views
3,667 views

Published on

1 Comment
4 Likes
Statistics
Notes
  • Hi, I've build a simple project like AJS: https://github.com/Ournet/nai - NAI
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
3,821
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
6
Comments
1
Likes
4
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • We haven’t progressed since the days of inline PHP, in fact we’ve regressed\n Node’s non-blocking architecture is being handicapped by archaic templating conventions\n We need something completely new (at least under the hood)\n
  • We haven’t progressed since the days of inline PHP, in fact we’ve regressed\n Node’s non-blocking architecture is being handicapped by archaic templating conventions\n We need something completely new (at least under the hood)\n
  • \n
  • \n
  • \n
  • \n
  • From the end user’s perspective, we’re finally back the experience we had with inline PHP.\nRegardless, we’re stuck with Ruby’s blocking IO calls. \n
  • From the end user’s perspective, we’re finally back the experience we had with inline PHP.\nRegardless, we’re stuck with Ruby’s blocking IO calls. \n
  • From the end user’s perspective, we’re finally back the experience we had with inline PHP.\nRegardless, we’re stuck with Ruby’s blocking IO calls. \n
  • Somehow we have this assumption that whatever we write in Node will be non-blocking.\nUnfortunately this isn’t true on a per-request level... if you have a blocking function, Node blocks.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • The uncached performance is only relevant on the first page load.\nAfter that performance is MUCH better, and will only improve.\n
  • The uncached performance is only relevant on the first page load.\nAfter that performance is MUCH better, and will only improve.\n
  • 2. Thought of this last night actually...\n
  • 2. Thought of this last night actually...\n
  • 2. Thought of this last night actually...\n
  • Obviously Ryan was joking around, but in threory AJS could be used as\nan asynchronous “PHP” by simply serving up AJS files, mapping URIs\nto a directory structure. Not that you’d want to.\n
  • \n
  • AJS — Asynchronous Templating in Node

    1. 1. AJS: AsynchronousTemplating in Node(completing the async puzzle)
    2. 2. Who am I?Evan OwenSenior Developer @ LifeKrazeLover of Ruby, JS, Redis, gooddesign and asynchronous code.
    3. 3. History of TemplatingOld-school PHP: the template == your app
    4. 4. History of TemplatingOld-school PHP: the template == your appalready flushed
    5. 5. History of TemplatingOld-school PHP: the template == your appalready flushed blocking
    6. 6. OO PHP + template == worse
    7. 7. OO PHP + template == worse blocking
    8. 8. OO PHP + template == worse blocking nothing flushed!
    9. 9. Ruby + ERB template == just as bad
    10. 10. Ruby + ERB template == just as bad blocking
    11. 11. Ruby + ERB template == just as bad blocking nothing flushed!
    12. 12. Rails 3.1 Automatic Flushing == better
    13. 13. Rails 3.1 Automatic Flushing == better<head> flushed
    14. 14. Rails 3.1 Automatic Flushing == better<head> flushed still blocking
    15. 15. Rails 3.1 Automatic Flushing == better<head> flushed still blocking other db calls must wait
    16. 16. What about Node? It’s non-blocking, right? WRONG.Node will block (per-request)at your first blocking function.
    17. 17. Node + EJS == not enough
    18. 18. Node + EJS == not enoughnon-blocking
    19. 19. Node + EJS == not enoughnon-blocking non-blocking
    20. 20. Node + EJS == not enough non-blocking non-blockingblocking!
    21. 21. Node + existing async libs == frustrating node-asyncEJS
    22. 22. Node + existing async libs == frustrating node-asyncEJS things to worry about
    23. 23. Node + existing async libs == frustrating nun
    24. 24. Node + existing async libs == frustrating nun more things to worry about
    25. 25. Node + existing async libs == frustrating nun more things to worry about no logic allowed, loops are hard
    26. 26. What we need —
    27. 27. What we need —1. Familiar, standard syntax
    28. 28. What we need —1. Familiar, standard syntax2. Nothing extra to learn or think about
    29. 29. What we need —1. Familiar, standard syntax2. Nothing extra to learn or think about3. Completely non-blocking, able to continue rendering while waiting for callbacks
    30. 30. What we need —1. Familiar, standard syntax2. Nothing extra to learn or think about3. Completely non-blocking, able to continue rendering while waiting for callbacks4. Fast
    31. 31. Node + AJS == async, easy
    32. 32. Node + AJS == async, easy superset of JS (similar to EJS)
    33. 33. Node + AJS == async, easy superset of JS (similar to EJS) use callbacks naturally (can/should be defined in controller)
    34. 34. Node + AJS == async, easy superset of JS (similar to EJS) use callbacks naturally (can/should be defined in controller) include partials
    35. 35. How AJS works —
    36. 36. How AJS works —1. Parse source to an abstract syntax tree (AST)
    37. 37. How AJS works —1. Parse source to an abstract syntax tree (AST)2. Add “futures” hooks around callbacks
    38. 38. How AJS works —1. Parse source to an abstract syntax tree (AST)2. Add “futures” hooks around callbacks3. Recompile and cache optimized JS
    39. 39. How AJS works —1. Parse source to an abstract syntax tree (AST)2. Add “futures” hooks around callbacks3. Recompile and cache optimized JS4. Execute code inside a VM that manages and handles async callbacks
    40. 40. How callbacks are handled —
    41. 41. How callbacks are handled —1. At the exact spot a callback is passed to its async function, we create a “future” buffer.
    42. 42. How callbacks are handled —1. At the exact spot a callback is passed to its async function, we create a “future” buffer.2. We continue executing the template, flushing everything up until a callback that we’re still waiting on.
    43. 43. How callbacks are handled —1. At the exact spot a callback is passed to its async function, we create a “future” buffer.2. We continue executing the template, flushing everything up until a callback that we’re still waiting on.3. When each callback returns, we fill in its buffer and continue flushing down the page as we can.
    44. 44. JS Compatibility —Should be mostly complete, cancorrectly compile embedded jQueryand underscore.js source already.(no they aren’t templates, but they are complex JS)
    45. 45. What aboutperformance? —
    46. 46. What aboutperformance? —Parses ~40-50,000 lines/sec uncached.Good, not great (should improve).
    47. 47. What aboutperformance? —Parses ~40-50,000 lines/sec uncached.Good, not great (should improve).But AJS can render while Nodewaits on your DB calls, and pageloads will feel faster because<head> resources aren’t blocked.
    48. 48. Current limitations —
    49. 49. Current limitations —1. Since callbacks are detected and at runtime, callbacks can’t be nested. There may be some ways around this, but we may not want to encourage it...
    50. 50. Current limitations —1. Since callbacks are detected and at runtime, callbacks can’t be nested. There may be some ways around this, but we may not want to encourage it...2. There’s no layout nesting built into the middleware.
    51. 51. Current limitations —1. Since callbacks are detected and at runtime, callbacks can’t be nested. There may be some ways around this, but we may not want to encourage it...2. There’s no layout nesting built into the middleware.3. Others...
    52. 52. My inspiration —Your welcome, Ryan.
    53. 53. How to get it —1 - npm install ajs2 - github.com/kainosnoema/ajsSubmit issues, fork and improve!

    ×