22.02.2026 12:49
👍 0
🔁 0
💬 0
📌 0
This reminds of the work the @e18e.dev community is working on. I love it!
bsky.app/profile/ryan...
Ah, that makes more sense. Thanks for the clarification.
Why would that be an issue?
That's a good question. As long as the timeout is short it shouldn't affect it, but I'll have to play with it.
For the reasons I listed above. We've created special tooling around injecting DSD into the page rendering lifecycle and acted like we've fixed SSR. We've just slapped a big, complicated bandage on it - especially for things like design systems.
bsky.app/profile/stuf...
That's a really cool idea! A pain point for some of the knowledge in these private servers is that it's not always easy for the general public to find. I wonder if there's a way to surface that content for SEO.
Yeah, I hate jumping into type declarations. This seems way nicer.
Are teams using #TypeScript declaration maps to provide a better go-to-definition experience for developers?
I've used source maps, but I don't think I've provided declaration maps.
#SoftwareEngineering #Programming
Hahaha! If I was using something like @webawesome.com, would it be beneficial to have the go-to-definition behavior?
Even if it's minified?
What if it's uglified?
I've also found going to the type definition is not very useful for me most of the time.
That's a good point. Would the class be useful if it were uglified?
I don't plan on overriding what JS frameworks do. I'm really asking about things like plain HTML or other templating languages like .NET and PHP. Those don't typically have type systems or property binding.
Frameworks typically use their own type system and have bespoke behavior for the go-to-definition.
...or do we need anything? Standard HTML doesn't do anything.
That's a good point. In HTML, we can't really use props in the markup.
I have not seen that problem. Can you provide an example?
When you are in an #html file and you want to go-to-definition for a custom element, what do you think the behavior should be? Should it go to:
- type definition
- JS file where class is defined
- CEM entry
- something else
#webcomponents #javascript
These are not linking to an external style sheet.
That adds another layer of complexity because even if you "style them into existence", it results in layout shifts as they are rendered.
You are correct. It has since been improved.
dev.to/stuffbreaker...
I haven't played with it very much, but I don't think so.
In some cases it could, but I don't think it would for lazy-loaded components.
For many of our use cases that's not an option because components are lazy-loaded, but I do agree that that can be a good idea - especially for smaller components.
Here's what I've settled on. It seems to work pretty well so far.
dev.to/stuffbreaker...
You will still see FOUC before the component is defined and applies the stylesheet.
True, but most of my components use JS, so there will be problems anyway. 🤷♂️
