Is a plugin rewriting RMMZ codebase into ES6 standard a good idea?

[DoubleX 208]

I think such a plugin has at least the following potential advantages:

1. Those avoiding direct prototyping like a plague can work with an ES6 version

2. Those not being familiar with ES5 don't have to learn this outdated approach, especially when it's just for writing RMMZ plugins

3. As this plugin can be directly maintained by the RMMZ plugin developer community, it might address their needs more effectively and efficiently(as long as such changes won't break plugins not written with this plugin in mind)

 

And at least the following potential disadvantages:

1. This plugin will need to be kept in sync with the default RMMZ codebase changes, which can be very complicated and convoluted for the plugin developers involved to detect all the changes in the latter(while letting the plugin users/other plugin developers know if the plugin's outdated is an easy, simple and small task)

2. This can further "encourage and recommend" ES5 vs ES6 flame wars among some plugin developers(and can be a serious community trouble if it becomes a widespread drama), as some will write plugins in the ES6 standard with this plugin and some will continue to write ES5 with direct prototyping without this plugin

3. Some plugin users touching plugin implementations will have to deal with both ES5 and ES6 styles, as some plugins will be written in the former and some will be written in the latter(or even mixed styles in the same plugin in some rare extreme cases)

 

To make this post more effective and efficient, I've used nearly 35 hours in 3 days to write 1 such plugin(0.9.5 with just the core parts).

While it might break some plugins not written with this plugin in mind despite the fact that I've checked about that several times already, I want the discussion to focus on whether THIS DIRECTION AS A WHOLE is a good idea, so I hope it's not so poorly written that it'll defeat its purpose in this post :)

Edited August 5, 2020 by DoubleX

[Kayzee 4,032]

Is refactoring another project's codebase purely for the sake of refactoring another project's codebase ever been a good idea? No really, I legit am not sure. I suspect the answer would be: Only if people actually use the new codebase. Not sure if you have given the average user any real reason to care, or even the average programmer.

[PhoenixSoul 1,404]

I say, if it has both short and long-term benefit and such is a greater benefit than a detriment, it's worthwhile, otherwise, mileage varies.

[casper667 131]

Probably not a good idea.

 

Most existing plugin creators are going to use ES5 (assuming that's what the default codebase is actually written in) as they already know it from MV, and it'll also be easier to port MV plugins over using ES5 since those are already ES5. This would really only be for new plugin developers who are coming in and already familiar with ES6 but not ES5. A new dev who does not know either will likely have no preference and be fine learning ES5 which is what most RPG maker focused tutorials will be covering. I think this means adoption of such a plugin would be low even if it was a good idea.

 

On top of that, there are a lot of issues this could create including the disadvantages you already noted and introducing additional bugs not in the default codebase.

 

MZ should have switched to ES6 (or in my preference a different language than JS altogether) if they wanted the community to do so, but they decided not to for one reason or another so we will just have to deal with ES5 until hopefully the next maker program.

[Kayzee 4,032]

Also: I should have before, since I not really being that familiar with 'ES5' or 'ES6' I should probably ask:

 

What exactly is the difference here? How the API calls work? The coding style? Are ES5 and ES6 actually that fundamentally different?

 

Also Also:

 

What's wrong with prototyping anyway? It honestly seems to me to be functionally the same thing as using classes only with slightly different semantics.

[DoubleX 208]

While I'm personally fine with ES5 direct prototyping, quite some potential MZ plugin developers have rather strong opinions against the default RMMZ codebase sticking to that style, so I've come up with this whole idea and made a little experiment with it :)

[DoubleX 208]

With RMMZ released for a while, it seems to me that there's not much demand on applying the ES6 standard to RMMZ, so I decided to drop this idea.

However, those wanting to continue on this whole idea can freely take over my failed experiment