Link to the post: https://news.ycombinator.com/item?id=8495498
Link to the bugzilla entry: https://bugzilla.mozilla.org/show_bug.cgi?id=1087963
The performance is kind of bad in Firefox but I'm not sure it justifies blocking the entire browser because of that. For a comparison, Google Photos is slow as hell in Firefox, but you could still use it if you want to.
The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works. Firefox is fast enough if you write code with it in mind.
...but hey, who cares about anything except chrome right? If someone visits play.google.com on an ipad and safari crashes screw them for not using android right?
Its Business Politics at play, not technical restrictions.
Or alternatively it's economics. Maybe someone, somewhere had to make a decision similar to "If we want a good experience that includes Firefox users from day 1 it will cost $x and delay launch by y weeks". And he had to sell that to his boss.
Even in a company as awash with money as Google, someone has to justify budget choices.
Not really. And here's a list of arguments why it's okay to focus on one browser (at least at first):
1) It's in beta, so you want to get it right before focusing on making it work everywhere
2) Developing for multiple browsers adds overhead to developers. I imagine they like to utilise some experimental webkit features, which are either not available in Firefox/gecko
3) Related to 2), they would add a lot of overhead making sure the UI and UX is the same, using multiple vendor prefixes and workarounds for other things.
And just to point out,
>dont release product until it works
is probably the worst advice ever to give to people. You want people to actually test your application. You can never catch all the edge cases that can/will happen, in your mind, and sometimes your assumptions are wrong. This is a pretty basic concept or Lean UX etc.
If you plan to support cross platform, do so from the start.
You can argue about feature parity and 'first user experiences' all you like, but practically speaking, if you don't support the target platforms from the start, you're dooming yourself to FOREVER have 1st class and 2nd class platforms.
You see this all the time in apps; flagship on iOS, rubbish half implemented android version that launches 6 months later and never always gets updates 3-6 later, broken, with bugs. Or vice versa.
I'm not in any way saying that you should to be cross platform, or what platforms people should support. That's a business decision each business has to make. ...but it's not a technical decision. Technically, if you know what platforms you support from the start, you can implement the product with that in mind.
I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through retroactively having to go back and support additional platforms. I dare say, business people who make decisions but don't have to actually deal with the consequences of them.
I honestly feel for the Inbox team. I'm sure there a lot of really tedious days ahead of backporting and bugfixing ahead for them (if google decides to make firefox support a thing).
Maybe in GUI applications, but not so much in web browser applications.
>If you plan to support cross platform, do so from the start.
You are already close to automatically supporting all platforms. The point of "not supporting" a browser, is to avoid tedious and time consuming testing of said browser, because CSS and JS works differently in every browser (although close to the same in webkit browsers like chrome and safari).
>I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through retroactively having to go back and support additional platforms.
Again, your arguments might apply to a OS application, but not to web browser "applications".
Generally, I also subscribe to the mindset of: make it right for one OS. Instead of: make it shit for all OSs, but usable.
Finally. Going out of your way to support platforms that _might_ be used, for an application that you don't really know if people will use in the first hand, is absolutely idiotic.
You need to know how, why and if people actually will use it, before spending time and money on supporting multiple platforms/browsers.
Just to finish of,
>I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through...
I've literally only heard this from people that have never developed for multiple platforms, and expect that "once it works on X, it must work on Y". It just isn't so. Implementations, however neat, always differ in GUI-land.
I can only recommend you seek additional input from your immediate peers before writing your next web 'application'.
(hint: the considerable negative feedback re inbox not working in firefox is the kind of bad press companies would rather avoid)
I believe many people know and understand that it's not unheard of for Google to release app updates on iOS a couple of weeks before the Android version comes out.
And while I've wanted to visit app stores cross platform to add items to a wish list while on the go, and been a little frustrated by not being able to do so, it does seem like a bit of an edge case. Although I suppose with both iTunes and Google Play edge cases can still be huge.
Except that almost no one does it nowdays. MVPs, early launches, etc. Why Google should be held to one standard while every "innovative startup" is held to a completely opposite?
By the way, did no one read what Google itself has to say about Inbox? It's explicitly stated as not a replacement for GMail. They're playing around with UX idea. You can look at it as a very elaborate A/B test.
Google does have a history of blocking browsers they don't support, no matter how functional it may seem.
You can't get support out of Google at any price, unless you're an advertiser. But in that case, it's only help for your ads and nothing else.
You can't talk about "support cost" when it's zero.
What cost is there?
If I've switched UA string Google might not even be able to tell, without actively seeking out the information, that other browsers are using it - how then could that be an extra cost?
School me, please.
Remember, there isn't any kind of really legitimate API for 100% determining which browser you're running in. There's a lot of ad-hoc methods which usually work.
These folks spent extra effort to block it from even TRYING to run in FireFox.
How are the FireFox devs supposed to see the bad performance that they need to fix for Inbox to work right if they can't run it at all?
Also, with respect to performance, this comment in the article might shed some light:
"Also see Bugzilla entry. The use of spare arrays with huge indexes was a performance issue in Firefox. It's been fixed in Inbox and in FF but not shipped in FF yet. (https://bugzilla.mozilla.org/show_bug.cgi?id=1087963)"
When you get bug reports from internal customers it's never "the site isn't working in Firefox 33 with all extensions turned off. It loads but is a little slow.". The bug report you get is simply "it isn't working, you get a blank page".
Answering those types of emails cost real money.
I recall back in the IE5 days that IE on Mac was a significantly different beast than IE on Windows despite being named the same.
Nobody from Google bothered to file any bugs against Firefox; it wasn't until a Mozilla engineer saw the Google engineer's complaint on the HN thread that he filed it and fixed it himself!
...what? Why would they need "sparse arrays with huge indexes" anyway? This sounds more like a problem with the developers doing something ridiculous, and not the browser. Maybe Chrome is faster at it, but that's like saying "compiler X has a performance issue with bubblesort."
More precisely, I'd like to see what exactly they're trying to do with this sort of code. Optimising "sparse arrays" sounds like matrix algebra and scientific computing, not an email client.