4 ms·

Building a simple static site generator in 100 lines

• orf 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? 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.
  • 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!
• inglor 8y ago
  Bluebird maintainer here - not sure why you included it in your example. I've been working with the V8 team and they've been making a ton of progress making native promises fast. 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; }); ```
  • wheresvic1 8y ago
    Aha, thanks for the info - I've been using bluebird for so long it's pretty much reflex at this point. I'll edit it out to simply use native promises :)