4 ms·

> It’s a single 5k line file with 190 top level functions in it That's interesting. Do some people prefer this style? If yes, how come?

quesomaster9000 2y ago
If you look at the end-user API documentation[1] it's pretty good. But the htmx.js file itself seems to struggle from a certain type of internal naming scheme that will take a while to get up to speed with and doesn't really lend itself to being easy to context switch in & out of it, where you might simply forget that things exist and end up re-writing or inlining these fragments. This naturally stems from a very organic development process, where something starts out as a quick prototype, then the functions get too big so you split fragments out into things like `shouldProcessHxOn` and `processHXOnRoot` which absolutely make sense at the time where you're avoiding duplication, and trying to turn it into something 'more proper' with 'better abstractions' would actually cause the code to balloon in size and make it much bigger and much more like object spaghetti. On the whole though, a large amount of the file is type documentation, e.g. `/* @param {Node} start */` which is more a failing of JavaScript itself than anything else, and honestly a 5k self-contained file with good public documentation of what's user-facing vs internal is pretty easy to grok if it's something you work with frequently. If you were to rewrite this in a saner language like Python with a more functional style, you could probably condense it down to 1000 lines or less. [1]: https://htmx.org/api/ https://htmx.org/api/
internet_points 2y ago
I do. I've always felt that I'm doing something wrong when I do this, but I much prefer not having to switch files all the time and navigate folders etc. looking for things. With everything in one file, I can just use regular within-file search (and M-x occur in emacs which is a bit like clickable (and editable) grep). If I need "focus", I just use narrowing in Emacs (shows only the highlighted part of the buffer, with handy shortcuts for narrowing to current function/class). If I need to see something side-by-side, just split or clone the buffer. I loathe working on those java etc. projects where you have a zillion classes each in their own file, many with maybe a handful of members each; whenever I switch files I feel like I'm losing context.
uludag 2y ago
I prefer this style. I primarily use Emacs as someone else mentioned. I feel like it's sort of similar to editor tabs vs buffers. Like, once you have a good way of switching between buffers, separate editor tabs seem like a superfluous UI element. In a similar way, if you have powerful ways of navigating to the function definition you want, then everything being in the same file doesn't seem to matter. Also, having all the code in a single file helps expression exposition of the code. You can sort of captivate the reader of your code, and present the code in the order of your choosing.
- arresin 2y ago
  Really appreciate the reply. Thanks.

quesomaster9000 2y ago

If you look at the end-user API documentation[1] it's pretty good. But the htmx.js file itself seems to struggle from a certain type of internal naming scheme that will take a while to get up to speed with and doesn't really lend itself to being easy to context switch in & out of it, where you might simply forget that things exist and end up re-writing or inlining these fragments. This naturally stems from a very organic development process, where something starts out as a quick prototype, then the functions get too big so you split fragments out into things like `shouldProcessHxOn` and `processHXOnRoot` which absolutely make sense at the time where you're avoiding duplication, and trying to turn it into something 'more proper' with 'better abstractions' would actually cause the code to balloon in size and make it much bigger and much more like object spaghetti. On the whole though, a large amount of the file is type documentation, e.g. `/* @param {Node} start */` which is more a failing of JavaScript itself than anything else, and honestly a 5k self-contained file with good public documentation of what's user-facing vs internal is pretty easy to grok if it's something you work with frequently. If you were to rewrite this in a saner language like Python with a more functional style, you could probably condense it down to 1000 lines or less. [1]: https://htmx.org/api/ https://htmx.org/api/

internet_points 2y ago

I do. I've always felt that I'm doing something wrong when I do this, but I much prefer not having to switch files all the time and navigate folders etc. looking for things. With everything in one file, I can just use regular within-file search (and M-x occur in emacs which is a bit like clickable (and editable) grep). If I need "focus", I just use narrowing in Emacs (shows only the highlighted part of the buffer, with handy shortcuts for narrowing to current function/class). If I need to see something side-by-side, just split or clone the buffer. I loathe working on those java etc. projects where you have a zillion classes each in their own file, many with maybe a handful of members each; whenever I switch files I feel like I'm losing context.

uludag 2y ago

I prefer this style. I primarily use Emacs as someone else mentioned. I feel like it's sort of similar to editor tabs vs buffers. Like, once you have a good way of switching between buffers, separate editor tabs seem like a superfluous UI element. In a similar way, if you have powerful ways of navigating to the function definition you want, then everything being in the same file doesn't seem to matter. Also, having all the code in a single file helps expression exposition of the code. You can sort of captivate the reader of your code, and present the code in the order of your choosing.

arresin 2y ago
Really appreciate the reply. Thanks.