Hacker News Reader

Comment by sbarre | Hacker News Reader

My concern with this approach is that frameworks encourage consistency and give everyday developers access to at least some best practice patterns. And there's no reason for developers working on a business application to have to reason about standard patterns like caching, components, data storage, etc..

If you just go with "vanilla" HTML/Javascript, what will inevitably happen is that you will end up with a homebrew internally-developed framework anyways as people save and re-use patterns and start building ad-hoc tools and libraries, and that homebrew framework will inevitably be much worse (and poorly documented) when compared to a well-tested existing open source framework like React or others.

View on HN

That is all very true, but are you prepared to take over maintenance of a React fork in the future? Or perhaps attracting developers will hard, using an antiquated framework 10 years down the line.

My point is, you're going to pick "the wrong framework" regardless of your choice. There's going to be issues one way or the other.

Perhaps the safest way is something like htmx, where the heavy lifting is done by the backend, you're stuck with that regardless, and if you need to do a fork, then it's a minimum of JavaScript to maintain.

I don't think front-end is going away anytime soon. I would put good money on React being around in a decade or even longer.

Either way, no one has a crystal ball and trying to make decisions today that account for a problem you might have 10 years down the road feels like a bad way to go about things.

Find a proven well-supported solution that works today. Hence my comment about building on the shoulders of giants by adopting a robust popular open-source framework - so your team can just get to work on what matters to the business, and not worry about re-inventing the wheel on the underlying common tooling that already exists.

Then keep an eye on where things are going and don't fall too far behind on your updates.

Staying on top of your technical health/debt and remaining current as technology evolves should be baked into your strategy anyways, regardless of what tooling you choose.

I think this can apply to any technology decision.

HTMX is in NO way a replacement for frontend libraries. If you can achieve what you wanted to do with HTMX you didn’t need any frontend framework to start with.

Also, repeating this again… the hype and the marketing from HTMX is something I never thought I would see, it’s worse than vercel’s

i think that depends on what you mean by "frontend framework"

consider the following examples:

Bulk Update - https://htmx.org/examples/bulk-update/

Infinite Scroll - https://htmx.org/examples/infinite-scroll/

Active Search - https://htmx.org/examples/active-search/

unless you adopt the tautology that anything you can accomplish with htmx automatically means you didn't need a frontend framework, i think many people would expect that accomplishing UX patterns like this would require a front end framework like react or similar

on the marketing front, i don't know what to say. I try to be funny on twitter, but I've been doing that forever and nobody cared. ThePrimeagen and Fireship Dev started covering htmx in July which was a big bump, and the Github Accelerator helped too. I think i mostly got lucky: right place, right time, right vibe. I don't spend any money on marketing and I don't have any VC or FAANG backing.

Pretty sure htmx is a framework, it adds a new abstraction on top of HTML to integrate server rendered templates. You can then amend it with some UI library (e.g Material) on the front to make it all look nice.

it's kind of a semantic argument

the distinction i like between "library" and "framework" is:

* a library you call into

* a framework calls back into code you provide

Using this definition, from a javascript perspective, htmx can be considered a framework, since you are providing "code" (well, html attributes) that it is hooking up event handlers and calling back into.

However, from an HTML perspective, htmx is a library, in that you "call" into the htmx code by "invoking" attributes.

I lean towards calling htmx a library because I have a bias towards the HTML-first interpretation of htmx, but I admit that you could easily justify the other interpretation of htmx.

Reply on news.ycombinator.com