[superkuh]

>In the end, your document is now fully an HTML document, not a Markdown document that becomes an HTML document. It’s a minor perspective shift, but might have some cascading effects on things I’ve written above.

But this style of custom-elements requires successful javascript program execution to achieve that "HTML" document. Just like markdown requires some parser program to turn it in to HTML. It's not really fully an HTML document.

It's a good idea. It just would be a better one to write the custom-elements as wrappers for actual HTML elements. Like how https://blog.jim-nielsen.com/2023/html-web-components-an-exa... shows instead of trying to do it SPA style and requiring perfect JS execution for anything to show properly.

HTML mark-up really isn't that heavy. The avoidance of it seems mostly to be because it's considered "old" and "old" is bad, or at least not useful on a resume. But it's old because it's so good it's stuck around for a long time. Only machine generated HTML is bulky. Hand written can be just as neat and readable as any Markdown.

[thangalin]

> It just would be a better one to write the custom-elements as wrappers for actual HTML elements.

pandoc has an extension for this:

https://pandoc.org/demo/example33/8.18-divs-and-spans.html

KeenWrite, my (R) Markdown editor, supports pandoc annotations:

https://youtu.be/7icc4oZB2I4?list=PLB-WIt1cZYLm1MMx2FBG9KWzP...

> Just like markdown requires some parser program to turn it in to HTML.

Or XHTML, which is XML, which can then be transformed into TeX macros, and then typeset into a PDF file with a theme (much like CSS stylizes HTML).

https://youtu.be/3QpX70O5S30?list=PLB-WIt1cZYLm1MMx2FBG9KWzP...

This allows separating content from presentation, allowing them to vary independently.

[spankalee]

JavaScript is one of the three core file types of the web. You can rely on it as much as HTML and CSS. I don't get the unique derision of JS compared to the other files types.

[superkuh]

That's an understandable take in nearly all commercial and institutional contexts. But in others just involving human people, no. Many times JS does fail or isn't available. So building progressively enhanced web documents preserves utility across the spectrum of human visitors (and maintains accessibility). But if you only have a profit motive, then yes, there's no need for robust solutions. The amount of people that can't do JS well won't eat into profits or cause enough complaints to get you in trouble.

[lelandfe]

I think progressive enhancement is a cool approach to building stuff.

I also think “turn JS on” is a fairly reasonable ask these days. A lot of the web tends to break when CSS is disabled or fails, too.

[spankalee]

If your HTML or CSS fails to load, you're going to have a hard time too. Web pages have many critical resources.

[superkuh]

Failing to load is not a problem. Failing to execute is.

Usually because the web dev have used some new Javascript feature only $latest JS engines support. HTML and CSS if they're there they're there. Sure, there's caniuse for HTML and CSS. But they only have to load. The text/images/etc will be there. JS both has to be loaded and executed. If the later doesn't happen just right then the text and other multi-media won't be there. It's a very big difference.

[rustystump]

Generally i agree.

I think there are a group of people who are salty that js became “the lang” for the web. Another group of people loath the framework insanity of webdev. I count myself among the ladder not the former. I equally hate all languages.

Js is heavily overused but the “web” of today is not the web of the 90s or 2010s which some people cannot get over.

[troupo]

No, you can't really rely on it. Welcome to Performance Inequality Gap: https://infrequently.org/2024/01/performance-inequality-gap-...

[o11c]

One additional thing that article fails to mention: you should not test your device in a context where it can cool itself easily. Test on your devices when they are wrapped in a blanket, and while there's another program using 100% CPU.

[rustystump]

Your conclusion is not the same as the article you link. Js is fine but it should be used relative to the targeted use case.

That astonishingly long and researched read loses impact when it draws a primarily moral based argument in the thesis. Being fast is better for both the privileged and underprivileged.

Moral handwringing rarely moves people to action.

[troupo]

> Your conclusion is not the same as the article you link.

My conclusion directly derives from the article. If your app relies on Javascript, it will be non-functional/broken/unusable for a huge number of people while their devices struggle to download, unzip, parse and run your JS bundles.

BTW. It's worse with web components built with default assumptions (without bundling). Since `import` statements will cause a long waterfall as each component loads its dependencies.