Template tags/choo/bel/yo-yo ("TCBY stack") community live video hangout
max-mapper opened this issue · comments
There's a buncha folks who are building things on the TCBY stack and have feedback/questions for the community. So let's do a community video hangout!
- Time: Monday, June 20th, 10AM PST
- Duration: 1 hour
- Format: 5 minute lightning talks, with discussion after all talks.
- Youtube of call: https://www.youtube.com/watch?v=a97Mw2z1SAI
- Hangout link: https://plus.google.com/events/can1eim9s9d6cm9sbf04v590vi8?authkey=CI3-yc3LmpeVWA
Anyone will be able to watch and it will get posted to YouTube after.
If you want to participate, comment below with a title of your lightning talk. It can be to show off something cool you made with choo/bel/yo-yo or to get feedback on an idea.
"Yo-Yo+Minidux in Dat Project's Hyperdrive UI"
✨🙌✨ "code chunking and yo-yo"
"Data Down, Actions Up and The End of Peer Dependencies"
@kristoferjoseph what do you mean by "code chunking"? - don't think I can make it to this particular hangout, but happy to answer questions!
@yoshuawuyts @timwis and I have been discussing life-cycle events and how they might/should surface through choo. since choo is based on yo-yo it likely makes sense to discuss them here as well
@yoshuawuyts what I mean by "code chunking" is what webpack calls "code splitting" https://webpack.github.io/docs/code-splitting.html
I am currently using this feature with CSS Modules as well.
Going to see how far I can get on a demo of this with browserify + yo-yo this weekend.
My talk will be showing how far I got as well as what I am able to get with webpack and see if any of you geniuses has any ideas on how to accomplish something similar with the TCBY stack.
cool idea! but not sure i can make the time, as it's 5 am New Zealand time...
if i do come i'll probably talk about: "forget TodoMVC, a 'Twitch Plays Pokémon'-style 'Roguelike' using inu".
i can talk about using choo in the new version of minidocs
Aw yeah, my monday evening plans fell through (aw no!) so I'll be able to make it out after all. Reckon it'd be cool to talk about choo v3 ✨
Not sure if ya'll can access the hangout from the link at the top of the page, but if not try this one: https://hangouts.google.com/hangouts/_/hoaevent/AP36tYf_eOOs815XwRd95nhFA2x5fnl2nxu01Gu2Twpg0HDYPEMa2g?hl=en&authuser=0
@kristoferjoseph try now
Youtube link: https://www.youtube.com/watch?v=a97Mw2z1SAI
So from the call, some practical stuff we might want to consider doing:
- create a lil froyo / train related logo (🍰 ❤️ 🚂)
- mash all of our guides together into a nodeschool / minidocs style repo so people can pick stuff up (tcby-handbook?)
- create a repo page a la https://pull-stream.github.io | http://stack.gl/packages
- think about lifecycle hooks / do we need them at all?
- build more frameworks, because diversity and opinions ✨
Train gummies do in fact exist, so our froyo + toppings theme works!
I just opened an issue for logo ideas.
I think this issue can be closed now right?
Another take away: It would be nice to have a page or repo for cataloging 'widget' type things (like react components) made with yo-yo. Does anyone have re-usable components they would like to show?
Awesome video! Really liking ideas you describe.
I was thinking it would be good if those were written down somewhere ... some kind of guidelines or even manifesto if you like.
I'm really fascinated by idea of "create my selectbox and let it seat there for years without need to update". Because front-end JS landscape is moving at ridiculous speed atm this can really be a game changer imo. As you say, as long as common API is the DOM it should play nice with other libs/frameworks.
What are the downsides of this approach? Is it the generated file size because each custom element needs to wrap its back-ing libs (like yo-yo/bel etc.)?
Another thing I guess you're then able to update component by component instead of being forced to update/rewrite whole app when framework or lib introduces braking API changes.
@zigomir Yep! You're spot on. File size is the biggest downside to this approach (that I've witnessed elsewhere with nested dependencies). Over time, the version of the underlying back-ing lib starts to vary amongst the ecosystem. For instance with streams, it's common to have projects with a good deal of through and through2 versions in your dependencies.
Luckily npm >= 3 does a lot of fix this by automatically deduping (and we're following semver to the letter).
We are also actively mitigating by keeping the back-ing libs small and with simple APIs so we can eventually make breaking changes rare. But there is nothing to prevent someone from forking and the ecosystem moving towards their backing lib instead, in which case semver can't save us. If that ever happens, hopefully those forks will keep the APIs simple and follow semver too. :)