Ruphin · HackerTrans

3 дня назадdiscuss

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.

Ruphin

9 месяцев назадdiscuss

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

Ruphin

10 месяцев назадdiscuss

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.

Ruphin

10 месяцев назадdiscuss

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.

Ruphin

10 месяцев назадdiscuss

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.

Ruphin

10 месяцев назадdiscuss

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?

Ruphin

10 месяцев назадdiscuss

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.

Ruphin

10 месяцев назадdiscuss

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.

Ruphin

10 месяцев назадdiscuss

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

Ruphin

10 месяцев назадdiscuss

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/[email protected]/index.js?module

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

Ruphin

10 месяцев назадdiscuss

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.

Ruphin

10 месяцев назадdiscuss

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?

comments