301–310 of 520 posts
Earlier quoted context omitted.
[flagged]
You'd do well to read https://news.ycombinator.com/newsguidelines.html -- all that baseless assumption and disingenuous false accusation really isn't in any way civil or useful... but then when you're cheap enough to bring the Holocaust into a discussion about data protection legislation, you're really not in a position on ethics - or indeed anything else.
Earlier quoted context omitted.
The complexity is just shifted around from JS to HTMX (or hypothetically, html). Not a noticeable improvement.
With JS you must use JS or TS and the steam factory that comes with it. With htmx you can use any language. That's a very high improvement for many.
Can you elaborate on what you mean by this? Front-end framework don't care what language back-end logic is written in. For example, I have a Vue/Vite site that calls back-end functions that I'm gradually migrating from one language to another, and no front-end changes have been required.
Earlier quoted context omitted.
With JS you must use JS or TS and the steam factory that comes with it. With htmx you can use any language. That's a very high improvement for many.
> With JS you must use JS or TS and the steam factory that comes with it. With htmx you can use any language. Can you elaborate on what you mean by this? Front-end framework don't care what language back-end logic is written in. For example, I have a Vue/Vite site that calls back-end functions that I'm gradually migrating from one language to another, and no front-end changes have been required.
It's so odd to live long enough and see the steady pipeline of "look at this much simpler way of doing web apps, just write HTML, not like the previous complex way" projects, which then turn into the previous complex way as the eyes turn towards the next "simple way of doing web apps, just write HTML...". Angular and React started this way on the frontend, while ASP and PHP started this way on the backend (of course…
So many web revolutions touted as "don't use Java and all that big stack, instead use our SUPER SIMPLE stack called:"
Rails: wow did rails eventually encompass a massive stack of dizzying extensions options and frameworks.
React: I laughed when I saw basically a full rewrite of various Java unit testing frameworks in javascript.
But HTMX seems to get love that angular/react/etc never got from a HN front page perspective.
I take a dim view of AI so far, but one thing it could be fantastic for is "take this basic HTML application and write it in framework X" so I can finally see a good comparision.
The web framework landscape has needed a "reference web app" since the year 2000 where frameworks could demonstrate their way of doing rendering, layout, validation, forms, routing, error handling, data binding / data retrieval, tables/grids, media. As in your web framework isn't even close to prime time unless you can show WHY it is novel or useful.
Earlier quoted context omitted.
With JS you must use JS or TS and the steam factory that comes with it. With htmx you can use any language. That's a very high improvement for many.
> With JS you must use JS or TS and the steam factory that comes with it. With htmx you can use any language. Can you elaborate on what you mean by this? Front-end framework don't care what language back-end logic is written in. For example, I have a Vue/Vite site that calls back-end functions that I'm gradually migrating from one language to another, and no front-end changes have been required.
You can also do the same in Node if you want to, I currently have a TS website that is mostly templated HTML in production (without htmx). Htmx would be perfect for that site.
Earlier quoted context omitted.
Many of the ideas and concepts in htmx are things we worked on starting around 2012 at a top tier investment bank. Implementation details differ quite significantly, but the idea of hypermedia driven applications was core to everything we did. We unfortunately weren't able to win hearts and minds around these concepts in the long run, and blog driven development (a.k.a. cargo culting) replaced our efforts. I feel som…
Or it's because you weren't Facebook. Like angular, react got the huge initial boost in popularity because of the brand behind it.
React didn't get much adoption initially and FB didn't spend money on marketing their framework, like Google did with Angular. Developers started using React to speed-up table rendering in Angular application, and only after some performance-related blogposts adoption started to grow.
Earlier quoted context omitted.
> With JS you must use JS or TS and the steam factory that comes with it. With htmx you can use any language. Can you elaborate on what you mean by this? Front-end framework don't care what language back-end logic is written in. For example, I have a Vue/Vite site that calls back-end functions that I'm gradually migrating from one language to another, and no front-end changes have been required.
Yes, but you still need to write the frontend code in JS/TS
There's also WASM, which is slowly gaining steam, but it still isn't a first class citizen like JS is.
Earlier quoted context omitted.
Generating some HTML instead of JSON isn't that much data/CPU. But doing all that in the browser might have a big impact on UX performance-wise.
This doesn't make sense. Can you elaborate? If it's not much work for the server, why would it be work for the browser?
I started with Perl in ‘96 and have lived through what feels like everything — PHP, jQuery, Drupal, Backbone, Node, Angular, ClojureScript, React, GraphQL, and NextJS. Htmx feels like a divergence from the trend, and is worth thinking about. Htmx asks us a good question: “does the complexity of your work reside essentially on the server or essentially on the client?” The complexity for the vast majority of websites r…
> A hybrid approach is necessary.
This is "the islands" approach, as advocated by Astro, for example:
https://docs.astro.build/en/concepts/islands/
This approach is consistent with htmx and friends, and we're using it on an htmx project with simple vanilla JS for the pieces of interactivity. For small and medium projects and a small team, this can be enough, and it's a breath of fresh air to be able open up dev tools, point to part of a page, and understand everything there just by looking at the html and small snips of JS.