Crackle vs. Sparkle #107
Labels
No labels
bug
discussion
documentation
duplicate
enhancement
good first issue
help wanted
invalid
Jameson
joke
options window
question
Split!
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
sparkle-devs/sparkle#107
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally posted by @PPPDUD in #106
@codingisfun2831t What do you think about this?
I do think that typescript and npm might be a bit too much; but like... can't we split things into multiple js files or something? I'm not well versed into code refactoring, but like... there's gotta be a way!
Once upon a time, that model would have made sense, but now unfortunately it wouldn't work very well with stuff like GreaseMonkey userscripts and bookmarklets unless we pulled some network trickery that would break offline usage.
I guess we could probably build a system that can blindly include the contents of text files into other files, but that would be rather janky if I do say so myself.
why are we even still supporting userscripts and bookmarklets? Is it just because of firefox?
I'm sure ESBUILD, what I'm using for the Typescript packaging, supports the same but with Javascript. However, one advantage I find is that you can have types for all the Snap! classes, e.g. Morph, and be able to easily use them.
Probably yes! And also, my current system still supports it. It just outputs a single index.js file (index.min.js, theres a big index.js) in dist/ and the extension uses that.
Well, I figured that not everyone wants to use an extension when they can just load a userscript, and some Chrome installations won't let you install extensions in the first place, in which case you can use bookmarklets.
Okay. Still, my system support it! Its still a single file at the end of the day.
Your system adds userscript headers for userscript managers and
javascript:URIs for bookmark managers? Yeah, sure.But it can. AGAIN, AGAIN, just like our current index.js, it produces one. It can trivally be modified for a release build that also builds the userscript and bookmarklet.
@codingisfun2831t, since you're working on a competing project, would you like to leave Sparkle for the time being to avoid conflict-of-interest issues?
I suppose, but it's easier to just use Sparkle's pre-headered builds.
I don't want it to be! I've said before, I think, that I want the code to be the new Sparkle. I just have it local and not finished and not renamed to Sparkle, so I just kept it as a repo on my account.
Again, what @codingisfun2831t is doing is just a new re-write of sparkle. Again, we can work together, not against each other!
What do you mean by this? The build system will, if implemented, output these files as a side-thing after build (most possibly if a "release" flag is set).
@codingisfun2831t @e016 If we're going to do that, we're going to need a few ground rules:
The primary reason that I'm not currently working with you on this is that your project violates rule number 1; that is, it does not recognize the authority of Sparkle's Orchestrator or Vice Orchestrator as project leader.
I see, that makes sense. I take back that point.
Seems dictator-ship like.
Also, isn't d016 vice orchestrator, if im not wrong?
yep, i become vice orchestrator after doing nothing with sparkle with PPPDUD's ban
@codingisfun2831t I know it sounds a bit dictator-like, but I am the Orchestrator, and projects that don't recognize the Sparkle authority structure are by definition not Sparkle projects.
Remember that you're free to leave and compete with us at any point if you don't like my leadership style.
Then I wont have Crackle as a Sparkle project! I will write it with @tethrarxixet like we originally intended!
And I shall compete with Crackle.
@BoxyCPU You alive yet?
Then go for it! Go without supportingthe Firefox extension store (because me dont like it... wahhh.....)! Go with your huge single index.js file and horrible mod saving!
Don't forget who has the largest addons repository, the most supported platforms, and the most iterated-over codebase!
(And also I think I'm going to be stealing your addons-from-URLs idea as an addon.)
And doesnt have any existing extensions! :)
Question mark? Addon from URL? That already exists?
What???
Well, as preloaded addons I suppose. But really I want to grab the part where users can actually choose to add them in the interface.
As in, on extension stores! No one wants to use something if they have to m- oh wait userscripts exist. Sorry that wasnt a valid argument I talke that back
Anyway also I do still wan tto work with you, but I think you need to sort out some issues with Firefox and NPM.
And I think that you need to sort out some issues with Firefox and NPM too, which is why I'm not sure that this is going to work out at the moment.
@BoxyCPU
? No i dont. Have you even checked what I've been saying? If youre saying that as "you like to have a good development expereicne instead of one file" and "be able to use it on your main browser" then fine.
I think that what you're doing by attempting to publish your extension on Firefox is actively harmful to other small developers, and that your architecture is fundamentally-flawed, but I suppose those are just my opinions. As for using it on your main browser, how many Sparkle/Crackle users actually use Firefox in their day-to-day lives?
I, for one, use Chromium for nearly all tasks.
Again, why are we so fixated on FIREFOX?? @codingisfun2831t 's index.min.js that generates after each release will function AS A USERSCRIPT!!!
True. But its still better to have a FireFox extension for those who want it!
Shouldn't that just be integrated into sparkle directly? Or is this going to end up like minecraft, where you have to install mods if you want the game to run smoothly.
That's true, and I'm not against a firefox extension. However, we shouldn't be fixating on that as a reason for why we should split up.
Addon development is easier and means that if there's a bug in an addon, users can just disable it until it can be fixed.
I agree, but I think that publishing to Firefox's extensions marketplace is the wrong way to go about things.
yeah, I did think that you might want sparkle to be a "addons all the way down" thing.
Why??? If you're so worried about firefox, then...
DON'T PUBLISH IT THERE!!!
I don't see the issue with just not putting it there! Once we're ready we might put it there, but in the meantime, we DON'T HAVE TO!
Yes, the main two split up reasons, atleast for me, are:
Well, I think that @codingisfun2831t (correct me if I'm wrong) wants to actively publish it though. And even if we did produce a Firefox extension but not publish it, we would have such a small userbase that it would be wasteful to keep maintaining it.
Well, the alternative was losing our members left and right.
Wouldn't want to become too professional, now would we?
No, no; I meant "not producing the firefox extension", not just "make it but don't publish it".
Oh, I see now. My bad.
Its just build tools? Using CMake isnt too professional???
Your entire management scheme is too professional! (at least, according to @codingisfun2831t)
Well, I don't see how piling on a bunch of tools that you wouldn't use outside of professional environments helps.
I'm talking professional in the terms of management.
Ah yes, the unprofessional manager who enforces the use of modular TypeScript with esbuild.
Thats build tools, IN THE CODE. Not management. Im talking professional management such as, e.g. mailing list. And its not even that many tools! Its just typescript (mainly for easy Snap! work) and a packager.
Remember, I wanted to implement direct emails (not a mailing list) so we could communicate better and more casually.
Okay, srue. But we still dont need allat!
Oh, and that one time you (PPPDUD) wanted weekly releases!
This! Its not the best decision especially if theres only likje a tiny patch or no commits at all during that. And if theres a major change, you might want to release two or more times a week! (e.g. you do a major change, release, and then fix bugs, release patch.)
Whenever development is slow, we slow down the schedule accordingly. Bug fixes can come out early, and in fact have several times. I still want weekly releases because the alternative is slowing down to the point of near-death like the old Crackle did.
That was because I was the only person working on it. And the fact that Tethrarxixet wasnt online much.
Even then, do we really want a slow release schedule for an actively-evolving project? It's a flexible rule, we just follow it most of the time because it's usually a safe pace to make releases at.
yeah, but the way you first told us that implied that it was a fixed schedule!
Well, I apologize for that.
@BoxyCPU Are you alive now?