I ask because when I have travelled for work, it's the corporate hotels that have often baked a Chromecast into their TV experience, even to the point of sorting out their wifi network so you're only able to cast to the screen in your room. Their splash screen offers "live TV" or the option to "stream from your phone".

They often don't shout about the fact that it's a chromecast doing the work, but the telltale standby screen that shows up when you're not casting something normally confirms it.

What is it about this release that has lost your support? Specifically gating the Apple Intelligence stuff to the most modern hardware?

I did also find manual focus produced odd green visual artefacts in the live view as you move the focus control.

With that said, it’s a nice UI, hopefully the bugs can be ironed out!

I use it where I’m dealing with internal code or data for work where I need to know it’s all staying on-device.

I’ve had it roughly translate portions of code to another language (normally one I’m very familiar with so I can vet it), create mermaid syntax flow charts for code where I need to visualise a process for non-technical consumption, and compare two very similar job descriptions to understand where a candidate might be better for one role or another.

I have on occasion also asked it to condense a wordy email going out to senior staff but I find Mistral 7B is a bit all or nothing and will take my 5 paragraphs and shrink them to a couple of sentences with lose most meaning. Having to hand hold it through each paragraph and then rewrite in my own style is never much of a time saver.

- I’ve had employers that require a confirmation step from an app as a form of 2FA. If my phone isn’t awake, the notification comes to my watch and I can approve my login from my wrist

- If some action requires typing on my watch, I get a prompt on my iPhone to do the typing there instead of on the tiny watch keyboard. The characters I type via the phone appear in real time on the watch as if I were typing directly

- Dismissing and snoozing notifications syncs so I don’t have to dismiss and snooze notifications on multiple devices

- Similarly, if I set an alarm on my phone, the alarm will ring on my phone and, if I’m wearing it, vibrate my watch without further setup. Again, actions I perform to that alarm can all be performed on the watch or phone.

I’d guess these are all tiny, tiny quality of life features, but I’d be very surprised if other non-Apple watches have the ability to implement them.

The fact that the headline is USUALLY “GitHub was down” says a lot more than the individual post in isolation!

The problem I see with this is that whatever you’re sending this to must have knowledge of the meta information superjson produces, so at that point you’re investing in it as a wrapper library. The fact you can extend the types it serialises also complicates things and means the receiver needs further implementation specific knowledge.

I think in my original comment, I was imagining a world where JSON.serialize threw errors on unknown types and we needed a wrapper just get basic JSON out of it.

But I think in the case of JSON.stringify it’s more about use case. 99% of the time, users of this method are taking some data and serialising it to a JSON compliant form to send to the server. JSON doesn’t support functions, or complex objects like a Date, so I tend to think it’s a reasonable default that functions disappear and Date’s are converted to an ISO standard. To insist that every single user runs a preparation step that strips out unserialisability data and chooses how to handle Date objects sounds laborious, error prone, and ripe for another npm dependency everyone suddenly normalises for every project.

Maybe a “strict mode” of some sort where you could have it throw on anything for cases where you need to guarantee everything is being sent?

OTOH, I have to concede that while this method has silent failures, they then implemented JSON.parse to throw at the slightest issue. So I have to admit there’s consistency even within the API.

"Apple has partnered with CTDI for the SSR store and the fulfillment of related parts and tools. CTDI will utilize its SPOT subsidiary, including SPOT customer service agents, in support of SSR store customers."

It makes sense that Apple would offload this to someone else, but I agree it's a rather jarring experience.

[0] https://www.ctdi.com

- Open lid

- Lock screen shows

- Screen fades to black as it realises there's an external monitor

- Finally unlock, windows are all bunched up on the internal display

- Everything becomes unresponsive, maybe even another fade to black

- A minute after initially opening the lid, suddenly all the windows pop back into place

I have no idea if this is improved on M1 machines, but it's frustrating enough on my Intel 16" that I've just pushed all the auto-lock timeouts to excessively large durations.

Between lacking support and poor performance over and over in the Android ecosystem, it became a very easy decision to move over to the Apple lock-in unfortunately. Their phones generally stay out of my way and work snappily when I need them to.

It's a real shame to have had this experience, and to watch others around me have similar issues before jumping ship to Apple. I think the competition provided by the big Android vendors is important, but I just can't justify dropping money on a new device every 18 months.

I do, however, think that working with React changes your mental model somewhat, and when I'm working with React I catch myself doing a lot more data wrangling close or in the rendering loop than I would in any other modern framework. Certainly since class components have fallen out of favour, you're working with a function designed to be run hundreds of times, while Vue and Svelte both provide clear patterns to deal with data at the point of change, then separately deal with updating the display of that data as required.

It takes using something like MobX to really push a React codebase to a data-driven model and that means many inexperienced developers fall into the common pitfalls far more easily than if they're using an alternative framework imo.

I think the true progressive enhancement route would be to render the menu either visibly on the page (maybe at the bottom?) or on a separate page entirely. Your burger menu icon is a link (either an anchor to bring the menu into view or to the dedicated menu page) and if JS is supported, you hijack the link using code similar to the parent comment and add a class to bring the menu element into view from there.

In doing so, your page can work just as HTML, not even CSS required, and if JS is supported then you have real state management to control the visibility of your menu (although accessibility concerns still potentially exist if you're not careful!).

The idea that this type of thing should be happening anywhere near the view rendering loop is the exact reason I've not had a great time picking up React codebases.

By the time you're rendering data into markup, the data should be in the exact state you need it. No further filtering or data mangling or sorting. That type of data manipulation should happen at the point of data change and then it shouldn't happen again until the data changes again.

The simplistic templating languages in Vue/Svelte/Alpine/whatever-comes-next force you to pull your data manipulation back to somewhere more appropriate, with Vue even throwing a warning if you try to filter within v-for construct.

Because React is JS, people are let loose to do wildly inefficient operations and do them over and over and over whenever _anything_ in that component changes.

The real kicker would be if they removed the options API, for small components, it's all you need and I find prototyping with it easier than the composition API. So I for one am hoping they don't drop support for it in Vue 4!