I'm back from my holidays, so it's time to do the final twenty episodes. But before I get back to coding, let's take a look back at some of the ideas I tried, which ended up not working.
As the goal of the series is to write a post a day, I cannot spend too much time on an idea that's not working. I'm not saying none of these ideas are possible, just that the obstacles were too great, and after giving them a try, I ended up deciding to do something else instead.
Imba
One thing I tried repeatedly is to do some episodes with Imba. Imba 1 used to be my favorite frontend framework before I discovered Svelte.
Then our paths diverged - Imba 2 is a major breaking change, that has been in alpha for two years now, and some of Imba 1 use cases are still not ready, sort of Angular 2 transition style. Meanwhile Svelte solves a lot of the same problems with a much less radical design, is stable, and is very popular.
Still, I wanted to try writing a few small things in Imba 2. Unfortunately that didn't work out. imba create even comes with Electron template, but that doesn't work at all. And trying to adapt its regular template to Electron, I ran into too many mysterious errors with Electron not being able to deal with preload etc.
The problem is not with Imba as such, it's really with various boilerplates tying it to Electron, so I hope they fix it someday.
Opal Ruby
Opal Ruby promises to run Ruby in the browser. It's actually in an awkward position, as it's not completely compatible with regular Ruby, making many changes to bring it closer to what JavaScript VM expects - such as making strings immutable, making all numbers floats, regexps being are just limited JavaScript regexps, no support for full Unicode etc. So it will run simple Ruby code, but no real hope of running any bigger codebase without major adaptations.
On the other hand, these changes don't go far enough to provide seamless interoperability with the JavaScript world - especially browser APIs. Every JavaScript API needs an Opal wrapper, or it's a major pain to use. So Opal is much harder to use than "flavored JavaScript" languages like CoffeeScript or JSX.
Not to mention a lot of changes it makes to bridge JavaScript - Ruby gap cost a lot of performance. And then there's the whole under_score vs camelCase mess.
As a result, Opal Ruby has its use cases, but they're a lot narrower than the promise of "just run Ruby in a browser" would suggest.
I tried to make an episode about it, but there was a bit too much fiddling with wrapper code, so I ended up dropping the idea.
Window.requestAnimationFrame
There was a bunch of episodes when I tried to improve performance of the hex editor. One of such ideas was to do recalculations on requestAnimationFrame, even though that's a bit messy in Svelte.
I coded the whole thing, and discovered that it's completely unnecessary, as scroll events already debounce to correspond to exactly requestAnimationFrame rate.
That's a rare case where episode got derailed because something was too good, rather than not good enough.
WASM
WASM promises to run any language in a browser. Those promises come with a lot of caveats. Compiled WASM has no direct access to browser APIs, and needs to talk to JavaScript wrappers. Its interoperability with JavaScript is quite painful - WASM code is limited to just passing numbers back and forth, even Strings aren't supported directly - because obviously JavaScript strings don't match what most other languages expect. And it needs to go through wrappers to even run its own code - for basic things like allocating memory it needs to go outside WASM code.
The good thing is that WASM at least has better track record than Opal Ruby at running nontrivial codebases directly. The bad thing is that even hello world turns into an enormous mess of wrapper code, and after looking at it for a bit I decided I really don't want to be writing about it.
I think WASM might be worth investigating someday, but it would take a lot more than one quick episode.
Other JavaScript frameworks
I wanted to do some episodes in a lot of different frameworks, but framework landscape is very sparse now. jQuery is the absolute winner form among the first generation of frameworks. React is the clear winner from among the second generation, with Vue and Angular being quite far behind. Svelte so far looks like the clear winner from among the current third generation. Everything else either faded away, or never had a chance.
I did Marko and Malina, two frameworks you've likely never heard of, which try something interesting. And I guess D3 and Phaser are very sort of frameworks too. But when I was looking for other frameworks to try, it always felt like "well, nobody uses that anymore", or "well, nobody used that ever", and none of the early gen frameworks even look that interesting.
Other Electron alternatives
I checked out a few direct alternatives to Electron like NW.js and Neutralino. There's a lot of them, but it's not clear they offer anything new. A lot of them use system browser instead of bundling Chromium, and that leads to so many compatibility issues to save a few MBs I have no idea why anyone would want to do that.
One thing I thought I'd do but didn't really do much is try other UI frameworks. I tried NodeGui React (NodeGui Svelte wasn't working), which is Electron-like environment based on Qt, and it wasn't too bad.
I thought about trying out other UIs like Glimmer, JavaFX, Tauri, Flutter, etc., but a lot of them require highly unfun languages like Rust, Dart, or Java; and a lot of them are non-reactive and require painful manual syncing of state and UI. I might still try a few in the remaining time.
Coming soon...
Let me know if there's anything you'd like to see me try before the series ends.
In the next episodes I plan to give JRubyFX and Glimmer a try, as well as just write a few small Electron apps for fun. See you soon!
Top comments (0)