shrew
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.
- 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!
It's a shame as I liked a lot of Angular.js but it still lags behind in size and performance these days so it's only attractive to teams that know they're making large, heavyweight web-based software from the start.
This demo[1] runs a similar template to the initial few in the Hibiki HTML tutorial via Vue. I've been able to use the full Vue templating features and I've used a minimal amount of JS to set it up. The script I've included is ~4x smaller than the minified prod build of Hibiki, and my data models are in a real JS script tag so my code editor will treat it as real JS, as are my event handling methods which interact with my data model. AlpineJS is actually half the size again of Vue's prod build, I just chose Vue as I work with it regularly.
In trying to save developers the trouble of learning JS where they're not familiar, Hibiki feels like a new, less known, less documented DSL wrapped in non-standard HTML tags and lots of esoteric naming conventions in order to connect logic, data and layout together (it gives me ColdFusion vibes). While I could see the idea with remote actions, replicating this kind of loop in JS is trivial and feels less "magic", with the benefit that a strict data structure isn't thrust on the developer that then leaks into their backend code.
If a developer doesn't want to learn JS, they can get by just fine with server rendered pages which need to update with every action. If they want interactive content without reload, it's probably best for them to learn the small amount JS required to do what they want.
I apologise for being so down on the idea, especially as I'm keen to see more projects embrace the approach of keeping it simple, and ridding themselves of painful build steps and huge node_modules folders. But I'm struggling to see the benefits of Hibiki over the incumbent frameworks available.
[0] https://alpinejs.dev [1] https://jsbin.com/mifiwabuqa/edit?html,output
- handling cookies
fetch('https://example.com', { credentials: 'include' })
fetch('https://example.com').then(response => {
if (response.ok) {
// Response is 200-299
}
if (response.status === 404) {
// Status code specific handling
}
});
fetch('https://example.com', { mode: 'no-cors' });
fetch('https://example.com').then(response => response.json()).then(json => {
// Do something with a parsed JSON object
});
With that said, I've not used $.ajax in anger for a good long while so I may be missing out, particularly as I note there have been API changes in newer versions of jQuery. Are there some specific use cases that you've found fetch to be particularly inept in dealing with?
I suppose my only counter left would be "is the UK market alone worth the complexity?" Having split off from Europe, and in-fighting among ourselves to the point where we may see the UK itself splitting up again in the next decade. Is it really worth adding additional complexity for a comparatively small market when companies could simply target the continent of Europe as a single market, regardless of EU membership, and probably reach a similar audience with a similar conversion rate.
I'm probably being overly cynical and only time will tell, but I just don't feel the UK alone commands the importance to have things its own way, so to me being lumped in with the EU as the lowest common denominator seems inevitable.
This is anecdata, so fair warning, but over the last year (at a guess) I've noticed many US sites, FAANG companies but also smaller sites too, all flashing cookie/data protection type popups at me where they didn't previously. I've assumed that's because they need to comply with the CCPA which came into force last year, though it's totally a guess. I suppose their geoIP tracking may've just improved and spotted I'm in a GDPR country.
When does this type of legislation reach a point of critical mass where the UK is simply behind the curve and most companies just show the popup by default?
From a development perspective, having a whitelist or varying set of conditions per country adds complexity, I could very easily see a development decision being made to use GDPR as the common denominator and just code once for that, knowing that'll cover the company globally. Sure if your business relies on tracking and serving ads, then you may accept the additional complexity to behave different for different countries, but it still becomes a development decision that didn't have to be made before, and it's one with diminishing returns as legislation on privacy tightens.
I've used sites like One Time Secret[0] before and one of the big benefits is that it's pretty fast to store the sensitive data, grab the link and send back to the colleague. Bitwarden Send looks as though you need to be logged in to the Bitwarden site, dig out the feature page among the rest of your password manager and fill out a whole form in order to get a link to send, which would add a barrier to entry for the whole process that wouldn't encourage its use.
Maybe it's just me. It certainly looks like a good feature either way.
As a vague counter point, I use Firefox Focus[0][1] which touts the tracker blocking and ad blocking I'd rely on extensions for normally. It meets my needs as the only additional extensions I use on desktop are for tab and session cookie management, both of which are moot points in a browser without tabs and a "clear cookies after each session" policy.
[0] https://play.google.com/store/apps/details?id=org.mozilla.fo... [1] https://apps.apple.com/gb/app/firefox-focus-privacy-browser/...
My impression is that the Firefox shell offered is still able to provide the various anti-tracking privacy features that many would point to Firefox for, and the variety of browser shells available should mean that you'd be able to find a UI to your liking if Safari's isn't.
At that point, the only thing I can see missing is a non-webkit engine. I get that that's an annoyance and definitely on the same anti-competitive level as 00s era IE, but by and large web developers account for it and it works acceptably. As much as I'd need it to for mobile browsing.
Would just be interested to know if there's something more I'm missing.