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