User:Prd

Git
Ah, now I've got it.

Studybuddy

• HTTP
• HTML
• CSS

• LESS
• Mustache

• JS

• Node - See: https://nuxt.com/docs/api/nuxt-config#nitro
• Vue - See: https://github.com/vitejs/vite-plugin-vue/tree/main/packages/plugin-vue
• Nuxt - Test environment being built.

• Leaflet - Foundation of the map but as per the coordinate transformation the library is mostly a guideline, not a rule.
• jQuery - Too prevalent not to be familiar with.

• PHP- (We hate Laravel)

• Parsoid

• Nginx - See maintenance & downtime plans.

• SSL

• Kubernetes

• Blue/Green

• MySQL

• MariaDB

• Cargo
• MW-core
• Unix
• Bash

• Q: Why a high level framework? Why not Laravel?

• Good questions, here's the answers:

• 1. A similar line of thinking as to "Why MediaWiki 1.43?". It serves the use-case and provides me access to a mountain-top view. I'm more than willing to traverse that mountain and don't want to ignore any aspect of the stack high or low. Also, I want to write in pure PHP so there's as little abstraction as possible when browsing the ocean of the MW-core and its extensions. Knowing when Laravel was utilized is good to know - it's not any more necessary than Nuxt to actually use. That said. I'm not overtly opposed to Laravel's use. I've been staring at PHP for weeks and catch snippets of JS as I go along. This is to forcefully expose myself to a JS heavy environment and adapt.
  2. Because I'm not actually restricting myself to the high level. As much as I want to see heavily bundled frameworks I'm spending just as much time perusing documentation on TLS, TCP/IP, HTTPS, DNS, SSL, nginx, etc. My intent doesn't stop at the wiki or the map. The path to total sysadmin is almost invariably going to be slow and filled with struggle. Wrestling with Nuxt and MediaWiki is just as important as taming nginx and cloud services. Everything matters.

• Also...

• No. I will not be using Django (Python) or Rails (Ruby). Considering the ubiquitous presence of PHP on MediaWiki and the lack of integrating tooling for the aforementioned I'm left with too much added work to try and get those spun up. Time is better spent developing skills which can directly translate to the wiki. Besides, a javascript heavy approach to the map gives me ample exposure to the other big player on the wiki (especially for gadgets). This is not about making the greatest map to ever exist built in the most ideal way. Rather, it needs to meet various functional uses and refine around those. Obviously the existing map is a rudimentary mock-up and embodies only one test of one feature (coordinate conversion).
• The topic of Leaflet has already somewhat been settled. The library is effortless to work with and boils down to optimization strategies. Load times have been as low as ~200ms for the global map wrapper via the Nuxt module.
• Vue's lovely interface options are the big task at hand since they're the primary driver of the interactivity. On measure the map itself is a static element with rigid elements requiring no manipulation beyond load routines.
• So you might ask - what of the mod loading capabilities? Simple answer: they won't be in the first iteration of the map. Before adding custom data I'd like to be sure all other forms of basic interactivity work fine.

• Nuxt is being used to produce the first iteration of the map. It might be used in the second or even third. By then I may change course to compare options, strip down the model further or embrace Nuxt fully. Who can say?