The Short Term

[calebjacob]

After talking with @gabehamilton and helping onboard @Kevin101Zhang and @jackson-harris-iii, it seems like we have some pain points and questions to think through for the short term while the new engine is being worked on:

• The new engine should help alleviate a lot of the issues we’re currently running into (not having access to global state or query management tools, not having access to NPM, not having access to modern JS syntax or TypeScript).
• Getting the new engine in place sooner than later will benefit everyone. The more features we build now on the old engine will mean a greater effort in refactoring once the new engine is ready. We’re currently accruing some level of technical debt with every feature we implement.
• We have quite a few developers contributing to our current components. Should we think about redirecting some of that effort to help out with the new engine? Another option would be spending some of our effort on improving the current VM, but we risk implementing even more technical debt and deviating from the new engine further.

An example of decisions we need to make right now:

• Should we start using the VM’s current export/require module syntax or would this cause too much of a headache when switching to the new engine?
• How do we handle really complex state that’s spread across multiple components? The activity feed + moderation is a good example of this getting out of hand.

What I’ve been trying to do:

• Encourage everyone to share paint points and requests on the new engine discussions page.
• Remind everyone that the current BOS/VM setup is a rough prototype that has a lot of limitations. In the short term, we just need to build features as best we can with our currently limited tools.

It might make sense to set up a meeting to dive deeper, but I first wanted to start with a public thread and get everyone involved thinking through the short term for BOS. Feel free to add any thoughts or questions. Thanks!

CC @charleslavon @mpeterdev

[mpeterdev]

Thanks for starting this conversation Caleb, we're currently at a point in development where these questions are more relevant than ever since we're getting close to a version of BWE which can support development of non-trivial components. As a reminder to everyone, the main item which remains for us to implement to reach that goal is CSS support.

Should we start using the VM’s current export/require module syntax or would this cause too much of a headache when switching to the new engine?

Great question, we haven't yet addressed what cross-component code sharing might look like in BWE unless the code was accessible as an npm package via standard import syntax (npm cdn / github). Is the current module syntax used for anything BOS specific, or is it vanilla JS? If it is vanilla JS then you could use it for now and plan on porting it to npm packages in the future.

That being said, I am not sure that is ideal because then that code wouldn't actually live on chain and the problem of dependency centralization is greatly exacerbated. i.e. if GitHub goes down it shouldn't prevent you from loading BOS components

I had been thinking that NPM imports would entirely supplant BOS modules, but I am thinking now that we may want to support both. I believe it should be relatively easy to implement in BWE as well.

In the short term, we just need to build features as best we can with our currently limited tools.

Something we have been talking to the emerging tech team about is building directly in React for anything that needs to be built before BWE is ready but is not feasible to implement well under the current VM. The reasoning here is that migrating a vanilla React component to BWE will actually be more straightforward than migrating a VM component to BWE, as long as the vanilla React component doesn't use features that BWE won't be supporting out of the gate.

We have quite a few developers contributing to our current components. Should we think about redirecting some of that effort to help out with the new engine?

With the addition of NPM imports, it's a great time to get more involvement on BWE outside of the core BWE team. The more component code we write against BWE now, the quicker we identify necessary improvements. This could take the form of either migrating some existing components to see how they perform or writing more targeted demo components.

When do we at Pagoda start converting our components to BWE?

This is the big question, we want to make the switch as soon as possible but there are tech debt penalties to switching prematurely. I would hate to end up in a state where we have done component migrations but need to be implementing features on both the BWE and VM component versions due to instability in the engine.

The alpha test will be extremely informative on how close we are to the engine being ready for significant usage. I am optimistic that it will be well received, but we will of course be expecting some bugs and shortcomings. If the findings do not lead us down a path where there is significant rework required or large performance penalties associated with the fixes, then I believe we could move soon after into a state where we are migrating a portion of near-discovery-components to use BWE.