Hacker News Reader

Comment by benatkin | Hacker News Reader

I think what you're saying demonstrably doesn't apply to the majority of developers. You could follow something like this: https://learn.svelte.dev/tutorial/welcome-to-svelte

However you would just be able to do what you can do with SvelteKit (Parts 3 and 4). Not too different from what you can do with HTMX.

You would need to deploy SvelteKit but could have SvelteKit call your backend API for all of the heavy lifting and its deployment requirements would be minimal.

Yes, a bigger chunk of the JavaScript ecosystem takes longer to learn, but you can also do more with it. If you make an apples to apples comparison I think they're effectively in the same ballpark, and JavaScript is better just by having more resources.

View on HN

> You could follow something like this: https://learn.svelte.dev/tutorial/welcome-to-svelte

I think if you are, like me, someone who for various reasons never followed the JavaScript ecosystem for various reasons over the last few years (in my case because I was working on exclusively backend APIs in C#), coming back into trying to do any frontend website is just ten thousand people saying "it's not that hard, just follow something like this: x", where 'x' is any one of forfty hundred humungous different frameworks.

If you don't want to have to learn a whole new ecosystem but just want to bang out something that can take advantage of a bunch of modern-ish nice front end paradigms like being able to selectively update individual components without having to do a full page reload then htmx feels like it would hit the spot for a lot of different use cases.

(I say this having only read the site several times, usually when it pops up here in some context, and I always think "oh damn yeh that thing exists, I have to give it a go at some point!" but never actually have yet)

htmx is yet another one of those forty hundred humongous different frameworks.

It also uses a DSL that has no application outside of its specific corner.

It also forces you to return HTML fragments via AJAX.

By the way I did use intercooler.js (prev. iteration of htmx) intensively and while I liked it at first, it really added up to being an HTML/JS soup when other developers started extending.

> humongous

14kb

> It also forces you to return HTML fragments via AJAX.

not true, you can return anything. support client-side templating for JSON etc

I doubt it – I haven't seen any indication of HTMX being a silver bullet.

Here's your list of examples: https://htmx.org/examples/

Here's validation: https://htmx.org/docs/#validation-example

It looks kinda like ruby.

I'd argue that neither is any particular JS framework a silver bullet. If HTMX works for their use cases without needing to write any JS then more power to them!

It is explicitly NOT a silver bullet

https://htmx.org/essays/when-to-use-hypermedia/#hypermedia-n...

I'd like to point out that if you require offline functionality in one project that it likely isn't a good fit for your other project that doesn't require offline functionality. We all have finite time and it's great to learn something once and be able to use it multiple times.

Offline functionality naturally requires client-side code to handle storage, caching, synchronization etc, so client oriented frameworks are preferable in those scenarios. However, this comes at the cost of additional complexity, and I argue that this complexity may be unnecessary and htmx may help you achieve your goals easier

You said it yourself:

> We all have finite time and it's great to learn something once and be able to use it multiple times.

We all have finite time and it's great to use tools that help us work efficiently, following the strengths of those tools, instead of having to maintain unnecessarily complex solutions

Reply on news.ycombinator.com