Comment by PaulRobinson

1 day ago

Nice list. Some thoughts:

- I think without the move to NeXT, even if Jobs had come back to Apple, they would never have been able to get to the iPhone. iOS was - and still is - a unix-like OS, using unix-like philosophy, and I think that philosophy allowed them to build something game-changing compared to the SOTA in mobile OS technology at the time. So much so, Android follows suit. It doesn't have a command line, and installation is fine, so I'm not sure your line of reasoning holds strongly. One thing I think you might be hinting at though that is a missed trick: macOS today could learn a little from the way iOS and iPadOS is forced to do things and centralise configuration in a single place.

- I think transaction processing operating systems have been reinvented today as "serverless". The load/execute/quit cycle you describe is how you build in AWS Lambdas, GCP Cloud Run Functions or Azure Functions.

- Most of your other ideas (with an exception, see below), died either because of people trying to grab money rather than build cool tech, and arguably the free market decided to vote with its feet - I do wonder when we might next get a major change in hardware architectures again though, it does feel like we've now got "x86" and "ARM" and that's that for the next generation.

- XHTML died because it was too hard for people to get stuff done. The forgiving nature of the HTML specs is a feature, not a bug. We shouldn't expect people to be experts at reading specs to publish on the web, nor should it need special software that gatekeeps the web. It needs to be scrappy, and messy and evolutionary, because it is a technology that serves people - we don't want people to serve the technology.

20 comments

PaulRobinson

Reply
JimDabell  1 day ago

> XHTML died because it was too hard for people to get stuff done.

This is not true. The reason it died was because Internet Explorer 6 didn’t support it, and that hung around for about a decade and a half. There was no way for XHTML to succeed given that situation.

The syntax errors that cause XHTML to stop parsing also cause JSX to stop parsing. If this kind of thing really were a problem, it would have killed React.

People can deal with strict syntax. They can manage it with JSX, they can manage it with JSON, they can manage it with JavaScript, they can manage it with every back-end language like Python, PHP, Ruby, etc. The idea that people see XHTML being parsed strictly and give up has never had any truth to it.

  • troupo  1 day ago

    > The syntax errors that cause XHTML to stop parsing also cause JSX to stop parsing. If this kind of thing really were a problem, it would have killed React.

    JSX is processed during the build step, XHTML is processed at runtime, by the browser.

eloisant  1 day ago

They would have gotten another modern OS instead of Next as the base for MacOSX (then iOS).

Another possibility they were exploring was buying BeOS, which would have been pretty interesting because it was an OS built from scratch in the 90's without any of the cruft from the 70's.

Also, the only thing specific to Next that survived in MacOSX and iOS was ObjectiveC and the whole NextStep APIs, which honestly I don't think it a great thing. It was pretty cool in the 90's but when the iPhone was released it was already kinda obsolete. For the kernel, Linux or FreeBSD would have worked just the same.

pjmlp  9 hours ago

There is hardly any UNIX stuff for iOS and Android applications sold via the respective app stores.

You won't get far with POSIX on any of the platforms.

bsimpson  1 day ago

Didn't Google already own Android when iOS was announced?

  • troupo  1 day ago

    Yes, and they were going to position it against Windows Mobile.

    When iOS was announced, Google scrambled to re-do the entire concept

    • giobox  1 day ago

      Not so much Windows Mobile, which never achieved serious market share. It was originally more planned to be a Blackberry competitor, and the early Android handset prototype concepts were all blackberry knockoffs with similar physical keyboard layouts.

      It has always appeared though like you suggest, that the project quickly pivoted to candy bar touch phones following the release of the original iPhone. It's worthwhile to remember that the industry wasn't nearly as convinced that touching glass was the future of mobile typing in 2007 as it later became, and the sales volume of Blackberrys back then was often incorrectly cited as evidence to support the case against touch.

      > https://www.bgr.com/tech/iphone-vs-android-original-google-b...

      2 replies →

donatj  1 day ago

On XHTML, I think there was room for both HTML and a proper XHTML that barks on errors. If you're a human typing HTML or using a language where you build your HTML by concatenation like early PHP, sure it makes sense to allow loosey goosey HTML but if you're using any sort of simple DOM builder which should preclude you from the possibility of outputting invalid HTML, strict XHTML makes a lot more sense.

Honestly I'm disappointed the promised XHTML5 never materialized along side HTML5. I guess it just lost steam.

  • detaro  1 day ago

    But a HTML5 parser will obviously parse "strict" HTML5 just fine too, what value is there to special-case the "this was generated by a DOM builder" path client-side?

  • chrismorgan  1 day ago

    > Honestly I'm disappointed the promised XHTML5 never materialized along side HTML5. I guess it just lost steam.

    The HTML Standard supports two syntaxes, HTML and XML. All browsers support XML syntax just fine—always have, and probably always will. Serve your file as application/xhtml+xml, and go ham.