These are chat archives for ThoughtWorksInc/Binding.scala

18th
Nov 2017
杨博 (Yang Bo)
@Atry
Nov 18 2017 03:20
Thank you for point out this bug! @kahliburke :+1:
Kahli Burke
@kahliburke
Nov 18 2017 03:21
Sure, sorry I didn't figure it out myself...
Kahli Burke
@kahliburke
Nov 18 2017 03:26
If you have any time to talk about stuff related to this library, my difficulty now is in trying to optimize the size of the macro generated code. In particular the differing implementation of Jvm vs Js as imported via the @enableMembersIf macro led me to the discovery that in deeply nested calls, ScalaJS does not optimize away certain conversion between Seq and js.Array (https://github.com/ThoughtWorksInc/Binding.scala/blob/1300e7bf0dbff01ccf100ad2fa4b7cc414cdd116/Binding/src/main/scala/com/thoughtworks/binding/Binding.scala#L146) which results in larger blocks of code than is necessary. I've inquired about it on the scala-js channel. Also, just trying to figure out how to reduce the resulting code size to make the fastOpt process run "fast". Large DOM views result in a lot of nested calls, and I'm curious whether some of the domBindingSeq calls from macros could be improved to prevent sibling nodes from producing nested Bindings.
杨博 (Yang Bo)
@Atry
Nov 18 2017 03:30
How about removing the @inline annoation from toConstantsData?
Those nested calls are actually IIFEs. See scala-js/scala-js#2675
Kahli Burke
@kahliburke
Nov 18 2017 03:35
Something to try... I remember reading this discussion between the two of you earlier, thanks for making that connection. So is it possible to avoid them?
If I have many sibling nodes like
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
That can result in lots of nesting too
杨博 (Yang Bo)
@Atry
Nov 18 2017 03:36
Because they are monadic expressions
Kahli Burke
@kahliburke
Nov 18 2017 03:37
Yeah, I was curious if it was possible to capture that in a single monad
杨博 (Yang Bo)
@Atry
Nov 18 2017 03:37
It performs something like CPS-transformation
Kahli Burke
@kahliburke
Nov 18 2017 03:37
Yes, I am passingly familiar with it although I'm certain you have a more detailed understanding given your work. So, trying to ask an expert :)
Seems like OutputMode.ECMAScript6 might offer a solution in the long term but not possible in current browsers, correct?
杨博 (Yang Bo)
@Atry
Nov 18 2017 03:43
Those IIFEs are not necessary for fullOpt even in current browsers because:
  • The code generated by Scala.js will be passed to Closure compiler
  • Closure compiler support ECMAScript2015 input
  • Scala.js can produce ECMAScript2015 output
We need some changes in Scala.js:
  • Don't generate IIFEs if the output mode is ECMAScript2015
  • Switch to ECMAScript2015 output mode in fullOpt, to generate the code for Closure compiler
Kahli Burke
@kahliburke
Nov 18 2017 03:45
Thanks for the clarification. Explains why things are much improved in the fullOpt version, this is mainly a development concern for me, the fastOpt process takes a long time and results in 20MB output.
As I write more UI, this scales up quickly
If you have an idea of clever workarounds within Binding.scala, let me know as I would invest some time into it.
杨博 (Yang Bo)
@Atry
Nov 18 2017 03:50
You may try to add a condition for IIFE generation that detects if the output mode is ECMAScript2015. I guess it will be a small change in https://github.com/scala-js/scala-js.
Kahli Burke
@kahliburke
Nov 18 2017 03:50
Oh on reading your note again I see I misunderstood you... the IIFEs are currently present in fullOpt but could be dealt with via Closure compiler if Scala.js would produce the ECMAScript2015/ES6 output
That sounds like a good idea, as in development it's not a problem to use a modern browser that supports ECMAScript2015.
杨博 (Yang Bo)
@Atry
Nov 18 2017 03:53
It's irrelevent. Clousure compiler can convert ES2015 to ES5
Kahli Burke
@kahliburke
Nov 18 2017 03:53
Ok, but for development workflow we would use fastOpt which does not pass through Closure, correct?
杨博 (Yang Bo)
@Atry
Nov 18 2017 03:54
I guess @sjrd also wants to reduce number of IIFE generation even for ES5.
Kahli Burke
@kahliburke
Nov 18 2017 03:55
That would be great too, but for development I could simply enforce ES6 output and make sure devs use a modern browser? So I'd get the benefit of no IIFEs in dev mode, but that code would then work across a wider browser suite once pushed through fullOptJs?
杨博 (Yang Bo)
@Atry
Nov 18 2017 03:57
Yes. Totally disabling IIFE for ES6 is a easier change than delicately reducing IIFEs.
Kahli Burke
@kahliburke
Nov 18 2017 03:57
Anyway, I think you've inspired some good ideas on where to focus effort. Thanks for taking the time to discuss it, time to start looking at the scala-js codebase to see if that's at all penetrable by mere mortals.
杨博 (Yang Bo)
@Atry
Nov 18 2017 03:58
Thank you, too!
Kahli Burke
@kahliburke
Nov 18 2017 03:58
Glad we met in the same time slot, talk again later :)
杨博 (Yang Bo)
@Atry
Nov 18 2017 03:58
:smile: