<span class=navbar-toggler-icon></span></button><div class="collapse navbar-collapse" id=navbarToggler><ul class="navbar-nav mr-auto mt-2 mt-lg-0"><li class=nav-item><a class=nav-link href=/about.html>About</a></li><li class=nav-item><a class=nav-link href=/blog.html>Blog</a></li><li class=nav-item><a class=nav-link href=/gallery.html>Gallery</a></li><li class=nav-item><a class=nav-link href=/download.html>Download</a></li><li class=nav-item><a class=nav-link href=/docs.html>Documentation</a></li><li class=nav-item><a class=nav-link href=/community.html>Community</a></li></ul></div></nav><div class="position-relative overflow-hidden p-3 p-md-5 m-md-3 text-center bg-dark bg-grid"><div class="p-lg-1 mx-auto my-1 text-white text-left"><h1 class="title display-4 font-weight-normal">Ready<br>Bridging the web gap in EndBASIC█</h1></div></div><article class=container><p>After a ton of work, a lot of which was unexpected, I am ecstatic to announce that EndBASIC is now a reality on the web! The whole language interpreter can now run as a fully client-side web app on a computer, on a tablet… and even on a phone. Yes: the whole thing, which is written in Rust (94%), works in a modern browser with just a tiny bit of JavaScript glue (1%).</p><p>Witness for yourself in the <a href=https://repl.endbasic.dev/>dedicated website</a> or… you know, right here in an iframe!</p><iframe id=terminal src=https://repl.endbasic.dev/></iframe><p>I have to confess that this launch is <em>way</em> more exciting than getting the command-line version of EndBASIC <a href=/2020/05/endbasic-0.2.0.html>up and running</a>. After all, I’ve written countless command-line tools over the years (or is it decades now?), but have done very little work on the web. Exploring new technologies—WASM, some HTML5 stuff, push on green—and seeing how my kids were wowed when they realized that this could reach anyone in the planet, <em>instantaneously</em>… is priceless.</p><h1 id=motivation>Motivation</h1><p>My plan after the 0.2.0 release was to add some “visual” features like <code>COLOR</code> and <code>LOCATE</code>, which happened relatively quickly. But after doing that, I felt that having to deploy new versions of the code to my kids’ computer (which they rarely use) felt clunky. What if this was all accessible via the browser so that they access it from, you know, the iPad they are now using every day for home schooling? After all, I’m looking for immediacy in getting to the coding experience with this project, so that felt fitting.</p><p>With that in mind, I had a <a href=https://twitter.com/jmmv/status/1260885543333888001>rudimentary proof of concept</a> up and running in less than two hours with <em>zero</em> past experience with WASM and very limited experience with JavaScript.</p><p>But getting to the final version has taken much longer… and a lot of sweat. In particular, I was stuck for almost five days trying to make the simple <code>INPUT</code> statement work, and then I had to put a lot of grunge work to port the uninteresting bits to the browser (like <code>SAVE</code> and <code>LOAD</code> using HTML5’s local storage).</p><p>Why? Let’s peek through the journey.</p><h1 id=step-1-trimming-dependencies>Step 1: Trimming dependencies</h1><p>The first roadblock that appeared when cross-compiling the EndBASIC interpreter to WASM were some dependencies that are not ready for this target. I had just finished adding features to change colors via the <a href=https://crates.io/crates/crossterm>crossterm crate</a>, and that crate does not have support for targeting WASM.</p><p>So the first step that had to happen was the thing I didn’t do originally out of fear of making things too complex: keep the language core separate from the REPL. Doing this <a href=https://github.com/endbasic/endbasic/commit/0c6fc69d15a11c8478b243bff2113f9992c0e251>wasn’t too complicated</a> though: introduce a Cargo workspace, pull things apart, and do a couple of code changes to move the <a href=https://crates.io/crates/rustyline>rustyline</a> and crossterm dependencies to the REPL crate. The core is now lighter-weight and makes no assumptions on how it is connected to the user console.</p><p>… which means EndBASIC can now be trivially embedded into other programs if you so wish, with a very small cost (and with the potential of reducing that even further). Stay tuned on this.</p><h1 id=step-2-cross-building-to-wasm>Step 2: Cross-building to WASM</h1><p>The second step was hooking up the interpreter to a web page. This was pretty easy thanks to the tutorial in the <a href=https://rustwasm.github.io/book/>Rust and WebAssembly</a> book, and as said above, it took 2 hours tops.</p><p>Integrating <a href=https://xtermjs.org/>xterm.js</a> wasn’t too hard either by following the trivial demo code, though this exercise highlighted that command editing on the web would be much crappier than on the console for a while. Simply put, <a href=https://github.com/kkawakam/rustyline/issues/377>rustyline doesn’t work on the web</a>, and I haven’t yet implemented any of its fancy features.</p><h1 id=step-3-dealing-with-blocking-io>Step 3: Dealing with blocking I/O</h1><p>The third step is where the real pain came: making 99% of the EndBASIC interpreter work in a web context was trivial. But getting the remaining 1% took nearly five days—or, really, early mornings / late nights because, after all, this is happening in my free time!—of experimentation. So what was this 1%? <code>INPUT</code>.</p><p>You see, the way I designed EndBASIC was: the REPL is a loop that executes statements. When one of these statements is a call to <code>INPUT</code>, the interpreter issues a callback to a function supplied at construction time, and that callback blocks until it reads a line of text to feed back to the <code>INPUT</code> processor. But… <em>you can’t block in JavaScript</em>.</p><p>I spent quite a bit of time trying crazy things like adding buffers, condition variables, futures, etc. especially after seeing that there seems to be some support for atomics in WASM. But I couldn’t get that to work, and the fact that this support was gated behind experimental features in the Rust toolchain and in Firefox made me quickly realize that I was down some crazy path. After all, there are plenty of web apps that do harder things without using experimental web features, so I was definitely doing something wrong.</p><p>In the end, I was forced to <a href=https://users.rust-lang.org/t/dealing-with-blocking-input-in-wasm/42695>ask</a> the Rust user forums for advice after seeing that the answer seemed to be making my code async-friendly. I feared approaching this route for lack of knowledge, so I wanted some reassurance that it was indeed the way to go. And… I got that confirmation.</p><p>So after some more failed attempts, I took the plunge and made the whole interpreter async-friendly just so that the <code>INPUT</code> callback could be async. And you know what? <a href=https://github.com/endbasic/endbasic/commit/57835dff0fa251bb96f8ab740ebc1092a09ba281>It wasn’t that hard</a> after all. With that resolved, making input work was not much harder, and this was one of those “Eureka!” moments that I crave for but rarely get to experience.</p><p>And making <code>INPUT</code> work also unblocked interactive program editing via <code>EDIT</code>, which brings us to the next step.</p><h1 id=step-4-abstracting-program-storage>Step 4: Abstracting program storage</h1><p>At this point, the whole language interpreter was working and I knew I had unblocked the main problem to bridge the web gap. But the whole thing was still too unusable to announce. In particular, all commands that deal with program storage were still unusable because they assumed I/O against a file system. I knew not abstracting this early enough would come back to bite me… and it did, but I wasn’t expecting it would happen so soon.</p><p>I had to introduce an abstraction to isolate program storage so that commands like <code>DIR</code>, <code>LOAD</code>, and <code>SAVE</code> could do different things depending on the underlying platform. With this abstraction in place, it was pretty easy to add a <a href=https://github.com/endbasic/endbasic/commit/f6d8c18201db6e6998b77c7f615bda7ba4cf7a6c>specialization</a> that uses HTML5’s local storage instead of the local disk.</p><p>I got a little bit stuck here as well because Travis CI didn’t want to run my browser tests while my macOS installation did, which made me <a href=https://users.rust-lang.org/t/wasm-bindgen-test-and-no-tests-to-run/43444>ask</a> in the Rust user forums again. But, this time, I found the answer but myself a few minutes after, and it stemmed from version inconsistencies in my dependencies.</p><h1 id=step-5-push-on-green>Step 5: Push on green</h1><p>The last cool thing that I played with throughout this process was configuring the Travis CI pipelines to push a new version of the web interface as soon as it passes tests and is merged into the master branch.</p><p>There is not a lot of magic here (and I think what I did is a bit too “manual” compared to what Travis CI offers), but seeing the whole thing work in an automated fashion is very pleasant. The next step in here is migrating to GitHub Actions—I’m using Travis CI out of inertia—but that yak ought to be shaved another day.</p><h1 id=parting-words>Parting words</h1><p>To be honest, I have now spent way more time on the frontend aspects of EndBASIC than in the language interpreter itself, which is not what I was originally expecting. And as a result, the language is still lacking some important features—in particular, <code>FOR</code> loops and function calls so that I can add things like random numbers and timers.</p><p>Anyway, with that said, head to:</p><blockquote><p><a href=https://repl.endbasic.dev/>https://repl.endbasic.dev/</a></p></blockquote><p>to give all this a try.</p><p>Expect things to break everywhere but know that you can just reload the webpage to start afresh (Ctrl-Alt-Del, anyone?) 😄. Don’t hesitate to send feedback and… <strong>if you are willing to help me build EndBASIC, please let me know!</strong> I have some pretty strong ideas on what I’d like this whole thing to look like, but there is a ton of work to be done at all levels.</p><p>Thanks for listening.</p><script>$(document).ready(function(){$("#terminal").click(function(){})})</script><div class="row post-links"><div class="col-6 text-center"><span><a href=https://www.endbasic.dev/2020/11/endbasic-0.3.html>« Next post</a></span></div><div class="col-6 text-center"><span><a href=https://www.endbasic.dev/2020/05/endbasic-0.2.0.html>Previous post »</a></span></div></div></article><footer class="pt-5 pb-3"><div class=container><div class=row><div class="col-md-8 text-left"><form class=form-inline action=https://hugo-dynamic.endbasic.dev/api/sites/6a633c2c-7fda-11ec-86e4-1cfd087199c2/subscribers/add method=post><input type=text name=email placeholder="Enter your email" class="form-control input-sm text-center mx-1" size=20>
0 commit comments