Ruphin

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.

One of my favorite ambigrams is the title logo from an old 1995 PC game classic, Tyrian. It's so subtle I never realised until a few years ago.

You can find the logo here, along with the excellent soundtrack: https://alexanderbrandon.bandcamp.com/album/tyrian-original-...

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?

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.

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

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:

https://unpkg.com/lit@3.3.1/index.js?module

You can even dynamically import that in the a running browser console and use it directly on any webpage.

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.

A tree is a subtype of a graph, but it is not the same as a DAG. A diamond-shaped directed graph (edges A->B, A->C, B->D, C->D) is a DAG, but not a tree.

Very interesting. From playing a single game you immediately notice that traditional chess theory doesn't apply to this game at all. After some testing I found a few things in particular that change the way the game plays out drastically:

When having two pawns adjacent one of them can still defend the other by having it only slightly behind. They can also alternate defending each other with a single move. Pawns can also attack/defend things directly in front of them by pushing up against them. These things combined mean that it's almost impossible to have any pawn weaknesses, other than having a singled out pawn with no neighbors. In general pawns are the most improved piece with this ruleset.

The ability to move directly forward makes knights significantly stronger. Knights ability to move through other pieces is also particularly strong versus pawns which can now block most pieces from moving around quite easily.

Since pawns generally mainly move along one axis, it is easier to control the distance between pieces in the forward-backward axis than in the left-right axis. This makes it harder to utilise Rooks to capture two adjacent pieces. Bishops on the other hand have an easier time capturing two adjacent pieces, if positioned correctly. I'm not sure this compensates for the fact that bishops now have a much harder time penetrating positions, they are the most easily blocked of all the pieces.

Overall it is very interesting as a chess variant, it plays so very different from chess. It's hard to even figure out reasonable openers.

If you would want to run a tournament for this you'll probably need a better client, potentially with built-in online play. I could be tempted to work on something web based, but it would take a while to finish.

If you like this kind of thing you should take a look at the suckerpinch channel on YouTube. The technical complexity and amount of effort spent on some of his projects is quite unbelievable, with no practical use other than displaying the crazy things you can do with computing.

Particularly Reverse Emulating the NES and Harder Drives are good examples of this.

Look at the pictures of sample hands in the link you posted. From the position of the hand and fingers it's unlikely they are software generated, but they have the same "neat" aesthetic as the other pictures.

I think what you're seeing is just pictures taken by someone with attention to detail.

With Ethereum no longer in the game the total USD issuance for GPU mining probably dropped over 80%. Is your strategy to just wait out for miners to capitulate until mining is profitable again? Are you not worried that this will crater the value of your hardware?

For context, electricity costs in some places in the EU are currently at $0.8/kWh (including taxes and other costs). The war significantly inflated these numbers, last year they were around $0.3/kWh.

Proof of Stake and Proof of Work only impact the consensus model of the network (i.e. how new blocks are added), but for network participants that do not participate on consensus there is no difference. Just like in Bitcoin or in Ethereum now, you can run a node without participating in mining or staking.

If you run an Ethereum node now, it will still be the same after the Merge, and not somehow less valid. It will still check the correctness of all the transactions, as it does now.

I think a large cause of this confusion is the "validator" terminology; calling nodes that produce blocks through staking validators makes people think that normal nodes don't validate or check anything, but this is not correct.

Making it illegal to have Bitcoin is not very easy.

What you call a "self-hosted bitcoin wallet" is just knowing some combination of bits that happens to be the private key that gives you the ability to sign transactions for some Bitcoin. How do you make it illegal to know something? What if I tell you my private key, does that mean you are then suddenly violating payments laws? What if you stumble upon it by accident?

Technically any string of 32 bytes is a valid private key that can hold Bitcoin. There just might not be any Bitcoin in the address associated with it at this time. What if I "know" a random string of 32 bytes, am I then suddenly in violation of laws when someone randomly deposits Bitcoin to the corresponding address?

The legal difficulty is that the action of having or holding Bitcoin (or mostly any cryptocurrency) is something that has no physical representation and is purely information based.

Mining or making transactions is a different story altogether. These require, amongst other things, that you send specific digital information across the internet which is certainly something that can be made illegal.

A technique similar to what you described is sometimes used in graphics engines for games. It's generally referred to as "motion blur". I think what the engines actually do is determine if an object has a velocity relative to the camera, and apply a stretch and blur effect on the object based on the direction of movement. This is relatively cheap (don't have to render many times times per single frame), but comes with a downside that the blur effect "overshoots" which can look weird when an object suddenly decelerates.