Migrate off jQuery

[kj7rrv]

The site has outgrown jQuery. We need to migrate off. Not sure how we make decisions here, but we will need to either choose a new framework or choose to not use one.

[sushain97]

No framework isn't really a viable option.

[TinoDidriksen]

Outgrown jQuery? Goodness no. jQuery is alive and well, and unlike all the other fly-by-night new-every-week JS frameworks, it just works and is maintained. I say that project using other JS frameworks would be better off moving to jQuery.

[sushain97]

The state management in this project is pretty complicated. There's no way to test it sanely and nothing is remotely broken up into components. Feel free to try messing with some of the core translation bits or writing meaningful tests.

It needs a rewrite in something more suited to dealing with complex state. We don't need Redux or any of the more complicated libraries but something simple like Preact would make it significantly better. Sure, there are lots of ephemeral JS libraries out there but ones like React have proven their value.

jQuery works just fine, until a point.

[sushain97]

Moving away from jQuery would also make it more accessible to younger contributors (i.e. GCI) that are often unfamiliar with or haven't even heard of jQuery.

[kj7rrv]

Do we need to use a framework at all?

On Sat, Dec 7, 2019 at 3:00 PM Sushain Cherivirala notifications@github.com wrote:

Moving away from jQuery would also make it more accessible to younger contributors that are often unfamiliar with or haven't even heard of jQuery.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/apertium/apertium-html-tools/issues/351?email_source=notifications&email_token=AN54XP2PZRONEMAMTORUXE3QXQTHDA5CNFSM4JXFPIOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGGRLVA#issuecomment-562894292, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN54XP5KW5D44DOVUAWR4V3QXQTHDANCNFSM4JXFPIOA .

[sushain97]

jQuery is hardly a framework. It's more a set of utility functions. The biggest thing it gets us is something that is a "framework", Bootstrap.

[sushain97]

I don't feel bad about saying this about the current state of the code since 90% of it is my fault. I'm sure that it could have been written better but the imperative style of programming that jQuery encourages just doesn't work well with complex user interfaces that are better programmed "functionally". Having to think about how your change will potentially impact every single other piece of the user interface is unsustainable and makes further development on this project pretty difficult even for someone who wrote most of the current code. Perhaps it could be completely rewritten to be more modular using only jQuery but if we're going to do a complete rewrite, jQuery isn't the right choice IMO. I'm definitely not voting for something like Angular but Preact/React aren't particularly difficult to pick up and offer lots of advantages. It's possible to use these frameworks without also succumbing to the 2GB node_modules + 10m webpack build effect.

[kj7rrv]

OK, so it sounds like React/Preact is the best choice?

[sushain97]

That's what I would vote for but I'm open to other suggestions.

[kj7rrv]

Would doing it framework-less be OK?

[sushain97]

I don't think that's a good idea. It offers basically nothing over using jQuery. The jQuery dependency is pretty light.

[kj7rrv]

Do we want to use react or preact?

[kj7rrv]

also, if I do it, I have access to any major browser except Safari.

[kj7rrv]

Would doing this entail a complete rewrite of the frontend?

[kj7rrv]

Should I start working on a React version locally?

[sushain97]

Do we want to use react or preact?

I haven't looked closely enough in a while.

Would doing this entail a complete rewrite of the frontend?

Basically.

Should I start working on a React version locally?

This migration isn't really GCI shaped & I'm afraid I don't have the bandwidth right now to set up all the scaffolding to make it into bite-size tasks (if even possible). Note that it's not just the frontend code that needs to be rewritten, it would be the CI configs, the build/testing steps, the linting, the documentation and more.

[kj7rrv]

After we decide react/preact, is there any reason I can't start working on it locally when I'm waiting for a mentor to accept GCI tasks? I would have quite a bit of time that was not GCI.

On Mon, Dec 9, 2019 at 12:24 AM Sushain Cherivirala < notifications@github.com> wrote:

Do we want to use react or preact?

I haven't looked closely enough in a while.

Would doing this entail a complete rewrite of the frontend?

Basically.

Should I start working on a React version locally?

This migration isn't really GCI shaped & I'm afraid I don't have the bandwidth right now to set up all the scaffolding to make it into bite-size tasks (if even possible). Note that it's not just the frontend code that needs to be rewritten, it would be the CI configs, the build/testing steps, the linting, the documentation and more.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/apertium/apertium-html-tools/issues/351?email_source=notifications&email_token=AN54XP6XYZA53H2NG7KGVJDQXX6DFA5CNFSM4JXFPIOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGIINWA#issuecomment-563119832, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN54XP2HVHTC64YHMN45TWDQXX6DFANCNFSM4JXFPIOA .

[kj7rrv]

If small size and performance are important, Preact sounds like the better choice.

[kj7rrv]

It looks like either one needs node.js for a normal installation. However, it appears to be possible to avoid this.

[sushain97]

After we decide react/preact, is there any reason I can't start working on it locally when I'm waiting for a mentor to accept GCI tasks?

I can't stop you from trying! But really, I don't encourage it because I don't have the time to actively mentor an undertaking of this scope. There are a lot of "hidden" requirements.

It looks like either one needs node.js for a normal installation. However, it appears to be possible to avoid this.

We'd have to produce compiled dist files. There can't be a runtime dependency on Node.

[sushain97]

Er, to clarify, the minified and compiled bundles + source maps would have to be checked in.

[kj7rrv]

What are dist files? I could pretty easily avoid the Node dependency. In fact, I could even make it static files if needed.

[kj7rrv]

I'm referring to doing it separately from GCI. Also, the minified and compiled bundles of what?

On Tue, Dec 10, 2019 at 9:19 AM Sushain Cherivirala < notifications@github.com> wrote:

Er, to clarify, the minified and compiled bundles + source maps would have to be checked in.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/apertium/apertium-html-tools/issues/351?email_source=notifications&email_token=AN54XP72S3N3PSIEY4MJ5C3QX7FQ3A5CNFSM4JXFPIOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGQBGWI#issuecomment-564138841, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN54XP4NFKPZ7CP4UC4ZJXDQX7FQ3ANCNFSM4JXFPIOA .

[sushain97]

Static files aren't possible. This project needs a build step (check out what the current build steps do for context as to why).

The minified and compiled (technically, transpiled) versions of the ES6 for browsers.

There's already a Node dependency here for development, just not for building it. There's no sensible way to get rid of it.

[kj7rrv]

I meant it would build to static files.

[sushain97]

Sure. That's really the only way (and what we do right now) aside from SSR which we're definitely not doing.

[kj7rrv]

What's SSR?

On Wed, Dec 11, 2019 at 8:51 AM Sushain Cherivirala < notifications@github.com> wrote:

Sure. That's really the only way (and what we do right now) aside from SSR which we're definitely not doing.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/apertium/apertium-html-tools/issues/351?email_source=notifications&email_token=AN54XPYHM5RF3ETZ6G3AIFTQYEK7TA5CNFSM4JXFPIOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGT2CUI#issuecomment-564633937, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN54XP7G7E4KRMNV5MEC43TQYEK7TANCNFSM4JXFPIOA .

[sushain97]

server-side rendering

[kj7rrv]

Ok, thanks!

[xavivars]

I'd jump in (but please take this just as an opinion). I've been recently (past few months) working quite a lot with GatsbyJS, a "static site generator" based on react.

Pros

• super easy to start
• handles a ton of stuff for you (build pipeline, etc)
• generates REALLY fast websites
• easy to move to another react-based framework if required
• AMAZING open source community
• really cool features (graphql, etc)

Cons

• very opinionated

I won't be able to support as a mentor the rewrite of Apertium's website as a GCI task (requires planning and breaking up the work too much) but I'm happy to help guiding this outside GCI

[kj7rrv]

It won't really work as part of GCI anyway. It'll have to be separate due to the size of the task.

[sushain97]

I've heard of Gatsby before but haven't used it. It might be worth a try! However, I foresee a couple of complications:

• our build process is moderately wild (fetching from random HTTP services, editing input HTML, etc.) that might not mesh will with Gatsby's opinionated build framework.
• the transpiled code might have a bunch of boilerplate/React'y bloat in it and this project is currently relatively lightweight

[unhammer]

• our build process is moderately wild (fetching from random HTTP services, editing input HTML, etc.) that might not mesh will with Gatsby's opinionated build framework.

https://www.gatsbyjs.org/ seems to suggest that pages can be rendered from existing json/API sources. Server-side rendering sounds like a good reason to at least look into Gatsby. In fact, reading about it, it sounds like it does more or less what our Makefile does, just in a much more maintainable manner =P

[xavivars]

I've been thinking about Apertium as a good use case for Gatsby for a few months now, but never mentioned it because I don't like proposing work and not being able to spend time on it, and also because of the amount of time spent on our own custom build.

But it's definitely worth giving it a try.

Reading data at build time from static files (json, yml, Markdown,...) is straight forward, and it's also relatively easy to pull data from services.

[kj7rrv]

Won't the build process be replaced entirely in the migration process?

[kj7rrv]

Gatsby looks pretty good for this.

[kj7rrv]

I'm gonna work on a version, it'll be a good learning exercise for me anyway. It'll be under a permissive OSI-approved license, so Apertium can use it if it turns out good.

[unhammer]

Won't the build process be replaced entirely in the migration process?

That'd be great =D

(it feels more correct to call it a rewrite than migration …)

[kj7rrv]

Yeah, it isn't really a migration.

[kj7rrv]

Also, should I make it a PWA? It seems that that will be pretty easy with Gatsby.

[kj7rrv]

https://github.com/scoopgracie/apertium-site is the repo for my version. Right now, I haven't committed anything, so it's just a README and LICENSE (Apache 2, but I'm willing to relicense).

[kj7rrv]

I just thought... where are the translation files? I'll need them to continue.

[kj7rrv]

nvm, found them

[kj7rrv]

What browsers do we need to support? Last 2 versions of IE, Edge, Chrome, Safari, Firefox, and Opera?

[sushain97]

https://browserl.ist/?q=%3E+0.15%25 would be nice. It's a matter of determining what the bundle size tradeoffs look like.

[kj7rrv]

What market share of browsers do we need to support? 1-2%?

[sushain97]

I just linked directly to what I wanted.

[kj7rrv]

OK, thanks!

[kj7rrv]

Anyone who wants to contribute, see https://github.com/scoopgracie/apertium-site/issues/.

[sushain97]

Transposing my thoughts from an email conversation with @jonorthwash:

There are multiple axes where taking a 3rd party dependency/framework is useful.

1. Build system Current approach: Makefile + Python scripts Preferable approach: A JS bundler system like Webpack/Parcel/Rollup - GatsbyJS is just Webpack underneath as far as I can tell. My opinion: Almost anything is better than what we have now. Really though, this stuff is relatively less likely to change once set up so it's not a huge deal if it's complicated. We've rolled our own and it ~works for now but is pretty complex.

2. UI framework Current approach: Bootstrap Preferable approach: I dunno, there are lots of options here. I personally like http://blueprintjs.com/ but it might be the wrong aesthetic for apertium.org. It also doesn't necessarily come with all the layout utilities we would want. My opinion: We can probably go in lots of reasonable directions here. I would focus on A) something that will work with the JS framework and B) something that comes with all the things we need included. It's probably not a huge deal though, we can customize what we use and html-tools isn't that complex as far as the UI components go. We should find something that supports all the Boostrap components we use now (alerts, notices, etc.).

3. JS framework Current approach: jQuery Preferable approach: React/Preact+JSX. Or even React+TypeScript potentially! Even Vue.JS is a possibility. My opinion: If I were writing this scratch, I would use React + TypeScript. They both have huge communities and lots of folks that can work on html-tools. React also offers the libraries/built-in state-manangement/functional components structure that we would need to make html-tools more maintainable/less prone to bugs/more readable. IMO - We should not use plain JS (especially not ES5) with no JS framework. If we do, we might as well not rewrite at all.