Meta: Migrate away from ExtJS about hamsket HOT 12 OPEN

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.

from hamsket.

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

from hamsket.

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

from hamsket.

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.

from hamsket.

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

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

from hamsket.

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

from hamsket.

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

from hamsket.

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.

from hamsket.

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.

from hamsket.

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.

from hamsket.

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.

from hamsket.

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.

from hamsket.