For client side, those are features of the DOM. If you want to go with Opal, then except for recording (though there is a sizable implementation of audio manipulation), everything is wrapped nicely in the Opal-Browser library: GitHub - opal/opal-browser: Browser support for Opal.
You can mix this part with any other Opal library, like Glimmer, if it doesn't have those features. Or you can use it by itself using a Nokogiri compatible API - but you will have to implement those nice interfaces yourself. On the other hand, this may be the easiest way to start if you don't have a lot of experience in web development - you can start with some examples I made: https://github.com/opal/opal-browser/tree/master/examples . And compared to other Opal solutions it may be the most lightweight thing to choose.
I have heard about Isomorfeus having some features of React-Native wrapped, which would allow you to create mobile native interfaces while sharing at least some code with the web version, but documentation for that may be a little bit scarce. Otherwise you will need to go with Apache Cordova and for desktop with Electron - and unfortunately, some people will hate it due to the heavy weight.
You also have https://hyperstack.org/ at your disposal, which is another library, or rather a deep integration between React and Rails and it's robust and well documented. For some kinds of workflow, you won't even need to write WS/AJAX code yourself. Thru the React ecosystem you will be able to get a lot of ready components that may even feel native on the mobile platforms. But I'm unsure how well it will be suited for mobile.
Glimmer will be the only solution here that would allow you to create a native desktop application. And maybe in the future Andy will make a native mobile implementation as well.
Going with Opal will give you Ruby on the client side, but will induce some size and performance cost - which mostly shouldn't matter that much, but it's up to you to decide.
A middle ground may be https://hotwired.dev/ which is made by the Rails people and is integrated with Rails. For some simple web applications you will be able to write no JavaScript at all, it's just backend. It doesn't use Opal.
If you want to go the JS way, you can either go pure DOM or jQuery - which would be somewhat equivalent to going with Opal-Browser. jQuery is now mostly thought to be an outdated thing to use, since the pure DOM now provides mostly everything you can get from jQuery without adding a (small) size cost - but jQuery has a very nice API and also has a lot of extensions.
Or you can go with React or Angular directly. Those are actually quite big systems that you will need to learn, but compared to the above solutions, your investment in this knowledge will pay off in well paying jobs, because Opal is relatively unknown. They have some benefits like being able to declaratively describe user interfaces (just like every other listed solution except for DOM/jQuery/Opal-Browser where you will need to update the elements yourself).
Maybe use something like Qt? It's C++/JS. I'm not sure how it compiles for the web, I know about some successes, but both desktop and mobile are well supported.
From other inspiring web technology, I will recommend you to take a look at Svelte. It will give you benefits of clean look of the modern JS frameworks while delivering the smallest code size and best performance possible. All this while keeping your code minimal.
For backend I personally use Roda with Sequel. Both are made by the same person and they integrate very well together. Roda is, just like Sinatra, minimal. Rails has a big community and this fact will allow you to abuse your search engine to quickly find solutions. Remember that you won't be able to deploy your backend on mobile, you will have to choose to communicate with it via API if you need, because sometimes you can even do without it.
So as you see, there's no perfect solution to everything. If you want to find a job, it may be hard to go with some more obscure solutions (which may be very cool otherwise!). Picking a big solution will force you to organize your code, picking a small one will give you liberty. Prioritize mobile and desktop users will be unhappy. No knowledge? For lesser known things you won't find answers about the bugs you just uncover - may also happen that you will have to maintain it if you start to depend on it too much. Get an ancient technology and don't get the swag points. Get a too big solution and cause heavy load times. Decide to write three separate frontends for web, desktop and mobile - and now you have 4 applications to develop. My advice to you would be to try at least a few of solutions and find out which one suits you the best.
···
On 10/20/21 21:20, Die Optimisten wrote:
painting (diagrams and also free-hand?)
How to (fast) transfer data - ajax, websocket
What about playing (and perhaps recording) audio and video (file and
stream)?