>see https://htmx.org for what I mean, they could implement this concept in the browser in a week, and it would change web development dramatically)

Yes. Has anyone ever purpose it?

i tried to propose it a few times, but I'm a crazy man in montana, and I don't have a lot of pull

hopefully at some point someone will notice it

Kudos to you for trying.

If you had a browser build as a working implementation you’d get a ton of interest quite quickly

best I can do is one hacked up javascript library

HTMX is great ! So much can be done without even any scripting client-side.

Isn't htmx implemented in JavaScript which is downloaded clientside so you can use the hx- directives?

Yes it is implemented in Javascript. You don't have to write JS yourself in your application though. Not that I can't write Javascript, it's just that some things are a lot easier with hx directives.

i think they mean "user written js"

HTMX is a "HTML library" rather than a JS library. It just happens to be implemented in JS for necessary reasons.

If browsers natively supported HTMX features (and possibly _hyperscript) that would be a total game changer.

Well, at least it's no trouble to include these two libraries and bring your clients into the 21st century of hypertext. But doing so without JS would be amazing.

> PUT, PATCH and DELETE

Is this really that much better than POST http://www.mysite.com/thing/100/delete ?

GET and POST have actual client-side implementation differences. The rest is simply semantics.

I love REST but these extra verbs seem redundant.

If you are treating URLs as references to resources, you want the ability to CRUD those resources.

PUT and DELETE correspond with U and D, so they make sense to include. PATCH is a little less obviously useful (partial update vs. a full update w/ a PUT.)

Regardless of our feelings about them, they are there in HTTP, the HyperText Transfer Protocol. So maybe we should make them accessible through the HyperText we are transferring.

I really doubt the world is going to standardize over that specific style of implementation and, frankly, the semantic web is dead. Long live the bazaar...

Those are literally standards. With very specific semantics and expectations https://github.com/for-GET/know-your-http-well/blob/master/m...

And the number of projects that I have seen follow them is fewer than the number of projects that just seem to wing it. Which is my point... perhaps this standard is superficial and unnecessary, and maybe we should discard it.

IETF/whoever can write whatever they want, I only care about what I actually encounter. That's "standardization"

edit- All those nice looking checkboxes depend on the individual implementation. It's a nice concept but how many projects have actually implemented it to the conventions about idempotency/etc shown?

edit2- who is for-GET anyway? A random github link doesn't have much more worth than a random Medium link

I promised myself to never-ever answer the "CRUD vs HTTP verbs" topic. I could not resist.

It is a huge shortcut to map CRUD operations to HTTP verbs POST, GET, PUT, DELETE. By the way, the definition of HTTP verbs defined in the HTTP RFCs (from RFC 1945 to RFC 7231) and the original thesis from Roy Fielding about REST (which is defining REST principles as an architectural style) never talk about one-to-one relationship between CRUD and PUT-GET-POST-DELETE.

While I understand that it might be confusing without deep-diving in long-long-lectures, the last RFC explains clearly what is the purpose of each HTTP verb including the difference between PUT and POST:

   The fundamental difference between the POST and PUT methods is
   highlighted by the different intent for the enclosed representation.
   The target resource in a POST request is intended to handle the
   enclosed representation according to the resource's own semantics,
   whereas the enclosed representation in a PUT request is defined as
   replacing the state of the target resource.  Hence, the intent of PUT
   is idempotent and visible to intermediaries, even though the exact
   effect is only known by the origin server.

Therefore it would be perfectly valid to "create" a resource with both PUT and POST methods as well as "update" another one with, also, PUT and POST. It is actually even clearly stated with a few examples in the RFC. For instance in POST definition:

   Appending data to a resource's existing representation(s).

I used to defined PUT and POST requests according their characteristics: the first one is idempotent, the second is not ... but could be. Therefore, in my understanding, it is perfectly valid to perform an "upsert" (insert or update) to a resource which doesn't exist yet but for which you already know the URL, it is indeed idempotent. For instance:

   PUT /resources/xyz

A last piece of evidence is the first line of PUT section in RFC 7231:

   The PUT method requests that the state of the target resource be
   created or replaced with the state defined by the representation
   enclosed in the request message payload.

I hope it helps to clarify a little bit the topic.

Do you have any references to documented, truly REST APIs? In your experience, what (pragmatic) shortcuts were needed to veer from (some definition of) "pure" REST?

IMO Stripe API[^1] is following well the REST principles and constraints. Btw, if I well remember, they are not using PUT at all while they obviously allow users to update some resources.

They implemented an "Idempotency-Key" header that you could maybe call a "shortcut". Although it's not really deviating from HTTP standards. I guess it was easier and more pragmatic for Stripe and users to implement an "Idempotency-Key" header instead of duplicating each POST endpoint with PUT and PATCH methods since they also allow partial updates. I guess (again) that they would also have to use/implement additional header (such as ETag or If-Match) to replicate current "Idempotency-Key" header behavior.

Disclaimer: This last paragraph is full of assumptions and I most probably miss a lot of internal details from Stripe API.

[^1] https://stripe.com/docs/api

>> I love REST but these extra verbs seem redundant.

The extra verbs make your URLs less redundant!

Funny. I was expecting the article in a pure HTML page. Instead, it has a rainbow of CSS & JS.

Clunky, how?

If anything I'd associate javascript with clunkyness.

Well, I think a lot of people (developers at least) associate SPA-type web applications with smoother transitions, etc.

I agree with you to an extent: I've had some very bad experiences with javascript applications as well, but the general sentiment is (reasonably, in my opinion) that a well done SPA will feel smoother than a well done MPA

W/ htmx or similar libraries like unpoly or hotwire, you can close this gap. The big difference is the ability to update partial bits of HTML, rather than needing to do a full page refresh.

As a predominantly (hobbyist) systems developer, the pervasiveness of NPM is a major detractor for website development.

I have done a few Angular and React apps to keep the skills sharp. The imposed workflow for the power is an interesting set of tradeoffs, never mind the magic and amount of decisions you need to make to use both.

Add on top of that the rest of npm, nvm, css compilers, the various css toolkits for layout, and the rest and it just feels so complicated, even for the most basic page which needs to pull in some data over an api.

It doesn't seem to be getting any simpler.

Lets say you want something as simple as a table-of-contents. If you're doing HTML, you gotta render this yourself. In Wordpress or webpage generators like Jekyll or Hugo, table-of-contents generated from H1 / H2 headers is basically just one line.

Lets say you want to sort all your posts by date and paginate the results (say, 20 results per page or something), as per typical blogging patterns. That's a lot of HTML cruft you gotta make for this to happen. Meanwhile, Wordpress / Jekyll / Hugo (etc. etc.) do this all automatically for you.

I don't think it matters what generates the page. Wordpress/etc could generate plain html pages and the author's points would apply equally.

Personally, I prefer html with a little embedded css. It works, it's quick, it's all in one place, and it lets me produce suitably elegant pages.

HTMX can do a lot and it just requires not being dogmatic about avoiding the server doing some work every now and then and sending perhaps a little more data down the wire.