Ruphin

The build from Grok is completely broken on mobile, for what it's worth.

The situation in Iran has nothing to do with NATO really. It is a US initiative, and NATO was not involved in any way in decision making or policy.

If your political system does not present you with a candidate that aligns with your interests or beliefs, you should vote to change the political system. Not voting is consent to the status quo.

I hate to be that guy, but in this case I think it's appropriate to say that "Blockchain" solves this problem. The core idea behind Bitcoin and (some) derivatives is that it enables digital objects that cannot be copied and have a distinct owner. You are not wrong that from a technical perspective this is a very hard problem (digital objects are just bits of information, and there is no way to restrict making a copy of that), which is why some people felt like Bitcoin is a truly remarkable technical invention. But the practical side of it seems to problematic still (as far as I know there are virtually no successful uses of this technology in digital marketplaces outside speculation platforms)

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.

Oh nice, I wasn't aware this was even possible.

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?

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.

Obviously this wouldn't be suitable for (serious) production deployments, but it is a super accessible way to easily get started anywhere.

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.