Things are currently going quite well with the JavaScript extension. It's an interesting case where we're actually on the bleeding edge of what anyone is doing--and our needs are feeding back into the design of Emscripten. So by comparison to our usual Amish tech modality, it's fun to feel somewhat relevant.
-
The "ReplPad" console is coming along. It has a rudimentary Watchlist. It even has its own interactivity test. So hopefully we'll enter a virtuous cycle of improving it and being able to make sure it stays improved and does not break.
-
@BrianOtto has made an ambitious Rebol-powered application in UI Builder. You use a forms-building dialect to make a page that you can actually download as a folder you can put somewhere and statically serve on the web. Here's a tutorial...and you can see that it's a pretty intense first application!
-
@giuliolunati and @gchiu have been making it so that we can serve and get our hosted builds from S3, and we've done the magic so you really can make a jsfiddle and get yourself a Rebol, via one script with browser detection and wires everything up: load-r3.js
-
@gchiu is putting together some experiments embedding chess in the browser, or doing calculations for power bills in New Zealand.
I've mentioned that it's truly remarkable that the JavaScript code is all an extension. It adds nothing to the core build if you don't pick it out of the extensions during rebmake. It is an example of delivering what hostkit was trying to do but couldn't really: to make the core embeddable in an arbitrarily foreign host.
On top of all this, big technical steps have come down the pipe. Eliminating "hostkit" and factoring things into extensions slimmed the release JavaScript build by more than 100k (and the debug build by almost 200k). UTF-8 Everywhere made it in, and the system hasn't exploded yet. The Redbol emulation is still a very rudimentary effort, but it does build the static pages behind hostilefork.com, and it managed to generate a test PDF while running Gabriele's Rebol2 pdf-maker.r dialect.
...but in another month we'll be halfway through 2019
I'm trying somewhat to keep my eye on the clock.
In March I posted Web Build: Dangers and Opportunities. I said it was exciting there's interest in all these applications. And I've also encouraged people to do what's fun...it's better than being bored and wandering off. (When people are volunteering their time, they should do what they want to do.) But it means we're not really getting multi-person efforts--and keeping all these projects running has a cost.
It's an inescapable fact: these efforts are expanding the scope of the project--not focusing it. Reading between the lines, there is nothing metrically suggesting we are getting closer to any specific milestone of a language deliverable.
Open questions on GitHub and in forum posts are growing vs. contracting. There are some successes: there's nice solid "clicking" of things regarding the WORD!-ness of ISSUE!s and how ANY-STRING!s relate to ANY-WORD!s. But there's little in the way of historical question-marks being taken off the table.
Here's something that isn't a problem unique to Rebol in the world of software, but still a problem: if you sit down and try to write something real, you'll instantly face a paralyzing question with no compass. ("should the keys in a JSON object be SET-WORD!s...do you use MAP! or OBJECT!", "if you use a MAP! what would the literal form be", "how do module exports work", ...)
Should The Mission Be Changed: Web Framework 2021?
The pressures that have come down the pipe are to deliver more modularity for the construction of web apps.
This will consume all available resources.
My direction in thinking was different. I thought that a tutorial--and the vetting for what would go in the tutorial--would be a good thing to rally around. We could look at the script of what we were trying to teach people, and be asking "Hm, is that true?". This would provoke the writing of tests and specs...the closing of issues.
The tutorial itself would be feeding back into the definition of the artifact. When a tutorial point came to seem too much of a gray issue, we simply strike the feature from Beta One.
And having this tutorial selling 24/7 would hopefully bring on board new people, to feed back into the design and revive the effort of defining the language.
But if there's no common vision, we don't have to call this out as a priority. It can be a thing that happens on its own time--when and if it happens. So we can call it off if people think something more exciting is afoot. I just don't want to run into that trap of what I said in my other post: "If expectations aren't managed, then even Herculean successes can look like failures."