Build is slow about jet

[marcamos]

@lud Thanks for writing this up; I'll take a look as soon as possible.

[ryanccn]

The post-build hook seems redundant and breaks Eleventy

[marcamos]

Looking into this a little (finally), I see that this chunk of code was introduced in #125 by @geshan. Before I investigate further, I thought I'd at least mention this. Based on what @geshan wrote in that pull request, this code improved things for them.

What does everyone think?

[geshan]

Just to add on it, this was working for me and it was needed when there were lots of posts to avoid race condition issues. If it is causing an issue I can revert PR #125 , let me know your thoughts.

[lud]

@geshan as I understand it, the files that tailwind looks to find what classes name to keep are the sources, not the build.

So in dev, the two builds (tailwind and posts) should be independent, which makes page refresh in browser very fast. With the current setup, any change to a page runs a build of tailwind before updating the browser with the websocket and that makes it not very fluid to work with.

In build mode for prod, you do not care about the time, so you can run two commands instead of one, so the hook is not needed.

Finally, if you need to use the build result for tailwind filtering, the watch mode should already work.

[marcamos]

@geshan @lud Thank you both for your time and your attempts to improve jet.

I have a medium-to-large codebase running on jet already, with the code in question already in place, and things run fine. What I think I'll do (in the near future) is see how that same codebase runs if I comment-out the code in question.

[lud]

@marcamos can you try to update a markdown file and tell me if the refresh is instant in the browser?

To me it was not until I removed the hook.

But yeah, I can make my own changes since the project is not meant to be synced with git anyway :)

[marcamos]

@lud Absolutely! I'll do some testing as soon as I can, then report back.

[marcamos]

OK, here's my somewhat low-effort test results: I tested one jet-based codebase that's, I guess, medium sized (my personal blog), as well as the default jet codebase, both before and after making the suggested changes above.

---

My blog, before removing the code as suggested above:

• npm run dev: [11ty] Copied 852 files / Wrote 61 files in 17.09 seconds (280.2ms each, v1.0.2)
• After editing/saving a file: [11ty] Copied 852 files / Wrote 61 files in 1.34 seconds (22.0ms each, v1.0.2)
• npm run build: [11ty] Copied 852 files / Wrote 61 files in 15.63 seconds (256.2ms each, v1.0.2)

My blog, after removing the code as suggested above:

• npm run dev: [11ty] Copied 852 files / Wrote 61 files in 14.94 seconds (244.9ms each, v1.0.2)
• After editing/saving a file: [11ty] Copied 852 files / Wrote 61 files in 0.53 seconds (8.7ms each, v1.0.2)
• npm run build: [11ty] Copied 852 files / Wrote 61 files in 14.88 seconds (243.9ms each, v1.0.2)

---

Default jet codebase, before removing the code as suggested above:

• npm run dev: [11ty] Copied 2 files / Wrote 1 file in 0.70 seconds (v1.0.2)
• After editing/saving a file: [11ty] Copied 2 files / Wrote 1 file in 0.70 seconds (v1.0.2)
• npm run build: [11ty] Copied 2 files / Wrote 1 file in 0.68 seconds (v1.0.2)

Default jet codebase, after removing the code as suggested above:

• npm run dev: [11ty] Copied 2 files / Wrote 1 file in 0.03 seconds (v1.0.2)
• After editing/saving a file: [11ty] Copied 2 files / Wrote 1 file in 0.02 seconds (v1.0.2)
• Run npm run build: [11ty] Copied 2 files / Wrote 1 file in 0.03 seconds (v1.0.2)

---

So, yeah, it certainly looks like things run a bit faster if the suggested changes are made.

[lud]

Thank you for the tests! The main pain point to me is After editing/saving a file. The reload time in the browser is above two seconds for me with the code, from pressing Control+S to page reload. Obviously I just guessed the time, it is not something I can measure properly.

Anyway, as I said I am not asking to remove the code since I could just remove it from my own copy, but maybe a comment to tell that it is not strictly needed could be right.

[marcamos]

@lud You're welcome, and I definitely appreciate you bringing this up.

@geshan I'm leaning towards removing this small chunk of code, and at the same time I'm curious: if you were to temporarily remove it from your codebase, do you notice any issues (or, improvements)?