It's interesting you mention upfront that you travel. Is that travel for work where you might be staying in corporate hotels?
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.
iOS18 will still be available for older devices right? From the looks of the preview, it’ll go back to phones from 2018 which is fairly standard for Apple. And I’d imagine older iOS versions will continue to receive security updates for several years after they’re dropped from the latest version.
What is it about this release that has lost your support? Specifically gating the Apple Intelligence stuff to the most modern hardware?
Same phone and same OS version down to the patch number. I’ve noticed UI hangs and stutter when changing the grades, and BNW in particular seems to cause the biggest issues. Not yet experienced a crash even if I flick between grades in quick succession.
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!
Similar to another reply, my M2 16GB MacBook happily runs Mistral 7B, and it will do a decent job of most requests.
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.
Not the parent, but just a few things I’d guess would be Apple Watch specific:
- 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.
To be fair, downtime is often posted for services popular among HN readers, I don’t think there’s malicious intent, it’s merely the acknowledgment of an incident.
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.
I understand your point and I can’t deny that Javascript continues to introduce weird, silent failures and quirks even today when everything is a bit more thought out than “the bad old days”.
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.
I thought it was a bit sketchy too and spoke to their support agent about it. It seems this site is run by a partner, SPOT or Service Parts or Tools. Their privacy policy lists servicepartsortools.com as a domain but visiting the domain shows a standard parked domain page. The domain is owned by CTDI[0] which does seem more legitimate. The response I got from the support agent after pressing the issue was:
"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.
- 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.
I'm unsure this is true. I was certainly disappointed when I went for a Samsung S8 at launch and found it laggy and glitchy 12 months in, and unusable at 18 months. As a short term money saver, I bought a 2016 iPhone SE and was amazed to find it got 2 more years of updates before I finally decided to retire it.
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.
You can 100% do these things in React, I don't believe React is a less able framework by any means. If anything it gives you a powerful toolbox and pulls down the guard rails.
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 love no-JS type hacks and solutions as your post has suggested, but I would actually be more concerned about using solutions like your hidden menu in production than what the parent has suggested. Some of them, like the checkbox dark mode, are indeed hacks and cause issues with accessibility, and when I've tried a suitably complex burger menu without JS, I find it a buggy and annoying UX.
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!).
Do you have an example you've run into where a DSL such as Svelte's or Vue's has actually stopped you from doing something? Would be genuinely interested to see it as I've never run into such a situation myself.
My feelings exactly, it makes for a satisfying separation of concerns, and if you understand what's going on under the hood it makes for cleaner templates and more obvious component code.
> Because you sometimes want to filter, sort or project your data.
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.
To be fair, React has been pulling this type of thing version after version. It seems like we MIGHT be settling on functions and hooks now, but only time will tell.
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!
Unfortunately they pretty much dumped the class syntax early on in Vue 3's development, so you'll probably find it quite hard to transition to Vue 3 if you Vue 2 codebase is full on class components. I had a similar issue having adopted the class syntax and I think rewriting is probably the only way out.
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.