shrew

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?

Ah, my lack of knowledge rather than a bug then, my bad! Thanks for explanation!

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!

Interesting, I’ve never seen this, thanks!

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.

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

Ah that last point really struck a nerve.

- 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.

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.

Or as part of display: grid which also has severe quirks with position: sticky despite it being a much newer API.

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.

As far as I've seen, what killed it was the issue that Angular "v2" was so different from Angular.js (v1) that the upgrade path simply wasn't there. Eventually an upgrade path emerged where a page ran both a bulky Angular.js app AND an Angular v2 app, but it wasn't good enough. By then, React (and to a lesser extent Vue) were looking far more interesting so many teams made the decision that if they had to rewrite their app, they may as well write it in something that has a large community around it and was seen as the "latest and greatest".

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.

I appreciate React and Angular are difficult to get going without some sort of build step (React can do it, but not JSX, so it's not optimal), but Vue has always made it very easy to start right in the browser. AlpineJS[0] is newer on the scene, but it also focusses on doing exactly what Hibiki is trying to do with a much smaller API surface area.

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

At a guess, they're probably sticking with it because it enables Javascript/Typescript as an interfacing language for plugins which, given the language's popularity and cross-platform nature, is probably part of the reason the plugin catalogue is so large.

I'm genuinely curious to know what you find severely lacking in fetch compared to $.ajax.

- handling cookies

    fetch('https://example.com', { credentials: 'include' })

- HTTP status codes

    fetch('https://example.com').then(response => {
        if (response.ok) {
            // Response is 200-299
        }
        if (response.status === 404) {
            // Status code specific handling
        }
    });

- CORS

    fetch('https://example.com', { mode: 'no-cors' });

- JSON handling

    fetch('https://example.com').then(response => response.json()).then(json => {
        // Do something with a parsed JSON object
    });

I've used all of the above patterns regularly for several years now and never found any of them particularly cumbersome and certainly not lacking feature wise. If async/await syntax is available to you, it's even more succinct than the Promise style above.

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?

Very true, for a big company, the time may well be worth it, particularly for the likes of FAANG where they have UK branches of their company.

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.

Okay, fair point, they might just re-include the UK in whatever exclusion list they have and that'll be that. But since GDPR came into force, others have followed suit, several other countries have begun implementing similar legislation.

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.

The promise of this is great and being a feature of Bitwarden, which is already fairly well trusted, is a plus in terms of peace of mind. But did anyone else find the demonstration a bit underwhelming?

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.

[0] https://onetimesecret.com/

Ah this is the best bit! Because many companies cater for a global audience, us Brits will STILL have to endure the stupid little popups AND we'll have no protection or recourse from privacy invasion! Can't wait! /s

Gotcha, that's completely fair and not something I'd considered. Thanks!

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/...

Honest question: is it simply the fact you can't use a Gecko engine on iOS that makes it useless to you?

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.