Created
April 2, 2014 18:44
-
-
Save jlongster/9940472 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
*** 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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment