Skip to content

The staging branch#141

Merged
hmdne merged 15 commits intomasterfrom
staging
Jan 9, 2023
Merged

The staging branch#141
hmdne merged 15 commits intomasterfrom
staging

Conversation

@hmdne
Copy link
Copy Markdown
Collaborator

@hmdne hmdne commented Nov 26, 2022

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.

@hmdne hmdne force-pushed the staging branch 2 times, most recently from bdc6e3f to 6209754 Compare November 26, 2022 22:47
@hmdne
Copy link
Copy Markdown
Collaborator Author

hmdne commented Nov 27, 2022

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.

@hmdne
Copy link
Copy Markdown
Collaborator Author

hmdne commented Nov 27, 2022

The reasons why I moved some Gems to a git release:

hmdne added 5 commits January 5, 2023 09:28
This improves development tremendously - while live reload doesn't work now
(but manually refreshing page does) the development load times are much much
better, especially connected with recent improvements to Opal::Builder.
Also, source maps now work correctly.

Ref: opal/opal#2479
@hmdne hmdne force-pushed the staging branch 3 times, most recently from 3ceba44 to b890810 Compare January 5, 2023 11:48
@hmdne
Copy link
Copy Markdown
Collaborator Author

hmdne commented Jan 5, 2023

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?

@easydatawarehousing
Copy link
Copy Markdown
Collaborator

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

@hmdne
Copy link
Copy Markdown
Collaborator Author

hmdne commented Jan 9, 2023

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.

hmdne added 2 commits January 9, 2023 14:07
Also, move opal-parser to opal ruby-engine. This won't matter for now.

This reduces bundle size a little:

Before:
$ ls -al build/javascripts/application.js
-rw-r--r--. 1 user root 2225786 Jan  9 14:00 build/javascripts/application.js

After:
$ ls -al build/javascripts/application.js
-rw-r--r--. 1 user root 2080461 Jan  9 14:06 build/javascripts/application.js
Correct a couple of other issues with Opal-WW that we didn't catch
previously.

Bundle size after this commit:
$ ls -al build/javascripts/application.js
-rw-r--r--. 1 user root 493657 Jan  9 15:34 build/javascripts/application.js
@hmdne
Copy link
Copy Markdown
Collaborator Author

hmdne commented Jan 9, 2023

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.

hmdne added 5 commits January 9, 2023 17:15
Also, don't actually execute the code on the first page load.
We don't necessarily need it. This made a race condition
happen while testing the async engines.
@hmdne hmdne linked an issue Jan 9, 2023 that may be closed by this pull request
@hmdne hmdne merged commit f54838b into master Jan 9, 2023
@hmdne hmdne deleted the staging branch January 9, 2023 19:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Using class names suffixed with consecutive numbers triggers type error

2 participants