NO BUILD SYSTEM FOR HTMX???? | Prime Reacts 

I’ve worked as a web dev for 3 years now and 90% of the websites have gotten upgrades during this time. It’s not that the devs want to upgrade the site, our clients do. Their websites are literally how they earn their money…

@@ciril2643 it logically follows that a web developer would be working on the sites getting the regular updates. What is your point?

@@c-spam9581 that there are rarely websites that are “built once and run forever”, unless you’re talking about blogs or showcase sites

The issue is that people don't distinguish between websites with dynamic interaction from full web apps. 95% of the times you don't need a desktop like experience and complex components. In these cases having a templating language for generating HTML on the frontend is absurd.

What an ignorant take. To insist that JS ecosystem was easier/better/performant 10 years ago than it is now suggests that either you haven’t worked with JS 10 years ago or all you know about the JS of today is through memes.

@@imaliazhar it's definitely not an ignorant take... I have a client, I took over their website from another dev (because that dev was clueless), it's a NextJS monstrosity. Even fully compressed into a tar.gz for deployment is still 1.8GB, and almost all of that is node_modules nonsense! For a site that could be rebuilt entirely in a static site generator! It's absolute madness! I have another client with an almost identical level of site functionality that I built with Hugo and... it's

To think that JS is inspired in Self, and the DX of both those things couldn't be further apart... If you never played with Self (or at least Smalltalk), it's an interesting experience :) You live inside the program, all the devtools, libraries, everything is part of the same system, you grow that system into your program step by step, you can edit your code in the debugger as you go... the absolute polar oposite of having to write, build, test. But if you are a Vim user, the experience is very mouse centric, so that might make it a bit less pleasurable (and no, GNU Smalltalk is not the same, that's just like Ruby with less Perl in it).

JS was never meant to be good and useful. v8 didn't get the memo and made it fast/popular. People built tools to escape from the mess that JS is

What do you consider a complex build system? types > minify is used in most cases.

If you want to understand why, let us know and I can try to give an explanation of why a build system is required. If you’re just being cheeky then ignore

JS is still a bad foundation to build on since it was never its intended purpose to handle heavy logic@@TheSaintsVEVO

You clearly didn't check out the "hyperscript" section of the docs.

​@@noherczegnot op. But how does that relate. I am a systems programmer, please speak in laymens terms.

@@DeveloperOfGames Can you explain your rationale?

Why? For me it only makes sense when the backend and frontend are coupled. For 2 two different teams, technologies or complex UI, I don't see it yet

I agree that HTMX is a step in the right direction. I have spent most of my career building Angular and React applications. 99% of our apps' behaviors are easier to implement with HTMX and/or Alpine. We should only be using React for the 1% of problems it simplifies.

logged in to up vote and say: i miss knockout-js. I think its approach is my favourite tbh: observables and simple to plug and play. shame it didnt have a good components solution.

One line of frontend stuff per week... Living the dream, my man

Neovim LSP has the same structure and it's builtin to telescope too. So I have it remapped to st since I come from Intellij (STructure) and can pull up the telescope search to jump by method, function, class

I wouldn't use it

​@@BinaryReaderThen don't

There is already a hmtx native for mobile development. It is called Hyperview.

Just don’t use it. Go wild

@@danvilela I always write stateless web apps

In the opposite direction, you have smalltalk, where you usually have one text window per method which hides how verbose smalltalk actually is

types, pollyfills, minimization, etc

​@@vitorguidorizzzi7538 yep I am aware on what people use it . the polyfill can included as such in the source or as an additional script inlcue and I have a CDN that can do minification. Types is a valid argument for people that prefer TS. I prefer vanilla JS

The web is a mess, esm, cjs we need a build step for targetting both

Just some average React developer trying to overcomplicate everything

A good example is to go beyond your own example of non-bias judgment and step into the shoes of a totally different person who has completely removed concepts like goals and history. If you can imagine what they see when they look at the project it could be so different that you can walk away with things we would never otherwise think to even question.

You will if you want to use a newer version of a library which is probably using a newer version of Typescript

Which is a non issue if you use OpenAPI and generate your validators from it. By doing so you in certain cases can skip a backend call, and do the work in the browsers, reducing load on your single source of truth.

​@@noherczegin what case can you skip a server validation call?

It ensures that if you are off by 1 character that you don’t highlight an entirely different word

😂😂

Sir, this is America

You either seem to not get the main point - or you would try to "program in htmx in react style"... because The point is that the STATE is not in two different architectural points. The state in modern web dev is represented and kept sync both on cliend and server side. Here the state itself only exists on the server side. Much simpler and much less code. The duplication of code is maybe not the best phrase as the main issue is "duplication of the state handling code" which this way easily can be spared.

​@@u9vata Of course. The "duplication of the state handling code" issue is something that I agree. Usually, there is no need to create the state transition both in client and server. You send the request to the server and it returns a payload that represents the new state and then I re-render the affected elements using it. The ideia is the same that you got with HTMX, but I already worked in that way using VueJS in 2018. The difference here is that I don't buy the idea to use HTML payloads. The problem here is not only the size, but that it is not the right level of abstraction that I expect from the server. If i receive a JSON payload that contains the same information, I still have the possibility to just render it using an HTML-like template and get the data in same format as HTMX, but I have the flexibility to do another things with that, like use it in special components. Here, still no duplication of code because the code responsible to render it is only in one place (and in my opinion, the right place).

​@@danilomendes977 > Usually, there is no need to create the state transition both in client and server. VS. > then I re-render the affected elements using it. I honestly take this re-render as part of the syncing of state. And I think its much worse to send around random json that the client somehow builds html from - compared to literally sending the html. Again... this way the state is at two places: you can easily do as crazy things with that data on the client as you wish - and server does not know. The responsibilities and system state is totally conceptually shared this way and I honestly think it is an antipattern... > a JSON payload that contains the same information, I still have the possibility to just render it using an HTML-like template and get the data in same format as HTMX, but I have the flexibility to do another things with that, First off: you totally waste CPU with parsing that json on the client - especially if no templating is needed at all. Secondly, I think this makes the whole system much harder to reason about and easier to spaghettify because of the "can do other things" part which is actually why I prefer the HTMX approach here. I actually did this much before HTMX too. Actually did this not that long ago with pure JS and no frameworks at all. Just pure JS and REST endpoints with json... I actually even thought about making a library for these kind of things (different than htmx in approach, but again: not that different in a way) but now that I look back, most of the things I did I can imagine doing with htmx. My approach was more clieant-heavy just as yours... In mine I just had a raw html (this was micro services) that they could literally copy-paste to anywhere they want - let it be a static page or some endpoint generating this html. Just copy paste it where you want it appear... I had naming and other conventions for CSS-ing it if you wanted it look different too or actually change html a bit. What the JS nearby this did was that it literally changed the existing placeholders with microservice data and communicate back andd forth with backend in json and that is all it did. The good property of this system is that the non-dynamic, really static simple html example design was used AS-IS for the copy paste and looked exactly as when designed alone in a minimal html... ^^I can imagine some points to this that htmx cannot do - but honestly more often than not it would just make things even more clean... > Here, still no duplication of code because the code responsible to render it is only in one place I disagree: you have the message passing from backend and then the rendering. Just saying... the backend is not getting data in your json right straight from database as the json end result, but your backend literally renders its various data... into json... then you render that json into html... Technically I would totally call that "rendering into json" just similarily as people say rendering into xyz... So this totally is a duplication at that point in 99% of the cases - and guess what? If you are in that 1% where you want something more complex, you can still use regular JS for that part.... Just honestly it will be so rare that most pages would not even need you to enable javascript anymore if browsers would natively support this functionality! I literally hope native support for this happens from browsers. This is even more sandboxed than running JS - so people who otherwise turn off javascript can still run this maybe. Also little browsers like command line browsers might be able to more easily support this than supporting a full JS engine "properly". This thus enable a wide range of applications - like embedded browsing use cases much more easier. > The problem here is not only the size, but that it is not the right level of abstraction that I expect from the server About size... I guess you know that this can be easily gzipped and likely not even that big of a deal at all. Honestly sounds like parsing the json would take longer than the whole sending without even any gzip anyways. I also think server is totally right abstraction level here. Imagine putting the json-rendering logic part unified on the client: that would mean extremely thick client with communicating literally to database via the backend as proxy that does not have logic. This is basically a no-no. The opposite: that making it a thin-client however is really doable and what htmx is doing: then you can remove the "render to json" part and as I said in most cases render directly to html to be exchanged on the viewer machine at some location. Also this is more fitting to overall web architecture where HTML were always what is to be sent around directly as state and the result to view: full page? html. streamed content that get slow pulled? html. Fragments to change out dynamically? Html. It is very unified this way, also loads more simple to debug just by looking at logs for example on production!

json and html have very littel difference in payload size, and unless you are never exceeding 1500 bytes per message, timing becomes a lot different second, its easier for a server to produce html than json... its... a weird thing, but it is what it is.

@@u9vata JSON here is just an example. If i am looking for performance in data exchange between client and server, I would probably look for another thing (a binary format?). But, in my applications, usually the bottleneck is in other place. The main point here is the right level of abstraction. With HTML payload, I don't know how to deal with the information inside the generated html in client side and sometimes you need it.

Sounds like hell to me

@@danvilela what advantage does a build step provide?

​​@@heinzerbrewcatch bugs during build time with types, minify the code, delete unused code and target different browsers, and don't forget about esm and cjs

What do you mean by that? The whole point of the htmx is interaction

It depends, well written code is easy to follow.

no web app works offline also, htmx is not for native dev

It's backend oriented, so no. Needs to run on the server.

Well, in some sense htmx could work offline - if you also make use of a service worker and some form of caching/localstorage/indexeddb etc... The requests would get sent off by htmx, intercepted by sw, retrieved, and updated in Dom. I have to assume that this is simpler with an htmx multipage hypermedia app that can easily cache HTML fragments for any url/endpoint than in some CSR framework SPA. It is also just good practice even when not offline - better performance, less bandwidth used, less server costs, etc...