Problem: 3500ish ms boot up time for js according to lighthouse

[janat08]

Problem: It takes 4 seconds to init js alone according to lighthouse (albeit with some major offenders w/o which its 2secs). Benchmarks: https://github.com/mitar/meteor-web-rendering-framework-benchmark, by blaze maintainer.

Solution: Use nx-framework which is expandable and based on proxies (5% audience usage unsupported) to render things reactively without editing any of the templates, but is as unmaintained as blaze. My offer of trying this for halfway free stands. This will also enable SSR.

[janat08]

@blockrazorbot claim

[gsovereignty]

Is nx meant to be used instead of Blaze?

[janat08]

No we can still use and keep all of blaze html templates and helpers and hooks (the power of proxies).

[janat08]

Although I'm unsure about the compilation steps, as in detecting that html that goes with a template, and bundling that.

[janat08]

Ill wait for reply here nx-js/framework#15, or a sign of life or 10-15 days. @blockrazorbot label "unmet dependency".

[gsovereignty]

In the longer term, we can always fork it and maintain it ourselves, but it had better work really well to justify it.

[janat08]

• get a template/html bundle .

• attach html to componentl with render middlewear (under section modulirazation),

• mapping tracker api to observers, and calling those for compatibility with other libraries.

• converting reactive vars to state

• attaching global helpers

• attach hooks/helpers,

• parsing spacebars into nx-framework, or hacking nx parser.

• map Template apis (currentData/instance) and currentData contexts/inheritance. The render middlewear has inheritance mechanics as api is to change to disabling inherited state.

Not doing for prototype:

• decouple from blaze compiler, look to vue compiler

• map events into DOM (since they have to apply within template only).

• make template helpers lazy (i belief I saw api for that, and yet I can't find it any longer)

• mapping session variables to global singleton

[janat08]

Blaze.toHTML(Template.mainLayout). Basically gives me what I want.

[janat08]

Blaze has special template for body, which would be the root, and I have to parse dynamic template function too.

[janat08]

try using react's compose to bind this to state for Template.instance(), and also apply arguments for template helpers.

[janat08]

@blockrazorbot remove "unmet dependency"

[janat08]

templatetag.js and codegen contain parsers in spacebars-compiler.

templating-tools produces render function with html-scanner.js
and templating-runtime consumes it producing code for client
one of method for templating tools consumes DIR as parameter.

[janat08]

SpacebarsCompiler.parse(htmlString), gives me what I want, would've saved a couple or 3 hours, if I bothered with reading the api.

[janat08]

This will take more like over 20 hours. I spend 8 hours on this, and you could fairly say that I got nowhere with 100 lines of empty code written (doesn't work, isn't very meaningful), and no way to get spacebars format that I want (in form of SpacebarsCompiler.parse(html string) at least on client, forget having it built by meteor.

[janat08]

NX-framework doesn't have SSR, and I believe meteor's server-render definitely expects static-html for it's compiler instead of blaze compiler.

[janat08]

I wouldn't mind giving it another stab only focusing on the small demo without bothering with the compiler, and then benchmarking that using mitar's benchmark repository. Which shouldn't be much different from simply comparing nx and blaze.

[janat08]

@gazhayes I offered special terms for this which went along the lines of I can be paid up to 8 hours, and if I can't deliver I don't get paid, do I close this?

[gsovereignty]

What do you feel like doing?

[janat08]

Im totally interested but would like to make money.

[gsovereignty]

Ok close it off. We can open this again later if it becomes 'interesting'.

[janat08]

but it is.

[gsovereignty]

I'll implement Kadira to get some more data first.

[janat08]

I belief kadira is for server.

[janat08]

I'll go do a tracker conversion. If it works/helps I'm billing it.

[gsovereignty]

OK. That's fine with me. But it's best to keep an eye out for higher priority things (errors etc) and do this as a lower priority.

[janat08]

1. onInvalidatedCallbacks

[janat08]

I've decided that it's easier to map oberve-utils onto tracker.api rather than other way around.

api:

• autorun

• flush //false on basis that there's no que

• nonreactive, onInvalidate require nonReactive, return to that

• active

• inflush //false on basis that flush isn't implemented

• currentComputation

• afterflush

• stop

• invalidate //false on basis that flush() isn't implemented

• oninvalidate

• onstop

• stopped

• invalidated// false on basis that invalidate() isn't supported

• firstrun

• changed

• depend

• hasdependents //stubbed

[janat08]

Unsure if api behaviour is replicated:

• stop computation on error (self.stop())

• no on error param (tracker/reaction-comp[prop])

• .depend() returns nothing

• do embeded observers act like trackers?

• queue object isn't being used, so things can change from under you unlike in blaze. CHANGE HOOKS if this is changed. test with bounties.

• incompute variable is ignored

• tracker.afterflush is likely meant to be used with stored computations, i don't think dependency acceptions computation object.

• needRecompute() absent in _runFlush

[janat08]

There's limitation on manipulating reactiveVars in autorun. nx-js/observer-util#25
Giving this a small break, @blockrazorbot label "unmet dependency".

[janat08]

@blockrazorbot label 'unmet dependency'

[janat08]

@blockrazorbot remove label "in progress"

[janat08]

@blockrazorbot unlabel "in progress"