To take a simple example, HTML was originally a pure markup language, so if you wanted to make text bold you <b>would do it like this</b>; simple, declaritive

But then it was decided that there was no semantic purpose to the <b> tag, <span style="font-weight:bold">so it became this</span>.

Now, with the ubiquity of js, it's more like <span id="bold-text">this</span> (along with something like getElementById("bold-text").setAttribute("style", "font-weight:bold") in the background).

It should be pointed out that things come full-circle: frameworks like Bootstrap define the <strong> tag which, via similar JS to above, all-but-duplicate the functionality of the original <b> tag. I think the OP's point though is that you have to add a JS framework to do this.

What? <strong> is a tag defined in the HTML standard (with a bold default-styling in browsers). There is absolutely no need for frameworks to do anything to it, especially not with JS.

<span style=...> vs <b> vs <strong> have different semantic meaning, and all have valid uses in modern HTML.

I think this is a bit confused? <span style="font-weight:bold">bold text</span> would be appropriate for a span of text that is to be set in bold for no semantically-relevant reason, otherwise you would use something like <strong class="important">this (please read carefully!)</strong>, and then use CSS to style the "important" class as bold. The <b> tag has actually been revived, but it is reserved for a span of text that is to be clearly set apart from its surroundings for some semantic reason unrelated to emphasis, importance or anything that's covered by other HTML tags or features.

Have you looked at the linked post? It creates a powerful mechanism for introducing new declarative elements. And gasp it uses JavaScript.

   import Ghost from "../components/Ghost"; 
   <Ghost size={80}>Thanks for reading!</Ghost>

I think you're overlooking CSS as well, which is a very nice declarative way that maintains semantics and makes styling more adjustable.

<span class="bold-text">this</span> and .bold-text {font-weight: 600;}

strong has been around for a long time.

Ya there are lots of articles on them, but let's start with these:

http://latentflip.com/imperative-vs-declarative

https://stackoverflow.com/questions/45016234/what-is-idempot...

https://en.wikipedia.org/wiki/Side_effect_(computer_science)

The early goal of the web was to create a longterm available, reliable, discoverable network of media over an inherently unreliable transport.

I keep trying to write a concise explanation of these but I can't fit it in a comment. Let's do it DECLARATIVELY haha:

imperative->functional->declarative

for()->foreach()->map()->executables+pipes->spreadsheet

C/BBS->perl/cgi-bin->Apache->HTML/CSS

manual network config->DNS

state machine/brittle long running process/fear of manual retry->idempotent request/response

Always, always, always work towards the rightmost side if you want the least side effects and highest reliability (critical for a distributed system built on unreliable parts!)

I'd like to say that declarative idempotency was an immediately obvious thing to the architects of the www, but what really happened is more like Darwinian evolution where each solution's fitness was measured by reliability. Declarative idempotency was also cheaper because requests/responses could be cached and scaled.

If we flip it around for a moment, imagine a web without these things. Every site would have a complex tangle of brittle code to do even the most trivial operations, and it wouldn't be able to pass data on to other sites (it would be an app). Without idempotency, users would have to be really careful to only click the send button once when they were transferring money (thankfully this hasn't happened much).

The one thing that I wish the web had though was a layer to make unreliable communication reliable. It would look something like a promise or future with no exceptional logic. That way we could think in terms of wiring up the inputs and outputs of many websites and then "load" it to execute the logic. Kind of like Ansible, where internally the logic is imperative but on the surface is declarative.

I'd also like to see declarative idempotence replace imperative code (especially object-oriented programming) at the developer level.