• 2 Posts
  • 75 Comments
Joined 1 year ago
cake
Cake day: July 10th, 2023

help-circle

  • Not perfectly optimised is fine, but non-functional isn’t acceptable. I’ve never seen a quirk personally, and quirks aren’t a good reason to help maintain Google’s monopoly on web standards.

    You may say less than 5% is fine, but it could be the margins in a low margin industry. 2% could be 40% of the profit.

    I haven’t seen a team operate where a senior isn’t checking it.

    Usually the bleeding edge stuff is used by small companies trying to establish themselves because they have nothing to lose and no reputation to protect.

    Plus, when you got Browser Stack, you catch a lot of problems like this.


  • CrypticCoffee@lemmy.mlMtoDeGoogle Yourself@lemmy.mlDegoogle Chromium help
    link
    fedilink
    arrow-up
    6
    arrow-down
    1
    ·
    edit-2
    14 days ago

    Because in web development there are compatibility tables of what features work with which browser. If a developer has used a feature poorly supported, they either haven’t done their homework, or intentionally made that call.

    In web development, most reputable Front End Devs would not choose bleeding edge, barely supported features even if the temptation was there because the user comes first. Generally, you wait until it has been adopted by the main browsers (chrome, safari, ff).













  • The issue is your mindset.

    You write bugs because you have something to learn. You’re so focussed on what you’re making, that when a learning opportunity arises, you are not open to it. You’re just looking to speedrun/hack it.

    You need to drop the delivery pressure and enjoy the journey. When a bug comes up, celebrate it “ah, you got me here. Interesting. What am I missing?”. Then you slow down, focus not on solving it, but understanding it. If you understand it, the solving is easy.

    If you consider learning “not progressing”, then you need to reflect on what benefit the pressure and delivery focus is.