These are chat archives for jdubray/sam

25th
Aug 2017
Vertex21
@Vertex21
Aug 25 2017 00:34
Loving the discussions here! My head is spinning but I'm starting to see clarity.. lol.. does anyone have any experience with Milo framework? https://github.com/milojs/milo
Jean-Jacques Dubray
@jdubray
Aug 25 2017 01:57
@Vertex21 :+1:
I think I came across it before. Anything in particular that you like? It looks like it's powering the Daily Mail CMS, that's quite an achievement.
Fred Daoud
@foxdonut
Aug 25 2017 13:33
@Vertex21 it looks along the same lines as KnockoutJS. Personally I don't like the idea of custom attributes on HTML elements with special syntax for data binding.
devin ivy
@devinivy
Aug 25 2017 13:46
@foxdonut what counts as special syntax to you?
or rather, what syntax for databinding would not be special :P
Fred Daoud
@foxdonut
Aug 25 2017 13:55
@devinivy ok I get your point :) but I prefer HTML in JS (hyperscript, JSX) over JS in HTML. With the former, loops, conditionals, "partials" etc. are just regular JS code instead of funky library-specific syntax stuffed into an HTML template.
Jean-Jacques Dubray
@jdubray
Aug 25 2017 13:56
:+1:
devin ivy
@devinivy
Aug 25 2017 13:57
does that preclude declarative views while working with "the platform" as a whole?
Jean-Jacques Dubray
@jdubray
Aug 25 2017 13:57
It's hard to believe this can improve productivity / workflow
devin ivy
@devinivy
Aug 25 2017 13:58
the platform, i.e. the web and its emerging standards surrounding web components
as much as i appreciate react/react-dom (and related vdom libs), i like to believe that working within the platform isn't damned.
i also am not a huge fan of the vdom's implications for our applications, specifically as it relates to performance. if you need performance you need to write your application in some odd ways (thinking: immutability and tools like reselect)
it's amazing all this comes from talking about data binding syntax haha
but really, talking about html-in-js, you have to start talking about the vdom almost immediately, and that has tons of implications.
devin ivy
@devinivy
Aug 25 2017 14:03
don't get me wrong– i also really appreciate html-in-js.
Zach Dahl
@schtauffen
Aug 25 2017 14:06
vdom is just a tool. libraries can create dom nodes and patch just as efficiently. see morphdom, nanomorph
just as / more *
devin ivy
@devinivy
Aug 25 2017 14:07
i see that. as it related to data-binding, though, you need a way to figure-out what needs to be re-rendered.
when projecting state onto a virtual dom tree, not when rendering the vdom to DOM
Zach Dahl
@schtauffen
Aug 25 2017 14:08
I think that eventually browsers will implement their own diff algorithm. So when I say "make this html into this html" you don't have to worry about performance implications
devin ivy
@devinivy
Aug 25 2017 14:08
i think the diff algorithms are great!
it's more about coming-up with the "new" side of the diff.
i.e. rendering virtually
Zach Dahl
@schtauffen
Aug 25 2017 14:09
I appreciate mithrils approach. just render the entire tree and diff
devin ivy
@devinivy
Aug 25 2017 14:09
i think it's very simple and i appreciate that. mithril is great. but at a certain point you can't get away with the time it takes to render the entire tree
Zach Dahl
@schtauffen
Aug 25 2017 14:10
I'm not sure you'd ever run into that situation in practice
devin ivy
@devinivy
Aug 25 2017 14:11
i suppose i will need to toy with it! but i can say that react certainly has this problem because i and others have seen rendering jank. otherwise popular tools like reselect wouldn't exist.
i haven't used mithril on any big projects, so i'm not entirely sure about mithril. maybe someone who has built a large app on it could speak to that.
Zach Dahl
@schtauffen
Aug 25 2017 14:13
I haven't used it on large projects, enterprises just bought into React mithril is a hard sell :P
Jean-Jacques Dubray
@jdubray
Aug 25 2017 14:13
The way I do it is simply by dividing my UI in 3-5 areas and calculating a hash of the innerHTML of each area, if the hash has not changed I don't bother rendering it. There are not that many cases where rendering an area takes any measurable amount of time.
I don't know how diff algorithms work, but grooming HTML at the element level sounds like overkill to me.
Zach Dahl
@schtauffen
Aug 25 2017 14:15
@devinivy have you tried looking into something like calmm-js ? since everything uses atoms it supposedly knows exactly which components to rerender
devin ivy
@devinivy
Aug 25 2017 14:15
i don't know, i think it's all relative to your wiring.
@schtauffen i haven't used that– but yeah, exactly! i've used polymer a lot and it does the same thing. of course it doesn't actually have a vdom :P
it's based on observers, and they can map changes to component properties onto changes to the component's DOM's attributes, etc. it's not as overbearing as you might think, but that's because the wiring is different.
Zach Dahl
@schtauffen
Aug 25 2017 14:19
I've been tinkering with alternative render strategies... and in the end I feel like the use case is so limited. Default react or mithril should handle 99% of what you throw at it just fine. In the use cases it doesn't, I see @jdubray strategy as a quick win: just break the problem down into smaller ones.
devin ivy
@devinivy
Aug 25 2017 14:21
:thumbsup:
i'm really not a super-nerd for performance. i'm probably more of a nerd for the platform :P
Zach Dahl
@schtauffen
Aug 25 2017 14:22
I'm more of a filesize nazi myself... and in that react + co can get real scary. My current project clocks in at almost 3MB before gzip <_<
devin ivy
@devinivy
Aug 25 2017 14:22
phewwie! yeah, it's a problem...
last thought on all that– considering how much effort has been put into vdom view libs (and their surrounding ecosystems), i just think we really haven't scratched the surface with web components, and i'd like to see more research there to find what's possible.
currently having fun today working on a templated website :D :D it's... server-side rendered lol
Fred Daoud
@foxdonut
Aug 25 2017 15:14
@schtauffen I'm with you on avoiding premature optimization worrries until (if) they are an actual bottleneck
As for filesize, several vdom libs are a fraction of react's size.. at the extreme, picodom :D
But yeah, preact, inferno, mithril, snabbdom...
devin ivy
@devinivy
Aug 25 2017 15:26
but it is a problem if premature optimizations regarding performance become a core part of the ecosystem (the way it's taught and the tools that are built).
thinking of the react ecosystem and the handling of immutable data– in the end that's all just for performant virtual renders.
too bad for that to leak into everyone's apps if it's not necessary.
this speaks less to issues with the tools themselves and more about the consequences of people having those tools.
i think everyone here is doing a good job debunking this :)
Janne Siera
@jannesiera
Aug 25 2017 15:35
Just throwing this out there: https://github.com/skatejs/skatejs
Zach Dahl
@schtauffen
Aug 25 2017 15:41
I don't advocate for immutablejs but I definitely like the benefits of of making all your functions pure (and never mutating).
Not for performance reasons, but because it makes everything easy to reason about. Tracking down bugs is a cinch and your tests are easier to write.
As a benefit, you get === checking for free :)
Eric Skogen
@audionerd
Aug 25 2017 15:54
Hey all!
Had a question about S>A>M
Let's say that when a model's X changes from 0 to 1, a function must be called (like, playing a sound).
Where do I put the code to detect the change to X and call the function?
Jean-Jacques Dubray
@jdubray
Aug 25 2017 15:58
@audionerd this is typically the role of State/Nap
The state function would detect the "state" of the system pass it/share it will nap (next-action-predicate) which would trigger an action to play the sound.
Alternatively, you can think of the player as a "view" and the state function would simply pass the "state representation" to that view.
Eric Skogen
@audionerd
Aug 25 2017 15:59
OK, so maybe I would store a lastX in the model, update it after each render. Then nextAction (nap) can compare lastX to X, detect the change, and decide if the function should be called?
Eric Skogen
@audionerd
Aug 25 2017 16:10
Maybe something like:
let model = {
  X: 0,
  lastX: 0,

  present (data) {
    if (typeof data.X !== 'undefined') {
      model.lastX = model.X
      model.X = data.X
    }

    state.render(model)
  }
}

let state = {
  hasChanged (model) {
    return model.X !== model.lastX
  },

  representation (model) {
    view.display(model)
  },
  nextAction (model) {
    if (state.hasChanged()) {
      callTheFunction()
    }
  },
  render (model) {
    state.representation(model)
    state.nextAction(model)
  }
}
Jean-Jacques Dubray
@jdubray
Aug 25 2017 16:16
yes, exactly.
the call should be state.hasChanged(model) but that's just a typo
Eric Skogen
@audionerd
Aug 25 2017 16:17
ah yes good catch :P
thanks!
Michael Terry
@formido
Aug 25 2017 22:48

@Vertex21 :+1:
I think I came across it before. Anything in particular that you like? It looks like it's powering the Daily Mail CMS, that's quite an achievement.

That's definitely an achievement to be proud of, but man Daily Mail's user experience is awful

The pages take forever to load. If you try to load more than a couple tabs your browser just starts bogging down and hanging.
Stupid autorunning video player
Just a horrible resource hog
Jean-Jacques Dubray
@jdubray
Aug 25 2017 23:40
that's almost true of any newspaper's web site!
Vertex21
@Vertex21
Aug 25 2017 23:43
I think they actually built Milo specifically for that project and then forked the JS framework off. I was kind of liking how modular it was and it's completeness, but as @foxdonut said it's not so awesome having all those js binders strewn throughout the HTML
I'm personally bouncing around between Milo, Mithril and Cycle for a CRM/POS system I'm building.. I just can't seem to decide what to use.
Michael Terry
@formido
Aug 25 2017 23:47
truish
Vertex21
@Vertex21
Aug 25 2017 23:47
Finding all this SAM stuff and @jdubray 's arcticles has had me now completely redraft all my thought processes on this project.. so thank you, but UGGHH!