Why would big tech be in favor of having to scan message content? It puts more regulatory requirements in place on their activities. Would they not be in favor of _less_ regulation so they can provide services to their users with fewer legal considerations?
If big tech _wanted_ to they could already backdoor their encryption and scan the message content, they don't need regulation to do that. The only thing that changes with regulation is that they now _have_ to, which cannot possibly be in their favor.
The effective tax rates on high income individuals is likely much less. There is a large correlation between income and wealth, and wealth increase through asset appreciation is largely not taxed, or at best taxed at much more favorable rates than general income tax.
Tax on income is not the problem, it's tax on wealth gained through asset value increase.
I am pretty certain that if you are in an org where c-suite shifts reasons for negative results to external sources, they will find a way to do the same in the age of AI.
Nothing in Web Components is forcing you to use ShadowDOM. Lit also allows you to make components without ShadowDOM if you prefer, because there are certainly cases where it can be necessary to do so (like for ARIA reference id-matching). For full single application development, it can feel like it gets in the way a lot, and you can make a good argument to use components without ShadowDOM in those contexts too.
All frontend "frameworks" do have some sort of solution to scope CSS to individual components, and without a similar solution, a native component system would not be viable. The implementation has its quirks, but it is a core capability that is necessary for some use cases. For third-party widgets or cross-application components like design systems, the ability to isolate your component from the site it is embedded in is very useful.
Think of shadowDOM as the web component alternative to scoped styles in Vue components (as an example). You don't have to use it, but it would be incredibly inconvenient if it wasn't included in the framework.
Vue _does_ have some sort of build step, because components use special macros that aren't imported, and the compiler (vite) even complains when you actually import them saying it's not necessary. The build also rewrites your code to some other format that I assume is more optimized because it can do some sort of static analysis.
Are these the main reasons for Vue to use a compiler if it's not necessary? Injecting dependencies and rewriting some code to allow better performance while retaining the nice syntax?
Re-implementing Lit from fundamentals is a great way to learn how it works! The core functionality is surprisingly simple, because it mostly relies on platform APIs to do the heavy lifting, like parsing templates.
I made this alternative implementation of lit-html to use as a research bed a long time ago when I was actively contributing to lit: https://github.com/ruphin/lite-html
Judging from this thread, many people have their own implementations, which is great to hear. I think there's a lot of value in solutions that are so simple that anyone can reproduce them.
I estimate the vast majority of "web projects" begin with npm installing something of some sort, yes. React is dominating the web development space (judging from the average "popular web stack 2025" search result), and it and a significant portion of the competing platforms start with installing some dependencies with npm (or yarn, or what have you). Especially projects that compete in the same space as Lit.
That isn't a criticism of projects that don't use npm, and it doesn't make them less valid, but it makes sense for the documentation to match the average developer's experience.
I guess for most people the standard is to install things from NPM which explains the format of the documentation. If you want to do something completely raw, you can replace 'lit' with something like this:
I don't know if there is a particular benefit, it's just different. On the consumer side there is no difference, because they consume Web Components, and that is what both solutions deliver. On the implementation side, I can think of a few differences:
Vue is more of a "framework" solution and has more things built-in. You can do the same things with Lit, but the implementation would look different, because you'd lean more on native APIs. A good example of that is the event model, Vue has some event model built in, but with Lit you would use EventTarget.dispatchEvent().
Lit is a runtime solution, it doesn't require a build and you can load your source directly in the browser. Vue on the other hand requires some form of compiler stage to produce something your browser can use. Compilers these days are fast, and Lit is specifically engineered to not have runtime performance overhead, so in practice this difference is rather minor. It is a very fundamental difference, so I think it's worth pointing out.
Vue can compile to other targets. If you are only delivering Web Components, this is mostly irrelevant, but in theory a consumer might be able to use the Vue components directly in their Vue project, which might give them a better DX. On the other hand, Lit is specifically designed to produce Web Components, so you'll probably have a bit less friction compares to using Vue, e.g when some Vue concept doesn't compile cleanly to Web Components.
Is there a major benefit to choosing one implementation over the other? I don't think so, unless you have a very particular requirement that one of them addresses that the other doesn't. For nearly all cases, it is just a different implementation syntax.
In most cases the only relevant metric in deciding between them is what technology your developers are more familiar/comfortable with.
Web Components is a pretty niche technology and as such it really appeals to some people, and it doesn't appeal to others, and that's okay. You don't have to like it, it isn't meant to be a good fit for everyone. But for some people it might fit really well with their requirements, and they probably have legitimate reasons for that.
If I understand correctly, your criticism is that the people for whom Web Components is a good fit are publicly discussing the reasons why they prefer it over other solutions?
There is a simple intuitive explanation for how an "infinite" game is possible:
We can define two different sequences of three characters that start with 0 and end with 1: 001 and 011. Because they each start and end with a different character, we can never create a series of three characters by chaining two of these sequences.
Now we can go one step deeper and encode the "001" sequence as 0, and the "011" sequence as 1. We can generate our 001 and 011 pattern again, but with our encoded versions of 0 and 1, giving us these sequences: 001001011 and 001011011. These sequences again have the same characteristics, they start and end with different sub-sequences (001 and 011) so they can be chained without creating a series of three sub-sequences.
We can now use these larger sequences and encode these as 0 and 1, and so forth ad infinitum.
That sort of response seems not too different from the classic "let me google that for you". It seems to me that it is a way to express that the answer to the question can be "trivially" obtained yourself by doing research on your own. Alternatively it can be interpreted as "I don't know anything more than Google/ChatGPT does".
What annoys me more about this type of response is that I feel there's a less rude way to express the same.
This is factually incorrect. Even though in most European countries there is a formal separation of religion and state, there is nothing that "forbids" any political party from having a strong religious affiliation. In fact, in nearly every European country there are major political parties with a strong Christian affiliation. See: https://en.wikipedia.org/wiki/Christian_democracy
There are even countries which have political parties that are Islamic affiliated.
The separation between religion and state refers to two things: the state not being able to enforce any religious aspects on citizens (freedom TO exercise any religion without interference from government), and religious entities not being able to influence or pressure the government outside the electoral process (freedom TO govern without interference from religious entities). Neither of these things prevents a political party founded on religious beliefs to participate in the electoral process.
Are you suggesting that Germany is not "free" to choose to have economic relationships with e.g. Russia because of United States military reasons? Do you think the US military is the primary reason Germany (the people, the government) is reluctant to trade with Russia?
It really depends if you can find a (cryptocurrency) exchange that lets you withdraw to a bank account in Costa Rica. If you can find one, you don't even need stablecoins. The way it will work is
US Bank -> Deposit USD to US cryptocurrency exchange -> Trade USD for Bitcoin (or some other crypto that has cheap transfers, it doesn't really matter) -> Send Bitcoin from US cryptocurrency exchange to Costa Rica cryptocurrency exchange -> Trade Bitcoin for USD (or local currency) on Costa Rica cryptocurrency exchange -> Withdraw to Costa Rica local bank
Theoretically, all of these steps can be done with less than ~$1 in fees. My banks and exchanges let me deposit for free and withdraw any arbitrary amount for 50 cents. Sending any arbitrary amount of cryptocurrency should be cheaper than that. The big question is if an exchange exists that lets you withdraw to Costa Rica banks, and what they charge for that.
There is no fundamental difference between Chess and Tic-Tac-Toe other than the computational complexity. It is not feasible to compute all of the game states in Chess, and so we cannot determine (at this time) a single optimal strategy the same way we can for Tic-Tac-Toe. But that does not imply that it doesn't exist. From a pure game theoretical perspective, they are the same category of game.
If there are more than 3 strategies, the same argument stands. IF there are multiple "optimal" strategies, AND these strategies create different "optimal" moves on the same board state, the opponent can just play the optimal counter-strategy after you make your move, because your move is enough information to give away your strategy. If your opponent cannot determine your strategy after you make your move, that implies the different strategies have the same "optimal" move.
There is no hidden information and turns are sequentially. This means both players have full access to all information, and that implies there must be a single "best" move. If the board is at a certain state and one player is to play next, the strategy of the opponent is irrelevant for determining the optimal move.
Proof:
Suppose that it is possible that different strategies exist that outperform each other. Lets consider the case that there are three "optimal" strategies that counter each other, call them Rock Paper and Scissors. Since these are the three "optimal" strategies, both players know the exact move produced by these strategies. The first important part to note is that there is no cost to changing strategy during the game. If an opponent has one fixed strategy, say Rock, the "optimal" strategy is to change your strategy to Paper. Since you have full information on the state of the board, you do not have to guess the strategy of the opponent, because there is no hidden information. Now you could consider the opponent strategy to be hidden information, but this doesn't hold for the following reason: If knowing the opponent strategy would alter your choice of move (by for example changing to Rock that specifically counters his hidden Scissors), the opponent can freely change to Paper after you made your move, because he can see that you changed to Rock before making his next move. If it was impossible for the opponent to tell that you changed your strategy, that implies that each strategy produces the same board state, and that implies the strategies are identical.
Big kudos for building things from scratch. Even though it's not directly applicable in most jobs, the knowledge you have from understanding the entire "stack" helps a lot when using tools and frameworks, because you understand their value and cost.