Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Sep 18 19:32
  • Sep 11 02:59
    torongu starred canjs/canjs
  • Sep 09 06:57
    tbreuss starred canjs/canjs
  • Sep 04 18:58
    cherifGsoul review_requested #5507
  • Sep 04 18:58
    cherifGsoul opened #5507
  • Sep 04 18:51

    cherifGsoul on post-release-script

    Add GitHub release automation (compare)

  • Aug 22 17:54
    ThisIsntMyId starred canjs/canjs
  • Aug 21 08:54
  • Aug 20 20:24
    ktitaro starred canjs/canjs
  • Aug 17 16:53
  • Aug 17 16:51
    kuustudio starred canjs/canjs
  • Aug 14 17:12
    cherifGsoul closed #5494
  • Aug 14 17:07
    cherifGsoul labeled #5490
  • Aug 14 17:05
    cherifGsoul labeled #5492
  • Aug 14 17:04
    cherifGsoul closed #5495
  • Aug 14 17:04
    cherifGsoul closed #5498
  • Aug 13 07:25
    kitoki starred canjs/canjs
  • Aug 11 17:41

    cherifGsoul on can3-youtube-terms-of-service


  • Aug 11 17:41

    cherifGsoul on 3.x-legacy

    Update playlist editor and add … (compare)

  • Aug 11 17:41
    cherifGsoul closed #5506
Frank Lemanschik
i only need to find a better way as creating fragments for each variable that changes as this feels so useless
as i can archive the same via and edit
maybe jsx can help but i don't know how that should work i am doomed :)
Kevin Phillips
have you profiled it to confirm there's actually a performance benefit to not creating new fragments?
Frank Lemanschik
performance nope :(
but i see it as double work
and un needed work
as from my view we return html we have html
so we can use after that the dom api for everything
as easy as select <span id="myName">Mr Myer</span>
and then select myName change innerText done
but i performance benchmarked domDiffing
and i think that could be a alternate i simply check if the dom matches if not sync it up async
that outperforms on bigger apps
as we can handle the view as Whole
it don't matters where the changes come from we only need to make sure that view matches whats expected
and many observations arn't needed this way
only the edit able content
Kevin Phillips
but you're doing a lot more DOM manipulation
Frank Lemanschik
yes sure but my co workers from chrome and mozilla have improved on that also
and its not about real pefformance
for example often you don't even want to change something in less then a MS
Kevin Phillips
its not about real pefformance
what do you mean?
Frank Lemanschik
Material design examples and research
they found out that it feels better to show some loading and transition
Kevin Phillips
Frank Lemanschik
even if its not needed there are also time frames that feel diffrent
Kevin Phillips
but that kind of thing shouldn't be done at the framework level I don't think
otherwise, you can never have things be fast
Frank Lemanschik
i can via preComputing
i simply prepare what gets computed and insert and change
that dom manipulations are fast
Kevin Phillips
but if you have to make 10,000 changes instead of inserting 1 fragment
it won't ever be fast
Anyway, it's good that you're exploring alternatives. I'll be interested to see how it turns out.
Frank Lemanschik
yes i am on that :) since more then 2 years
but good idea
do you got a benchmark for the current implamentation
so i can work against that benchmark?
Kevin Phillips
Frank Lemanschik
maybe you did internaly some benchmarks i only need to know the test cases so i know what to imrove
ok so far so good i understand the example :) i will do the same with some of my alternates
@frank-dspeed thanks for the feedback
I haven't quite narrowed down when it happens but I have a "standard" route with the associated data
I wouldn't expect changing the would result in a refresh of the app
anyway, I am not quite sure when it happens so I'll keep an eye out for something that is reproducible
Frank Lemanschik
i think its the expected behavior
as soon as you know what exactly happens befor reload
you also have the solution :)