3 ms·

> Out of interest, in the first nodejs code sample why are you including Bluebird to just call main()? It seems redundant, wouldn't 'main()' in the outer scope

by messe 8y ago

> Out of interest, in the first nodejs code sample why are you including Bluebird to just call main()? It seems redundant, wouldn't 'main()' in the outer scope have the same effect? 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.

always_good 8y ago
IMO writing synchronous code in Javascript seems like the premature optimization (e.g. fear of introducing cognitive overhead of async code?) when async code is so trivial to write and just about everything is already async. 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.
wheresvic1 8y ago
I find using async await leads to a lot more simpler and understandable code. Moreover, one can stick to the try ... catch semantics. It's also a fewer lines than promises and the then calls with the anon functions.
- messe 8y ago
  > I find using async await leads to a lot more simpler and understandable code. Moreover, one can stick to the try ... catch semantics. > 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.
  - wheresvic1 8y ago
    Ah I see now - yes you are right that would be an option since both fs an fs-extra provide sync functions. 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!

by messe 8y ago

always_good 8y ago

IMO writing synchronous code in Javascript seems like the premature optimization (e.g. fear of introducing cognitive overhead of async code?) when async code is so trivial to write and just about everything is already async. 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.

wheresvic1 8y ago

I find using async await leads to a lot more simpler and understandable code. Moreover, one can stick to the try ... catch semantics. It's also a fewer lines than promises and the then calls with the anon functions.

messe 8y ago
> I find using async await leads to a lot more simpler and understandable code. Moreover, one can stick to the try ... catch semantics. > 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.
- wheresvic1 8y ago
  Ah I see now - yes you are right that would be an option since both fs an fs-extra provide sync functions. 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!