Formerly /u/Zagorath on the alien site.

  • 6 Posts
  • 160 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle

  • 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.


  • Zagorath@aussie.zonetoLinux@lemmy.mlThe Mozilla layoffs ... will get worse
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    5
    ·
    6 days ago

    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.















  • 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.