Do you really want to use HTML syntax to write Javascript?

Well, react did almost the exact didn’t it? And I don’t really have to worry about js if htmx is enough? I don’t have strong opinions, just asking

IMO all htmx is doing can also be done by a JS library that simply uses strings as IDs and classes. Would you use this kind of library if it wouldn't be packaged into this weird XML-like format? For instance if we take this example: https://htmx.org/examples/tabs-hateoas/ So in this example there is not much difference if we call a factory function for these two elements and then add them to DOM after our script runs.

What's interesting is that when you do bare JS you tend to do this element creation factory function patern by default. The difference with this one is that now not only you don't do API-based programming, but you are forcing the client to be HTMX-only. So basically you take DOP-like patterns out the window as you're now sending pre-rendered HTML chunks. And when I went to HTMX webpage I found this page which has some memes: https://htmx.org/essays/ And then I found this gem: https://htmx.org/img/memes/fullstack.jpg Also on a side note: I remember that my friend who learns PHP couldn't grasp JS. So this would be a saving grace for him probably. Until he'd need to write a 3d-controlled real-time volume knob (that also controls left+right sound) that he wouldn't be able to specify in base HTMX :thinking_face:

JSX embedded html syntax inside JS documents, with the expectation that you will use the full power of Javascript to fill in any gaps. This is trying its hardest to fully replace Javascript with attributes to HTML tags. I honestly cannot think of any scenario where this sounds like a worthwhile investment of my time to learn to do well. If I want a site that is mostly static, I can build a static site and then augment with JS as needed. If I need more of JS, I can build a SPA instead and have full control. I can't see the value proposition of something that basically amounts to a JavaScript framework, but relies on a DSL constrained by the syntax of HTML. (I guess you said you are new to frontend, so maybe you don't realize that HTML is verbose and seriously lacking in expressivity.) And if your goal is to learn about front end, this will either hide what you need to know from you or expose it to you in the most uncomfortable ways possible when you try to do something slightly different than it was designed for.. Bonus: I seriously doubt you will find a pleasant interop story between Htmx and ClojureScript.

@U028ART884X Honestly that meme captures the allure of it.

I'm not sure if you used that word correctly: https://www.thefreedictionary.com/allure Probably you wanted to use "full extent of it" or "all of it" or "full meaning of it".

@U028ART884X no, I meant it as it is defined in dictionary. The attractiveness of htmx for someone like me (who does not know much js) is exactly that it lets me stay in backend without bothering about complicated build tools or frameworks.

You can always include inline JS into the HTML file like this: https://www.geeksforgeeks.org/how-does-inline-javascript-work-with-html/ And then you can call your builder functions as you like. This way you can have this same workflow without this exotic library (but with more additional boilerplate) that won't work with other things. i.e. by using htmx you're limiting yourself quite a bit. The drawback is that you'll need to write what htmx provides for you.

> lets me stay in backend without bothering about complicated build tools or frameworks. This is not exactly true because htmx is actually a tool that runs in the client itself. It interprets the XML and then does some magic behind the curtain for you. So by saying that you don't want to use JS or don't want to use a framework you opt for a htmx framework that has hidden the JS from you. I don't say that it's not useful but it's not very flexible once you'll get into a situation where you'll want to have custom stuff.

Actually you'll then start to mix htmx with JS which you can actually do 😄 but you wanted to avoid JS so then you'll need to refactor

@UC1DTFY1G - We use HTMX quite a lot and really like it. • It's a small framework and it's really easy to pick up • You just use it where you need it. It doesn't impact the rest of your code at all. • If you need even more interactivity then you can use hyperscript (a js library too) or JavaScript or ClojureScript. Server side rendered websites are often simpler to build and maintain compared to client side SPAs (there's no JSON API, no React etc). HTMX let's you use server side rendered websites in even more use cases where HTML on its own is not enough. Note, you don't need a Clojure wrapper for HTMX you can inline bit of HTMX in hiccup when you need it.

> @U90R0EPHA I seriously doubt you will find a pleasant interop story between Htmx and ClojureScript. FYI - We haven't found interop a problem at all. Any function/definition in ClojureScript can be exported and called from HTMX (or HyperScript or JavaScript). They can also be exposed as web components and used directly from HTML. Benefit of the HTMX approach is that you only have to write javascript/clojurescript if the functionality can't be achieved with server side clojure/hiccup, HTMX or Hyperscript. One way of thinking about this: Jut because we sometimes have to drop down to assembly level code for certain functionality, that doesn't mean we should always write assembly level code.

https://github.com/whamtet/ctmx

> Do you really want to use HTML syntax to write Javascript? A bit tongue-in-cheek, but React et. al. could be asked the opposite question: Do you really want to use Javascript to build HTML and have your state stored in multiple places? I know it’s not an apples to apples comparison, but the premise of HTMX is not to write Javascript using HTML; it is to fix HTML such that actual hypermedia-driven REST APIs are feasible. Yes, that requires a bunch of JS.

> hypermedia-driven REST APIs are feasible So the client will try to support new tags but then back-end could instead add inline scripts and do that by including JS. :thinking_face: This is not the same as sending XML but it's still a valid way to extend the functionality of HTML. Do you intend to make all of the content XML-readable?

don't avoid learning js, imo. it's everywhere and not going anywhere. use htmx for convenience after you know js.

and if you want to learn a js spa framework then learn react, it's by far the most popular and the main cljs frameworks are built atop it

also htmx is fine, don't let anyone tell you a technology is inherently bad, there are trade-offs with everything and it matters more whether those are the right trade-offs for you

> Do you intend to make all of the content XML-readable? I’m not sure I understand. Your server renders HTML, and the browser presents that HTML. HTMX reads the HTML as well and augments the tags it knows how to handle. So you will want your server to only render HTML, yes.

For me it seems like HTMX to HTML might end up like "hey, let's add kitchen sink to JS and then do it again and again!"

> use htmx for convenience after you know js. Devs in our team are able to learn and use the basics of HTMX in just a few minutes. Learning JS + React can take weeks or months. So it's definitely a possible strategy to learn HTMX first. We've found that HTMX + HyperScript + SCSS can eliminate most of our need for clojurescript/javascript in a standard business app.

What you are gaining is the ability to have your server be the single source of truth, side-stepping any issues of data synchronization. Your API becomes discoverable, because your HTML describes the possible actions at any point (the HATEOAS).

Not sure where the kitchen sink comes into the picture. 🙂 HTMX basically adds the ability for HTML elements to trigger requests, and knows how to swap in the responses at the relevant spots. This avoids the need for DOM diffing and other other techniques.

I didn't try htmx but any addition at HTML-like level should probably be reviewed by somebody. Maybe those who wrote HTMX are smart enough but what does it mean to HTML? I was probably thinking too much, don't mind me.

I don’t think it has any impact on HTML. You have always had the ability to add arbitrary tags on your HTML elements.

I encourage you to give it a try. It feels very well-designed.

You can also create completely custom HTML tags <my-tag my-arg="hello"> with CustomElement. There is no need for the HTML Spec to incorporate the features of HTMX now because it can now be done by libraries (e.g. HTMX). Like how Clojure Core does not incorporate libraries like clj-time and specter. - doesn't mean you shouldn't use them.

If you search only by xxx_id or by (xxx_id, yyy_id), then the unique index should be enough. If you also search by yyy_id, then you should create an index for that column. Not sure about (yyy_id, xxx_id) - I'd expect PostgreSQL to be able to understand that the value should be swapped, but who knows.

thank you

But also, don't just trust me as I'm not a DBA. :) It's easy enough to test, and you should definitely do so given that there's probably a specific PostgreSQL version that you use - it might be important.

You may want to try this: https://www.postgresqltutorial.com/postgresql-tutorial/postgresql-explain/

@U2FRKM4TW, yeah, I decided to try and find something in docs about this. Turns out, PostgreSQL has article specifically about this :'D https://www.postgresql.org/docs/current/indexes-multicolumn.html

@U028ART884X, thank you, I'm just too scared of the execution plans, they seem too complicated to me. But I guess I'll have to dig into this

> scared of the execution plans I don't really know what they actually do but I think that it's a good thing to look into if you want to work with specific query

@U03FBSSUPSP honestly, learn to not be scared of them. EXPLAIN is basically one of the best, if not the best feature that most no-sql databases lack. It's hard to understand at the beginning, but it really pays off on the long run - I had queries that got execution times cut by half or more just by understanding EXPLAIN 🙂

This tool is also pretty nice: https://explain.depesz.com/ And another one: https://explain.tensor.ru/

Here we go 😄 https://explain.depesz.com/s/qHyB#html https://explain.tensor.ru/archive/explain/ba0d3fdb5767df5b208efed78c5561d3:0:2022-11-14#explain This is a random query I found in the internets... what do I even do with the results... :thinking_face: It's an okay query and it selects something from constraints but it's too much for me. But basic queries could probably be alright to ananlyze :thinking_face:

Did you use EXPLAIN or EXPLAIN ANALYZE?

And it's significantly harder (at least, for me) to use the results when I don't have the original query in front of me.

This query selects every FK constraint and produces VALIDATE string that could then be executed in a FOR loop:

explain analyze SELECT FORMAT(
    'ALTER TABLE %I VALIDATE CONSTRAINT %I;',
    tc.table_name,
    tc.constraint_name
  ) AS x
  FROM information_schema.table_constraints AS tc  
  JOIN information_schema.tables t ON t.table_name = tc.table_name and t.table_type = 'BASE TABLE' 
  JOIN information_schema.key_column_usage AS kcu ON tc.constraint_name = kcu.constraint_name 
  JOIN information_schema.constraint_column_usage AS ccu ON ccu.constraint_name = tc.constraint_name 
  WHERE  constraint_type = 'FOREIGN KEY' 
    AND tc.constraint_schema = 'public'

Ah, I wouldn't look at such a query at all - it uses only built-in objects, and some of them, if not all, are views with their own logic. I wouldn't expect any reasonable optimizations here. But I could be wrong.

> But I could be wrong. I don't really use PSQL that much but I think that explain analyze could help to find out whether you forgot to index a column. And OP was thinking whether his unique constraint was taken into account. And yes, this query is probably basic and can't be optimized further. But even then the analyzer shows red colors so it's a good thing to know that it does that anyway.

What kind of queries do you talk about? json? hstore? Postgis? arrays?

Trying to understand an explain over a random query found in the internet sounds really weird. Also, not knowing the query is hard, but indeed I can see it probably filtered over a case, which is insanely costly. There are lots of sequential scans and other stuff, so these should be optimized.