Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx in a Nutshell

htmx.org

Post reply on HN
Print view View original

261–270 of 414 posts

Re: Htmx in a Nutshell

#261

Post by scoofy »

sureglymop wrote: post #241
scoofy wrote: post #236

Earlier quoted context omitted.

Not yet. Eventually, but right now it's just a hobby trying to become a business, and until I get a big enough database to provide a moat, I'm a bit nervous about giving it away for free. I'm not sure if that's the best course of action, but I'm just a guy who's a bit embarrassed to really like to programming in python and playing golf.

I completely understand, best of luck with your project! I was looking for an example authentication implementation in htmx that's why it caught my attention.

I don't use it for that since it's a wiki. I just use a typical sign in page and flask session (which i think is an HMAC hash cookie), but users can obviously edit the wiki without signing in, though with some serious restrictions to discourage vandalism.

Re: Htmx in a Nutshell

#262

Post by lmm »

icedchai wrote: post #203
kkapelon wrote: post #195

Earlier quoted context omitted.

While I would love to argue whether DropWizard is a framework or not there is no need for that. Just go to google trends and compare Spring and Dropwizard. Or look at https://www.jetbrains.com/lp/devecosystem-2021/java/ . Dropwizard doesn't even appear in the list of web frameworks. I mean, if you still believe that Java has as many frameworks as Javascript has (and had in the past) there is nothing I can say that wi…

I've been using Java on and off since 1996. It absolutely has had a ton of frameworks over the years. Yes, I realize many of them are niche or no longer in use, but that doesn't mean there isn't a legacy application where you have to maintain 10 or 20 year old garbage. FYI, I despise both J2EE and Spring. (Maybe Spring Boot is okay.)

Spring Boot is recapitulating the worst parts of old (like, 3.0-era) Spring. It's the biggest step backwards in programming history since... I actually can't think of anything worse.

Re: Htmx in a Nutshell

#263

Post by lmm »

xmonkee wrote: post #86
t8sr wrote: post #75

I'm confused about what value this adds. The introductory example is certainly not helpful, as it takes an ` Blog ` and turns into 7 lines of markup to accomplish the same thing. (And then it says a bunch of things that are arguably not desirable, like "any element can now trigger requests".) Like: what's the point of using this over HTML5+js? I've spent 15 minutes reading the website and I still don't understand why…

Consider the case of calling your backend with a POST call and then updating your app in response. Typically, for a SPA: your backend would return some data, and your frontend would then figure out how to update your html in response to it. For a multi-page-app: your backend will redirect the user to a whole new page with new HTML. This is somewhere in between: Your backend will send just a little bit of HTML and you…

Hmm so like how Wicket Ajax works, but as something you can bolt on to any framework? That's cool, although I'm not sure how well it would work if the framework isn't component-oriented in the first place.

Re: Htmx in a Nutshell

#264

Post by silver-arrow »

taolegal wrote: post #214
t8sr wrote: post #97

Earlier quoted context omitted.

Replying to myself: I guess the main point of this library is to use HTML as the protocol payload between serve and client, instead of JSON. I can see the benefit of doing that, although I have a bone to pick with the condemnation of all data APIs because JSON is awful. Protocol buffers, for example, are trivially forward and backward compatible and mostly self-describing. Also if you build stuff on top of hypermedia…

> I guess the main point of this library is to use HTML as the protocol payload between serve and client, instead of JSON HTTP is named Hypertext Transfer Protocol after all. Exchanging schema-less JSONs is conceptually pretty lame. It's plain old RPC architecture. That's why we end up needing to write API docs to line up the frontend and backend, or otherwise inspect backend code to figure out what's being handed ov…

This answer is exactly correct. You must really think about how this dramatically makes developing these types of applications simpler by a magnitude. You are literally killing significant complexity that causes time, effort, and bugs. And, no, this is not merely shifting the problems back to the server-side. This is how HTML should have evolved in the first place.

Re: Htmx in a Nutshell

#266

Post by recursivedoubts »

modernerd wrote: post #265
recursivedoubts wrote: post #2

howdy, I'm the creator of htmx, happy to talk about it

Is htmx a good fit for Electron apps? Curious to know if anyone in the community is actively using it that way.

i have heard that people are using it in electron, but it seems a little crazy to me

Re: Htmx in a Nutshell

#267

Post by recursivedoubts »

hexmiles wrote: post #218
recursivedoubts wrote: post #2

howdy, I'm the creator of htmx, happy to talk about it

Hi, on the subject of hypermedia: I recently saw your talk when you showed hyperview.org as an alternative to HTML for mobile use case. As someone who is very interested in the space, are there other hypermedia implementation (if is the right word) that you found interesting? Or do you have some pointer for those who want to explore this space? Personally I really want some kind of hypermedia framework for terminal a…

heya, i don't know of any terminal-based hypermedia, but that's an interesting concept

maybe gopher as a prototype example?

adam stepinski (creator of hyperview) is one of the heroes of hypermedia in that he didn't just develop a hypermedia format but also developed a hypermedia client, and you need both for a proper hypermedia system

so, I would say... maybe you are lookin' at the person in the mirror who is going to make that terminal app hypermedia?

Re: Htmx in a Nutshell

#268

Post by qudat »

leetrout wrote: post #3

I am burnt out (but recovering!) with web dev and htmx is what I am using for my project. Django, DRF, Postgres, tailwind and HTMX. I am so tired of all the front end frameworks and all the complexity that gets added. At some point I think you need it and you get returns from it but hearing more people in the industry recognize and talk about how JS everything isn't always the answer gives me hope. I like what HTMX h…

I’m pretty burned out by devops and backend solutions. I think the number of cloud native services and tools is similar if not more exhausting than FE in terms of depth and complexity.

Re: Htmx in a Nutshell

#270

Post by getcrunk »

toinbis wrote: post #252

I guess it's important to note that in many cases you'll be willing to pair htmx with either alpine.js (using https://htmx.org/extensions/alpine-morph/ ), or with hyperscript ( https://hyperscript.org/ , developed by same team as htmx). Things that don't require request to server - managed by alpine, things that do require - by htmx. There are situations where both tools can be used, one has to pick.

I’ve been looking for alpine and forgot what it was called, have come across it some time ago. I knew I would find it in the comments on this post as it’s kind of like htmx. I didn’t even know the same people made both!
Post reply on HN