8 ms·

Actually before that he worked at Google. He has made it his life mission to get chromium everywhere.

jacobolus 4y ago
Before that he made the Dojo JavaScript library (jQuery precursor / competitor). Alex Russell’s position has always been that web developers (especially library authors) need as many browser features as possible to help them build the most flexible / capable web applications possible. He has consistently pushed for browsers to ship new features ASAP, with the idea that developers can paper over the differences or work around a buggy API, but can’t turn nothing into something. My impression is that he joined Google because he thought that was the best way to further that pre-established goal; it’s not fair to say that he’s just promoting this because he thinks it is in Google/Microsoft/Chrome’s interest. By contrast, Safari developers’ position has long been that new browser features should be carefully evaluated and then implemented at leisure, because this is a long game and we don’t need rush jobs. Their focus is more on client-side resource use (it’s shocking how far behind Chrome is on this one), correctness of the features they do decide to implement, performance, and user privacy (Google’s whole business model is ubiquitous surveillance). These two positions are both defensible, but are at odds with each-other. For Safari developers, Chrome trying to ram big piles of half-baked new features down every browser’s throat ASAP is just a recipe for churn, and getting developers to adopt them right away so that users then come complain that “Safari is broken” is endlessly annoying. For Chrome developers (or web developers who want to build on new shiny features right away instead of waiting 2+ years for cross-browser adoption), Safari lagging behind is “holding back the web”.
- mtomweb 4y ago
  How does that explain the enormous number of major bugs?
- kjksf 4y ago
  Safari / WebKit used to be the engine driving the web forward. Apple had no problem rushing things when they were at the brink of death and had to compete with IE and Mozilla by making a better browser. Only when they could kill the competition by simply saying so they switched to a leisurely mode of development. Not to mention they are also very leisurely about fixing bugs. Spin that one to make it look good for Apple, please. The only consistent position that Apple has is: what's good for our business. When they had to compete, they were forced to compete. Now that they don't have to, they don't and instead pay a few PR people to spin it as good for customers for this or that reason. With a generous free help from folks like you, also telling us how Safari is really superior browser. All we ask Apple is to put that theory to test: let Chrome and Mozilla compete and we'll see what actual users prefer.
  - jacobolus 4y ago
    Personally I find Chrome to be utterly unusable for my browsing habits (hundreds of browser tabs open at once). It glitches, spins up my laptop’s fans like there’s no tomorrow and burns through battery, eats all the RAM it can find, and easily crashes. And that’s without even getting to the privacy discussion. The existence of a Chrome-based iOS browser would quickly lead web developers to drop Safari and Firefox support (“just install Chrome bro!”) so I for one am thankful that Apple is not budging here. Their browser is, for me, strictly superior. And their political decisions are the last defense of a multi-browser web.
    - deleted 4y ago
      [deleted]
    - patrec 4y ago
      > The existence of a Chrome-based iOS browser would quickly lead web developers to drop Safari and Firefox support (“just install Chrome bro!”) Yeah, that would totally happen because websites that force people to install some massively resource hungry and sluggish browser first will obviously out-compete those that don't.
      - jacobolus 4y ago
        Joe Random web developer doesn’t necessarily care whether the browser he personally develops against is disrespectful of someone else’s client-side resources. He just wants to make his website with as little busywork as possible, and testing every website feature for cross-browser compatibility is busywork. If he can avoid the trouble by telling visitors to switch browsers, he will be happy to do so. This is not hypothetical: developers have been putting up “this site works best (or only works) in X browser” warnings for decades by now.
        depressedpanda 4y ago
        No, what would happen is that Apple would actually have to spend resources on competing with other browser engines, instead of holding the web back via monopoly. They certainly have the money to do so.
- nwienert 4y ago
  Wow, explains a lot. It’s such a shortsighted position for a browser - it’s one of the only platforms that literally can’t have breaking changes, and they want to bloat it even more? The entire problem with the web is they keep adding high level half-solutions over and over, many that intersect and almost none that actually solve things at the right abstraction. What we need is lower level primitives and performance. Instead we got Web Components, a disaster, and seemingly a thousand new CSS features (coming only from Chrome) that serve only to further entrench Google. Simpler and lower level APIs and ruthless work on performance would have given us a far richer platform to target, leading to better interop with cross compiling native tools, better experiences, and less bloat. Seems like weekly a Google evangelist tweets a gushing, emoji-laden joyous tweet about a new feature they’re shopping tomorrow adding some super arbitrary thing (the latest is some page transition spec which again is such a half-solution). Extend and extinguish!
  - aaaaaaaaaaab 4y ago
    >Seems like weekly a Google evangelist tweets a gushing, emoji-laden joyous tweet about a new feature they’re shopping tomorrow adding some super arbitrary thing (the latest is some page transition spec which again is such a half-solution). Extend and extinguish! They’re going for that juicy promotion, no matter what! The future of the Web be damned…
- doix 4y ago
  > correctness of the features they do decide to implement, performance, If this was the case, I would hate Safari significantly less. If the only issue with Safari was that they didn't implement certain features, that would be fine. I could check the compatibility matrices and just avoid features that aren't implemented. The problem is that every now and then they support something, and it _appears_ to work, but then there's some weird interaction that breaks some interaction and it takes forever to debug. Sometimes it's reproducible in Epiphany(webkit issue), but other times it isn't. Safari updates their webkit version pretty infrequently so bugs that are fixed in webkit are not fixed in Safari. So the only way to know if it works in Safari is to test in Safari, which requires OSX. Safari is the new IE. IE had better client-side resource use for a long time compared to firefox/netscape. IE didn't implement new features and they had IE only features just like Safari (you can select text in images in Safari). IE only worked on windows and made linux/osx developers suffer just like Safari makes linux/windows developers suffer today.
  - nwienert 4y ago
    When you develop in Chrome of course you’ll feel like bugs only exist in other engines. Developing on Safari it feels like the opposite. A few years ago I’d have agreed somewhat, but Safari has accelerated considerably and improved wrt standards. In fact better than Chrome as of late, if you follow the Interop project, and it feels as much.
    - doix 4y ago
      I primarily use Firefox, but I usually have 3 browsers open: Chrome/Firefox/Epiphany to try and make sure stuff works correctly across all 3 major engines. Unfortunately stuff still slips through into Safari land. I am not a language specification lawyer. If I hit a difference in behavior, I don't open up the spec to try and figure out who is right and wrong. It's entirely possible that Safari is in the right. But when Chrome/Firefox/Latest webkit agree, and Safari doesn't, I'm fairly confident it's Safari's fault at that point. But even if it was Safari's fault and I could test that on Linux/Android, that would be fine. The biggest annoyance is that you can't possibly know if what you're doing would work without buying Apple hardware.
- stiles11 4y ago
  Performance wise Safari web assembly can't possibly compare to chrome enabled simd web assembly. For anything complex safari's performance is a setback
  - jacobolus 4y ago
    I do a lot of numerical work in Javascript, and I typically find Safari to be the fastest JavaScript engine on my machine for the code I try (sometimes about the same or sometimes several times faster). Safari’s Javascript performance is pretty impressive. Web Assembly is a new and rapidly changing feature. SIMD support in Web Assembly is even newer. Neither one has yet been adopted by most websites / web applications. In a few years I would expect more developers to start adopting these technologies and Safari to have finally gotten around to a SIMD implementation. Personally I hope the browsers all figure out how to get double-precision FMA operations (fused multiply-add) in wasm.
  - deleted 4y ago
    [deleted]
- simion314 4y ago
  If Apple cases about privacy then they could deny Chrome in the Store for the specific reason but allow say Chromium or Firefox (or sure they can find some specific reason why Firefox or Chromium have less privacy and why the iOS users are incapable for deciding for themselves to use Firefox).
- MCArth 4y ago
  This isn't true! I've encountered many bugs in safari (fullscreen pointer lock not working on most html elements comes to mind), and they certainly do not value quality.

Before that he made the Dojo JavaScript library (jQuery precursor / competitor). Alex Russell’s position has always been that web developers (especially library authors) need as many browser features as possible to help them build the most flexible / capable web applications possible. He has consistently pushed for browsers to ship new features ASAP, with the idea that developers can paper over the differences or work around a buggy API, but can’t turn nothing into something. My impression is that he joined Google because he thought that was the best way to further that pre-established goal; it’s not fair to say that he’s just promoting this because he thinks it is in Google/Microsoft/Chrome’s interest. By contrast, Safari developers’ position has long been that new browser features should be carefully evaluated and then implemented at leisure, because this is a long game and we don’t need rush jobs. Their focus is more on client-side resource use (it’s shocking how far behind Chrome is on this one), correctness of the features they do decide to implement, performance, and user privacy (Google’s whole business model is ubiquitous surveillance). These two positions are both defensible, but are at odds with each-other. For Safari developers, Chrome trying to ram big piles of half-baked new features down every browser’s throat ASAP is just a recipe for churn, and getting developers to adopt them right away so that users then come complain that “Safari is broken” is endlessly annoying. For Chrome developers (or web developers who want to build on new shiny features right away instead of waiting 2+ years for cross-browser adoption), Safari lagging behind is “holding back the web”.

mtomweb 4y ago
How does that explain the enormous number of major bugs?
kjksf 4y ago
Safari / WebKit used to be the engine driving the web forward. Apple had no problem rushing things when they were at the brink of death and had to compete with IE and Mozilla by making a better browser. Only when they could kill the competition by simply saying so they switched to a leisurely mode of development. Not to mention they are also very leisurely about fixing bugs. Spin that one to make it look good for Apple, please. The only consistent position that Apple has is: what's good for our business. When they had to compete, they were forced to compete. Now that they don't have to, they don't and instead pay a few PR people to spin it as good for customers for this or that reason. With a generous free help from folks like you, also telling us how Safari is really superior browser. All we ask Apple is to put that theory to test: let Chrome and Mozilla compete and we'll see what actual users prefer.
- jacobolus 4y ago
  Personally I find Chrome to be utterly unusable for my browsing habits (hundreds of browser tabs open at once). It glitches, spins up my laptop’s fans like there’s no tomorrow and burns through battery, eats all the RAM it can find, and easily crashes. And that’s without even getting to the privacy discussion. The existence of a Chrome-based iOS browser would quickly lead web developers to drop Safari and Firefox support (“just install Chrome bro!”) so I for one am thankful that Apple is not budging here. Their browser is, for me, strictly superior. And their political decisions are the last defense of a multi-browser web.
  - deleted 4y ago
    [deleted]
  - patrec 4y ago
    > The existence of a Chrome-based iOS browser would quickly lead web developers to drop Safari and Firefox support (“just install Chrome bro!”) Yeah, that would totally happen because websites that force people to install some massively resource hungry and sluggish browser first will obviously out-compete those that don't.
    - jacobolus 4y ago
      Joe Random web developer doesn’t necessarily care whether the browser he personally develops against is disrespectful of someone else’s client-side resources. He just wants to make his website with as little busywork as possible, and testing every website feature for cross-browser compatibility is busywork. If he can avoid the trouble by telling visitors to switch browsers, he will be happy to do so. This is not hypothetical: developers have been putting up “this site works best (or only works) in X browser” warnings for decades by now.
      - depressedpanda 4y ago
        No, what would happen is that Apple would actually have to spend resources on competing with other browser engines, instead of holding the web back via monopoly. They certainly have the money to do so.
nwienert 4y ago
Wow, explains a lot. It’s such a shortsighted position for a browser - it’s one of the only platforms that literally can’t have breaking changes, and they want to bloat it even more? The entire problem with the web is they keep adding high level half-solutions over and over, many that intersect and almost none that actually solve things at the right abstraction. What we need is lower level primitives and performance. Instead we got Web Components, a disaster, and seemingly a thousand new CSS features (coming only from Chrome) that serve only to further entrench Google. Simpler and lower level APIs and ruthless work on performance would have given us a far richer platform to target, leading to better interop with cross compiling native tools, better experiences, and less bloat. Seems like weekly a Google evangelist tweets a gushing, emoji-laden joyous tweet about a new feature they’re shopping tomorrow adding some super arbitrary thing (the latest is some page transition spec which again is such a half-solution). Extend and extinguish!
- aaaaaaaaaaab 4y ago
  >Seems like weekly a Google evangelist tweets a gushing, emoji-laden joyous tweet about a new feature they’re shopping tomorrow adding some super arbitrary thing (the latest is some page transition spec which again is such a half-solution). Extend and extinguish! They’re going for that juicy promotion, no matter what! The future of the Web be damned…
doix 4y ago
> correctness of the features they do decide to implement, performance, If this was the case, I would hate Safari significantly less. If the only issue with Safari was that they didn't implement certain features, that would be fine. I could check the compatibility matrices and just avoid features that aren't implemented. The problem is that every now and then they support something, and it _appears_ to work, but then there's some weird interaction that breaks some interaction and it takes forever to debug. Sometimes it's reproducible in Epiphany(webkit issue), but other times it isn't. Safari updates their webkit version pretty infrequently so bugs that are fixed in webkit are not fixed in Safari. So the only way to know if it works in Safari is to test in Safari, which requires OSX. Safari is the new IE. IE had better client-side resource use for a long time compared to firefox/netscape. IE didn't implement new features and they had IE only features just like Safari (you can select text in images in Safari). IE only worked on windows and made linux/osx developers suffer just like Safari makes linux/windows developers suffer today.
- nwienert 4y ago
  When you develop in Chrome of course you’ll feel like bugs only exist in other engines. Developing on Safari it feels like the opposite. A few years ago I’d have agreed somewhat, but Safari has accelerated considerably and improved wrt standards. In fact better than Chrome as of late, if you follow the Interop project, and it feels as much.
  - doix 4y ago
    I primarily use Firefox, but I usually have 3 browsers open: Chrome/Firefox/Epiphany to try and make sure stuff works correctly across all 3 major engines. Unfortunately stuff still slips through into Safari land. I am not a language specification lawyer. If I hit a difference in behavior, I don't open up the spec to try and figure out who is right and wrong. It's entirely possible that Safari is in the right. But when Chrome/Firefox/Latest webkit agree, and Safari doesn't, I'm fairly confident it's Safari's fault at that point. But even if it was Safari's fault and I could test that on Linux/Android, that would be fine. The biggest annoyance is that you can't possibly know if what you're doing would work without buying Apple hardware.
stiles11 4y ago
Performance wise Safari web assembly can't possibly compare to chrome enabled simd web assembly. For anything complex safari's performance is a setback
- jacobolus 4y ago
  I do a lot of numerical work in Javascript, and I typically find Safari to be the fastest JavaScript engine on my machine for the code I try (sometimes about the same or sometimes several times faster). Safari’s Javascript performance is pretty impressive. Web Assembly is a new and rapidly changing feature. SIMD support in Web Assembly is even newer. Neither one has yet been adopted by most websites / web applications. In a few years I would expect more developers to start adopting these technologies and Safari to have finally gotten around to a SIMD implementation. Personally I hope the browsers all figure out how to get double-precision FMA operations (fused multiply-add) in wasm.
- deleted 4y ago
  [deleted]
simion314 4y ago
If Apple cases about privacy then they could deny Chrome in the Store for the specific reason but allow say Chromium or Firefox (or sure they can find some specific reason why Firefox or Chromium have less privacy and why the iOS users are incapable for deciding for themselves to use Firefox).
MCArth 4y ago
This isn't true! I've encountered many bugs in safari (fullscreen pointer lock not working on most html elements comes to mind), and they certainly do not value quality.