j-f1

I’m not sure about macOS, but on iOS you can install the App Store Connect app (https://apps.apple.com/app/id1234793120) and then enable notifications for new reviews from there. ([app] → Notifications → Mobile → Reviews, [your initials] → Notifications → Customer Reviews)

There were a lot of changes made in the Swift 1–3 time frame as the team learned what it was like to write Swift at scale and developed a unique language style. That’s all done now, and Swift 5 code (released 2019) should continue to be compilable with few exceptions long into the future. It’s different enough from Swift 1 that it’s basically a different language though.

The biggest source-breaking change on the near-term horizon (which is still in progress) is compile-time enforcement of concurrency safety.

Looks like someone figured out how to use Svelte inside of Observable a while ago — see https://observablehq.com/@ajbouh/svelte-experiments

There were security vulnerabilities a while ago that resulted from people being able to upload React-element-shaped JSON objects in certain places strings were supposed to go. IIRC this allowed for XSS, so React added a special symbol (the $$typeof key) that would have to be imported somehow in order to add it to the plain objects.

For #1, check out JSON Feed (https://jsonfeed.org/). It’s at least supported by Feedly, and it’s probably supported elsewhere too.

> that’s why some content authors, like Daring Fireball’s John Gruber, as an example, only provide their full RSS feed to paying subscribers

This is false. I am not a paying subscriber, but I still get the full content of Daring Fireball articles in my RSS reader. In fact, the RSS feed is one of the links on the site’s sidebar. https://daringfireball.net/feeds/

I’m guessing it’s the Dat Protocol → https://www.datprotocol.com

Fortunately, if you use Prettier to format your JSON files too, it’ll quote unquoted properties and remove trailing commas: https://prettier.io/playground/#N4Igxg9gdgLgprEAuEwA6UAEmDOE...

This is actually quite challenging because the template language allows you to insert template tags into any location in the template file, and while people usually put them in reasonable places, there’s no guarantee. For example, someone could do a thing like `{{ less_than }}div class="foo">abc</div>` and that would be totally valid but a nightmare to parse.

That’s different from a more structured template-style language like JSX, where there are only a few valid places to embed JS expressions so it isn’t too challenging to make them all look good.

There’s https://github.com/jhipster/prettier-java, which expands Prettier to work with Java, but I’m not sure how complete or thoroughly-tested it is. It also requires that you have Node installed, which could be be a downside for people who only work with Java.

This isn’t really possible due to Prettier’s design, unfortunately. It basically lays out each statement on one line until it gets to the maximum width, then tries a variety of ways to break the line until it’s under the limit.

We also don’t want to look at how the code is formatted coming in because one of Prettier’s goals is to make sure everyone’s code looks the same, which wouldn’t be possible if we looked at how the input is formatted too much.

Isn’t this true of any client side site? If the client side JS has access to some information, it’s always possible for the server to inject custom JS that returns the data. Theoretically this setup provides little additional security but it does allow (for example) people to use a client pinned to a version they’ve verified to not leak information and collaborate without worrying about leakage. (Excalidraw developer here)