discussion: Roadmap

Sharing a bit of a higher level overview currently only in my brain so all y’all know what’s going on:

3.0 Use CPS

• get nested effects and error / value propagation
• streamline view api
• trim bytes by making yo-yoify applicable

---

3.1 Performance

• add request animation frame to cap updates and better handle burst updates
• provide standalone bundles for inclusion in codepen and the like

---

3.2 Plugins

• app.use() API (oh god)

---

3.2.1 fix path triggers

• fix the send(location:href) call

---

3.3 Custom async paradigms

• provide wrap hooks so alternative async implementations become first-class citizens (e.g. choo-pull, choo-xstream, choo-rxjs, etc.)

---

4.0 Routing

• upgrade sheet-router to handle hash routes by default; would make handling routes a complete no-brainer (it can be a bit tricky rn when using both hashes and normal routes)
• update sheet-router to no longer use route()

---

4.1 Components

This is where we add one of the last large feature additions: choo/component.

• add choo/component based on nanocomponent
• replace const with var, all the way down

---

5.0 polish mode

I think at this point choo is quite stable. The syntax will probably not change; we’ll just keep making things smaller and faster.

• switch over to nanomorph
• allow querystrings to become part of routes
• remove on-load from choo/html now that it’s part of choo/component
• remove prev from elements as nobody uses it anyway
• change stack trace callback to keep history inside hooks

---

5.1 / 6.0 threads

• use threaded effect and reducer execution using webworkers

---

Goals not (yet) bound to roadmap

• look into trimming all .forEach() and .map() calls and replacing them with ES3 equivalents - speed and less array allocations ftw
• get (dev)tools out there that can visualize all action calls and lay them out visually - would make debugging silky smooth
• add a whole bunch of benchmarks so we know how choo is doing compared to itself

[shama]

@yoshuawuyts My primary worry is plugins creating flavored elements; elements that only work with some choo plugin enabled. My secondary worry is the ecosystem creating choo plugins which could have been just regular modules accessible to everyone.

Plugins by their nature are convenient and is why every framework implements an API for it. But my goal has been to try something different then what everyone else currently does. I want to see if a client side ecosystem can be built without peer deps.

Just my 2 cents, but what if we tried to achieve the individual desired app behaviors (logger, devtools, etc) without a plugin system first. Then fallback to implementing a plugin API if the behavior is useful and deemed impossible without it?

[nolanlawson]

Yeah this is a super under-researched area, but I did implement vdom-serialized-patch as a solution for virtual-dom anyway.

Best advice I can give is that you need to architect it such that the perf gains of multithreading are not outweighed by the cost of serializing and sending messages to the worker. I wrote about this a bit but to sum up:

1. Send stringified JSON in postMessage()
2. Batch the messages
3. Make the messages as small as possible

Also this works best when basically the entire app lives inside the web worker because otherwise you are sending messages back and forth from the worker to the main thread constantly.

There’s also some research from Parashuram and from Chris Thoburn.