Formerly /u/Zagorath on the alien site.

  • 1 Post
  • 276 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle
rss





  • I don’t even think that’s remotely true.

    I’ve seen two cases that actually directly impacted my ability to use Firefox. I can only presume there are many more. Those being supporting the column-span CSS property (available since 2010 in other browsers with vendor prefix, and early 2016 without, while being late 2019 for FF) and supporting iPad OS’s multi-window functionality (introduced mid 2019, Firefox has had it for just a handful of months now). I have first hand experience telling me very directly that this is true.

    There’s also been a lot of talk about Firefox’s lack of support for PWAs. I’ve not experienced that myself to be able to comment more than to say I’ve noted others have complaints.


  • The point is that with open source you can effectively leech off of Google for now, while still retaining the flexibility to nope out and do your own thing at any point you decide.

    Considering just how severely behind they are already (as I mentioned in my other comment, they’re often 3–5 years behind other browsers in implementing new web standards or operating system features), I see anything they can do to reduce how much they need to maintain independently as a good thing. In an ideal world where they had all the funding and development power they could want I might say sticking with the completely independent Firefox would be great. But that just isn’t where they’re at today.


  • They wouldn’t be at the mercy of anything. That’s…how open source works. If it changes in a way that breaks things for you, don’t pull that change. At that point, if the change is drastic enough to require it, you can turn that soft fork into a hard fork and hope that Edge, Brave, Vivaldi, Opera, etc. join you; something that would significantly hamper Google’s ability to maintain their dominance of the browser engine market. That’s a choice that they simply don’t have today when being based on Firefox and Gecko means using an inferior browser platform.


  • Honestly I’ve been saying for some time that Mozilla’s resources would be much better spent making Firefox a soft fork of Chromium. Primarily: use the Blink browser engine and V8 JS engine, with only the changes to those that they deem absolutely necessary, and maintain a privacy-forward Chromium-based browser. Maybe try and enlist the help of Brave, Vivaldi, and other browsers that are currently Chromium but which prefer more privacy than Google offers.

    It’s not zero effort, and especially as Google continues to develop Chromium with assumptions like the removal of Manifest V2 it might take some effort to maintain, but it cannot possibly be as much effort as maintaining an entire browser.


  • Okay but they often don’t give users what they want

    You should see the state of Firefox on iPad OS. I started using it earlier this year after they finally rolled out support for multiple windows—a feature Safari added in 2019 and Chrome had only a few months later.

    Nice that they finally have this feature, but the browser itself is nearly unusable. It stutters constantly and freezes, locks up, or force reloads with some regularity. In a way that Chrome and Edge (and I assume Safari, though I have never really used that) never do.

    Or on desktop OSes, a website I frequented around 2016–2018 used the column-span CSS property, which Firefox didn’t get around to implementing until December 2019.

    It’s been very clear for some time that, whether it’s because they stretch themselves too thin or some other reason, Mozilla has been failing to continue to deliver an excellent product for their users.




  • Yup absolutely. I mentioned web APIs because that’s what I’ve got the most experience with, but .h files, class library public interfaces, and any other time users who are not the implementor of the functionality might want to call it, the code they’ll be interacting with should be tailored to be good to interact with.


  • If the doco we’re talking about is specifically an API reference, then the documentation should be written first. Generate code stubs (can be as little as an interface, or include some basic actual code such as validating required properties are included, if you can get that code working purely with a generated template). Then write your actual functional implementation implementing those stubs.

    That way you can regenerate when you change the doco without overriding your implementation, but you are still forced to think about the user (as in the programmer implementing your API) experience first and foremost, rather than the often more haphazard result you can get if you write code first.

    For example, if writing a web API, write documentation in something like OpenAPI and generate stubs using Swagger.



  • We could have used the tilde, which has been used in formal logic & maths for negation in very many contexts for a long time.

    It’s used instead in C and many C-like languages for the far less useful bitwise negation. Of course, we could have had it work in the same way as bitwise vs logical and & or, by dialling up the symbol. Which would have massively improved its visibility compared to the bang.

    But for some reason, no. They chose the bang instead.