5 ms·

> Whenever I develop for JavaScript, if I find a module that just has weird undefined and undocumented behavior, I get rid of it no matter how powerful. `rm -r

> Whenever I develop for JavaScript, if I find a module that just has weird undefined and undocumented behavior, I get rid of it no matter how powerful. `rm -rf Chrome.app` The equivalent between native development and web is not the quirks of a library, it's the quirks of browsers. That's the metal you're running on.

oblio 5y ago
> I wish I could do that with the Mac developer ecosystem. It's closed and Apple will say that gives them a premier experience but it's the little snags that cost me 90% of my time and are impossible to troubleshoot other than grunting through it. Might be worth reading the entire post and commenting on it in its entirety, not cherry picking.
- kennywinker 5y ago
  I'm not sure what you mean by cherry-picking, I'm directly addressing their comment. The kinds of struggles `xrd` mentions (Gatekeeper, protocol handlers) are not library level dependencies, they are the platform their code is running on. Comparing that to a js library is just the wrong equivalence. If their beef was with AppKit, or NSWindow or something at the dependency level then yeah it's fair to compare that to an npm package. The bulk of my experience has been with native development, so I find these struggles familiar and un-threatening. However, when I do browser-based development and I'm faced with one of those massive "Browser compatibility" tables on Mozilla.org explaining how this "standard" is implemented in wildly different ways across the major browsers, and then the reality turns out to be different from what the table suggested, I get as frustrated as `xrd` is.
mschuster91 5y ago
> The equivalent between native development and web is not the quirks of a library, it's the quirks of browsers. That's the metal you're running on. Unfortunately, the one browser causing the most miserability for web developers these days is Safari itself, not Chrome as you implied. It is the only web browser engine that's allowed to be used on iOS devices, and many people use it on Macs since it is able to use all the undocumented quirks and nooks in OS X to smash Chrome/FF in battery usage. The problem is that it has so much stuff that's outright broken (IndexedDB), is outdated (its developer tools) or just plain sucks (it won't play <video> elements if the server doesn't serve Range HTTP headers, for example - painful if you're streaming from inside a CMS). And that's been the case for years. Safari is the new IE. Apple should be forced, just like Microsoft, to de-bundle it from the OS and open up and document their private APIs to allow Chrome and Firefox to be competitive!
- gjsman-1000 5y ago
  If they did that, you’d risk Chrome taking over and extending it’s browser engine monopoly to be even bigger. And Firefox, remember, laid off most of the engineering team. The only real people benefiting would be Chrome based browsers, with their ability to spread Chrome to even more places.
- kennywinker 5y ago
  > Unfortunately, the one browser causing the most miserability for web developers these days is Safari itself I think it's a bit of a straw man to say that the only reason web development is hard is safari. Browser support is irreducibly difficult as long as we live in a world with more than one browser. Safari may stand out as the odd duck, but I for one don't want to stream video on my 3gb a month data connection if it has to load the full content in order to jump ahead 2min.

oblio 5y ago

> I wish I could do that with the Mac developer ecosystem. It's closed and Apple will say that gives them a premier experience but it's the little snags that cost me 90% of my time and are impossible to troubleshoot other than grunting through it. Might be worth reading the entire post and commenting on it in its entirety, not cherry picking.

kennywinker 5y ago
I'm not sure what you mean by cherry-picking, I'm directly addressing their comment. The kinds of struggles `xrd` mentions (Gatekeeper, protocol handlers) are not library level dependencies, they are the platform their code is running on. Comparing that to a js library is just the wrong equivalence. If their beef was with AppKit, or NSWindow or something at the dependency level then yeah it's fair to compare that to an npm package. The bulk of my experience has been with native development, so I find these struggles familiar and un-threatening. However, when I do browser-based development and I'm faced with one of those massive "Browser compatibility" tables on Mozilla.org explaining how this "standard" is implemented in wildly different ways across the major browsers, and then the reality turns out to be different from what the table suggested, I get as frustrated as `xrd` is.

mschuster91 5y ago

> The equivalent between native development and web is not the quirks of a library, it's the quirks of browsers. That's the metal you're running on. Unfortunately, the one browser causing the most miserability for web developers these days is Safari itself, not Chrome as you implied. It is the only web browser engine that's allowed to be used on iOS devices, and many people use it on Macs since it is able to use all the undocumented quirks and nooks in OS X to smash Chrome/FF in battery usage. The problem is that it has so much stuff that's outright broken (IndexedDB), is outdated (its developer tools) or just plain sucks (it won't play <video> elements if the server doesn't serve Range HTTP headers, for example - painful if you're streaming from inside a CMS). And that's been the case for years. Safari is the new IE. Apple should be forced, just like Microsoft, to de-bundle it from the OS and open up and document their private APIs to allow Chrome and Firefox to be competitive!

gjsman-1000 5y ago
If they did that, you’d risk Chrome taking over and extending it’s browser engine monopoly to be even bigger. And Firefox, remember, laid off most of the engineering team. The only real people benefiting would be Chrome based browsers, with their ability to spread Chrome to even more places.
kennywinker 5y ago
> Unfortunately, the one browser causing the most miserability for web developers these days is Safari itself I think it's a bit of a straw man to say that the only reason web development is hard is safari. Browser support is irreducibly difficult as long as we live in a world with more than one browser. Safari may stand out as the odd duck, but I for one don't want to stream video on my 3gb a month data connection if it has to load the full content in order to jump ahead 2min.