Server side representation? 😈

Server side HTML - SSH 😂

Are there examples of having a dynamic form. For example a form with an input field and a "+" button to add a new field below it. Each time you click + it appends a new input field. For example a shopping cart and + adds a new line item

i'm starting something new and i am thinking about htmx and wondering for an open source project that is basically a CRUD app and designed to be accessible to everyone, including people who are just starting out coding what do y'all think the simplest stack would be? (the simplest one that is good: something that won't be outgrown and isn't tedious. CRUD should be easy like it is in Rails) I'm thinking the right answer probably includes JS rendering templates on the server side and htmx on the frontend?

the simplest stack may not be the same as the easiest stack for people who are getting started with coding. RoR may be the easiest one but even with that for web dev you need a certain baseline level of expertise

another option may be Racket as it is designed to be easy to learn: https://docs.racket-lang.org/continue/index.html

Yes! Here's a "grid" widget in the app I'm building right now. You can add/edit/delete rows directly into the table, which writes back to the server pretty instantly. Here's a video of my dev instance: https://cdn.discordapp.com/attachments/725789747212976259/1106407217781026866/Dynamic-Form-Example.mp4

The code is built for a production system, so it's not the best demo code to dig through. But in case it helps: Here's the widget code: https://github.com/benpate/table And here's the code that's running in the video: https://github.com/EmissarySocial/emissary/blob/main/render/step_EditTable.go

In general, an editable form is pretty straightforward to accomplish. A few things I decided on while building this: 1. Swap out the whole

<table>

, not individual ``s. This is because of some funkiness in targeting rows in a table that make it error-prone. For me, it was easier to redraw the whole table each time. 2. Because of this, it's simpler to only allow editing on one row at a time. In the widget I showed, clicking on another row will de-select the previously selected row. 3. It basically works like a state machine. There's VIEW and EDIT states with actions that move between them (add a blank row, select a row, post a change, delete a row, cancel changes)

Agreed. This same dilemma comes up with htmx itself. People will look at the examples, which are intended to demonstrate a specific tag or feature, then be confused about using it in the real world. We get specific feedback about accessibility every now and then, even though the point of the examples isn't to showcase that particular feature. On the flip-side, code that's really easy to use in production can be a bear to step right into. 😦

Methinks “simplest” and “won’t be outgrown” are in conflict. Something that won’t be outgrown will be batteries included and those usually go a mile deep.

Simplest was maybe not the right word - I was thinking more "easy for a beginner to contribute to".

Easy for beginners is a framework/library that uses simple functions that accept requests and return responses. But that’s only easiest in the sense that it has a concise Hello World app. Something that grows is back to batteries included. So rails, Laravel, Django, Phoenix, etc. I don’t think there’s a shortcut.

However, I’ve thought about writing project setup scripts that get someone to a point where they can start building. Something that uses a batteries included framework but let’s you start with the simple hello world. Batteries included with training wheels.

I think beginners will benefit more if they can focus on one small piece. Once they understand a small piece, then they have a foothold to expand from. So with Django for instance, they could focus on just making a model, and all the other parts get auto-generated (views, templates, admin, routes, serializers). I’ve got the automatic views, admin, and serializers done so far.

and HTML server?

i dont think there is nothing micro about the aproach, i hate that proposal

at this point ssr looks like a lost cause, perhaps getting away is better

yeah its pretty hard to answer that... i guess in the end it depends of what they want to do... I am biased to kotlin, not the easiest but has an interesting type system and can be good to introduce to strongly typed langs. While js could mean one less language to learn, you may be able to use close to no js in the frontned. on the other side i have come to despise js

python maybe, or regular ruby if RoR is too much? (ror maybe actually the best option as it helps with the while db and all)

Is it possible to delay the hx-indicator ? If the request takes ie. < 500ms its basically only a flicker which doesnt make much sense. I couldnt find any option and failed to do it with a css transition. Any ideas?

Hm yeah I agree. I've been working with rails for 16 years and was just in the mood for something new lol 😅Thanks for responding!

I may have succeeded in hacking something in css that makes it work (using transition delays with visibility,opacity) but I still think there ought to be a better default in htmx

I've come to the exact same conclusion for forms as well

I agree. Ran into this a while ago and dropped the indicator altogether as it was making a bit of a mess for quick request-response cycles.

someone on my team just got bit by https://github.com/bigskysoftware/htmx/issues/1221

sorry to return and be like "here's a bunch of my issues"

lol

😑

it makes me feel like I bring value