DoneJS Contributors Meeting – 2017-07-14

Please add topics for discussion (and your status if you’re a contributor).


Live Stream:


  • React View Model

Last week:

Next week:

  • Still some more CanJS 3.9 stuff to promote :slight_smile:
  • Close out a bunch of in-progress work
  • Figure out upcoming priorities


Last week:



can-ndjson-stream 0.1.6

can-migrate-codemods 0.0.1


can-migrate-codemods getting started docs

Next Week

Continue on can-migrate

Topic: can-reflect

  • speed up can-stache by using Observations instead of computes
  • provide a path to using other types of observables in templates (kefir streams, etc)
  • clean up code throughout canjs by using a consistent set of APIs

Last week

I was not able to do contributions I had a lot of work on my daily job so I did extra hours, sorry guys.

Next week

I will work on canjs/donejs issues.

This week:

  • Streaming presentation

Next Week:

  • Vacation


  • streaming presentation preview

Attendees: @bgando @chasen @cherif_b @christopher @justinbmeyer @matthewp @phillipskevin

Discussed topics:

React View Model:

NDJSON Streams:

Reflecting on can-reflect:

  • Did we reach our original goals?
    • can-stache is faster but not as fast as the initial prototypes were; still have some more work to do
    • Using other types of observables (like Kefir streams) hasn’t been built out, but it’s possible now
    • All of CanJS’s code is much cleaner thanks to can-reflect
  • can-observation/reader/ is now can-stache-key
  • We got into the weeds on the above points and how computes, streams, and promises can/should work (within a stache template)

Streaming presentation preview:

  • Traditional client-side rendered SPAs: send HTML to start loading JS, JS fetches data, all data comes back to render to the page
  • DoneJS’s current server-side rendering improves this by including HTML & data in the initial response, but still has to wait for all the data to come back before responding
  • New incremental server-side rendering:
    • Initial response will include the bare-minimum to start streaming the server-side rendered HTML body
    • As the server’s virtual DOM is constructed, the same instructions will be streamed to the client, allowing it to build the page before the app’s JS has been loaded
    • This results in your page being progressively server-side rendered
    • Maybe in the future: if the app’s JS finishes before all of the HTML is rendered, have JS take over
  • Matthew’s article: Utilizing HTTP/2 PUSH in a Single Page Application
  • This approach allows any server-side rendered app to be progressively loaded, because we’re just sending the necessary DOM mutations over the wire
    • If your app renders one component, then a second one that manipulates the first one, that’s fine because the DOM events will be played in the same order on the client