481–490 of 533 posts
Earlier quoted context omitted.
You haven’t had to deal directly with JS on front end since Dart released over 10 years ago
Dart hasn’t been much better in my experience, but you have reminded me to revisit Kotlin/JS!
Earlier quoted context omitted.
> Rails has a library that will refresh the page when files change without a full reload What if you have a modal opened with some state? Or a form filled with data? Or some multi-selection in a list of items that triggers a menu of actions on those items? Etc. And it's true Vite can't always do HMR but it's still better than the alternative.
> What if you have a modal opened with some state? Stimulus controllers can store state. > Or a form filled with data? Again, you can either use a Stimulus controller, or you can just render the data into the form response, depending on the situation. > Or some multi-selection in a list of items that triggers a menu of actions on those items? So, submenus? Again, you can either do it in a Stimulus controller (you can…
Yes, obviously, but do these maintain state after hot reload?
Earlier quoted context omitted.
> The little image preview can be a tiny "island of JS" if you have to have it. I would consider that the bare acceptable minimum along an upload progress indicator. But it can get a lot more complicated. What if you need to upload multiple images? What if you need to sort the images, add tags, etc? See for example the image uploading experience of sites like Unsplash or Flickr. HTMX just ism't the right tool to solv…
None of what you described requires anything more than an isolated island with some extra JS. No need for complex client-side state, no need for a SPA framework, no bundling required, not even TypeScript. If you relied on DOM and a couple of hidden fields, 90% of this would be a few dozen lines of code plus some JSDoc for type safety.
Please implement a multi image upload widget and then come back to argue about this.
Earlier quoted context omitted.
Yeah, I don't know how someone can say that with a straight face to other engineers. It's like people just talk in memes or something. This is how a lot of discourse feels these days. People living in very different realities. Though in this case, seeing the most complex C++ app they've built would illuminate what's going on in theirs.
It's not a different reality. To give perspective to what JS I've dealt with - I worked a couple years on a legacy webapp. It used vanilla JS and the only library used was jQuery. It heavily used iframes for async functionality in combination with XSLT to translate backend XML apis to HTML. Opening up a 10K lines JS file is like jumping into the ocean. Nothing is obvious, nothing makes sense. You're allowed to just d…
I think that’s a feature not a bug.
But then again, I generally like and use Typescript.
Earlier quoted context omitted.
A lot can be said for just putting a "back" button a page. I still do it occasionally for this very reason. Then again, my user base for the apps I write are the most non-technical folks imaginable, so many of them have no concept of a browser back button to begin with. I am not being hyperbolic either.
Thing is, the browser back button is still there, though. So now you have two identical buttons that do different things. And that's really bad UX.
Earlier quoted context omitted.
It is fine, though.
No, it’s footgunny and riddled with bugs. Most JS barely works and edge cases just aren’t addressed. I’ve seen undefined make it all the way to the backend and get persisted in the DB. As a string. JS as a language just isn’t robust enough and it requires a level of defensive programming that’s inconvenient at best and a productivity sink at worst. Much like C++, it’s doable, but things are bound to slip through the…
Earlier quoted context omitted.
I think the DX is significantly better as well with fast reload… As a user, the typical SPA offers a worse experience. Frequent empty pages with progress bars spinning before some small amount of text is rendered.
This exactly. It seems like the last 10 years of JavaScript framework progress has been driven by DX, not UX. Like at some point everyone forgot this crap just needs to work at the end of the day, no user benefits from 3 rewrites over 5 years because the developer community decided functions are better than classes.
Earlier quoted context omitted.
10s is painful. A server-rendered app should be able to deliver that data, already rendered, in closer to a fifth of a second. Fast enough that the user doesn’t even notice any wait.
> 10s is painful. A server-rendered app should be able to deliver that data, already rendered, in closer to a fifth of a second. How do you know how large the dataset is? All you know from my post is that a dataset that takes 10s to download (I'm indicating the size of it here!) takes under a second to filter and sort. My point is that if your client-code is taking long to filter and sort, then your dataset is alread…
Earlier quoted context omitted.
What do you like about HTMX? I coming from a world of plain JS usage -- no SPAs or the like. I just felt like HTMX was just a more complicated way to write what could be simple .fetch() requests.
I like that it still feels like html. I think that's it's biggest selling point. You write: Send Compared to (ChatGPT helped me write this one, so maybe it could be shorter, but not that much shorter, I don't think?): Send async function handleSubmit(event) { event.preventDefault(); // the form submit stuff const form = event.target.form; const formData = new FormData(form); const submitter = event.target; if (submit…
Going with your example, how would you do proper validation with HTMX? For example, the input element's value cannot be null or empty. If the validation fails, then a message or something is displayed. If the validation is successful, then that HTML is replace with whatever?
I have successfully gotten this to work in HTMX before. However, I had to rely on the JS API for that is outside the realm of plain HTML attribute-based HTMX. At that point, especially when you have many inputs like this, the amount of work one has to do with the HTMX JS API starts to look at lot like the script tag in your example, but I would argue it's actually much more annoying to deal with.
Earlier quoted context omitted.
What do you like about HTMX? I coming from a world of plain JS usage -- no SPAs or the like. I just felt like HTMX was just a more complicated way to write what could be simple .fetch() requests.
maybe check out fixi.js: https://github.com/bigskysoftware/fixi
After enough of the HTMX JS API, I figured, "What is HTMX even buying me at this point?" Even if plain JS is more verbose, that verbosity comes with far less opinions and constraints.