allover

Presumably because the icon will be shown on high-dpi displays (retina screens etc), no?

The problem is that such a browser wouldn't be any use to users in the short-term, because most of the web simply wouldn't "work" in it.

So, I don't think it's developers that are the problem. As a web dev myself, I'd much rather have less, mostly unnecessary, complexity to deal with, but I can't see a rational path towards that.

The counter argument would be that git is the poster-child of poor UX, which could be blamed on the fact that it exposes too much of its internal data structure and general inner-workings to the user.

I.e. too much focus has been put on data structures and not enough on the rest of the tool.

A less efficient data structure, but more focus on UX could have saved millions of man hours by this point.

Parent is simply referring to the front-end skill of building an app with rich client-side state that isn't persisted to a backend DB.

> large React applications tend to be just as heavyweight and hard to understand as Angular ones once you need a router, state manager, and 20 or 30 other "compact" libraries to do what you're trying to do.

I largely disagree with the comment you're replying to in its oversimplification of things, however, this simply isn't true. 'Create React App' plus 'React-Router' is literally all you need for the vast majority of applications.

And you don't need "20 or 30 other compact libraries", unless what you're doing is specialised and requires them.

The idea you need "a state manager" is an unfortunate fallacy, due to React/Facebook's history by accidentally implying a Flux-like solution should be added to augment React, when in fact so much more could be achieved by simply following React's component model, and React's built-in mechanisms for managing state.

Exactly - the innerHTML approach doesn't work for component composition and it completely fails for things like forms, where you will blow away form input focus/cursor state etc.

This was a stumbling-block of the fairly simplistic predecessors to the React/Angular generation - like in Backbone.js if you chose to implement 'render()' in such a naive way.

> Or am i missing the point completely

Sort of. These are ways you can built web components today with modern conveniences that some of these _libraries_ (not frameworks), might lend you.

The site isn't claiming these different approaches can all be used together on one page in a practical way.

Technically you could, but it would have the obvious downsides you mention. This is just the reality of the limitations in the standards today.

So it's not secure by default.

I think you're being downvoted because other things being insecure is not relevant or an excuse.

When you say "this is squarely a Debian issue", do you mean "in his opinion", or that you agree?

So the app is vulnerable by default, yet the author is claiming this doesn't matter, because he instructs how to run it in a safe way?

Correct, or am I oversimplifying/missing something?

Very interesting optimisations, but I would not say the author "missed" these points, since this wasn't the point of their post.

There absolutely is a cookie law. The UK legislation is "PECR" [1] which sits alongside the GDPR.

> PECR are the Privacy and Electronic Communications Regulations. Their full title is The Privacy and Electronic Communications (EC Directive) Regulations 2003.

> They are derived from European law. They implement European Directive 2002/58/EC, also known as ‘the e-privacy Directive’.

> PECR cover several areas:

> The use of cookies or similar technologies that track information about people accessing a website or other electronic service.

See "How does this fit with the GDPR?" for how the two relate, tl;dr:

> The GDPR does not replace PECR, although it changes the underlying definition of consent. Existing PECR rules continue to apply, but using the new GDPR standard of consent.

[1] https://ico.org.uk/for-organisations/guide-to-pecr/what-are-...

Parent edited their comment from "can" to "can't", and I got downvoted, yikes.

This is not correct, in the UK at least. Similar technologies like LocalStorage fall under cookie law. [1]

[1] https://ico.org.uk/for-organisations/guide-to-pecr/cookies-a...

If you're genuinely confused, I assume they missed out the word "selling" before "software".

To be fair it does perform better than everything else, which is why people are so forgiving of it, but it still doesn't excuse their ineptitude on privacy and security.

tl;dr of your comment is "I don't care about privacy, if the product works".

But privacy is not about those privileged enough to where privacy doesn't matter.

I don't care that you don't care. Privacy matters.

Of course, but that suggests Apple isn't smart enough to know this and hasn't sufficiently anonymised the data, which is pure speculation?

You're assuming malice over incompetence.

Having heard mainly "nothing but guff" justifications for microservices in non-enormous orgs, I think (as usual, and some law I forget dictates) the latter is more likely.

> it should be opt-in, not opt-out

Sure, it would be nice if no company ever shared data with any other company, but that does not track in this case.

People signing up for an Apple branded Goldman Sachs credit card shouldn't be surprised or affronted by the fact Goldman Sachs gets anonymised data from Apple.

Why the hell anyone would sign up for this crap is beyond me. But it's not a reason to drag Apple into the context of a thread about a company guilty of basic privacy failures -- sending personal data to a 3rd party social network the user has no connection to.

Please also understand what 'anonymised' means, it means _not reversible_ i.e. you _cannot_ tell who the user is.

Opt-out of sending anonymised data, to the company providing the credit service.

I'm not sure you read the article you linked to properly:

> Apple is changing the privacy policy for Apple Card with iOS to share a richer, but still anonymized set of data with Goldman Sachs in order to allow the creation of a new credit assignment model, which could expand the group of users that may be able to secure credit. > There is also a beefed up fallback method in the works that will allow users to share more personal data on an opt-in basis with Goldman Sachs if you do not at first get approved

So anonymised by default.

Opt-in, IF you want to share more personal data.

Do you also understand it's Goldman Sachs that run the credit cards, accounts, etc, they're not just randomly sharing data with Goldman Sachs?

Context matters - we're not talking about making arrests here.

Are you in China? Could you explain/give context to the violence shown here: https://twitter.com/AF632/status/1238704923417575424

You are conflating unrelated things.

Using a framework like tailwind does _not_ affect whether your actual HTML elements are semantic, which is what would affect accessibility.

In the context of Tailwind though, the situation isn't really "that".

Tailwind allows you to "feel" like you're just quickly prototyping, without afaict compromising maintainability at all.

If you're concerned about the ability to reuse an HTML fragment and associated styles (or just a bunch of styles), they have decent docs on that: https://tailwindcss.com/docs/extracting-components/

I know what 'bait and switch' means, just like I also know what FUD means.

Next you'll call them Micro$oft. Come on now.

That's a fair point - thanks for the reminder :|

It's true insofar as VS Code is widely loved by web developers.

So it "furthers my intended point".