Building a simple static site generator in 100 lines
smalldata.tech
smalldata.tech
Interesting read through. The core of a static generator is not complex, but adding all the extras that people want and making it more general is where the problems lie.
As well as that, making everything async feels like it's a very premature optimization. It's only a static site generator for feck's sake.
Especially for something that is mostly filesystem access.
If this were Rust where you'd have to bring your own Tokio event loop or I/O thread pool because its filesystem API is blocking, then I'd probably agree.
For example, even though this example's `writePages` function writes each file serially, they would just change it into Promise.map(pages, writePage, { concurrency: 8 }) to add concurrent writes.
It's also a fewer lines than promises and the then calls with the anon functions.
> It's also a fewer lines than promises and the then calls with the anon functions.
Promises + call with anon functions is still asynchronous code. I'm wondering why not just use easy-to-reason-about, easy-to-read synchronous code for something like this rather than messing around with async/await.
Depending upon the number of files, the async approach will be faster (to be benchmarked) but you are correct that for 100 files or less on a modern computer at least there is probably no perceptible difference.
For me personally, I'm just so used to writing it this way, I didn't even think that it could complicate the tutorial - thanks for pointing it out!
Bluebird has more of an API appeal as well as performance in older apps/servers.
Also, if you're bring it - you can `Promise.try(() =>` and don't forget to add a:
``` process.on('unhandledRejection', e => { throw e; }); ```