Live data from Hacker News

Htmx Is the Future

quii.dev

851–860 of 875 posts

Re: Htmx Is the Future

#851

Earlier quoted context omitted.

this is a shallow and dismissive comment lacking any basic charity or nuance: dijkstra was just bad at “goto.” this doesn’t worry me, though. those in the react crowd that insist on this arbitrary and newfangled “frontend/backend” stratification and are dogmatic about it are by definition going to stick with what they know and won’t come and bother us who choose tools based on real experience and their practical meri…

"Frontend/backend" is neither new nor pointless. The people who pretend they are are usually backenders who are under the false impression that frontend is simple.

if you’ve been writing HTML since 1999 like me then it’s newfangled. in 2008 when i got my first paid job writing ASP and PHP at a web dev shop, nobody was “frontend”. there was the content person, the designer (photoshop wiz), the builder (convert design into HTML) and the dev. we still had to support IE6 or our manager would yell at us. i wrote my first SPA at work in 2011, and that was radical—everyone thought it was a bad idea. some people thought backbone.js might be a cool approach. took ages for react to appear.

took until maybe 2015 before i remember seeing any job ads of “frontend” positions, it takes a while before a job market develops around a technology.

i didn’t say it was pointless. i said the stratification of “dev” into “frontend dev” and “backend dev” is newfangled and arbitrary. you could also split devs into other classes (DB only, CSS only, etc.).

it is funny when people who don’t know you accuse you of incompetence because you don’t like their tools or methods. dogmatic. i prefer some other tools and methods and i am delivering value to customers. pragmatic.

Re: Htmx Is the Future

#852
post #2

Personally I believe strongly in thick clients but this is a pretty neat demo anyways. I see a lot of resemblance to http://catalyst.rocks with WebComponents that target other components. I think there's something unspoken here that's really powerful & interesting, which is the declarativization of the UI. We have stuff on the page, but making the actions & linkages of what does what to what has so far been trapped i…

> ...declarativization of the UI. We have stuff on the page, but making the actions & linkages of what does what to what has so far been trapped in code-land, away from the DOM. The exciting possibility is that we can nicely encode more of the behavior into the DOM, which creates a consistent learnable/visible/malleable pattern for wiring (and rewiring) stuff up.

Web “app” development finally catching up to where Visual Basic and Delphi were ~30 years ago, hurrah!

Re: Htmx Is the Future

#853

I just want Visual Basic for the web man. Screw writing lines of code. I want to point and click, drop complex automated objects onto a design, put in the inputs and outputs, and publish it. I don't care how you do it, I don't want to know any of the details. I just want to be able to make things quickly and easily. I don't care about programming, I just want to get work done and move on with my life. At this rate, w…

> I just want Visual Basic for the web man. Screw writing lines of code. I want to point and click, drop complex automated objects onto a design, put in the inputs and outputs, and publish it. I don't care how you do it, I don't want to know any of the details.

Do an Internet search for “Quartex Pascal”, and/or its creator, Jon Aasenden. He has a blog on WordPress, and a Facebook group. His crazy Quartex project is apparently nearing completion. It's an Object Pascal compiler and IDE — kind of a Delphi / Lazarus clone, if you will — that compiles to JavaScript, for the end product to be run in the browser. I think that's as close to “Visual Basic for the web” as one can get.

Re: Htmx Is the Future

#854
post #375

> HTMX is the Future I'm not seeing it. SPAs can be overly complex and have other issues, but I'm not seeing HTMX as a particular improvement. Also, a bunch of this article doesn't make sense to me. E.g, one of the listed costs of SPAs is managing state on the client and server... but (1) you don't have to -- isn't it rather common to keep your app server stateless? -- and (2) HTMX certainly allows for client-side an…

> SPA's also aren't inherently "very easy to make [...] incorrectly".

Judging from the ones one encounters in the wild, yes they are.

Re: Htmx Is the Future

#855

I somewhat get where htmx is coming from. It's not bad per-say.. I actually like the general idea behind it (it's sorta like Turbolinks, but a bit more optimal using fragments instead of the entire page, though Turbolinks requires zero additional work on the markup side and works with JavaScript disabled out of the box). With that being said, I imagine it would become unmaintainable very quickly. The problems htmx is…

> It's not bad per-say..

Per se. It's Latin for “in itself”; has nothing to do with saying anything. Think about it: What would “per-say” even mean?

Re: Htmx Is the Future

#856

Lol, we're still having the SPA discussion 7 years later in the year of our lord 2023? Talk about the positives of YOUR approach, don't tear down a different approach that half the industry is using. You're not going to say anything new or interesting to the person you are trying to convince this way. Experienced engineers already know the trade-offs between an SPA and a server rendered experience.

> Talk about the positives of YOUR approach, don't tear down a different approach that half the industry is using.

AIUI TFA wasn't by the creators of HTMX, so it isn't the author's approach.

Re: Htmx Is the Future

#857
post #452

I keep saying this and will say it again: what's really needed is a state-ful GUI markup language. HTML+DOM+JS+CSS is the wrong tool for the CRUD/GUI job, and force-fitting it has inflamed the area so bad many don't want to even try to scratch it. Bloated JS frameworks like Angular, React, Vue, and Electron have big learning curves and a jillion gotcha's because they have to reinvent long-known and loved GUI idioms f…

> Let's byte the bullet and create a GUI markup standard.

Heh, fun pun.

> Perhaps base it off Tk or Qt kits to avoid starting from scratch.

VCL / LCL.

Re: Htmx Is the Future

#858
post #368

I don't know. The tabs example on the htmx page is perceptibly slow to me. Making a rest call every time I switch a tab, each time sending 90% of the same html skeleton data over the wire feels like a sin to me. Returning html from my api also feels like a sin.

> Returning html from my api also feels like a sin.

Sorry, but that's just... Silly. HTML is what the Web is all about.

Re: Htmx Is the Future

#859

Earlier quoted context omitted.

And? Your average React dev is bad at proper backend too.

So then doesn't it make sense that frontend devs focus on frontend and backend devs focus on backend?

It makes sense that application developers focus on getting an application to work. In the case of these newfangled “Web applications”, that would be focussing on getting HTML to render in the user's browser. That focus doesn't have to have anything to do with an arbitrary split into “frontend and backend”.

Re: Htmx Is the Future

#860

Earlier quoted context omitted.

[flagged]

I'm sorry for saying something you disagree with. Next time I'll ask for permission to comment my opinion. Really, what's the point of your comment? At least state why you think I have no idea what I'm talking about, the way you wrote it adds literally nothing to the conversation.

[deleted]
Post reply on HN