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.
That is why you have capital gains, which is ~30% in France.
Investment income is flat taxed.
And inheritance taxes, which are very high in France.
If you want to increase taxes, consider taxing income more and capital gains at a progressive rate. Although I haven't seen good data on effects of say a 70% capital gain tax, might hurt th,e economy. I did some reading on this subject last month and the sweetspot was around 20% to 35% on that classification of income.
Do you want to take people's wealth and cap it? IE, nobody is allowed more than $5 million? What are you advocating for instead?
First, wealth tax doesn't work because it requires a ton of work to decide what constitutes "wealth," and then you have to carve out so much crap. The only wealth tax that currently works well is on real estate, as it doesn't move, and the state already taxes that.
For example, how do you tax a private business? In Spain, for example, it is a big carve-out, which leads to people never selling a company, which hurts their economy as you have tons of zombie companies. Or what people do is they take their money and buy apartments and rent them out on Airbnb, wrap them in a business, and get around the wealth tax.
The most effective way to tax wealth is to tax income, capital gains, and inheritance effectively.
But, lets say you can wave a magic wand and tax wealth (France already taxes real estate with a wealth tax + property tax).
What would a 2% yearly wealth tax raise? Maybe 15 to 25 billion a year in France, so it does nothing.
Total French private wealth is around $15 trillion (https://en.wikipedia.org/wiki/List_of_countries_by_total_pri... ), French government spending is around $1.8 trillion/year. Even if the French government were to expropriate the entirety of private wealth, it wouldn't even be enough to cover 10 years of spending. Fundamentally the French economy isn't producing enough to support the current level of spending, due to a continuously falling ratio of workers to retirees.
> Even if the French government were to expropriate the entirety of private wealth, it wouldn't even be enough to cover 10 years of spending
America's $6.75tn budget [1] would blow through our $140tn private wealth in 21 years. Even Norways $0.11tn budget [2] blows through its $1.6tn of private wealth in 14 years.
Perhaps the better metric is deficit as a fraction of private wealth? If that looks unsustainable, the problem is in publicly-held assets and services.
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.
> Nothing in Web Components is forcing you to use ShadowDOM
Yes. There is just one thing forcing someone to use shadowDOM: slots. You can't use slots without shadowDOM or at least use something like this.children to capture the content inside the <custom-element></custom-element>.
It's not possible to make slots work without a separate tree like shadow DOM. The browser can't tell what the container for a slot is vs what content should project into it.
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 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 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 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.
Vue can be used as an ordinary JS library without special build setup. You can even load the library from a CDN as a global variable like the old jQuery days.
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?
Tree shaking, that is removing code that is not used.
Bundling several files into one to save on requests.
Transpiling, that is, if you want to write code in a different language to javascript eg. Typescript then vite will compile that to javascript.
Linting ie. Reformatting your code to standardise it across developers.
Vulnerability checking, are your dependencies out of date?
Execution of build tasks eg. Preparing static assets like images.
Packaging your app for deployment eg. Zipping
Including logging and hot reload triggers during development.
Bundling environment specific changes eg. Different backend urls if deploying to test envs.
Running unit tests on rebuild to avoid regressions.
Having said all that, the bundling for me is a disadvantage as my own code changes more than 3rd party libs and they are cached. I'm less fussed with types and a lot of the tests and env stuff can be done with a single-file express server for development.
The main advantage for me is that a buildless app will still work correctly in 6 months- permacomputing considerations.
IRRC Vue will compile your templates on the fly if you don't pre-compile them, so you will be punished twice -- in performance and in bundle size for skipping the build step.
If you can eat the cost to get something in return, it's a nice trade off.
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?
The main problem is that for a "niche technology" it sure infects too many standards, requires an insane amount of new standards and makes supporting things needlessly complicated.
There are some good parts in the ~30 standards they require, but instead of just the good parts you get the whole horse, and the cart it's attached to, and the cargo in the cart.
> 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.
I guess it also hints at why the sequences keep getting smaller when you compress it several times (as mentioned in a footnote). Each compression peels away layers in this expansion. That’s my intuition at least.
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.
Let me google that for you is typically a sarcastic response pointing out someone’s laziness to verify something exceptionally easy to answer.
The ChatGPT responses seem to generally be in the tone of someone who has a harder question that requires a human (not googleable), and the laziness is the answer, not the question.
In my view the role of who is wasting others time with laziness is reversed.
The thing is, the magic robot's output can be wrong in very surprising/misleading/superficially-convincing ways. For instance, see the article we are commenting on; you're unlikely to find _completely imaginary court cases to cite_ by googling (and in that particular case you're likely using a specialist search engine where the data _is_ somewhat dependable, anyway).
_Everything_ that the magic robot spits out needs to be fact checked. At which point, well, really, why bother? Most people who depend upon the magic robot are, of course, not fact checking, because that would usually be slower than just doing the job properly from the start.
You also see people using magic robot output for things that you _couldn't_ Google for. I recently saw, on a financial forum, someone asking about ETFs vs investment trusts vs individual stocks with a specific example of how much they wanted to invest (the context is that ETFs are taxed weirdly in Ireland; they're allowed accumulate dividends without taxation, but as compensation they're subject to a special gains tax which is higher than normal CGT, and that tax is assessed as if you had sold and re-bought every eight years, even if you haven't). Someone posted a ChatGPT case study of their example (without disclosing, tsk; they owned up to it when people pointed out that it was totally wrong).
ChatGPT, in its infinite wisdom, provided what looked like a detailed comparison with worked examples... only the timescale for the individual stocks was 20 years, the ETFs 8 years (also it screwed up some of the calculations and got the marginal income tax rate a few points wrong). It _looked_ like something that someone had put some work into, if you weren't attuned to that characteristic awful LLM writing style, but it made a mistake that it's hard to imagine a human ever making. Unless you worked through it yourself, you'd come out of it thinking that individual stocks were clearly a _way_ better option; the truth is considerably less clear.
The issue is not truth, though.
It's the difference between completely fabricated but plausible text generated through a stochastic process versus a result pointing towards writing at least exists somewhere on the internet and can be referenced.
Said source may be have completely unhinged and bonkers content (Time Cube, anyone?),
but it at least exists prior to the query.
You can find the logo here, along with the excellent soundtrack: https://alexanderbrandon.bandcamp.com/album/tyrian-original-...