It's good to publish early, and publish often--and I'm glad people are enthusiastic about the visibly cool possibilities of putting the interpreter into the browser!
BUT excited though one may be, there are some big points that need to be emphasized to anyone you choose to show things to (especially the Rebol-biased):
1. JavaScript is NOT bloating and contaminating the core
The JavaScript extension code may live in the main repo for versioning convenience, but it is completely separate. If you instead build an EXE, it isn't having to skip #ifdef TO_JAVASCRIPT smattered around in core files--it's simply not building ANY of the files in the directory the JavaScript bridge lives in.
Don't forget how we're fighting the dependency war more than ever. You don't even need GNU make to build...just a Ren-C executable and a 350kb TCC compiler (though you need EMCC to target the web). There's even a TCC Extension and we're only a stone's throw from being able to bootstrap from a Ren-C executable and source alone.
So the only influences of this endeavor on the core are good ones...helping make it versatile enough to embed in very foreign hosts. It makes it likely to be able to repeat that success elsewhere (C#. Qt. Red...? :-/)
2. It's very early, and this is VERY ambitious
The techniques are experimental and use bleeding edge tools. We're also trying to support a spectrum of browsers without making people fiddle with experimental settings so they won't be turned away by some initial hassle. This complicates things even more--but I think is still worth it. Again: see (1), this "complexity" is borne by the JavaScript extension alone.
I definitely don't have a thought out plan from the start--because I'm having to learn what's possible and what is not possible as I go along. If you can read between the lines, I think what's going on here is rather impressive--but you have to be pretty deeply experienced to articulate why in an informed way. Still, even the deeply experienced probably shouldn't try to pass judgment on it...yet.
3. Beta/One is NOT about shipping a next-generation web framework
Beta/One is a 24/7 online tutorial that demonstrates a vetted subset of cool features...that we have reasonable confidence are not going to need to be unlearned.
Is it exciting that the way the tutorial is being built is with an eye to generality that can be applied to other web apps? YES!
Is that web app generalization a "product" trying to publish this year? NO, NO, NO!
So be mindful of what you tell people (including yourself). If expectations aren't managed, then even Herculean successes can look like failures. And if focus slips too much into infinite distractions there won't be a Beta/One.
(Note: I do find this all kind of exciting, in spite of what I would think I'd think. Making a VID-like GUI, in a browser? Ick! But the reasons for liking it are only due to relatively recent technical advancements. That's advancements in Ren-C and its design, and in the web tech: without WASM and pthreads and ES6+Promises and ASYNC+AWAIT this would be vastly less interesting, to the extent it would be possible. It really is something you can only write circa 2019, trying it earlier would have been miserable and ugly!)