5 ms·

meh, desktop Safari is actually a very good browser. It is the fastest of all browsers in macos for a bunch of operations and their support for ES6 features be

meh, desktop Safari is actually a very good browser. It is the fastest of all browsers in macos for a bunch of operations and their support for ES6 features beats all the other browsers (99% in https://kangax.github.io/compat-table/es6/ https://kangax.github.io/compat-table/es6/ ). Also one could argue that if Apple did not invest so much in WebKit then chrome would have had a harder time achieving its current usage and would probably be a very different browser than what it is today. My 2cents

maratd 9y ago
> their support for ES6 features beats all the other browsers This is deceptive. They purposefully do not support critical features that other browsers do support. As a developer, if there's one browser that consistently gives me headaches, it is Safari. https://developer.mozilla.org/en-US/docs/Web/API/FormData/get#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/API/FormData/ge...
- geocar 9y ago
  As a user, I hate having to open Chrome[1] because of some "critical feature". Honestly, I sometimes wish you "developers" would find some other way to implement your application. [1]: http://i.imgur.com/NcPu5IU.png http://i.imgur.com/NcPu5IU.png
- zghst 9y ago
  Honestly, there are so many libraries out there that abstract away issues like this. By building an app from scratch, custom rolling logic, you automatically opt-out of the good tools that negate all of the tiny differences in browsers. I've had my share of Safari issues, but over time, the amount of libraries I've co-opted into my dev strategy has helped me bypass the majority of browser issues.
nolok 9y ago
I do not know enough about Safari to agree or disagree with your general point, but I find this part to be really irrelevant: > Also one could argue that if Apple did not invest so much in WebKit then chrome would have had a harder time achieving its current usage and would probably be a very different browser than what it is today. The same can be said on an even larger scale about microsoft and IE 5 and 6; that doesn't mean in anyway that years later they were not a pain stopping the web from going forward. In other word, I don't see how that has any impact on the conversation at end (neither for or against the point made). EDIT: Not sure why the downvotes. Apple invested a lot into Safari (and thus webkit which lead to chrome). Doesn't change in any way if Safari is or isn't holding the web back currently, which is why I say it's irrelevant to paren't countering argument. And in fact, we have a previous examples since we lived the same scenario with Microsoft who invested a lot into IE 5/6 (and leading into DHTML, XMLHttpRequest, ...), which then definitely hold the web back. This is, literally, the same argument. I don't see how I can be downvoted for stating that obvious fact unless you think that IE 6 didn't hold the web back after a while.
- johncolanduoni 9y ago
  Chrome's renderer started as a fork of WebKit. Last time I checked nobody was able to fork any version of IE.
  - nolok 9y ago
    That's not my point. Thread says "Safari is holding the web back". Parents answers "Safari created the tools that lead to big parts of the modern web". My answer is: so did IE 5/6. That doesn't mean after a while and for a long time they weren't holding the web back, it's a side fact that has no relevance.
ko27 9y ago
> their support for ES6 features beats all the other browsers That's really grasping for straws. All modern browsers almost fully support ES6 features. Tail optimization are more controversial because they can actually lead to a performance decrease in some cases. Far more important are things like custom elements and service workers on which Safari is lagging behind.
- geocar 9y ago
  > Tail optimization are more controversial because they can actually lead to a performance decrease in some cases. How exactly can the tail-call elimination optimization decrease performance? Sounds more like an implementation problem.
  - lvh 9y ago
    Both TCO and PTC can decrease performance easily for a bunch of reasons. TC39 addressed this[0] when considering explicit tail call sites. Reasons vary from Windows ABI (Chakra) to something as simple as "now I have to figure out if this is really a PTC" -- and if your function has a PTC but that only gets invoked once, it's not hard to see how the extra analysis pressure doesn't weigh up to the elided stack frame. JS engines were already extremely optimized, it's not like you're taking a CS student's first lisp interpreter and adding TCO. (Fortunately, some of the litmus tests for whether you can apply PTC are encapsulated within strict mode, and the compiler stages definitely know that for free already.) [0]: https://github.com/tc39/proposal-ptc-syntax#performance https://github.com/tc39/proposal-ptc-syntax#performance
    - geocar 9y ago
      I remain unconvinced that just because it's difficult for a couple of JavaScript implementations, that we're still not talking about an implementation problem. How exactly does anyone think that v8 doing something badly, is proof that something cannot be done well?
      - lvh 9y ago
junkculture 9y ago
I agree. Not only is it the fastest, it's also the most reliable. I have Firefox thrashing about more often than not, and I refuse to use Chrome or its google infected variants. Brave seems promising but doesn't yet have extensions.

maratd 9y ago

> their support for ES6 features beats all the other browsers This is deceptive. They purposefully do not support critical features that other browsers do support. As a developer, if there's one browser that consistently gives me headaches, it is Safari. https://developer.mozilla.org/en-US/docs/Web/API/FormData/get#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/API/FormData/ge...

geocar 9y ago
As a user, I hate having to open Chrome[1] because of some "critical feature". Honestly, I sometimes wish you "developers" would find some other way to implement your application. [1]: http://i.imgur.com/NcPu5IU.png http://i.imgur.com/NcPu5IU.png
zghst 9y ago
Honestly, there are so many libraries out there that abstract away issues like this. By building an app from scratch, custom rolling logic, you automatically opt-out of the good tools that negate all of the tiny differences in browsers. I've had my share of Safari issues, but over time, the amount of libraries I've co-opted into my dev strategy has helped me bypass the majority of browser issues.

nolok 9y ago

I do not know enough about Safari to agree or disagree with your general point, but I find this part to be really irrelevant: > Also one could argue that if Apple did not invest so much in WebKit then chrome would have had a harder time achieving its current usage and would probably be a very different browser than what it is today. The same can be said on an even larger scale about microsoft and IE 5 and 6; that doesn't mean in anyway that years later they were not a pain stopping the web from going forward. In other word, I don't see how that has any impact on the conversation at end (neither for or against the point made). EDIT: Not sure why the downvotes. Apple invested a lot into Safari (and thus webkit which lead to chrome). Doesn't change in any way if Safari is or isn't holding the web back currently, which is why I say it's irrelevant to paren't countering argument. And in fact, we have a previous examples since we lived the same scenario with Microsoft who invested a lot into IE 5/6 (and leading into DHTML, XMLHttpRequest, ...), which then definitely hold the web back. This is, literally, the same argument. I don't see how I can be downvoted for stating that obvious fact unless you think that IE 6 didn't hold the web back after a while.

johncolanduoni 9y ago
Chrome's renderer started as a fork of WebKit. Last time I checked nobody was able to fork any version of IE.
- nolok 9y ago
  That's not my point. Thread says "Safari is holding the web back". Parents answers "Safari created the tools that lead to big parts of the modern web". My answer is: so did IE 5/6. That doesn't mean after a while and for a long time they weren't holding the web back, it's a side fact that has no relevance.

ko27 9y ago

> their support for ES6 features beats all the other browsers That's really grasping for straws. All modern browsers almost fully support ES6 features. Tail optimization are more controversial because they can actually lead to a performance decrease in some cases. Far more important are things like custom elements and service workers on which Safari is lagging behind.

geocar 9y ago
> Tail optimization are more controversial because they can actually lead to a performance decrease in some cases. How exactly can the tail-call elimination optimization decrease performance? Sounds more like an implementation problem.
- lvh 9y ago
  Both TCO and PTC can decrease performance easily for a bunch of reasons. TC39 addressed this[0] when considering explicit tail call sites. Reasons vary from Windows ABI (Chakra) to something as simple as "now I have to figure out if this is really a PTC" -- and if your function has a PTC but that only gets invoked once, it's not hard to see how the extra analysis pressure doesn't weigh up to the elided stack frame. JS engines were already extremely optimized, it's not like you're taking a CS student's first lisp interpreter and adding TCO. (Fortunately, some of the litmus tests for whether you can apply PTC are encapsulated within strict mode, and the compiler stages definitely know that for free already.) [0]: https://github.com/tc39/proposal-ptc-syntax#performance https://github.com/tc39/proposal-ptc-syntax#performance
  - geocar 9y ago
    I remain unconvinced that just because it's difficult for a couple of JavaScript implementations, that we're still not talking about an implementation problem. How exactly does anyone think that v8 doing something badly, is proof that something cannot be done well?
    - lvh 9y ago

junkculture 9y ago

I agree. Not only is it the fastest, it's also the most reliable. I have Firefox thrashing about more often than not, and I refuse to use Chrome or its google infected variants. Brave seems promising but doesn't yet have extensions.