drinking-code/cherry-soda

Just another (super cool) JavaScript web framework.

cherry-soda's Issues

Roadmap

Tracking plans for cherry-cola.

Stability & Flexibility

Cherry-cola has to become stable with all the current features.

• Dynamic code synchronisation (DOM)
  • Text content
  • Attributes
  • Element types
  • Wrapping / unwrapping elements (moving the other elements horizontally)
  • Appending / prepending elements (moving the other elements vertically)
• Stable client side element finder (DOM tracking) [low priority]
• Assigning multiple elements to a single ref [testing]
• Lexical scope extraction as a function, give file and target position, and (target) function with lexical scope is extracted and bundled
  • For doSomething() callbacks
  • For state .use() callbacks
• Complete document elements (html (?), head, body) components
• Full CLI (dev, build, start)

Performance

• Leverage Bun's APIs (instead of relying on the polyfills)
• Analyse and optimise compiler timeline and communication between different components of the compiler
• Optimise the style plugin for imports to compile css (and scss, sass) module names without using sass
• Test for rendering performance
• Focus on page load (perceived) performance

Features

• Deferring sideEffect() results
• Routing (and location, response codes)
• CSS splitting and deferring
• Islands
  • Island priority
  • Scrollable islands (infinite scrolling with predefined content)
• Component / module lazy loading (code splitting)
• Images
  • Image component (automatic responsive images)
  • Image generation (favicon, thumbnails / rich link image)
• Static site generation
• Tool for analysing site load performance
• Full client site automatic app version manager
• Boilerplate generator

Use esbuild/bun instead of webpack

Design deficiency with rapidly changing states

A state listener like this

doSomething((myElement, [myState, setMyState]) => {
    const mouseOverHandler = e => {
        setMyState(/* some always changing value */)
    }
    myElement.addEventListener('mouseover', mouseOverHandler)
    return () => {
        myElement.removeEventListener('mouseover', mouseOverHandler)
    }
}, [myElement, myState])

is constantly being re-called, even though it does not have to be. Requiring the state in the statesAndRefs array (to use the setState function) does not imply the usage of the state's value.
Providing the option to use a setState without listening to state changes will drastically improve performance.