People like to point at ladybird, but really the way to go before this can become a daily driver is probably in the hundreds of person years of development
It'll be gone the moment upstream drops it. Maintaining this in a fork will be a lot of work. Fortunately it's still available even in Chrome for a while, but that's just an ultimatum
Even if maintaining Manifest V2 is too much work after upstream drops it that doesn't necessarily mean that they just have to accept Manifest V3 as shipped in upstream.
From what I've read there are two main problems with Manifest V3 when it comes to ad blocking.
Problem #1. The webRequestBlocking permission is gone:
> Note: As of Manifest V3, the "webRequestBlocking" permission is no longer available for most extensions. Consider "declarativeNetRequest", which enables use the declarativeNetRequest API. Aside from "webRequestBlocking", the webRequest API is unchanged and available for normal use. Policy installed extensions can continue to use "webRequestBlocking".
That does not necessarily mean good ad blocking must break. Most people find the ad blockers on Safari to be fine, and Safari does not have that kind of blocking. It has long required the declarative rule kind of blocking.
Some brief searching suggests that the rules for Chrome's declarative blocking are actually more powerful than Safari's.
That brings us to the second Manifest V3 problem.
Problem #2. The declarative rules only allows something like 30k rules. Apple found that such a low limit is not sufficient and raised it to 150k.
I'd guess that maintaining a fork that just raises the limit in Chrome would not be a problem for the Chromium-based third party browsers.
The big question would be whether the current 30k limit is there for technical reasons or for marketing reasons like not wanting ad blocking to be too effective. If it is a technical limit the forkers might also have to rewrite the rule processing engine which would likely be more than they would want to deal with.
> That does not necessarily mean good ad blocking must break. Most people find the ad blockers on Safari to be fine, and Safari does not have that kind of blocking. It has long required the declarative rule kind of blocking.
This presupposes that advertising platforms will not react to the changes to adblocking in any way, but I don't think that's realistic.
The declarative rules can only be changed with updates to the extension (AFAIK, please correct me if I'm wrong). This means users can't block ads themselves (at least uBlock Origin Lite can't do it), and it will take between days to weeks until new block lists have propagated.
Now, remember last year when YouTube started blocking adblockers? They changed their implementations sometimes multiple times per day, and after minutes to hours new blocklists were distributed that got around them. This won't be possible anymore with Manifest V3, so Google just has to update their adblock implementation often enough to finally get rid of them.
And the same goes for other platforms. Once the majority of users is using browsers that only allow declarative blocking, more platforms will start updating more frequently.
> The big question would be whether the current 30k limit is there for technical reasons or for marketing reasons like not wanting ad blocking to be too effective. If it is a technical limit the forkers might also have to rewrite the rule processing engine which would likely be more than they would want to deal with.
It’s Google. The whole Manifest is there for marketing reasons. The whole browser even. Google doesn’t want us to have a nice browser because it benefits us. It benefits them. And this will continue. With V3 they already did the biggest cut down of af blocking in their browser. They will continue this path.
Their main income is ads. They don’t care for anything else.
While these forks are nice and all, I'm not sure how meaningful it is in the bigger picture if 99% of the work done on it is still done (and paid) by the same people.
Similarly, I don't get those "I use brave instead of Firefox", as if that wasn't 99% chromium.
Don't get me wrong, I know there's not much choice. But that whole direction of "action" that people take just seems like a working marketing tarpit to me.
At least Brave is a profitable company that employs multiple people and they can keep up with Chromium's changes (Some manifest v2 extensions are kept available or certain UI features are reverted).
Most of the Firefox forks are 1-5 person gigs. They are not sustainable.
At this point, "marketing tarpit" seems like a pretty accurate description of Mozilla's stewardship of Firefox as well, so if I'm going to get sucked one, I'd rather it be the one that's taking a maybe untenable stand for something that I agree than the one that's trying to gaslight me about whether "disseminating user data to a third party for valuable consideration" is what most people would consider "selling user data".
That is an unreal standard to hold anyone to while using Microsoft or Google products, because this wouldn't even register compared to what these companies do on a regular basis. People are just less dependent on Mozilla so moral outage doesn't feel as pointless.
I'm not sure I understand your criticism. Are you arguing that I'm holding Mozilla to an unfair standard, or other users? I don't pretend to have any moral high ground about what I use versus other people; I just don't personally find the argument that using a fork of Firefox right now is a "marketing tarpit" to be compelling enough to convince me to change my mind about it.
I mean... the unified timeline is literally the number one feature this app advertises. If you find that doesn't work for you, their product vision just doesn't align with your preferences. What's the point of even engaging if you know they don't build what you want on such a fundamental level?
From the title, it took me a while from the description to understand what I'm looking at. The readme really needs some more info 1) targeted at end users of an app, possibly just a few screenshots will do, and 2) targeted at developers and the audience of emerge, e.g. concrete interactions that a dev of this app would have with emerge, also including a screenshot or two
So interestingly, many folks I've talked to had a reaction of "so jj is just a frontend to git, big whoop. There are hundreds of them, my favorite is X". That's an understandable reaction.
But jj is more than that, and you couldn't implement it as a git wrapper. I think the core innovation is that rebases are so fast they are essentially free, which opens up amazing potential.
But so far I haven't found a way to really convey the full weight of this without a long explanation, because people are so used to thinking in git, it takes a long time to go beyond "so rebase -i will be faster, then? But it's not slow, is it?"
It's funny, that git is now in the position that subversion was in almost two decades ago: People were so used to svn and felt productive with it, it was hard to convey why free branches and a distributed data model are a gamechanger, and how much svn limited their thinking. But as a git user you had certainty that you were right, and that your tool is superior.
Now, people are so used to git, in an eerily similar way. But ask most git users, "how would you move a specific change from your branch to another?" I have yet to receive a confident answer and workflow to this (they do exist ofc), the common reaction I get is that this isn't something they'd ever need anyways.
Oh I do that quite often, either because I didn’t realise I was committing on the wrong branch, or I decided to split my work in two branches, or i need some other unmerited change for my current branch…
It’s usually a rebase —onto or cherry-pick, I’d say I agree it’s not simple.
jj seems interesting, I’m very comfortable with git but I think its UX is terrible, but everyone use git and it is not an area where I have capacity or willingness to innovate. I’d love to see git being replaced with something better designed though
The downside part is "it is not an area where I have capacity or willingness to innovate". I'd happily follow, I don't care enough to lead the innovation.
Yeah, this is the real advantage that jj (and sapling) have compared to how many years I'd been hearing about fossil and seeing it as a non-starter to experiment with.
The difference between git and svn is, svn is very fixed in terms of workflow. On the other hand, git allows many different workflows, and allows people to handle their codebases the way they see fit.
Of course, no tool is truly universal, and git frontends and alternatives leverage different parts of the underlying data structures with different trade-offs.
I personally never use rebase, and am a merge guy. I don't use a gazillion branches either, not because I'm afraid of them, but my mental model works like that. Some people squash commits, others rebase, etc. Everybody is different in their ways.
svn to git was a fundamental change and allowed new things to happen. jj on the other hand makes some workflows easier while others take the back seat. So I don't see jj as a git disruptor, but an opinionated alternative tool which uses git data structures as the backend.
I agree that the change isn't of comparable magnitude. But JJ changes the user facing conceptual structure of version control. It unifies working directory, stash, index and commit, and replaces them with a single thing. And it shows that all existing git workflows can efficiently be constructed on this much simpler conceptual basis.
In my mind this demonstrates convincingly that gits conceptual model carries unnecessary incidental complexity. Within a fixed complexity budget jj absolutely does allow new things to happen.
I also don't really see any workflow examples that truly suffer under jj, so I don't think it's just another trade-off. It's a real substantial improvement. If it wasn't it wouldn't be making headway against gits network effects.
From what I understand, all these different places/things (working directory, stash, index and commit) confuses, and comes across unnecessary to some people. They want a simpler solution, and less mental load during version control phase of their software, that's understandable.
In my experience software developers come in two flavors. a) Developers who want to understand all the pieces they work with and have the desire to deep-dive into them b) Developers who write and commit code. They think that former part is their job and care about it. They don't care after it leaves their machine (in the sense of "I give box to machine it magically integrates").
IMHO, jj is very enticing for the latter camp, and that's not a bad thing. Not all of us are passion programmers/developers, and some are don't want to think about beyond their immediate realm. I respect these people. But, again, from my perspective, jj doesn't make sense for me. It's useful alright, but I actively use index, commit and stash very naturally. I might be good at understanding it because Eclipse has a great git integration which makes everything super workable and understandable, and I'd never change a power tool like git to something "push button, magic happens" class of tool.
jj might be very conductive to more complex workflows by removing some complexities, but unifying my stash, staging area and index is not something I want to be dome to my workflow for example.
Some trade-offs make great headways into networks because a large part of that network is silently suffering without being aware, and the trade-offs are worth it. See Rust for example. People accept 5x mental load and 10x compile times for memory safety. Same for jj. People accept a much simpler interface because it makes their painful workflows "push button, magic happens" levels of simplicity. Or, the people who like jj work under time pressure and want to remove a time-sink from their workflows, again understandable and respectable.
Having something like "jj" is not a bad thing. What I'm squarely against is "git is dead, new king is jj. Now move to your new kingdom and worship jj" mentality.
I think you have it backwards. jj is absolutely for "a) Developers who want to understand their tools". The simpler data model opens up new workflows that weren't possible before.
Unifying concepts is not taking away any expressive power. It just makes the system as a whole simpler to reason about.
I think it's a similar step up in power as moving from Windows to Linux. On Windows, to toy with the system at all you need to set up a C++ project and dig through win32 API docs and deal with opening/closing handles and void* pointers just to change anything, so I rarely bothered. On Linux everything is right there in the file system so there's almost no friction to changing things. You can do anything imaginable in a minute or two with just a shell script.
In Linux, Everything Is A File. In Jujutsu, Everything Is A Commit.
You’re making an understandable mistake. Jj being simpler doesn’t mean it is less powerful. It means it’s more powerful. This happens very rarely, but it is the case here. Removing the index and stash as unique concepts doesn’t mean that their use cases disappear: they gain power, because you can use any tool that works on a commit on your “index” or “stash” because they’re also just commits.
I actually like git’s CLI. I never understood why people wanted a simplified git. I’m never going back to git from jj. It’s just better.
Being in group #1 does not mean that I want to interact with every system at the lowest possible levels. I want to interact in ways that fit how I work, not to fit how I work to the ways the system works.
> "git is dead, new king is jj. Now move to your new kingdom and worship jj"
No one is saying this. If you feel like people getting excited about Jujutsu is them telling you that you must love it, that's on you. The fact that it is built on top of Git means that even if others are using Jujutsu, you are not forced to when working in the same repos.
I was a git power user. I am comfortable with and understand the index, stash, rebases, the reflog, and all the rest. I have written a git implementation.
I have converted to jj and will never go back. It is simpler and more powerful.
Probably a lot of that is because it is painful. When it becomes a no-op, suddenly a lot of things become easy to do.
Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard.
Do you ever want to maintain a linear chain of branches? Branch A needs to be merged before Branch B needs to be merged before Branch C. It’s a massive pain with git, especially if you need to change Branch A. It’s a no-op in jj.
There are a ton of straightforward and useful workflows in git that are just completely impractical.
No, not because it's painful, I just don't need it.
> Do you ever want to go back and edit a previous unpublished commit?
Honestly, no? I plan what I'm going to change, do it, commit it, and if I messed up, I don't hide it, just fix it and write "I messed up X in $HASH. This fixes that".
> Do you ever want to maintain a linear chain of branches?
No, I always keep a single thing moving at one time. If the project is big, I use a branch per feature, if it's a smaller branch, there's a development branch. That's all. I have a habit of designing before touching code, so I always move in well planned moves.
It's not like that because I'm afraid of rebase. It's just how I design/implement software. Yes, it's generally not a group work, but I do what I do, and it works.
> There are a ton of straightforward and useful workflows in git that are just completely impractical.
That's fine. I don't claim otherwise. I just don't do to prefer source code / branch acrobatics. I'd love to share a seven year development tree to show how I work, but unfortunately that repo is not meant to be open, at least for now.
> Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard.
Also unnecessary, "git rebase -i" has an "edit" command that pauses the rebase at that commit to let you do whatever.
This is roughly the reaction I meant going into this discussion :)
The rebase next level part is not about using git rebase in the right way, it's about every command including status sometimes doing 15 rebases without even mentioning it.
What jj does is not require you to pause. It’s fine with leaving stuff in a conflicted state, letting you do whatever you want as a next step. That may be resolving the rebase, but maybe you didn’t realize you were gonna have a conflict and want to get something else done real quickly.
In-memory, always succeeding rebases are just really nice.
And also you can just… edit a commit. It’s not some special side effect of a certain flag to a different command. You can just say “gosh I really wish I’d made some changes here” and either move changes in, or just jump in and live-edit it directly.
It’s really a completely different way of thinking, but shockingly, one that essentially directly maps to what your actual intentions are.
For example, the solution to almost all problems is oddly kubernetes shaped even though that was not the case 15 years ago. And Google themselves would be the 1st to tell you that kubernetes is not capable of doing all jobs.
Monocultures are insidiously bad, they poison solutions and reasoning, but they have their upshots too- if you never need to learn a new mental model; us tech workers become more interchangeable and the cost to onboard goes down.
This is a pretty ignorant stance. It implies that the issues would somehow be easy to address if they were just acknowledged. Are you aware of the efforts that have been put into this so far? Have you considered that achieving the vague improvements you are asking for, working on a groundbreaking technology while holding together a rapidly growing community, is just really hard?
> People tend to think in terms of what they could lose, and not in terms of potential gains. It's easier for users to take familiar extensions to a new browser, than having to learn how to use an analog.
How is this thinking wise? What are the potential gains and analogs for the end (without having to learn how to code)?
What is the analog to Bypass Paywalls Clean and Cookie AutoDelete as an example?
If writing new extensions in Common Lisp was so easy, why do they only list two extensions as available?[1]
Nyxt and qutebrowser target power users but leave out WebExtension support. I think they'd be a lot more popular if they didn't.
Did you interpret the comment as an argument for not having web extensions and recreating the features builtin instead? Because I'm fairly sure it's saying the opposite, even the last you quoted.
