[tipiirai]

Tailwind example indeed does more, but only slightly. Would increase the size of CSS by 1-3%. The semantic version has clearly enough to prove the point the article attempts to make: significantly less code is needed and the resulting site is leaner & faster.

[Loeffelmann]

If you really want to compare code snippet sizes, you must offer the same functionality. Otherwise, the comparison is meaningless.

You did the exact same thing before when you compared the Headless UI combobox with your nue.js implementation. Offering fewer features will result in less code. Shocker.

Besides, I don't really care for these comparisons. If something is 2x longer code but more maintainable, it is 100% worth it. Just because something is short doesn't make it better.

[tipiirai]

I'm sure most developers can see the bigger picture with a 95-99% a implementation.

[tipiirai]

I know what you are talking about. Projects tend to slow down at the end of it. But responsiveness is not one of those things, at least on this project. My honest guess is 3%, the menu being the biggest piece. It can also be lazily loaded so that it doesn't increase the amount of primary CSS. Just like the dark mode was implemented.

Having said that, I promise 100% feature parity on my next article. Thanks for the heads up!

[kissgyorgy]

You are underestimating the effort/size spent on the last 5% of a project.

[Loeffelmann]

Features that look easy to implement and are not a big deal can turn out to be massive problems and require a large amount of code to actually pull of. I would, in some cases, count responsiveness to be one of those things. Stuff like that may seem like 5% of the functionality but actually makes up a large chunk of the code. This is why you must always have feature parity if you really want to compare code size.