Reducing the size of can-stache-element

[matthewp]

can contains a lot of stuff that isn't always necessary, like can-query-logic and can-connect (and related packages). StacheElement can and should be an entry point to using canjs. We should work to making StacheElement as minimal size wise as possible.

I created a build in this branch: https://github.com/canjs/can-stache-element/tree/size

Here are the results:

no-min	min	gzip	min+gzip
802.8kB	274kB	190kB	66.4kB

And here are the two 20 largest modules by size:

Module	Bytes
can-reflect@1.18.0#reflections/shape/shape	40089
can-observable-mixin@1.0.0#src/define	39669
can-stache-bindings@5.0.0#can-stache-bindings	37603
can-reflect@1.18.0#reflections/observe/observe	31459
can-view-scope@4.13.6#can-view-scope	31365
can-event-queue@1.1.7#map/map	29452
can-construct@3.5.6#can-construct	27324
can-bind@1.5.1#can-bind	22192
can-dom-mutate@2.0.5#can-dom-mutate	19285
can-stache@5.0.0#src/mustache_core	18760
can-stache@5.0.0#can-stache	18333
can-reflect@1.18.0#reflections/type/type	17677
can-view-parser@4.1.3#can-view-parser	16909
can-attribute-observable@2.0.0#behaviors	15681
can-stache@5.0.0#src/expression	15252
can-stache@5.0.0#helpers/core	14201
can-view-scope@4.13.6#scope-key-data	13130
can-event-queue@1.1.7#value/value	12651
can-view-live@5.0.0#lib/list	12477
can-stache-key@1.4.3#can-stache-key	10946
can-observation@4.2.0#can-observation	10542

[matthewp]

I would categorize the bloat into a few categories

• Old browser support code
• Legacy functionality (like helper expressions)
• Unused / unnecessary abstractions (can-construct likely)
• Underutilized tree-shakability (can-stache helpers, can-reflect/shape)
• Extra abstractions (can-reflect, can-event-queue, etc)

I think the first 3 are the easiest to tackle, especially (1) and (3). Making things more tree-shakable may not be super hard but probably can't be done without a breaking change.

[matthewp]

For example, we can get rid of can-construct by removing it from use in can-simple-map. It appears that the only feature of can-construct that SimpleMap is using is the setup method. Can we replace this with a constructor?

[justinbmeyer]

Are those module numbers minified/gzipped? I think that’s important to knowing what to target. Inline docs would add a lot that would be pulled out.

[justinbmeyer]

Btw, I might have created an issue with these numbers.

[matthewp]

The module numbers are using that steal script you wrote. It would be hard to know the weight min and gzipped due to tree shaking.

[frank-dspeed]

At Present i am trying to evaluate a can-stache version based on mustache it would be nice to be able to SSR stache templates as string only representation without the glue code for livebindings.

i try to support as much of the syntax that can-stache supports so that the templates are compatible

a realy basic implamentation to show how i handle this.property references.

const Mustache = require('mustache');


function stache(templ) {
    return (props) => {
        return Mustache.render(templ, { this: props, ...props });
    }
}

// parses the template string and returns a view function:
const view = stache(`<h1>Hello {{this.subject}}</h1>`);

// Calling the view function returns HTML elements:
const documentFragment = view({ subject: "World" });

console.log(documentFragment)

// parses the template string and returns a view function:
const views = stache(`<h1>Hello no this {{subject}}</h1>`);

// Calling the view function returns HTML elements:
const documentFragments = views({ subject: "World" });

console.log(documentFragments)