441–450 of 530 posts
I'm a big fan of returning html instead of json when possible and I've been htmx curious for a bit. With all the examples people keep using, I assumed it would be way smaller. 16kb minified is a lot. Looking at the docs just now the core api seems reasonable, but it a lot larger than I'd assumed.
I'd bet that almost any site which isn't intentionally bare bones will have a lot more than 16KB of JS.
Earlier quoted context omitted.
> No Jobs > Another practical reason not to use htmx is that there are, rounding off, zero htmx jobs. > I just did a search for htmx jobs on indeed and found a grand total of two: one at Microsoft and one at Oak Ridge National Laboratory. > A search for “react”, on the other hand, gives 13,758 jobs. > Seriously, developer, which of these two technologies do you want to hitch your career to? I do not advocated for htm…
I think the number of job postings is pretty related to factors that I do consider valid when selecting a piece of technology (eg: language, framework, etc): - How easy is it to hire people with experience in this? - Relatedly, how easy will it be for the org to maintain this software after I (or the original team) leaves?
When NoRedInk switched to Elm, Richard Feldman, who was asked about whether this impacted their hiring experience in any negative way, said that on the contrary, hiring had never been better, because although the pool of candidates grew smaller, their quality (either prior experience of working with type-safe functional programming languages, or enthusiasm for learning them) got higher.
When Alex Russell announced several openings at Microsoft for development of design systems with web components, and certainly no react, he said this attracted a lot of really strong candidates.
I am not saying that a good web developer should be able to pick up any exotic language, such as elm, or purescript, or rescript, or clojurescript at no time; but what I am saying is that as far as web frameworks are concerned, they shouldn't be a criterion for hiring, and are unlikely to become an obstacle to it.
Earlier quoted context omitted.
As you should be able to tell from the other comments, this is not a library for me. If I had ever looked into it past trying to actually implement it, I would have realized that it's actually specifically for server-rendered content and using it for front-end development doesn't actually add much. The author made that very clear in the supporting documentation, I just never bothered to check. So I relayed my persona…
> it's actually specifically for server-rendered content and using it for front-end development doesn't actually add much It's for server-rendered content that can be used to build a frontend app. I know because I've done it several times. > I would also have to write custom JS for the functions I would try to invoke with htmx The difference is with invokers you would have to re-implement everything from scratch and…
glad you're enjoying your framework, friend!
Earlier quoted context omitted.
For sure the author had an idea and went to the LLM to produce the post. And I'm aware of those prior sites (some of which are linked at the bottom.) I mean nothing is straight LLM, you must prompt them and people are putting their ideas in and linking to other sources and getting stuff like this out. And hopefully editing or iterating, but not enough it would seem most of the time. I'm saying their perspective doesn…
I get it. Sorry if I wasted your time.
The second half of the video is great too, I love seeing the actual prompts that go into the LLM.
And I don't think you wasted my time, I'm sorry if "you're not a person" came off directed at you, when my complaint is really that I couldn't find you through all the tokens. I'm glad the video remedied that.
Earlier quoted context omitted.
There is a cert, it's just not signed by a CA.
That's in some sense even worse than plain HTTP, because it gives you a false sense of security.
May not be as standard as a CA model in the current landscape, but trust on first use has shown to be perfectly fine for SSH, and has the advantage that you're not trusting third parties to only sign valid certificates for authorized parties.
Earlier quoted context omitted.
> Resume-driven development should not be a thing. Pretend this is not about library choice, but rather about language choice. One language has 2 jobs, and the other language 13k jobs. I doubt you'd think for more than a second.
> One language has 2 jobs, and the other language 13k jobs. I doubt you'd think for more than a second. The Hacker News website runs on Lisp. How many jobs do you see on the market that ask for Lisp? And yet, for what it is, this site is amazing! I don't see them rushing to migrate to a python backend and a react-based frontend, no matter how many jobs there are for those.
You mean the message board? The website that has a grand total of 2 functions: post and comment?
> And yet, for what it is, this site is amazing!
It's 2 colors and text. That's it.
> ! I don't see them rushing to migrate to a python backend and a react-based frontend, no matter how many jobs there are for those.
It's A MESSAGE BOARD. A. MESSAGE. BOARD.
Earlier quoted context omitted.
> One language has 2 jobs, and the other language 13k jobs. I doubt you'd think for more than a second. The Hacker News website runs on Lisp. How many jobs do you see on the market that ask for Lisp? And yet, for what it is, this site is amazing! I don't see them rushing to migrate to a python backend and a react-based frontend, no matter how many jobs there are for those.
this site can also vibe coded in seconds.
It's a list of articles and comments. It would take like 3 pages from W3Schools to build this thing.
This is a retarded advice. Author clearly never tried to develop any serious web development. > the build time is over 30 seconds! that's silly. 30 seconds building time is nothing compare to the accumulated time you wait for micro changes to your frontend. for typical web development using react/vue/svelte you have hot code reloading, which can reload the current website for htmx to update, you have to wait for your…
Only backend developers that think frontend is trivial and we’re all just idiots think that HTMX is the solution. They saw it working in their hello world side project and think they discovered gold.
Earlier quoted context omitted.
> Resume-driven development should not be a thing. Pretend this is not about library choice, but rather about language choice. One language has 2 jobs, and the other language 13k jobs. I doubt you'd think for more than a second.
One language - JSX - has 10 jobs. The other language - HTML - has over 30,000 jobs
I feel like only a backend developer trying to score "gotcha" points could make this argument and be confident about it.
Earlier quoted context omitted.
That's in some sense even worse than plain HTTP, because it gives you a false sense of security.
Not really, modern browsers warn about self-signed certificates the same as HTTP (or sometimes even more). And obviously you can in theory verify the signature's fingerprint akin to a trust-on-first-use model like SSH. May not be as standard as a CA model in the current landscape, but trust on first use has shown to be perfectly fine for SSH, and has the advantage that you're not trusting third parties to only sign v…
> modern browsers warn about self-signed certificates the same as HTTP
So if I can read and understand those browser warning and am not a complete idiot, I will close the browser tab instead of proceed despite the warning. Which is the correct choice.
So now I cannot read the website at all.
Otherwise, if I do make the bad decision and accept the certificate, I don't know what will happen. But with HTTP, at least the browser says clearly that the site is unsafe.
So the fact that the website does have a certificate and serves HTTPS, as suggested in the GP, is completely irrelevant and useless.
> trust on first use has shown to be perfectly fine for SSH
If that is MY server or a server I trust/can verify. I don't know about you, but I never SSH into someone else's server and just blindly accept the keys. GitHub, for example, provides their SSH keys: https://docs.github.com/en/authentication/keeping-your-accou...