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.

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