Meta: Migrate away from ExtJS

[TheGoddessInari]

This seems like a good move, as explained in #17. ExtJS has an uncertain future, and updated ExtJS (from 2015!) can't be used for basic usability issues, and there may never be another new GPL version.

However, this'll require a ton of work to get away from. This is probably a long-term target, but I wouldn't mind grinding away at this.

Here is where to advocate for your favorite, most maintainable, sane, open-source friendly, roughly-equivalent framework.

[TheGoddessInari]

For reference, "Rambox Pro" migrated to React, rxjs, and Vue2.

[bliu13]

Not an expert on these frameworks at all, but you could move towards a similar stack as 'Rambox Pro'. I imagine they rewrote the app probably because it was horrific to maintain and there is money to be made. React seems to be 'pretty popular'. :P

[ThauEx]

I think first of all, someone should make a plan, what part of the UI needs to get replaced. I think the Rambox UI is not that much. There is the main window with the tabs and the service list. I don't know how much else ext js is involved, but with keeping most of the logic, a migration to something should be doable.

[TheGoddessInari]

ExtJS is intertwined with just about everything, it even proxies localStorage.

There's very little code that is (more or less) free of it.

[ThauEx]

So this means, replacing non ui components first would be a good plan, right?

[TheGoddessInari]

I'm not sure how much can be removed piecemeal, but making sure the infrastructure parts (like storage) work without ExtJS is critical, yes.

[ThauEx]

I checked out the localstorage thing and it looks like the offical implementation is being used. So no extjs one. Thats why, I would assume that only the ui needs to get rewritten with a new library/framework. But for this, someone has to decide which one to use.

[TheGoddessInari]

It's being proxied through ExtJS in Rambox. It's really everywhere.

I'm leaning toward something lighter and less crazy like perhaps Mithril, but I'm not sure what it'd need to be combined with, if anything. I'm assuming there is an actual need for such libraries.

[ThauEx]

Hm.. okay....

Mithril looks interesting, but the normal syntax is not that nice. It's looking better in combination with jsx: https://mithril.js.org/jsx.html Writing small components and having normal html code powered by jsx. So first step would be to implement the basics and check what is still working and what not.

[TheGoddessInari]

We're probably going to have to add native dependencies to get reasonable spellchecking. It'd be preferable (if possible) not to have giant, expensive pre-processor steps and special tooling other than that. JSX is presumably better than ExtJS because it doesn't have special external dependencies, but I'm weary of depending on a bunch of really heavy stuff.

To be fair, Mithril is more of a slim library (as are the others), while ExtJS is a "sink included" toolkit. A lot would have to be re-implemented as components for nearly anything else (I think), which is fine by me.

I think the first step would be figuring out the exact steps needed to start decoupling actual logic and storage parts from ExtJS, if this is to be done in a more piecemeal fashion instead of just a massive rewrite all at once.

And, well, one of the most annoying things about ExtJS is not being able to use 'regular javascript' just anywhere. You have to be extremely careful not to use particular syntax. It's making me feel that things that invade into the syntax level and use special compilers are generally going to be problematic, especially as they age or lack sane maintenance, as ExtJS has.

From some light reading, it seems that Mithril + Tachyon would be very composable without requiring external CSS (for the most part), for instance.

Strictly speaking, we don't have to be super light weight on UI since it's served locally, but it's still all interpreted. So the bottom line is probably, sane to maintain (especially long term), and does important DOM/refresh/rendering updates for us, so we don't have to worry about really suboptimal rendering on our end. If only we could sanitize the content in webviews to be less horrific. 💟

I'll investigate frameworks more in the coming weeks. September just tends to be crazy-busy for me.

[ThauEx]

Quick notice regarding local storage: The extJs component is called LocalStorage and never gets imported (is this automatically?). Inside the code, localStore is being used, which is the "normal" local storage.

I was thing about mithril a bit and I think it would be better to use "bigger" libs/frameworks. The reason is, that smaller ones might get abandoned more easily than the big ones. Then it gets complicated, because everything needs to get rewritten. Additionally they might have a smaller community, so less help, "components", etc.. If you would stick with ReactJs (and some state manager like mobx), I could support you. The current setup is already using sass for style, to having another toolchain for js/css should not change that much.

[TheGoddessInari]

Well, IMO, it's more like a lighter lib that doesn't force you to wrap your logic INTO itself, or into a view, might be easier to replace later on, and Mithril is used by a decent number of sites. Guild Wars 2 uses Mithril for its in-game marketplace. 🥇

Staying as decoupled as possible seems important.

I'll still find time to do a little mock-up in each and see what happens, but I don't want a repeat of the ExtJS mess where everything is hopelessly dependent on a years-old version, and no sane migration to newer versions OR away is really feasible because it's basically involving a 95% rewrite from scratch.

At this point, if it weren't for platform dependency nastiness (mostly Windows; I assume Chrome is 'necessary' anywhere for this despite being so huge), I'd be considering a rewrite from the ground up in a language and base more amenable to security.