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
[email protected]#reflections/shape/shape	40089
[email protected]#src/define	39669
[email protected]#can-stache-bindings	37603
[email protected]#reflections/observe/observe	31459
[email protected]#can-view-scope	31365
[email protected]#map/map	29452
[email protected]#can-construct	27324
[email protected]#can-bind	22192
[email protected]#can-dom-mutate	19285
[email protected]#src/mustache_core	18760
[email protected]#can-stache	18333
[email protected]#reflections/type/type	17677
[email protected]#can-view-parser	16909
[email protected]#behaviors	15681
[email protected]#src/expression	15252
[email protected]#helpers/core	14201
[email protected]#scope-key-data	13130
[email protected]#value/value	12651
[email protected]#lib/list	12477
[email protected]#can-stache-key	10946
[email protected]#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)