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

Not everyone is so scared of JS that we need separate silos for rendering in the browser and rendering on the server.


It’s not being scared of JS. It’s a weakly typed, poorly designed, gotcha-ridden, hodgepodge of a language. What’s there to be scared of?

It’s just people would rather write a low level, well-designed language than maintain JS codebases.


Consider it might not be fear but a strong dislike based on solid philosophical and/or aesthetic reasons.

Some of the people you're dismissing have probably been using JavaScript for a lot longer than you have.


There's nothing philosophically or aesthetically good about

  <button hx-get="/confirmed" 
        hx-trigger='confirmed'
        onClick="Swal.fire({title: 'Confirm', text:'Do you want to continue?'}).then((result)=>{
            if(result.isConfirmed){
              htmx.trigger(this, 'confirmed');  
            } 
        })">
  Click Me
  </button>
or about

  <div hx-get="/clicked" hx-trigger="click[ctrlKey]">
    Control Click Me
  </div>
or

  <form id="example-form" hx-post="/test">
    <input name="example"
           onkeyup="this.setCustomValidity('') // reset the validation on keyup"
           hx-on:htmx:validation:validate="if(this.value != 'foo') {
                    this.setCustomValidity('Please enter the value foo') // set the validation error
                    htmx.find('#example-form').reportValidity()          // report the issue
                }">
  </form>
Htmx's own examples push you to code that is unorganized and inaccessible.


In two of those three examples, the entirety of the disorganization and inaccessibility comes from the Javascript shoved into them.

In the remaining example, IMO it looks about as organized and accessible as I can imagine as far as HTML goes - my one complaint being the use of a div instead of something more semantically meaningful.


Ironically I can read through this code and know exactly what it does with no other context. I don’t even know what swal is but I can still tell what it does.


I mean sure, but compare that to

<button @click="doThing">

In Vue. Or just plain old JS onclick in Svelte.

By comparison, HTMX is illegible


What does "doThing" do? I can't tell by reading. The above examples, while maybe slightly verbose, are completely self contained!


Sorry was typing that on my phone so got lazy, `doThing` would be a method/function of some sort. You can also write it inline if you so wish, like `@click="console.log('hello')"`


Any non-standard HTML attributes look cursed to me, it seems like HTMX claims to be a solution for JavaScript excessive complexity but at the same time creating complexity in another place where is doesn't belong. There is a reason not XML but imperative C-like syntax stuck around for doing procedural things on the web


That's not a common case and it's not that horrific.

And even if it was - I would be prepared to suffer a lot of pain to avoid the javascript build pipeline and framework churn.

SPA frameworks drove me away from front-end dev and HTMX is making me consider returning.


I feel like there is a middle ground which is being excluded. I'm leaning towards alpine.js or similar lightweight JS frameworks which have better ergonomics than react or plain JS. Webcomponents also without Vue or React are a nice solution.


Oh definitely - I'm not an absolutist. I just want to have the least amount of contact with those aspects of the Javascript ecosystem that take me further away from HTML over HTTP and progressive enhancement.

And I fully accept that "web apps" probably need complex frameworks. I just think most people aren't really building web apps - they are building web sites.


Dunno where you got the first example from, but in idiomatic htmx it would be:

    <button hx-get="/confirmed" hx-trigger="Do you want to continue?">Click Me</button>

Hardly the horror story you are trying to write.

The second example: really? The words 'get' and 'trigger' don't tell you what it's going to do?

> Htmx's own examples push you to code that is unorganized and inaccessible.

You realize these are demo, ie sample code right? No one is forcing you to write exactly that code? You can write organized and accessible code in your own project?


Got it from right here: https://htmx.org/examples/confirm/

And the second example is not accessible. It should be a button.

A library’s demo/sample code should present best practices, not worst.


It says right there:

> htmx supports the hx-confirm attribute to provide a simple mechanism for confirming a user action. This uses the default confirm() function in javascript which, while trusty, may not be consistent with your applications UX....In this example we will see how to use sweetalert2 to implement a custom confirmation dialog.

It's implementing a custom confirmation dialog. Customized, non-default UI/UX usually means custom-written code in any framework I'm aware of. Maybe React has implemented magical customizations since the last time I checked.


React doesn’t require you to both abandon the principles of the library and write an inline string of code to run something slightly custom when you click a button.


htmx doesn't require you to write inline code in strings either, it's just a convenient compact way to do it in a demo. Also, it's not 'abandoning' any 'principles' because the 'principle' is to leverage small bits of JavaScript in a high-impact way. Eg, https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg


So where else will you put this code? A separate file? Multiple files? Maybe specific files for specific bits of UI? Maybe then you’ll need to handle bundling, transpiling, minification? Oops, we’re back to an evil pile of JS code that needs to be built.


Not really? HTTP/2 and ES Modules exist now, lol. And so does brotli compression done by my CDN. Bundling/transpiling/minification are basically obsolete technologies.


you can take anything in this type of context and it will look unorganized and inaccessible. react, angular, svelte, whatever-framework-du-jour … and much much worse than these examples


None of those will eval element attribute strings as JS.


every one of them has warts and insane shit




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

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

Search: