271–280 of 291 posts
Earlier quoted context omitted.
I thought the answer would be implicit in my question, but it's not very difficult to find an explicit answer, it's the second essay on the essays page: https://htmx.org/essays/when-to-use-hypermedia/#if-you-requi... Having said that, for a time-tracking application, personally I wouldn't be OK with the risk of a browser screw-up (e.g. site data deleted, malware hoses the browser) losing tracking data. But you do you…
I mean, they use Google sheets or another web app already, so....
You and I don't have the same constraints and resources as Google.
Earlier quoted context omitted.
With evergreen browsers, you can write modern JavaScript and it'll run in the browser just fine. And it's not like TC39 is pumping out lots of wild changes. The largest recent change is what, top level await? That's not exactly a wildly different language feature. A lot of this JavaScript criticism was appropriate circa 2017, but these days JavaScript's gotten a lot more stable.
Sure. With evergreen browsers. For anyone using old devices with outdated hardware--tough luck! They can, I guess, go buzz off and leave you in peace to write Modern JS. After all, that's the most important thing.
Earlier quoted context omitted.
That’s a bubble. You are in a bubble. React is dominant, sure, like the US is dominant, but it’s not The World.
The important part is that it's a bubble you can choose to live in. Companies everywhere use React and almost no one need ever choose to learn something else. As long as you know it you will be employable for another 20 years, just like with Java.
Earlier quoted context omitted.
What I hate is that you don't even write JavaScript anymore. You write fantasy future JavaScript. Sure, it will be available in ECMAScript 23, scheduled to drop in real browsers in 2092. But for now, here's a convoluted mess of polyfills, Babel, and WebPack, that we HOPE papers over the real behaviour of browsers, and suddenly your test-and-debug cycle has introduced a flow-shattering 15-second build cycle each time…
This is my problem with a lot of HN comments about JS: they read like they were written in 2014 (see also the “a new framework every week!” jokes) ES2015 was the one big language update, and although it took a while to all roll out and for older browsers to die off, at this point we’re now living in “the future” and almost all language changes are incremental. Like, you can write ES modules with async/await and run i…
Not everyone is on a greenfield project with full authority to grab the freshest and latest. Some of us are effectively living in 2014-- they can't say "no, you can't use IE11" to paying customers, or committed to a platform at the wrong phase of maturity, and remain stuck around a state-of-the-art-in-2014 build process.
Earlier quoted context omitted.
All your endpoints are delivering partial HTML instead of JSON and you can switch to, say, React for your next feature? I mean, you technically can, but for that amount of work and/or friction you can pretty much go between any 2 frameworks.
There is nothing preventing you from having new endpoints serve frontend JSON, or from refactoring select endpoints away from HTMX. If you are refactoring everything because a small subset of features didn't fit the HTMX glove, that's an engineering management failure.
Earlier quoted context omitted.
For a certain kind of application HTMX is a convenient way to work. It lets you write a webapp the way you did in 1999 except you can update pages partially. Here is a screenshot of an my HTMX-powered RSS reader https://mastodon.social/@UP8/110432673973724419 This is a research project, but it's a research project by an applications programmer so it has to be solid. Yet I have to be able to change anything when I wan…
Hey! I'm also building an HTMX-powered RSS reader, although it's more a side project than a research project. Good luck, it's been lots of fun for me so far! I've also found the productivity of a "strong" decoupling from frontend and backend to be super satisfying.
Suppose you want to add a ‘plug-in’ such as a new social media share button: often this is going to involve front and back end changes. In my RSS reader this could be a python package with declared entry points so the application could read it, enabling a few more http endpoints and also adding templates to extension points.
In a ‘standard model’ application you need to have an npm package and a Python package and corresponding extension mechanisms on both sides. You can probably make a system that wraps an npm package inside a Python package or maybe the other way around but it will be a struggle.
(The architecture of my current system was inspired by a system I worked in that not only used Scala, Typescript and Python but also Docker such that builds took 20 minutes! They could afford to do that on a venture capitalist’s dime but I can’t.)
Earlier quoted context omitted.
Isn't this comparable to any other situation where you reference something outside a project, even in C with libraries? (I've never used HTMX or even looked beyond this page for it, so maybe what I'm about to say is logically wrong.) If I said that for an HTMX project you must define all components you use within the project, wouldn't this hx-target example be very easy to identify quickly in the project? You simply…
if you decided to write C by building a lot of tiny global functions with no local state that called other globals functions, then it would greatly resemble programming with GOTO.
Isn't that Haskell?
Earlier quoted context omitted.
What would be a simple example of an event that you want to define inline but can't in plain html? Can you give minimal example on jsfiddle so we can compare different approaches?
Here you go: https://plnkr.co/edit/DQJrBWWQFgHtpltf?open=index.html&previ... Another big aspect of allowing to handle any event is integration with other JS libraries. See this basic example of interacting with Sortable JS [1] Also, htmx has a response header called `HX-Trigger`[2] which lets server trigger custom events on the client and you can handle those events as well[3]. This is quite useful if you have interd…
Earlier quoted context omitted.
Gulp is extremely out of date these days. Using webpack resulted in some of the most painful experiences of supporting serious production software in my career. The progress and maturity of JS tooling/DX as a result of stuff like esbuild and Vite, or Typescript more generally, can not he understated. For people not doing frontend it can seem like a neverending series of new stuff but there is a very rational and tang…
Gulp / Babel and then transition to webpack was my introduction to JS. Now Vite seems to be all the rage? But is it a bundler? Wepack seems to be very hard to configure. Looks like nginx config vs caddy config.
Rather, one would opt for something like vite, the spiritual successor to react-scripts, that bundles all of these tools together with some good defaults/plugins, a means to configure them, and usually also some kind of dev server with hot module reloading, for a complete developer experience using your preferred toolchain.
Check out 'parcel' for something pretty modern, universal, and low effort, IMHO.