Comment by PaulHoule

Comment by PaulHoule 4 days ago

I’m more of a full-stack but I develop “Firefox first” on my projects if I can and leave it to my tester to see that it works on Chrome. X-browser issues turn up rarely, I wind up having more trouble with Safari than anything.

I know Mozilla does worse on benchmarks, but I never complain about performance. Recently I tried some sites from one of the spammiest sectors on the web and found I couldn’t move the mouse without my Chrome lighting up like a Christmas tree and navigating me to crap sites, but the Firefox experience was that I had to click on something for all hell break loose.

We have an internal app that has screen with a JavaScript table thingie with 40,000 rows loaded locally. Crazy? Yeah. It performs great on Chrome and lags pretty bad on the fox. That’s the only bad screen, and we have a lot of screens.

Personally I don’t like it that they have an office in San Francisco. Emotionally I think, “the only thing anybody should be building in San Francisco is a homeless shelter.” Practically though, I think a browser company can’t “think different” if is steeped in the Bay Area culture, not least if they can get in a car and go visit people at Google and Facebook. If they were someplace else they might have a little more empathy for users.

MegaDeKay 4 days ago

Like you I have found Firefox to work pretty well in real world applications. The one place I found it did fall over was Microsoft Office Online. FF runs like molasses in a large online Excel spreadsheet vs Chrome.

Reply View 1 reply

wkat4242 4 days ago

Microsoft is absolutely terrible at Firefox support. I feel like they do it in purpose. In fact when I set my user agent to Edge half the issues in O365 disappear! Suddenly things actually work.
The latest crap is that it now requires me to sign in every single day on Firefox. And often after I sign in it immediately goes to "hang on while we're signing you out". Meanwhile they're pushing edge heavily as a vehicle of copilot promotion. So I'm pretty sure this is just intentional breakage..

Reply View | 0 replies

jodrellblank 3 days ago

> “We have an internal app that has screen with a JavaScript table thingie with 40,000 rows loaded locally. Crazy? Yeah.”

Crazy, no; a loop over 40,000 items should take a fraction of a second, and at 1KB per row it’s less than 1% of a 4GB memory stick.

The 1 billion row challenge leader parsed a billion rows of CSV - 10 GB of data, through a Java/graal VM - in 0.33 seconds!

Reply View 0 replies

paradox460 4 days ago

This works because you're deliberately targeting a set of features Firefox supports, and the overwhelming majority of the time they're a subset of what Chrome (and increasingly, Safari) support

Read over the various web platform blogs out there, and keep a tally of how many times you'll see "Firefox gains support for XYZ in 139, bringing it to widespread availability. Chrome has supported this since 32 and Safari since version 16"

And many of these are fantastically useful features. Sure, they're not ground breaking building blocks like in the old days when IE didn't even support certain types of box model, but they're echos of the past

Reply View 2 replies

PaulHoule 4 days ago

Worse than that, where I work I can only install an LTS Firefox so I am stuck with relatively old features, but, hey, I’m in React land using components with some time lag in their development that don’t use these new features. I was kinda shocked to see that mainstream toolkits aren’t using <dialog/> given that it is a huge leap forward for accessibility… screen readers do not see anything they’re not supposed to see, end of story. Trouble is that it does cause trouble for frameworks that depend heavily on portalization.

Reply View | 1 reply
- paradox460 3 days ago
  
  The one that's shocked me the most is when I was writing some CSS for a recent project using Lit components, and nesting doesn't work at all.
  Component level CSS is simple enough that I didn't really have to go out of my way to do anything above and beyond, and if I had to I could just use a loader that uses sass or postcss or something similar, but it was a bit surprising.
  That said, I have really enjoyed Lit. I wrote the original components for this project in 2023, and haven't really touched them till earlier this week. Bumped all package dependencies, and did the usual things you'd do for an upgrade, and they have had a stable API over the two years they've existed.
  Regarding Dialog, a few years ago, when it was brand new, I was working on a project that used LiveView and SurfaceUI. We had a few modals that were used throughout the app, and I was in the process of migrating them to use Dialog before getting laid off. The tricky part, at the time, was that a Dialog invoked through pure HTML, no JS, lacked certain features that were available to the JS APIs. The HTML side has caught up, and the JS APIs have improved, but I've not touched frontend professionally in that time.
  
  Reply View | 0 replies