
Building a simple static site generator in 100 lines - wheresvic1
https://smalldata.tech/blog/2018/08/16/building-a-simple-static-site-generator-using-node-js
======
orf
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
> 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.

~~~
wheresvic1
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
> 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
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
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
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 :)

