You can achieve a great deal of interactivity with pure get/post requests, along with a sprinkling of javascript one-liners and maybe alpine.js if client interactivity is important.
Yes, but doing with just HTMX, a framework we're talking in this thread, would be very painful.
Every project I started with alpine.js eventually transitioned to something heavier because it was hard to maintain once you're having something more interactive than an accordion or sliding drawer.
Well agree to disagree. To me, it felt like HTMX was a wrong tool for anything other than pure server side representation (i.e. a little bit more advanced than refreshing entire page on new data).
I guess it's easier if you move all client logic to server, but I didn't want backend to know about web representation details.
anything where you need popups or tiled windows, code editing, rich text features more complex than "render markdown into a div", heavy content like videos, multiplayer, real time chat, anything that has to work offline... htmx is only good enough for something like a company homepage or simple shop not big complicated apps. its actually the same reason i dont like htmx, the whole "true REST" approach is about making everything depend more on the server with a thin client that can only do a couple very simple things with the loaded page. if your connection to that server is slow or unreliable your whole app breaks.
its also the perfect opposite of "true web3" and ethereums original vision, where you load all static assets from ipfs, most app logic is client side and the server or blockchain only comes in (json api, no html fragments or full pages) when you need to interact with other users. still believe in it even after the crypto bros took the name for a bunch of scams and hosted everything on cloudflare anyway. the only thing they have in common i could find is no bundling but for different reasons - everything on server vs compiled libraries shared between apps.
slow/unreliable connections - well yeah this is a problem for any app...if you're delivering a 2MB paylaod to start the web app so that it doesn't need a connection, you're just betting that the user has a fast connection initially. what if that's not true either? back to square one. REST/Hypermedia encourages sending small payloads and working within those real constraints
I have no idea what you're talking about with "true web3 and ethereum". HTMX has nothing to do with web3 or crypto.
There is no moral excellence but which you invent for yourself. But given the first principle or goal of 'having the most impact', maximizing money is often quite useful.
This isn't a good example - people were completing 6-month bootcamps and getting $100k offers to do web development not too long ago, decades after the web and HTML took off. After a few years they were making as much as anyone who learned HTML and Web 1.0 back in the 90s.
Are the bootcampers better developers? Probably not. But they still were employable and paid relatively the same.
What bullshit essentially misrepresents is neither the state of affairs to which it refers nor the beliefs of the speaker concerning that state of affairs. Those are what lies misrepresent, by virtue of being false. Since bullshit need not be false, it differs from lies in its misrepresentational intent. The bullshitter may not deceive us, or even intend to do so, either about the facts or about what he takes the facts to be. What he does necessarily attempt to deceive us about is his enterprise. His only indispensably distinctive characteristic is that in a certain way he misrepresents what he is up to.
Also related - Gish-gallop
During a typical Gish gallop, the galloper confronts an opponent with a rapid series of specious arguments, half-truths, misrepresentations, and outright lies, making it impossible for the opponent to refute all of them within the format of the debate.[2] Each point raised by the Gish galloper takes considerably longer to refute than to assert. The technique wastes an opponent's time and may cast doubt on the opponent's debating ability for an audience unfamiliar with the technique, especially if no independent fact-checking is involved, or if the audience has limited knowledge of the topics.[3]
Gish-galloping! Today I learned, I'm going to have to remember that one. I think people can also gish-gallop unintentionally; especially in online discussion threads. When someone leaves comments that are very long, poorly organized, and more stream of consciousness.
Hot take: you can't have your cake and eat it too. If you aren't writing code, designing the system, creating architecture, or even writing the prompt, then you're not understanding shit. You're playing slots with stochastic parrots
The code grows beyond my usual comprehension, I'd have to really read through it for a while. Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away. It's not too bad for throwaway weekend projects, but still quite amusing. I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.
There's a new kind of coding I call "vibe
coding", where you fully give in to the
vibes, embrace exponentials, and forget
that the code even exists.
Not all AI-assisted programming is vibe coding. If you're paying attention to the code that's being produced you can guide it towards being just as high quality (or even higher quality) than code you would have written by hand.
It's appropriate for the commenter I was replying to, who asked how they can understand things, "while having never even read most of their code."
I like AI-assisted programming, but if I fail to even read the code produced, then I might as well treat it like a no-code system. I can understand the high-levels of how no-code works, but as soon as it breaks, it might as well be a black box. And this only gets worse as the codebase spans into the tens of thousands of lines without me having read any of it.
The (imperfect) analogy I'm working on is a baker who bakes cakes. A nearby grocery store starts making any cake they want, on demand, so the baker decides to quit baking cakes and buy them from the store. The baker calls the store anytime they want a new cake, and just tells them exactly what they want. How long can that baker call themself a "baker"? How long before they forget how to even bake a cake, and all they can do is get cakes from the grocer?
> Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away.
It's insane that this quote is coming from one of the leading figures in this field. And everyone's... OK that software development has been reduced to chance and brute force?
There are two ways to approach this. One is a priori: "If you aren't doing the same things with LLMs that humans do when writing code, the code is not going to work".
The other one is a posteriori: "I want code that works, what do I need to do with LLMs?"
Your approach is the former, which I don't think works in reality. You can write code that works (for some definition of "works") with LLMs without doing it the way a human would do it.
It means that just because a human can't read the code doesn't mean the code is not correct. Obfuscators exist, for example, and it's conceivable that the LLM writes perfectly correct code even though it's unmaintainable to us.
Thanks, that's a good insight into my value system then. I understand that code doesn't have to be human-readable to be correct. I don't want to work on a codebase filled with unreadable code which no human colleague understands though. This is also why I don't like a lot of web frameworks - the final code outputted to the page is a huge spaghetti of un-inspectable Javascript and HTML.
I want to have the ability to understand each relevant layer of the system, even if I don't necessarily have the full understanding at every given moment.
Also, to add to my point earlier: You don't like frameworks but it's frameworks all the way down to microcode, and that's a massive amount of layers. Javascript isn't an absolute source of truth, you're just picking one layer out of the entire abstraction stack and saying "this is good enough for me".
It's perfectly fine to do that, but also realize that other people might just choose a different layer, and that's fine too if the end result fulfills its purpose.
Sure, but that's more your preference than an objective way to do software "correctly". We're still figuring out what the latter means when LLMs are involved (hence my article here).
the hardware you typed this on was designed by hardware architects that write little to no code. just types up a spec to be implemented by verilog coders.
reply