Closed hmdne closed 1 year ago
The reason for current test not passing issue is that before this patchset (especially the patch using which we came -back?- to Tilt) is that before that the compilation used to be done before running the specs, now it's done during the first run. I will try to find that issue quickly and finish the PR with the patch that is the reason why this refactor has been done in the first place.
The reasons why I moved some Gems to a git release:
Ok - this patchset is ready. I have updated Opal to v1.7.0, which adds some support for Ruby 3.2 features.
In a couple of days we will release v1.7.1 which will correct a pressing bug that will allow us to switch to a WebWorker Opal, so that there won't be constants conflicts (#137) anymore. We will be able to have an infrastructure like follows:
[ main application, using Opal ]
[ controlling the browser and ]
[ the Ruby Engines ]
| |
| |
v v
[ Opal from opal-cdn via ] [ ruby-wasm-wasi ]
[ webworker to run ] [ from jsdelivr to run ]
[ user-supplied code ] [ user-supplied code ]
[ each time in a fresh ] [ each time in a fresh ]
[ context ] [ context ]
I also wanted to upgrade ruby-wasm-wasi to the stable version, but from what I see, it hasn't been released. The question is, should it become the default runner once it's released?
I also corrected the test system so it doesn't timeout anymore, since I replaced Sprockets with Tilt.
Tilt also hasn't been released with a bugfix, so we fetch the git master version.
@easydatawarehousing @hsbt what are your thoughts?
Your implementation of swappable Ruby engines looks very impressive! And future proof. Technically I can not really comment, have not done much with Opal/Wasm recently, but your changes all seem logical. Cleaning up of existing code can't hurt (this was pretty much the first thing I ever built in Ruby).
In the past there were some concerns over loading times of the site. Not everybody in the world has access to a broadband internet connection. Would this change impact loading times negatively? Other than that, as long as everything works on modern web browsers it is fine with me.
Thanks, Ivo
The implementation wasn't mine, I just rearranged the things and created an Opal-WebWorker runner.
In general, implementation of Opal over WebWorker will allow us to get rid of the parser parts of Opal, therefore reducing the sizes. But running the code will require downloading the respective implementation. I will do further experiments regarding performance.
Anyway, from my experience, even the current version of TryRuby isn't really outstanding in terms of sizes compared to other contemporary websites.
I have disabled the Opal RubyEngine, replacing it with Opal-WebWorker (and a couple other minor optimizations).
This changed the minified (uncompressed) bundle size from 2225786 bytes to 493657 bytes. This is for the initial load, for actually running code, you need to download some RubyEngine, either Opal-WebWorker from Opal CDN, or CRuby WASI from jsdelivr. So initial code run will certainly be slower.
This entire branch also disables the integration code for CRuby WASI until it's being used.
I have tried testing the CRuby WASI for replacement (note: this patchset doesn't replace Opal with CRuby WASI, just with Opal WebWorker), but actually the lessons are written with Opal in mind (compare: #134 ) and they don't work out of the box, would need to be amended.
In this pull request I will focus on a couple of changes to the application structure, trying to make it a lot more obvious, but also fixing a couple of issues.