wunderacle
@wunderacle.bsky.social
doing code at @HubSpot, some governance at the @openjsf, @webpack TSC; dabbling at @nodejs’s infrastructure
Trying my best ✨cool profile pics like yours help a lot 🫡
February 7, 2025 at 1:48 AM
Trying my best ✨cool profile pics like yours help a lot 🫡
node:pdf when? (Just kidding)
February 7, 2025 at 1:45 AM
node:pdf when? (Just kidding)
I appreciate the care here :)
January 28, 2025 at 1:33 PM
I appreciate the care here :)
Oh yes, sorry, what I meant is, a CLI flag to disable the warn at build time :)
January 27, 2025 at 4:02 PM
Oh yes, sorry, what I meant is, a CLI flag to disable the warn at build time :)
I see. I wish there was a way to remove the warning 🙈
January 27, 2025 at 3:36 PM
I see. I wish there was a way to remove the warning 🙈
Well, yes and not. Again, Next also contains a lot of powerful things out of the box. There is also Nextra nextra.site which is exactly like 11ty but based on Next.js
Technically speaking both 11ty and Next.js are huge busses; They have a lot of stuff under the hood.
Technically speaking both 11ty and Next.js are huge busses; They have a lot of stuff under the hood.
Nextra – Next.js Static Site Generator
Build fast, customizable, and content-rich websites with Nextra. Powered by Next.js, it offers seamless Markdown support, customizable themes, file conventions, and easy integration with MDX, making i...
nextra.site
January 27, 2025 at 11:33 AM
Well, yes and not. Again, Next also contains a lot of powerful things out of the box. There is also Nextra nextra.site which is exactly like 11ty but based on Next.js
Technically speaking both 11ty and Next.js are huge busses; They have a lot of stuff under the hood.
Technically speaking both 11ty and Next.js are huge busses; They have a lot of stuff under the hood.
Although, Vercel themselves say that most scenarios you shouldn’t need static exports… Next.js is after all a server-first framework.
January 27, 2025 at 4:44 AM
Although, Vercel themselves say that most scenarios you shouldn’t need static exports… Next.js is after all a server-first framework.
I still recommend Next.js. It does has a static export mode, and it works fine for GitHub pages and other self hosted options, although I always recommend the usage of rewrite rules as they will be needed to handle the .html to extensionless rewrite.
January 27, 2025 at 4:43 AM
I still recommend Next.js. It does has a static export mode, and it works fine for GitHub pages and other self hosted options, although I always recommend the usage of rewrite rules as they will be needed to handle the .html to extensionless rewrite.
We aint bundling components. The UI packages will just have the raw components. There is no reason to add a bundler there.
January 26, 2025 at 1:39 AM
We aint bundling components. The UI packages will just have the raw components. There is no reason to add a bundler there.
Sorry, what are you referring to? 🤔
January 26, 2025 at 1:23 AM
Sorry, what are you referring to? 🤔
I just rather separate App logic and make the components easier to read and maintain and leave styling as its own thing.
January 26, 2025 at 1:17 AM
I just rather separate App logic and make the components easier to read and maintain and leave styling as its own thing.
I’m completely fine with Tailwind’s default way of a “wall of classnames” — can be pragmatic for Git diffs and Prettier sorts it by default (as it does on CSS components)
January 26, 2025 at 1:16 AM
I’m completely fine with Tailwind’s default way of a “wall of classnames” — can be pragmatic for Git diffs and Prettier sorts it by default (as it does on CSS components)
And IMO I prefer the separation of concern of styling vs component logic. Technically speaking, it even allows multiple different stylesheets (if I’d like to wire some).
January 26, 2025 at 1:16 AM
And IMO I prefer the separation of concern of styling vs component logic. Technically speaking, it even allows multiple different stylesheets (if I’d like to wire some).
To be fair, not against a change. But nothing justifies right now abandoning what we have; I won’t recommend a refactor of how we do styles if so far the DevEx has been great.
January 26, 2025 at 1:15 AM
To be fair, not against a change. But nothing justifies right now abandoning what we have; I won’t recommend a refactor of how we do styles if so far the DevEx has been great.
But that is not @apply’s fault, that is how CSS components work. The bundler wire those as generated unique class names.
January 26, 2025 at 1:14 AM
But that is not @apply’s fault, that is how CSS components work. The bundler wire those as generated unique class names.
Not sure I get your concern. The components on their UI package have the exact same styling.
January 26, 2025 at 1:11 AM
Not sure I get your concern. The components on their UI package have the exact same styling.
Now, is it the intended way by the maintainers? Very possibly not. Does it work very well for us? Absolutely yes.
January 25, 2025 at 11:54 PM
Now, is it the intended way by the maintainers? Very possibly not. Does it work very well for us? Absolutely yes.
Also, we justify our usage of “apply” on the same doc at the bottom, and it works perfectly fine for us and it is honestly a surprisingly easy DevEx.
January 25, 2025 at 11:53 PM
Also, we justify our usage of “apply” on the same doc at the bottom, and it works perfectly fine for us and it is honestly a surprisingly easy DevEx.
Augustin, I ain’t going to change the whole website CSS because of some random Bluesky thread lol
January 25, 2025 at 11:50 PM
Augustin, I ain’t going to change the whole website CSS because of some random Bluesky thread lol
IMO it is a good take.
December 15, 2024 at 2:46 PM
IMO it is a good take.