my notes for day 1 throne of js, in org mode

gistfile1.txt

* day 1
** ashkenas on backbone
*** only 800loc
*** keeps your ui code stateless
*** a way to manage data
*** the expectations today are more then filling out forms and submitting them to the server
**** initial use of ajax was about as conservative as possible (html chunks)
*** philosophy is DIY ideal API
**** get the truth out of the DOM
***** the dom is not the document, it is the interface
***** UI is not an appropriate data source
*** debounce for implementing constant saving is a wicked cool use
*** BB is light and fast, it shouldn't be the bottleneck or noticable
**** isn't puritan, if you don't need a model, just use a value, everything else works
**** this is important, cause in js, writing a ton of code to solve a problem has a high cost
*** when to use backbone: when you have a lot of data and interaction
**** backbone gets you out of modal applications (if you want to do something, you go to a specific page)
**** modless means that you can see all your data, and many things to it
**** the most important thing about MV* is the separation between data and interface
**** people re-invent this wheel on any application of enough complexity
*** statelessness should be a way of life in ui programming
**** ui elements should not know or care about where they are, or where anything else is

** moschel on canjs
*** api is very positive sounding
*** 8.5k
*** can tries to provide the best features of large frameworks with the modularity of the small frameworks
**** helps prevent memory leaks
***** basically uses reference counting
**** live binding
***** automatically wires up binding based on what methods you call in your template
*** uses deferreds all over the place
** wycats on ember
*** inspirations
**** rails
***** conventions are good
      - dont spend time on trivial descisions
***** shared solutions are good
***** shared solutions should look similar
***** modularity is good
      - modularity should be hidden from casual users
***** clean internals is important for ongoing velocity
***** shipping is more important then perfect code
**** jquery
***** dealing with browser quirks sucks
***** repeating yourself sucks
***** you get leverage from shared solutions
      - community size has many benefits
**** sproutcore
***** universal declarative bindings
***** properties are a robust context
***** application structure
***** bad parts
****** hard to learn
****** coupled to a ui toolkit
****** file size (2-300k)
*** data bindings
**** some of the most sophisticated
     - it will figure out what needs to be updated in the dom
     - it does that update once
*** composable view framwork (widget)
*** setup and teardown (automatic memory management)
*** higher level eventing - no boilerplate
*** di of the various bits are handled for you
*** data management without the boilerplate
    - allows for swapping backends
*** router
    - conventions for state serialization
    - conventions to bring everything together based on the url
*** almost 1.0, when that hits breaking changes will be kept to a minimum
*** upcomming
**** server side rendering is on the roadmap
**** git model
**** local cache
**** better error handling
**** extended attributes - computed attrs++
**** offline support
** debergalis on meteor
*** we don't build for the original intent of the web
    - what do we want from a modern app?
*** distributed applications are a known, solved problem
    - the web is great for distribution
*** what we don't want is a stateles unidirectional protocol
*** what we need is a model where clients subscribe to changes in datasets
*** principals
    - data on the wire (not html)
    - same language/apis on the client and the server
    - security via rpc calls
    - push code without page reloads
*** redefining client/server
**** meteor apps are a network of peers that trust each other to varying degrees
**** the server is a "god peer"
**** all of the plumbing is abstracted
** ferrauolo - advocatus diaboli
*** rendering everything client side all the time is not always the best choice
** bender on jquery-mobile
*** even a browsers can have bizarre issues in mobile
**** a "tap" will fire "touch start" followed by "click"
*** android ics is such a small share its not worth mentioning
*** ics < is so, so bad
*** he wants jquery-mobile to mean "make mobile web sane" rather then "widgets for the mobile web"
** the battle of modest proportions :: render client side vs server side
*** server side rendering is a hack
    - you can't compare a ui done with client side vs server side
      rendering
*** its about the right tool for the job
    - wycats "My surgeon operated on me last week and did a great job,
      so I fired the workers working on my house because they used
      hammers rather then scalpels"
*** everyone agrees twitter made some bad choices
*** server side doesn't nessicarily mean faster (although it often is)
*** in meteor, there is no html. so it all becomes about client state serialization for initial load
*** in backbone, people are doing initial bootstrapping by running the same js on both the client and the server
*** in ember, they want to do this with convention based tooling, and don't think that there is any point in doing it other ways
*** angular is still talking about how to accomplish this
    - the direction they are going is to use their ioc container to
      bring in strategic fakes for running on the server side

*** the application code is moving to the client side, the server side is becomming a priviledged execution environment
*** very few people migrated windows apps to the web, we are going to be replacing everything when the paradigm shifts
*** i asked meteor is coming from a different place that is fundamentially different from what everyone else is talking about
    - meteor is all about a network of peers, everyone else is doing client/server
    - websockets is coming, do the other writers think of realtime as the next thing coming?
    - and if so, will your frameworks evolve to support it?
**** ashkenas thinks that it is really cool, and diserves experimentation, but backbone will never go there because it is beyond its scope
**** tom dale sees it as a convergence over time. Eventually, ember will have realtime support, and he sees meteor having post over http support

*** this is still considered a cutting edge technology. How do we take it mainstream?
    - nobody in their right mind is talking about 100% server side rendering anymore
      - when dhh talked about using 14 levels of cache instead of client side rendering, every js developer laughed
    - focus on building a great dev experience, and if it is really great then people will use it