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

Is htmx Just Another JavaScript Framework?

htmx.org

Post reply on HN
Print view View original

121–130 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#121

Post by satvikpendem »

chatmasta wrote: post #117
exabrial wrote: post #94

HTMX is signaling they're around for the long haul, we'll see if they break backwards compatibility or rewrite their API 15 times in the next year. I had one of my dev's do several node/js framework POCs in _September_ last 2023 (current year is Jan 2024 at the time of this writing). Nearly all of the POCs won't even run or build any more because the developers have rewritten something and broke all backwards compati…

It sounds like your devs are not following best practices with regards to lockfiles and version pinning.

Indeed. If half won't even build anymore, that's insane. It seems like they want to be on the latest version all the time which obviously will have breaking changes.

Re: Is htmx Just Another JavaScript Framework?

#122

Post by bcrosby95 »

diggan wrote: post #91
bcrosby95 wrote: post #90

Earlier quoted context omitted.

Spring Boot is a layer on top of Spring that makes it easier to use.

Sounds to me like Spring Boot is a library to be used with the framework Spring in that case, as far as I can tell.

It's more than just a library, there are "starters" that they've developed that will pull in everything you need for certain stuff (such as web, or database, etc), and it will auto-find and configure everything for you.

Furthermore, you can hand configure Spring. If anything, the framework here is the Java servlet container, not Spring. Spring just usually lives within that context.

And at this point I'm not sure if that's completely true either. It's common to embed the servlet container - this is how Spring Boot works. I assume you can do that with raw Spring considering that's what Boot does, but I never bothered trying because I would just use Spring Boot at that point.

Re: Is htmx Just Another JavaScript Framework?

#123

Post by quonn »

ahmedfromtunis wrote: post #70
quonn wrote: post #43

Earlier quoted context omitted.

That‘s why there is a lock file. The package manager and node version can likewise be locked.

Does the lock file render the need to update dependencies obsolete? Of course not. It just avoids that the build system *automatically* updates X to 1.2.3 and *accidentally* breaks your code. But when it's time to bump the version up a notch, that very fragile equilibrium may suddenly crumble. Lock files are not a substitute for sane dependency management.

I responded to someone who claimed that it broke by itself after 6 months. Lock files prevent this.

Re: Is htmx Just Another JavaScript Framework?

#124

Post by satvikpendem »

ahmedfromtunis wrote: post #70
quonn wrote: post #43

Earlier quoted context omitted.

That‘s why there is a lock file. The package manager and node version can likewise be locked.

Does the lock file render the need to update dependencies obsolete? Of course not. It just avoids that the build system *automatically* updates X to 1.2.3 and *accidentally* breaks your code. But when it's time to bump the version up a notch, that very fragile equilibrium may suddenly crumble. Lock files are not a substitute for sane dependency management.

This is the same in any language then.

Re: Is htmx Just Another JavaScript Framework?

#125

Post by falsandtru »

crftr wrote: post #21

HTMX aims to render itself obsolete by serving as a proof of concept to advance the HTML specification. In various interviews and blog posts, Carson has mentioned that jQuery was essential only until browsers implemented features like `querySelectorAll`. The discussion about Library vs. Framework misses the core objective of the HTMX project.

An example on the top page shows that this is an operation that should be written as a program. Therefore, this is not markup. Syntax that is not markup will not be the HTML specification.

>

Re: Is htmx Just Another JavaScript Framework?

#126

Post by quonn »

gofreddygo wrote: post #73
quonn wrote: post #12

So what's the problem with a bundler/transpiler etc? You set it up once. It takes a few hours, maybe a day. Then your platform _is_ TypeScript + React. This abstraction basically never leaks. I never need to look at the transpiled files to find an error. Nobody argues that a C compiler is worse than assembly or that drivers or an operating system are bad.

> what's the problem with a bundler/transpiler Problem is why do we even need one? All I'm trying to do is for my client code to update a part of the page and not the entire page. Why do I need to even introduce concepts of bundling and transpiling for this pig-headed simple task ? Further, react has a steep learning curve that a backend person need not be subjected to. And it evolves, so that search-copy-paste phase…

TypeScript is simply a much more robust type-safe language and the compiler abstracts away subtle differences between browsers. Likewise React abstracts away subtle differences between browsers.

And most applications are far more complex than just needing to update a small part of the page.

Re: Is htmx Just Another JavaScript Framework?

#127

Post by pphysch »

falsandtru wrote: post #125
crftr wrote: post #21

HTMX aims to render itself obsolete by serving as a proof of concept to advance the HTML specification. In various interviews and blog posts, Carson has mentioned that jQuery was essential only until browsers implemented features like `querySelectorAll`. The discussion about Library vs. Framework misses the core objective of the HTMX project.

An example on the top page shows that this is an operation that should be written as a program. Therefore, this is not markup. Syntax that is not markup will not be the HTML specification. >

How is that different than a standard or element that submits an HTTP request, receives some HTML in response, and uses that HTML to render a new GUI?

Re: Is htmx Just Another JavaScript Framework?

#128

Post by recursivedoubts »

I am the author of htmx. I think htmx is a library using the following definition:

- a library you call

- a framework calls your code

in htmx you add attributes to HTML to "call" htmx, so, from the perspective, you can call it a library. On the other hand, those "calls" are called back into via event handlers in JavaScript, so an argument can be made that, even at this level, htmx is a framework.

I liked alex's analysis and I think his definitions and thinking contribute to the discussion, so I posted it to the htmx website.

Even though I still consider htmx a library. :)

Re: Is htmx Just Another JavaScript Framework?

#129

Post by zdragnar »

ahmedfromtunis wrote: post #70
quonn wrote: post #43

Earlier quoted context omitted.

That‘s why there is a lock file. The package manager and node version can likewise be locked.

Does the lock file render the need to update dependencies obsolete? Of course not. It just avoids that the build system *automatically* updates X to 1.2.3 and *accidentally* breaks your code. But when it's time to bump the version up a notch, that very fragile equilibrium may suddenly crumble. Lock files are not a substitute for sane dependency management.

There's no reason that you absolutely have to update every dependency after 6 months. Not updating anything at all is perfectly fine.

Nobody in their right mind thinks you can change major versions without some elbow grease in any other language.

Re: Is htmx Just Another JavaScript Framework?

#130

Post by quonn »

gofreddygo wrote: post #73
quonn wrote: post #12

So what's the problem with a bundler/transpiler etc? You set it up once. It takes a few hours, maybe a day. Then your platform _is_ TypeScript + React. This abstraction basically never leaks. I never need to look at the transpiled files to find an error. Nobody argues that a C compiler is worse than assembly or that drivers or an operating system are bad.

> what's the problem with a bundler/transpiler Problem is why do we even need one? All I'm trying to do is for my client code to update a part of the page and not the entire page. Why do I need to even introduce concepts of bundling and transpiling for this pig-headed simple task ? Further, react has a steep learning curve that a backend person need not be subjected to. And it evolves, so that search-copy-paste phase…

They don‘t start if they use complex frameworks, many dependencies, don‘t use lock files, don‘t lock their package manager and don‘t lock nodeJS and don‘t use Docker.

If they use plain TypeScript and plain React, have a lock file, lock their package manager version and lock their nodeJS version and optionally ship a sane Docker setup they will certainly run.

It is true that it would be nice to have a single tool that combines a bundler, typescript, linter, prettier, package manager and runtime and have it all configured with reasonable defaults from a single file and not 5 configs. And people have tried this lately, with approaches like deno and bun. But it‘s difficult to get these adopted.

Still, it would be better for someone to take all these tools and freeze them in place or even fork them and then freeze them with only bug fixes coming, rather than throwing out 10 years of progress and going back to something that just doesn‘t work.

Post reply on HN