gistfile1.txt

*** You have joined channel #webcomponents                              [12:03]
*** Users on #webcomponents: jlongster jkomoros_ ericbidelman Guest76083
    joshbavari geekles pickachu cyee GeekShadow Ablu brainproxy qmx
    kcherkashin__ eddh dfreedm higgins dglazkov mmalecki Domenic_ leptonix
    addyo mathiasbynens sindresorhus thiagopnts Tudmotu1 bterlson theefer
    kentaromiura
*** #webcomponents modes: +cnt
*** #webcomponents was created on 2012-06-29 09:34:49
<dglazkov> yay jlongster!!!
<jlongster> haha hi!
<jlongster> yeah, not a huge fan of twitter
<dglazkov> Twitter is like the hallway. Nobody just loves hallways, but we all
           need them and use them every day                             [12:04]
<jlongster> especially for people who work from home
<dglazkov> :)
<jlongster> but yeah                                                    [12:05]
<jlongster> I don't know exactly what else to say; I think it comes down to a
            fundamental disagreement about storing app state in the DOM
*** _jeroengerits (~textual@dhcp-077-248-218-008.chello.nl) has joined channel
    #webcomponents
<dglazkov> sure. BTW, "DOM is slow" is not a good argument. If it's slow, we
           should make it fast
<dglazkov> we built this thing. We treat slow as bug :)                 [12:06]
<dglazkov> I think there will be many opinions on what's good.
<jlongster> yeah, that's not a good argument. the main thing is centralizing
            your app state so that you can control it easier
<dglazkov> that's just an opinion you have about how an app should work
<dglazkov> there are lots of people with different opinions             [12:07]
<jlongster> sure, and that's fine. but there are concrete things you can do
            with that which are so much harder otherwise
<jlongster> undo, serializing app state, recording changes, etc;
<jlongster> and on the other side, what is the benefit?
<dglazkov> none of that is harder with Web Components
<dglazkov> what makes you say that?                                     [12:08]
<jlongster> it is; for me, all I have to do is JSON.stringify(appState). How
            do you do that with Web Components without forcing each element to
            implement each functionality itself?
*** ryanflorence (~rpflorenc@ec2-184-72-231-143.compute-1.amazonaws.com) has
    joined channel #webcomponents
<jlongster> ok, let's step back; it's hard if we start conflating Web
            Components with app structure like Polymer does
<jlongster> if the components are strictly display-related, we're all cool
                                                                        [12:09]
<dglazkov> can you tell me more about app structure thing?
<dglazkov> trying to understand what this means
<jlongster> if I put all of my app state into its own tree structure, and just
            give pieces of it off to components for rendering, then it's easy
            to work with the app state (just a JSON structure)          [12:11]
<dglazkov> jlongster: have you heard of MDV?
<dglazkov> that's what Polymer does to achieve what you're asking for
<jlongster> yeah, I've looked into it a bit                             [12:12]
<jlongster> it's just a simple way to do data binding, right?/
<dglazkov> http://www.polymer-project.org/docs/polymer/databinding.html
<dglazkov> it's a bit more than that                                    [12:13]
<jlongster> sure, I think you could get somewhere with that
<dglazkov> what else do you need?
<dglazkov> with http://www.polymer-project.org/docs/polymer/node_bind.html,
           you can describe how each node is bound to the model
<dglazkov> which means that you can now compose your DOM tree out of arbitrary
           components and still have a consistent way for interacting with it
           via the model                                                [12:14]
<dglazkov> right?
<dglazkov> what's more, it's not something you invent every time you build a
           framework
<dglazkov> it's a standard platformey way of handling things
*** slightlyoff (sid1768@gateway/web/irccloud.com/x-wiaimkzvrjshmvee) has
    joined channel #webcomponents                                       [12:15]
<slightlyoff> OH HI
<jlongster> I know it's good to try to standardize this stuff, but I'm not
            sure we should. we're dictating a specific way to do data binding
<jlongster> I like how React.js does it a lot more
<jlongster> I'm trying to give good feedback, that's all                [12:16]
<dglazkov> jlongster: I understand :)
<jlongster> I want to interact with people involved in all of this instead of
            just ranting
ERC> /names #webcomponents
*** Users on #webcomponents: slightlyoff ryanflorence _jeroengerits jlongster
    jkomoros_ ericbidelman Guest76083 joshbavari geekles pickachu cyee
    GeekShadow Ablu brainproxy qmx kcherkashin__ eddh dfreedm higgins dglazkov
    mmalecki Domenic_ leptonix addyo mathiasbynens sindresorhus thiagopnts
    Tudmotu1 bterlson theefer kentaromiura
<dglazkov> mission accomplished :)
<jlongster> woot!                                                       [12:17]
<mmalecki> I'm curious how are webcomponents considered state
<dglazkov> react.js is a great nuclear winter survival strategy. It assumes
           that browsers never evolve
<mmalecki> I thought of them more as views
<mmalecki> (when related to the greater image of an app)
*** joshbavari (~joshbavar@wsip-72-198-169-61.ok.ok.cox.net) has quit: Quit:
    joshbavari                                                          [12:18]
<jlongster> mmalecki: they should be, but it's easy for people to stick state
            on them (and a lot of example I've seen do that)
<mmalecki> jlongster: ah, I see, so the usual basically ;)
<jlongster> dglazkov: playing devil's advocate -- why shouldn't browsers be a
            low-level rendering engine?
<dglazkov> jlongster: they totally should be! but then DOM is the wrong API
<mmalecki> jlongster: thanks                                            [12:19]
<dglazkov> jlongster: react.js uses DOM as a substitute for box tree building
<dglazkov> because there's no box tree API
<dglazkov> and that's sad on many levels
<jlongster> what would the box tree API offer?
<slightlyoff> jlongster: so we're not dictating anything                [12:20]
<slightlyoff> jlongster: you can do whatever you please in JS
<slightlyoff> jlongster: we're, however, uncovering primitives that make it
              easier to do and better performing when doing binding against
              DOM
<dglazkov> jlongster: it would enable you building the actual box tree (stuff
           that renders) rather than something that is actually an object
           model for the document
*** KidkArolis (sid15592@gateway/web/irccloud.com/x-ipuawiquhqqtamqo) has
    joined channel #webcomponents
<slightlyoff> (the lack of a box tree API came up again at the TAG yesterday)
                                                                        [12:21]
<jlongster> huh, so are we really considering working on that?
<slightlyoff> (we're hoping to get the "render worker" concept into the CSS
              WG's hopper)
<jlongster> it we had a lower-level API and then Web Components, I'd be down
            with that
<slightlyoff> sure, but it says nothing about the value (or not) of WC  [12:22]
<slightlyoff> being able to use markup-as-slang is GOOD for the world
<kentaromiura> I used to use iframes as a 'box-tree' canvas on ie6
<kentaromiura> but only for offline apps
<slightlyoff> jlongster: it allows us to be declarative when that's valuable
<slightlyoff> jlongster: which, as you note, isn't all the time
<slightlyoff> jlongster: but it's how we can (finally) do science about
              evolving the web (instead of all the guessing we're doing now)
                                                                        [12:23]
<slightlyoff> jlongster: we can survey what people are doing frequently in
              markup and then put *those* things into HTML
<slightlyoff> instead of just guessing or greasing the squeaky wheel
<jlongster> slightlyoff: yeah, I do get that point. I think part of my problem
            is that I was introduced to Web Components in the worst way
            possible: all this really weird tags that shoved everything into
            HTML                                                        [12:24]
<jlongster> so I'm now having to backtrack and see what should be declarative
            and not
*** jeevesq (~jeevesq@69.169.43.5) has joined channel #webcomponents
<jlongster> I like this talk: https://www.youtube.com/watch?v=AxyzonjWYuA
<jlongster> I'd love to see more Web Components like 'anchored-view' and
            'dismiss-view' which we can compose to make UI elements
<jlongster> instead of the UI elements themselves ('popup-view')        [12:25]
<jlongster> that's really interesting to me, and would be a great way to use
            Web Components
<slightlyoff> jlongster: we're at the very beginning of what's likely to
              emerge                                                    [12:26]
<ryanflorence> working with a lot of devs in ember with Ember.Component,
               people continue to view them incorrectly as partial templates,
               rather than elements with behavior                       [12:27]
<ryanflorence> but after a little coaching, and talking a lot about
               <select><option/></select> and <form><input
               type="submit"></form> its not a hard jump to realize you're
               building new elements, not partials.
<ryanflorence> rather than <x-tabs data="{{someData}}"> instead you build
               <x-tabs> <x-tabpane> <x-tabpanel> and <x-tab> and let people
               build up the UI themselves                               [12:28]
<jlongster> yeah, +1                                                    [12:29]
<jlongster> ryanflorence: still super curious how interop works. some UI
            components need to be aware of Ember router. how will that work
            with angular?                                               [12:30]
<jlongster> that might be a larger discussion though
<dglazkov> a quick rant: I think Polymer and Web Components have been
           over-conflated just a touch. Polymer is just one way of using the
           technology. As slightlyoff say, we're very early in the journey.
           Other ways are going to arise.
<ryanflorence> jlongster: ember's got a lot of opinions on how data flows and
               is bound. components can bind to their controller's properties
               (context of hte template in which they are rendered) and then
               the controller binds its property to the queryParams.    [12:31]
<jlongster> dglazkov: that's good to hear, I agree. TBH I think it does a
            little disservice to Web Components.
<dglazkov> I blame ericbidelman.
<dglazkov> FOR EVERYTHING
<dglazkov> including rain in california
<ryanflorence> jlongster:
               http://instructure.github.io/ic-tabs/query-params.html#/?country=0&food=0
               and the source:
               https://github.com/instructure/ic-tabs/blob/gh-pages/query-params.html#L136-L140
<dglazkov> I mean, WTF
<dglazkov> rain? what's that                                            [12:32]
<ericbidelman> SO RAINY
<ryanflorence> jlongster: so you can see here
               https://github.com/instructure/ic-tabs/blob/gh-pages/query-params.html#L30
<ryanflorence> the component binds its "selected-index" to the controller's
               "country" property and its job is done
<ryanflorence> then at the bottom of the file the controller binds its
               "country" property to the query params
<jlongster> ryanflorence: aah, thanks                                   [12:33]
<jlongster> that's pretty cool
<ryanflorence> indeed, its lovely to have "right answers" in browser apps.
                                                                        [12:34]
*** sjmiles (~sjmiles@c-71-198-153-117.hsd1.ca.comcast.net) has joined channel
    #webcomponents                                                      [12:35]
<dglazkov> hey, sjmiles                                                 [12:38]
<dglazkov> jlongster here thinks your <polymer-ajax> stupid.
<dglazkov> :P
<dglazkov> jlongster, meet sjmiles m the FATHER/MOTHER OF POLYMER.      [12:39]
<jlongster> hey! sssh. not necessarily!
<jlongster> uh oh
* jlongster hides
* dglazkov is not at all trolling for a cage match
*** ericbidelman (~ericbidel@207.198.105.19) has quit: Quit: ericbidelman
<dglazkov> LOL I see ericbidelman left before it got any worse          [12:40]
<slightlyoff> FIGHT FIGHT FIGHT
<dglazkov> I think we scared off sjmiles                                [12:41]
<jlongster> haha, well that's good anyway. I need to focus. I'll hang around
            here more often though!                                     [12:42]
<dglazkov> jlongster: you win!
<jlongster> YES
*** ericbidelman (~ericbidel@216.239.45.76) has joined channel #webcomponents
                                                                        [12:50]
*** cyee (~cyee@S0106147dc53cfa33.vs.shawcable.net) has quit: Remote host
    closed the connection
*** hmmmdrop (~hmmmdrop@50-1-96-86.dsl.dynamic.sonic.net) has joined channel
    #webcomponents
<dglazkov> ericbidelman, you totally missed an epic fight
<ericbidelman> dang it                                                  [12:51]
<ericbidelman> i was getting off the shuttle
<ericbidelman> i need logs!
<sjmiles> I'm here                                                      [12:52]
<addyo> I have logs and I'm still trying to make sense of the discussion so
        far :)
<addyo> catching up on
        https://twitter.com/ryanflorence/status/451397829445963776 etc.
<sjmiles> once you go declarative, you don't go back :)
<jlongster> sjmiles: declarative is good, but there are tons of ways to do
            that. React is declarative too.                             [12:53]
<jlongster> fwiw
<sjmiles> yes, there are many flavors of ice cream                      [12:54]
<sjmiles> I haven't heard your actual critique yet, most people that dislike
          polymer-ajax object to its declarative form
*** cyee (~cyee@S0106147dc53cfa33.vs.shawcable.net) has joined channel
    #webcomponents                                                      [12:57]
<jlongster> I think that's all I mean too, I want ajax in JS not in HTML
<jlongster> but I need to look into it further
<addyo> I think you'll see a number of efforts at trying to reenvision how we
        interact with primarily JS APIs in a more declarative manner    [12:59]
<addyo> some might seem more out there than others :)
<sjmiles> Polymer doesn't insist you use those things declaratively, there is
          extreme flexibility
<sjmiles> but using declarative (HTML) is wildly expressive, so the leverage
          is high                                                       [13:00]
*** _jeroengerits (~textual@dhcp-077-248-218-008.chello.nl) has quit: Quit: My
    MacBook has gone to sleep. ZZZzzz…
<sjmiles> btw, it's ok to say it sux and it's horrible, I will not freak out
          :)                                                            [13:01]
<addyo> sjmiles: I thought <polymer-ajax> was insane when I first looked at it
        :)
<jlongster> as addyo said, there will lots of various ways to do it, there's
            room for a few different techniques                         [13:02]
<addyo> With sufficient time to play with it, it actually becomes quite
        pleasant to use.
<jlongster> main thing I want to make sure we standardize on only the
            primitive elements
<sjmiles> who is "we"?                                                  [13:03]
<dglazkov> we the people
* dglazkov is comic relief at this point
<sjmiles> we the people will standardize on what they standardize on, that's
          one of the design goals s we can't predict what the community en
          masse will do                                                 [13:04]
<sjmiles> I'm always the straight man
<jlongster> sjmiles: I'm assuming there are w3c people in here. I mean
            specifically them I guess.
<sjmiles> I see s like I say, one of the compelling ideas IMO is that we let
          the best of breed components rise naturally in popularity     [13:05]
<sjmiles> and use that as a guide for standardization
<sjmiles> It's Alex Russell that first put voice to this idea for me
<jlongster> sure. I'm a huge proponent of sweet.js macros for JavaScript and
            it's the same idea for syntax.
<dglazkov> http://infrequently.org/2013/11/long-term-web-semantics/     [13:06]
<dglazkov> ^^ obligatory reading
<jlongster> there seems to be a difference between treating Web Components as
            enhancing your UI, or buying into it completely as a framework
<sjmiles> DOM is the framework
<sjmiles> Web Components is just parts                                  [13:07]
<jlongster> sjmiles: that's where I completely disagree
<jlongster> but it's complicated would take a long time to keep discussing :/
<jlongster> and I need to work. haha
<sjmiles> we use DOM as the framework
<sjmiles> ok, I will try to find the logs
<sjmiles> thanks for chiming in
<jlongster> The DOM is the display layer, I believe                     [13:08]
<jlongster> this is the point where we could debate for hours :)
<sjmiles> DOM has no display, DOM is a data-structure
<sjmiles> it's retained and maintains relationships
<sjmiles> these are just facts                                          [13:09]
<sjmiles> you can say "I consider it the display layer"
<sjmiles> I guess you did say that =P
<sjmiles> my bad
<jlongster> the data structure indicates semantical relationships. but yes,
            it's cool                                                   [13:10]
<dglazkov> one problem DOM and box tree are tangled up and there's no way to
           untangle them today. That causes peeps to think that DOM _is_ the
           box tree. But it's not.
<jlongster> dglazkov: if it's both, than you choose to treat it as one or the
            other
<sjmiles> agrred; the semantical relationships are why I like to use it as the
          'framework' s a rendering is generated from the framework     [13:11]
<sjmiles> agreed too
<jlongster> are there any links to define "box tree" more? curious about that,
            not familiar with it
<dglazkov> jlongster: box tree is a) an internal data structure that all
           browsers have                                                [13:12]
<dglazkov> b) a concept in CSS: http://dev.w3.org/csswg/css-box/
<dglazkov> c) something that developer have no way of reaching directly
<jlongster> gotcha
<jlongster> thanks
<dglazkov> it's called frame tree in mozilla, render tree in blink/webkit, and
           NaN in IE                                                    [13:13]
<jlongster> lol
<sjmiles> re: twitter (sorry jlongster, I know you have to go); IMO, because
          DOM is retained, it's perfect for application state           [13:14]
<sjmiles> and Web Components provide the scoping that prevent that state from
          being 'all over the place'                                    [13:15]
<jlongster> sjmiles: I see what you mean, and I don't have any direct
            disagreements. I think it's more of API preference at this point,
            maybe. I might still expand more in a blog post about the app
            state stuff                                                 [13:16]
*** afabbro (~afabbro@static-68-179-67-77.ptr.terago.net) has joined channel
    #webcomponents                                                      [13:17]
<sjmiles> cool, like I said, thanks for chiming in, it's very useful to hear
          thougtful feedback                                            [13:18]
<sjmiles> "it looks like monkey shit on a wall" and other forms of feedback,
          less useful
<sjmiles> (I paraphrase, but that was actual feedback)                  [13:19]
<sjmiles> =P
<jlongster> it's easy to be negative; hard to actually give thoughtful
            feedback :)
<jlongster> that's why I tweeted small bits instead of posting my blog post
<jlongster> my post doesn't feel constructive enough
*** ericbidelman (~ericbidel@216.239.45.76) has quit: Quit: ericbidelman
                                                                        [13:21]
*** ericbidelman (~ericbidel@216.239.45.76) has joined channel #webcomponents
                                                                        [13:23]
*** jonykrause (~jonykraus@f053064115.adsl.alicedsl.de) has joined channel
    #webcomponents                                                      [13:26]
<Domenic_> W3C TAG is actually discussing how to expose the box tree to
           developers