I guess what we're seeing here is a developer/development-first ideology versus a platform-first ideology.

Should the developer/development have to resubmit to the benevolent platform? Or should the platform have to support the development that has occurred?

I don't really care, but I know that I'd rather develop somewhere where my contributions aren't under constant threat of being wiped off the landscape.

Again, good luck with the other thing.

You have painted this false dichotomy.

In Apple's world: The users come first. Everyone else second.

The policies described in the root comment we're replying to have nothing to do with putting the user first. Apple puts Apple first, even when it's bad for users.

Maybe. But how bad would the user experience be if every time a user went to do an IAP, they were presented with a link to an external web page asking for their credit card information? Would that affect the security and privacy of the platform? Would it affect users' trust in the platform?

Maybe if Apple didn't charge many times more than credit card processors to handle payments, developers wouldn't be trying to avoid getting robbed.

I strongly disagree. Apple has made a lot of user-hostile moves recently. Suppressing ports to sell more dongles, constant nagging for apple paid services, uping prices to make up for lack of growth in volumes. Profits first, users and developers not on the map.

I find it amusing that people think a company making $10B in profit a quarter is trying to use $30 dollar dongles to make money.

Apple has been "suppressing ports" since they introduced the iMac over 20 years ago. The USB-C transistion didn't happen as quickly as the original USB transistion.

You don't have to buy dongles from Apple.

I am a developer but if more developers put users before themselves, we wouldn't have Electron apps.

Yes. Unless you want to use Google Maps. My SO just asked me to fix her phone to give her biking directions again. She uses the "Google" app to look up stuff, as far as I can tell the OS is now intercepting calls to https://maps.google.com and opening them in Apple Maps instead?!

That doesn’t happen. If you click on an address from Google’s website, it opens in Google Maps if it is installed. If you click on a link from any Google app it opens Google maps by default.

Mmm, well yes, happening now. From the "Google" app made a search, a long touch on the Directions link shows a maps.google.com URL, Google Maps is installed, even reinstalled GM thinking the registration was corrupted somehow. It opens in Apple Maps. Uninstalled Apple Maps and it prompt me to reinstall.

Perhaps since this is the Google app the URL they show for long touch is not actually what is getting executed when you tap, maybe they are sending a routing command directly, but either way there's a number of UI "nudges" to push you to Apple Maps over Google Maps that you cannot adjust or turn off without jailbreaking the phone.

I just clicked on a direction from Google on Safari and it took me to Google Maps.

I did the same from Chrome. It took me to Google Maps

I went to a third party web site within Chrome, click on "get directions", it took me to Google Maps.

Not so much platform first as user first. Platforms are nothing without users and developers are nothing without platforms. And luck isn’t needed when your platform is already the best. :)

That's fair, but currently being "the best," doesn't ensure that status.

And then you end up with Windows. Hack upon hack upon hack to keep old software running. It increases the surfaces of bugs and security vulnerabilities.

And you need that if that platform is to be used for anything serious. I don’t see Macs in the enterprise. And linux has the same obsession with backward compatibility / not breaking user space when making changes in the kernel.

Yet and still iPhones and iPads are. There are many reasons that Macs aren't in the Enterprise. But backwards compatibility isn't the main one.

To be fair, browsers aren't always perfect about preserving backwards compatibility for every API.

Miles ahead of native, and hundreds of miles ahead of mobile. For the most part, the web is one of the most future-proof platforms you can develop for, if not the most future-proof platform you can develop for.

But there's still room to improve.

IBM mainframes are the most future-proof platform you can develop for. Current mainframes have backwards compatibility going back to the 70's. Perhaps even the 60's.

The web is probably second, though. Either the web or Windows.

If we're including devices that almost nobody has access to, the most future proof device is not the one that keeps backwards compatibility, but the one that only has one version that is still produced, since initial compatibility is the only compatibility.

Any tricks and additional uses you develop for the abacus will likely long outlive any IBM if it's worthwhile. That doesn't mean it's particularly easy to develop something people will find worthwhile enough to propagate forward though. Backwards compatibility only matters as long as you have something that ca take advantage of it and a need to do so.

Pity that it still doesn't provide a fully Delphi like development experience.

What a hilarious statement to make.

Sure a website from 1996 will look the same. It will also have no accessibility, work terribly on mobile, be largely like reading a Word document and have none of the interesting features of modern web sites. Your world is not the world most people want.

I can think of some sites on the order of 15 - 20 years old that work better on mobile than sites made in the last 5.

And while the various accommodations for accessibility that have come up over the last two decades are nice, the fact is that most of the web was fairly accessibly using specialized user agents (or even just Lynx) by the very late 90s.

Hacker News is one such site that is very basic and has none of the stuff you outline as modern features. You know what? It is by far one of the most performant and enjoyable websites I use daily.

> let's talk about taking the entire web back to 1996.

Let's not, that's a tangent. The original statement to which you replied was this:

> A website from 1996 will look much the same in a modern version of Chrome. Good luck with your SDKs.

That remains true, despite the advances you listed. http://www.thekrib.com/ is an example from 1994 which still looks like it renders about the same. It doesn't have the bells and whistles, but the point is, _what was written remains available._ Interactive applications tracking a moving SDK cannot be left for future generations, they have to be maintained. Putting non-interactive content into those types of applications is forcing a maintenance burden forevermore.

The goalposts have wheels!

The modern browser is quite good at rendering text, just as it was in 1996. The web is largely still about words. What improvement is so important as to strike the words of those from 1996 off the record?

Nobody here has argued to start striking outdated websites off the record. However the advent of reader mode has certainly helped things in that neighborhood come through a bit cleaner.

But as yet websites don’t control rapidly evolving and privacy sensitive hardware on mobile devices. Also, user time spent in apps versus web browsers is hovering around ~90% versus 10. Might it be possible that having an up-to-date experience as it’s enforced by mobile platform owners could contribute somewhat to this abundant user preference for apps?

There is a lot to be said about adaptive web fails, text or graphics overflowing outside of the screen while locking the zoom level, botched overrides of browser behaviors. A simple old html page is often more readable on a smartphone than a page where the developper tried hard to fuck with the way it is rendered on a small screen. If the text is too small you can easily zoom in. And most smartphones these days have large, high dpi screens.