The larger the codebase, the harder it is to "just know" what's going on. Take the example `function format(date, options)`. In a very small codebase, that only you work on, you might know that it's supposed to return a string, that `date` is supposed to be a Date, and that `options` is supposed to be an object with for example a required format string, a locale, or whatever. But the more code is in your codebase, and the more people work on it, it becomes harder and harder, impossible even, to "just know" these things. This is where for example Typescript, or non-dynamic languages, are super valuable. Then you'd instead see in your code `function format(date: Date, options?: { format: string }): string`, and you'd immediately know, with no experience with the code base, what this function expects.
@@nguyen_timHaving templates dependant on your logic and having them loosely coupled and spread out in a lot of different files always spirals out of control eventually. Especially since the DOM has a lot of ephemeral state that cannot be represented easily with templates (for example scroll position), which results in a lot random snippets of JS that work against the architecture of your code base. That's the reason why the component model of modern JS frameworks won. It is much better for organizing your code. And there's also an added DX and UX advantage of sharing code between the backend and frontend.
@@Terr590 All good points! I appreciate the explanation. I’ve enjoyed using HTMX on small projects where the scope is limited and client side JavaScript is kept to a minimum. But I can see how it can cause more headaches than it’s worth when the project gets larger and (god forbid) successful. That being said, I’ve never written a large scale app with HTMX so take my opinions with a grain of sodium chloride.
When he says Javascript is a dynamic language (not the best for large codebases), what does he mean?
just that larger codebases tend towards static typing like typescript or whatever
The larger the codebase, the harder it is to "just know" what's going on.
Take the example `function format(date, options)`. In a very small codebase, that only you work on, you might know that it's supposed to return a string, that `date` is supposed to be a Date, and that `options` is supposed to be an object with for example a required format string, a locale, or whatever. But the more code is in your codebase, and the more people work on it, it becomes harder and harder, impossible even, to "just know" these things.
This is where for example Typescript, or non-dynamic languages, are super valuable. Then you'd instead see in your code `function format(date: Date, options?: { format: string }): string`, and you'd immediately know, with no experience with the code base, what this function expects.
Im playing GTA 5 (again). Is that Los Santos hat that Carson is wearing? 😁
HTMX is pro-spaghetti code
How so? Genuinely curious by what you mean.
@@nguyen_timHaving templates dependant on your logic and having them loosely coupled and spread out in a lot of different files always spirals out of control eventually.
Especially since the DOM has a lot of ephemeral state that cannot be represented easily with templates (for example scroll position), which results in a lot random snippets of JS that work against the architecture of your code base.
That's the reason why the component model of modern JS frameworks won. It is much better for organizing your code. And there's also an added DX and UX advantage of sharing code between the backend and frontend.
@@Terr590 All good points! I appreciate the explanation.
I’ve enjoyed using HTMX on small projects where the scope is limited and client side JavaScript is kept to a minimum.
But I can see how it can cause more headaches than it’s worth when the project gets larger and (god forbid) successful.
That being said, I’ve never written a large scale app with HTMX so take my opinions with a grain of sodium chloride.
love spaghetti
At least it is not pro-lasagna code
STOP DOING THINGS TO JAVASCRIPT - horizontal crapware
First!
First
Liar, go fight @sasquatch_devs