8 ms·
On a reasonably fast connection, I hit the increment button and it took almost two seconds for the counter to increment. Is it immediate for everyone?
by underdeserver 2y ago
On a reasonably fast connection, I hit the increment button and it took almost two seconds for the counter to increment. Is it immediate for everyone?
- Akronymus 2y agoIt's instant for me.
- arethuza 2y agoSeems instant to me and when I checked in the Firefox debugger the network calls are taking between 30ms to 50ms to respond.
- Difwif 2y agoSame. I know this is unfair but it made me subconsciously write off the framework. OP, this is purely marketing feedback but try to make the button fast. Love the direction you're taking, good luck!
- meiraleal 2y agoThat's not really unfair. This trend about moving frontend things to be processed in the server is "coincidentally" what the big cloud providers need to keep hitting their quarterly goals.
- oefrha 2y agoTotally depends on your latency to the server and server response time. Please don’t throw away two decades of client side advancements and do this for state changes that should be entirely local, people with higher latency will hate your guts. Use alpine or something like that if you don’t want to go full react/vue/svelte/solid/etc. It’s utterly terrifying that I now see this pattern evangelized every day. As an aside, I hate websites/apps sending HTML fragments like it’s 2005 because it’s much harder to pull data or automate things that way. But that’s usually considered an upside for developers who want to combat scraping. In practice it’s hardly a road bump for devoted scrapers, and actually increases server load for the same amount of data pulled, but it’s still considered a win by many.
- allknowingfrog 2y agoI've been following projects like Hotwire and HTMX for awhile now, and I haven't seen anyone argue that scraping is a major reason to adopt this approach. I also don't see a lot of opposition to the idea of incorporating something like alpine to add some UI niceness. What you see as a "terrifying" disregard for "two decades of advancements", others see as a liberating departure from two decades of unnecessary bloat. It's healthy to have more than one strategy available for building web applications.
- meiraleal 2y ago> others see as a liberating departure from two decades of unnecessary bloat Is moving the bloat to a blackbox in the backend really a better approach? Why not just not create a bloated frontend?
- p_l 2y agoBecause it might be in fact easier and simpler to implement it on backend?
- allknowingfrog 2y agoUsing htmx allows you to completely skip a layer of JSON serialization and parsing. It eliminates the complexity of maintaining a second, frontend application, as well as all of its build tools and dependencies. It even opens up the freedom to work exclusively in your preferred language. All of these are examples of removing elements, not just hiding them somewhere else.
- midairthief 2y agoFor me it takes around 200~300ms and occasionally ~800ms, not too long but enough to make it noticeable and feel weird.
- I_o_IllI__o_I 2y ago[dead]
- khasan222 2y agoThis is to me a non starter. Why does the server care what that im incrementing the local data? None of that is likely important until I am done. This is just one more layer on top, and one more possible point of failure/frustration, as illustrated by this parent comment.
- p_l 2y agoBecause you're incrementing server side data, not local. Which doesn't matter for trivial counter examples but the same technique is something I've used (not with ludic, but with HTMX) to trigger actions in physical space.
- itishappy 2y agoNo. It's fast, but not immediate. It's annoying but not unusable. Worse though, it starts dropping repeated clicks. Triple click increments counter by 2. Unfortunately, this is unusable.
- p_l 2y agoIt is honestly a bit too limited example. One way to handle it is for example to appropriately "lock" transaction on HTMX side, which is not done here.