8000 Slimmer production builds · Issue #30 · modulojs/modulo · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Slimmer production builds #30

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
michaelpb opened this issue Jan 29, 2023 · 2 comments
Open

Slimmer production builds #30

michaelpb opened this issue Jan 29, 2023 · 2 comments

Comments

@michaelpb
Copy link
Contributor
michaelpb commented Jan 29, 2023 •
edited
Loading

Several things to implement:

Alternative Modulo.js builds

Once Modulo.js's source code is more stable, it's time to create alternative versions of it. New

New repo structure

/Modulo.js
/alt/Modulo.prod.js
/alt/Modulo.core.js

That way, when you version pin Modulo with unpkg, it's easier to remember as well, e.g. unpkg.com/mdu.js@1.2.3/Modulo.js

Implementation of /alt/

Write a simple bash or npm script that "snips" the Modulo.js source code at specific locations specified by comments, e.g. [END OF Modulo.core.js], or if the snips are in JS as well, something like // - - - - SNIP - - - - (Exclude below from build) or something (e.g. both descriptive to humans and an unlikely thing to ever occur)

commands.buildslim

New "buildslim" command that applies SNIPs, and/or asset manager can try to substitute /Modulo.js for /alt/Modulo.prod.js during build.

Modulo.prod.js

Only what's needed for running in production. This excludes all processors. This will only include, then:

  • Most of the core Modulo class
  • All the CPart classes (but not their defaults, or associated definition processors)
  • Reconciler, DOMCursor
  • template filters, a few parts of Templater (but not template tags)
  • Some utils

Will need to refactor to get defaults in one spot, and eventually extract irrelevant parts of Templater and Modulo into separate things. One idea: Make it more like modulo.registry.cparts = class State { to really keep it separate. Also possible to programmatically snip, e.g. base it on entire lines that look just like that with class ClassName {, and then use configuration to "snip" based on ClassName's, until the next } that is followed by modulo or the end of the file.

Modulo.core.js

A tiny core of features to allow loading of CParts, so a custom Modulo build can be made, but no bundled CParts, utils, bundled templating language, reconciler, etc. Those can all be included separately (e.g. in separate JS files), so it's easier to "remix" Modulo into a new framework.

Sparse def

Sparse def: Factor out the repetitive code in definitions that would be loaded by defaults (i.e. subtract the keyset of config defaults from the keysets found in moduloBuild.definitions).

A KISS, non-recursive approach that renders the "defaults" as JSON, then renders definitions 1 deep into window.moduloBuild.definitions.x_MyDefinitionWhatever = Object.assign({ }, window.moduloBuild._defaults.Script, { removeKey: undefined, otherThing: "okay" });

The simplest algo would be "defaults-like", but just find "the most common setting" and create a base obj that way (with "undefined" being an option for a value as well, also allowing sub settings to "unset" by setting undefined), then another O(n) passover loop to trim all undefineds. (Maybe even a messy oneliner like: (() => { for (const def of Object.values(window.moduloBuild.definitions)) { for (const key of def) if (def[key] === undefined) delete def[key]; } })())

  • NOTE: Might want to profile, could go either way in terms of what's faster. It might be that "unrolled" defs parse or load faster as a single data structure, and that gzip is good enough to find repetitive substring runs in the source code that the gains from semantic refactoring would be nearly erased
  • Alternatively: Don't include defaults, but find a "largest subtree factoring" algo? window.moduloBuild._subtree['xe32f4ae']
@michaelpb
Copy link
Contributor Author

Very versatile / consistent build "snipping" option:

  • Before rendering each artifact (HTML, JS, CSS, etc), it does one final re-template with modulo, but a different token syntax:
  • `/-{-% comment %-}-/

This can be used for templating in the final product, and can be used within Modulo's source code to template different logic for production (basically like C preprocessors :( )

@michaelpb
Copy link
Contributor Author
michaelpb commented Apr 4, 2023 •
edited
Loading 
 187 // TODO: Replace with hardcoded definitions, nameToHash, and modules (with impossible X-hashes)
 188 /* TODO: Change to include this logic: for (const name of Object.keys(this.nameToHash).sort()) {
 189             const hash = this.nameToHash[name]; // Alphabetic by name, not hash
 190 */
 191 // NOTE: ALWAYS assumes "name" in nameToHash is a JS safe variable name 187 // TODO: Replace with hardcoded definitions, nameToHash, and modules (with impossible X-hashes)
     188 /* TODO: Change to include this logic: for (const name of Object.keys(this.nameToHash).sort()) {
     189             const hash = this.nameToHash[name]; // Alphabetic by name, not hash
     190 */
     191 // NOTE: ALWAYS assumes "name" in nameToHash is a JS safe variable name

michaelpb added a commit that referenced this issue Apr 4, 2023
@michaelpb
Meta templating to allow for slimmer Modulo build refs #30
ce87d40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@michaelpb
0