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

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


  • Total voters
    18

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,748
Reaction score
911
First Language
Chinese
Primarily Uses
N/A
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 :)
 
Last edited:

Tsukihime

Veteran
Veteran
Joined
Jun 30, 2012
Messages
8,562
Reaction score
3,832
First Language
English
I feel like for plugin devs we're just going to be doing prototype rewrite and alias anyways.

As long as changes to super classes can also affect child classes probably should be fine.

For me, all prototype code means easy copy paste.

Maybe it might be easier for others to learn the codebase...I don't know I'm already used to prototype so hard to say.
 

Shaz

Veteran
Veteran
Joined
Mar 2, 2012
Messages
39,966
Reaction score
13,602
First Language
English
Primarily Uses
RMMV
It doesn't bother me what it looks like, as long as it's easy to use, so if it sticks with the MV format I'm fine with it already. I suspect there might be a few people who would LOVE to have it rewritten though.

However, are you prepared to redo it as new builds are released that contain bug fixes? Could be a lot of work, and if you aren't able to keep up, your new codebase could become obsolete pretty quickly.

Personally, I'm not sure it'd be a great use of your time, and I think you could achieve more by just making plugins for MZ.
 

ImaginaryVillain

Sprokle Boi
Veteran
Joined
Jun 22, 2019
Messages
745
Reaction score
3,938
First Language
Absurdism
Primarily Uses
RMMV
Sounds like a whole lot of extra work just to "save time" with ES6. But if that's what people want to do... That's what people want to do. Not going to lie, I probably won't over complicate my MZ experience with something like this.
 

Trihan

Speedy Scripter
Veteran
Joined
Apr 12, 2012
Messages
2,604
Reaction score
1,947
First Language
English
Primarily Uses
RMMV
I thought MZ's codebase was written using ES6 standard anyway.
 

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,573
Reaction score
6,497
First Language
Indonesian
Primarily Uses
RMVXA
Due to class syntax fail to create an alias method as Hime had said, and the better practice would to just use a prototype syntax for plugin sharing, I personally think it's okay that the codebase keeps the prototype syntax rather than forcing it to use class syntax. So, for consistency, I'd vote for keeping the ES5 prototype syntax until class syntax could behave like an actual class. Having to know how JS works, I always feel that the class syntax for JS is, honestly, weird. The language is not built for such a method.

Frankly, the general user would see no necessity to replace the whole base code with this. Heck, they even skeptic with "Core Engine" as it creates a lot of compatibility issues, at least in their impression.

However, should anyone want to rewrite the codebase to be ES6 class syntax, they should do it individually in their project. Maybe for the sake of having an easier time reading? People who would do it probably the one who code their own game anyway.
 

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,748
Reaction score
911
First Language
Chinese
Primarily Uses
N/A
As long as changes to super classes can also affect child classes probably should be fine.
Due to class syntax fail to create an alias method as Hime had said, and the better practice would to just use a prototype syntax for plugin sharing, I personally think it's okay that the codebase keeps the prototype syntax rather than forcing it to use class syntax. So, for consistency, I'd vote for keeping the ES5 prototype syntax until class syntax could behave like an actual class. Having to know how JS works, I always feel that the class syntax for JS is, honestly, weird. The language is not built for such a method.
In my example, the new class ES6ExtendedClassAlias is specifically written to address this very problem:
JavaScript:
 *    # Aliasing functions/methods without prototyping on your side
*      Please note that it doesn't work with built-in JavaScript prototypes
*      like Array and String
*      Do these 2 additional things when using ES6 class inheritance aliasing
*      without directly typing prototypes:
*      1. Adds the following code right below a new class inheriting another
*         one:
*         - ES6ExtendedClassAlias.inherit(Klass);
*         Where Klass is the new class inheriting another one
*      2. Adds the following code right below extending an existing class as
*         a way to alias its methods:
*         - ES6ExtendedClassAlias.update(Klass);
*         Where Klass is the existing class being extended as a way to alias
*         its methods
*      Right now it doesn't work well with inheriting static functions in
*      classes, so those in children classes should use
*      ParentClass.staticFunc.call(this) instead of super.staticFunc()
I hope this won't create too much extra work for plugin developers though, because all they need to do is to remember this 2 commands :)

Maybe it might be easier for others to learn the codebase...I don't know I'm already used to prototype so hard to say.
I've also thought of this, as there are indeed some JavaScript programmers only learning JavaScript after the ES6 had become the mainstream, meaning that it's actually reasonable for them to not know ES5, and I expect quite some new RMMZ plugin developers will be of this type.

Personally, I'm not sure it'd be a great use of your time, and I think you could achieve more by just making plugins for MZ.
Actually I'm forming a basic knowledge on what the default RMMZ codebase does in general when writing this plugin as an experiment of the idea, so I think it's of good enough use of my time so far.
Of course, if it turns out that it's indeed a bad idea, then I can simply declare the plugin obsolete and announce that plugin developers using this plugin are at their own risk lol
That's why I think it's important for me to make this post with an example as soon as possible(even though I think I should have done so 2 days ago) - Preferably weeks before MZ is released, so the sunk cost can be kept under control if this idea doesn't work :D

I thought MZ's codebase was written using ES6 standard anyway.
My experience during the rewrite tells me that it's largely not the case.
While there are indeed some ES6 constructs like const and let, arrow functions, spread operator and even Promise(when fetching non local web audio using the default ES6 api with Promise), most of the codebase are still written in ES5 when they could have benefited from some ES6 constructs(e.g.: a use of spread operator in a single business logic building block removing tons of code duplications), especially in the case of class vs direct prototyping :p

However, should anyone want to rewrite the codebase to be ES6 class syntax, they should do it individually in their project. Maybe for the sake of having an easier time reading? People who would do it probably the one who code their own game anyway.
In that case, I hope my example can be of any use there ;)
 
Last edited:

Trihan

Speedy Scripter
Veteran
Joined
Apr 12, 2012
Messages
2,604
Reaction score
1,947
First Language
English
Primarily Uses
RMMV
Wait, do you already have the MZ base source code?
 

Solar_Flare

Veteran
Veteran
Joined
Jun 6, 2020
Messages
530
Reaction score
232
First Language
English
Primarily Uses
RMMV
My two cents: I don't think this is worth it. I actually prefer the ES5 format, as it doesn't try to pretend that you're using class-based inheritance.
 

Shaz

Veteran
Veteran
Joined
Mar 2, 2012
Messages
39,966
Reaction score
13,602
First Language
English
Primarily Uses
RMMV
I hope this won't create too much extra work for plugin developers though, because all they need to do is to remember this 2 commands
See, that's where my problem comes in. If I have to write my plugin in a certain way to work with your codebase, then it means only people using your codebase can use my plugin. Or that I have to write two versions. I'd prefer not to have my plugins reliant on anyone else's (or even others of my own).

I'd vote for keeping the ES5 prototype syntax until class syntax could behave like an actual class
Really? It's not even real classes? I've never looked into ES6 but I was under the impression, by the way everyone else raved about it all the time, that it was proper implementation of classes. If it's really not, then no, waste of time for me.
 

nio kasgami

VampCat
Veteran
Joined
May 21, 2013
Messages
8,949
Reaction score
3,039
First Language
French
Primarily Uses
RMMV
Personally i wouldng bother. Its to much work.

As for my plugin I use typescript which behave well like an oriented programming language.


Even then i built the typescript definition for mz core file I still have to do the whole definition file for the rest.

Although i do plan to build an proper dev environment with example so people can properly dev plugins with typescript without much constraint.

@Shaz it is an actual inplementation of a class it just behave with the prototype structure.
Es6 was built to shorten the whole prototype inheritance process

Its shorter prototype who behave with different rules. Class are automatically in strict mode which apply inheritance rules etc
 

Solar_Flare

Veteran
Veteran
Joined
Jun 6, 2020
Messages
530
Reaction score
232
First Language
English
Primarily Uses
RMMV
Really? It's not even real classes? I've never looked into ES6 but I was under the impression, by the way everyone else raved about it all the time, that it was proper implementation of classes. If it's really not, then no, waste of time for me.
It's not a real class, no; it's just syntax sugar. There's no semantic difference between an ES6 class and the prototype method that RMMV uses to define classes. Presumably you can even use the ES6 syntax to extend an RMMV core class.
 

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,573
Reaction score
6,497
First Language
Indonesian
Primarily Uses
RMVXA
Really? It's not even real classes? I've never looked into ES6 but I was under the impression, by the way everyone else raved about it all the time, that it was proper implementation of classes. If it's really not, then no, waste of time for me.
It's really just syntax sugar so that "it looks like other languages". The concept of the prototype itself on JS is different than most of the languages that use classes. I had to erase most of the knowledge regarding class-based language just to understand what exactly javascript is.

EDIT:
JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript's existing prototype-based inheritance. The class syntax does not introduce a new object-oriented inheritance model to JavaScript.
 
Last edited:

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,748
Reaction score
911
First Language
Chinese
Primarily Uses
N/A
Wait, do you already have the MZ base source code?
Not everything, but just the core parts, and I've rewritten almost everything there into the ES6 standard(except the JsExtensions as there's no way to override the built-in JavaScript prototypes like Array and String with ES6 classes) :)

See, that's where my problem comes in. If I have to write my plugin in a certain way to work with your codebase, then it means only people using your codebase can use my plugin. Or that I have to write two versions. I'd prefer not to have my plugins reliant on anyone else's (or even others of my own).
Agreed, and I think many other plugin developers will have the same concerns, so that's an disadvantage for such plugin developers as well(I'm also interested in how many doesn't have this concern though) :D
 

Trihan

Speedy Scripter
Veteran
Joined
Apr 12, 2012
Messages
2,604
Reaction score
1,947
First Language
English
Primarily Uses
RMMV
I can see the API function names, but I didn't realise the actual source code was on there. I can't find any, at least.
 

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,748
Reaction score
911
First Language
Chinese
Primarily Uses
N/A
I've just added the following instruction in my example:
JavaScript:
 *      4. (Plugin developers only)If you don't want your plugin to use this
 *         plugin but still want to alias functions/methods without direct
 *         prototyping on your side, you can copy the ES6ExtendedClassAlias
 *         class from this plugin without having to give me credit or ask your
 *         plugin users to do so(as long as you've just copied that class and
 *         nothing more)
This might be a happy middle ground for such plugin developers :)

I can see the API function names, but I didn't realise the actual source code was on there. I can't find any, at least.
 

Trihan

Speedy Scripter
Veteran
Joined
Apr 12, 2012
Messages
2,604
Reaction score
1,947
First Language
English
Primarily Uses
RMMV
I see it now. :)
 

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,748
Reaction score
911
First Language
Chinese
Primarily Uses
N/A
Frankly, the general user would see no necessity to replace the whole base code with this. Heck, they even skeptic with "Core Engine" as it creates a lot of compatibility issues, at least in their impression.
(Previously overlooked this part of your reply)I personally agree with this and actually, I'm completely fine with direct ES5 prototyping, but as I saw quite some potential MZ plugin developers having rather strong opinions against sticking with that style for the default RMMZ codebase, I wonder if some of them will so go far to ask their users to use a plugin just to let them conform with the ES6 standard more effectively and efficiently :)
 

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,573
Reaction score
6,497
First Language
Indonesian
Primarily Uses
RMVXA
(Previously overlooked this part of your reply)I personally agree with this and actually, I'm completely fine with direct ES5 prototyping, but as I saw quite some potential MZ plugin developers having rather strong opinions against sticking with that style for the default RMMZ codebase, I wonder if some of them will so go far to ask their users to use a plugin just to let them conform with the ES6 standard more effectively and efficiently :)
They are hurting themselves if they force the user to replace the MZ code base. If there's a weird behavior or anything, they take the blame even if maybe it isn't their fault.
 

Users Who Are Viewing This Thread (Users: 0, Guests: 4)

Latest Threads

Latest Posts

Latest Profile Posts


Only 99 more battlers to go :dizzy:
Stream will be live shortly with some game development! Feel free to drop by!
it took soooo long to get character assist to work right in my game. like certain fighting games, a team mate can hop in, do an attack, then leave. it works since these are all one on one fights (usually)
Honestly. Didn't sleep for a day. ONCE
Hi! I've been working on some character sprites for my pirate themed game.
Still somewhat new to pixel art, so feedback or inputs would be appreciated ^^

Forum statistics

Threads
104,260
Messages
1,005,031
Members
135,771
Latest member
Yeah_That_1
Top