User:Prd: Difference between revisions

Line 32:

<br>

*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).

::*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.

::*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. Since in reality the map itself is a static element with rigid elements requiring no manipulation beyond load routines.

::*Vue's lovely interface options are the big task at hand since they're the primary driver of the interactivity. Since in reality 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.

::*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?

:::*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?

@@ Line 32: / Line 32: @@
 <br>
 *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).
+::*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.
+::*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. Since in reality the map itself is a static element with rigid elements requiring no manipulation beyond load routines.
+::*Vue's lovely interface options are the big task at hand since they're the primary driver of the interactivity. Since in reality 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.
+::*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?
+:::*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?