Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Seems like overkill to bring in a framework just for inlining some static html. If that's all you're doing, a self-replacing script tag is neat:

    <script>
      function includeHTML(url) {
        const s = document.currentScript
        fetch(url).then(r => r.text()).then(h => {
          s.insertAdjacentHTML('beforebegin', h)
          s.remove()
        })
      }
    </script>
...

    <script>
      includeHTML('/footer.html')
    </script>
The `script` element is replaced with the html from `/footer.html`.


this here is the main idea of HTMX - extended to work for any tag p, div, content, aside …

there are many examples of HTMX (since it is a self contained and tiny) being used alongside existing frameworks

of course for some of us, since HTMX brings dynamic UX to back end frameworks, it is a way of life https://harcstack.org (warning - raku code may hurt your eyes)


If you want it more straight-forward and simple hypermedia approach, then check out https://data-star.dev (highly recommended, there are great youtube video's where the maintainers discuss their insights). Following up where htmx took things.


But this requires JavaScript...


> But this requires JavaScript...

Depending on the specific objection to Javascript, this may or may not matter:

1. You object to any/all JS on a page? Yeah, then this won't work for you.

2. You object to having to write JS just to get client-side includes? This should mostly work for you.

It all depends on what the actual objection is.


... but the folks behind that standard don't want to encourage browsing with Javascript off.


Why would the ES standards organization that defines JavaScript syntax encourage people not to use it?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: