Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

About this bulletin board and the Pale Moon website

Moderators: Lootyhoof, FranklinDM

Post Reply

Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Poll runs till 2021-03-25, 20:20

Yes
5
15%
No
16
48%
I'm not a programmer.
12
36%
 
Total votes: 33

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 8918
Joined: 2012-10-09, 19:37
Location: Seriphia Galaxy

Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Post by New Tobin Paradigm » 2021-02-23, 20:20

This is a poll aimed mainly at extension developers and those thinking of becoming one. With the changes set in store for Pale Moon and years of Add-ons SDK controversy with practical limitations of vague and deprecated abstraction layers verses traditional Toolkit and Bootstrapped extensions.. Should we, going forward, permit submission of forks and newly created extensions using this dead-end technology?

Currently the older cfx-generated Jetpack extensions have not been allowed since Phoebus 2.0 only newer jpm-generated.

NOTE: This will not affect the current application support or lack there of in Pale Moon and Basilisk nor will it prevent already established extensions on the site from continuing as normal.
How far are you prepared to go? How much are you prepared to risk? How many people are you prepared to sacrifice for victory?
Are you willing to die friendless, alone, deserted by everyone? Because that's what may be required of you in the war that is to come.

Image

User avatar
RealityRipple
Lunatic
Lunatic
Posts: 271
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California
Contact:

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Post by RealityRipple » 2021-02-23, 21:00

I think this boils down to capability. It's usually pretty easy to throw out any of that restartless/sdk junk and revert extensions to the clean, classic Overlay-centric addons, so the vital question becomes, is there anything that Jetpack allows for that absolutely can not be accomplished using older, more direct methods? In my experience thus far, the answer has been "no". And thus, the answer to whether they should be allowed also defaults to "probably no". However, if there are any specifically known cases where an add-on can not accomplish its task without Jetpack, then that answer switches to a "certainly yes". But, there aren't... Are there?

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 8918
Joined: 2012-10-09, 19:37
Location: Seriphia Galaxy

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Post by New Tobin Paradigm » 2021-02-23, 21:04

Everything Jetpack can do is merely carefully selected abstractions on permitted native functionality. So as you guessed. There is nothing a Jetpack extension can do that a normal one can't and indeed using Jetpack doesn't teach the developer anything about how to create (lowercase-m) mozilla extensions only how to create Jetpack extensions. Deff won't help you understand how things actually work in a way that allows you to progress to bigger and better things. It keeps you distracted by it's abstraction.

In today's terms it would be Mozilla's failed attempt to create a kind of WebExtensions system that no one asked for and no one wanted.
How far are you prepared to go? How much are you prepared to risk? How many people are you prepared to sacrifice for victory?
Are you willing to die friendless, alone, deserted by everyone? Because that's what may be required of you in the war that is to come.

Image

User avatar
moonbat
Moon Magic practitioner
Moon Magic practitioner
Posts: 2777
Joined: 2015-12-09, 15:45

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Post by moonbat » 2021-02-24, 02:26

Where's the 'Hell, no!' poll option? :twisted:
"One hosts to look them up, one DNS to find them and in the darkness BIND them."

Image
Linux Mint 20.1 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
Advanced URL Builder(fork)|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 29276
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Post by Moonchild » 2021-02-24, 11:31

moonbat wrote:
2021-02-24, 02:26
Where's the 'Hell, no!' poll option? :twisted:
It's implied in "No" ;P
"Son, in life you do not fight battles because you expect to win, you fight them merely because they need to be fought." -- Snagglepuss
Image

User avatar
jobbautista9
Fanatic
Fanatic
Posts: 108
Joined: 2020-11-03, 06:47
Location: Philippines
Contact:

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Post by jobbautista9 » 2021-02-25, 03:31

Jetpack should be discouraged for new extensions, so yeah that's a no for me. For forks of classic add-ons though, it might be useful to accept them, but only for use in Basilisk. I heard that Jetpack add-ons break more often in Pale Moon, but is this also the case for Basilisk?

I haven't developed an add-on in Jetpack yet, and from the looks of it, it seems it was trying to simplify and make the development of add-ons easier. Ironically, I find XUL to be simpler and easier to understand and develop for, as a new add-ons developer, despite the incomplete documentation of it.

So XUL of course should be encouraged, and if the forker can do it, they should rewrite it to XUL.
I just love Cyndaquil. Obviously the best Johto starter!

Developer of Ambassador in Window Menu, BrowserTickTock, Clickity Touch 'n Push, ColorPili, EditDatContent, EditDatTitle, Esrever, and Go Menu.

User avatar
moonbat
Moon Magic practitioner
Moon Magic practitioner
Posts: 2777
Joined: 2015-12-09, 15:45

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Post by moonbat » 2021-02-25, 03:47

jobbautista9 wrote:
2021-02-25, 03:31
I find XUL to be simpler and easier to understand and develop for
The best thing about XUL is that your UI definition is cleanly separate from the Javascript used to run it. Restartless extensions require you to directly manipulate the DOM to change the UI and that is quite a mess.
"One hosts to look them up, one DNS to find them and in the darkness BIND them."

Image
Linux Mint 20.1 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
Advanced URL Builder(fork)|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX

Post Reply