> Nearly half of Claude usage in India comprises computer and mathematical tasks: building applications, modernizing systems, and shipping production software.

I hope CLoudflare or another tech company buy deno. Deno is great, its lacking a big brand sponsorship.

Cloudflare are neck deep in v8 as their js runtime of choice. I doubt they'll be looking for another any time soon

Honda and few other have launched swapable battery vehicles in India too

I am using Antigravity with claude sonnet/opus 4.5. I still try to write front end components to give it some personality, AI is using same design/animations for everyone

Curious what are some better options. I feel it is completing with Jenkins and CircleCI and its not that bad.

Bazzite also mention

> improved CPU schedulers for responsive gameplay,

on their homepage https://bazzite.gg/

Oops you're right, I was searching the docs and couldn't find it, maybe it's time to snoop around in their repo...

You can use any sched-ext scheduled on Bazzite.

I am highly skeptical that we will see AI pay for itself by the end of the decade.

More likely Americans’ tax dollars will be shoveled into the hole.

Then it isn't a viable business. Find another path that doesn't risk crashing the economy.

Everyone like to shit on node/nextjs ecosystem. Developers are putting real effort to improve though. JS tooling is moving to rust, node is adding high level APIs so we should need lesser third part libraries.

I have an idea, also replace JS with Rust, don't stop at the tooling.

Kind of interesting how the scripting languages that were all the range in 2010 as replacement for Java, C#, are now being rewritten in Rust, Go, C++, Dart after crumbling in performance issues.

Why are you excluding C# and Java here? There are certainly many rewrites to these languages, but this kind of rewrites are "boring" for the crowds here and don't get the spotlight. IMO building web services with Rust, C++ is a almost always a wrong choice.

Because that isn't what cool kids in JavaScript ecosystem are flocking to, that is their parents languages.

Myself I will keep using C# and Java as long as I can in the middle of all this AI craziness, see my profile.

There're people working on all bad software, scammers also work hard. We should not reward them in anyway tho.

I personally did not see too many posts about cloudflare. Even if there were those did not get upvoted. Not sure what the issue is

Curious which web platform features are missing that are preventing Web components to complete with React(for application development not widgets)?

I think web components already compete extremely well for application development, and you see very complex apps built with Lit out there: Photoshop, Firefox, Chrome OS, Chrome DevTools.

Apps are well served because they have more control about how components are used: they can import the same shared styles into every component, take are to not double-register elements, etc.

But I think there are some important standards still missing that would open things up even more in the design system and standalone components side:

- Scoped custom element registries. This moves away from a single global namespace of tag names. Seems like it's about to ship in Safari. Chrome next.

- Open styleable shadow roots. Would allow page styles to flow into shadow roots. This would make building components for use with existing stylesheets easier.

- CSS Modules. Import CSS into JS. Shipping in Chrome. About to land in Firefox.

- ARIA reference target: make idref-based reference work across shadow roots

> - Open styleable shadow roots

What people using web components want is to get rid of shadowDOM and not feel like they are deviating from the correct path. shadowDOM sucks, stop trying to convince the world that we are using it wrong. shadowDOM is the whole reason web components did not become mainstream (yet?).

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

But that is quite the important feature lacking.

In my mind this has always made no sense to me, why slots aren’t independent of the shadow dom.

Same thing with how css is handled, especially since we have @layer and @scoped now

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.

I disagree completely. Shadow DOM is a huge help and when combined with per-component CSS using the :host() and nesting pattern, makes for very small CSS files and very short CSS class names. In other words, as far away from Tailwind as you can get.

It's also possible to import shared CSS in a base class and add it with super.styles() so you don't lose anything.

What about shadow dom sucks?

How else do you achieve that level of encapsulation to enable portable components?

You don't want to enable portable components all the time. If most of the components you use to create your app is made by yourself, those boundaries are annoying, not helpful.

The point is you mostly don't want this level of encapsulation

Please do not refer to CSS type imports in JS as CSS Modules.

CSS Modules has an established meaning for over a decade, one that is still relevant today. The CSS type imports are very different, and arguably worse.

Call them CSSStyleSheet imports of you need a name suggestion.

About CSS Modules – Are you referring to this? https://caniuse.com/mdn-javascript_statements_import_import_...

Seems like this feature was removed from Chrome.

Import assertions were replaced with import attributes (`assert` replaced by `with`).

See https://caniuse.com/mdn-javascript_statements_import_import_...

>- ARIA reference target: make idref-based reference work across shadow roots

How is this even supposed to work if each shadow dom has it's own scope of ids? `#id#subid` or something?

What if I want to ref to the outside?

The whole thing is not made for web development.

You can start with the Web Components Community Report: https://w3c.github.io/webcomponents-cg/2022.html

Or with opinions like this: https://dev.to/ryansolid/web-components-are-not-the-future-4...

O if you want to go down the technical rabbit hole, you can search for all the issues people have with them, e.g.: https://x.com/Rich_Harris/status/1841467510194843982

Another pain in the ass is the fact web components are registered globally. Good luck marrying this with npm dependency hell where two transitive dependencies both import a button.

The good part of react and friends is it's just javascript and the class is imported and referenced normally, not with a weak string-binding-through-registry kind of way.

Now add types to the mix and shadow dom and it brings constant problems without any upside.