Plus, he's got an awesome philosophy on programming to boot (yes, there is a programming philosophy! ... no comprende? Let me explain later).
All in all, it was really cool to meet someone that's completely congruent with what he says & lives out as a programmer. It almost felt Bret Victor-like.
That's pretty much it. As you'd expect, he knows alot of node modules, far too many to mention here.
console.diralot to inspect & debug
test.jsthat requires the module and tests its functionality
module.exports = ...(When I say immediately, I really do mean immediately).
npm install tape tap
test.jsfile as a set of tests (see below).
README.mdfrom scratch with introduction, example & license.
t.plan(numberOfTests) // do stuff t.same ... // asserts
Now... if you've already done a few modules, the above set of steps might seem like nothing special to you.
The secret sauce is that substack is fast - really fast! He thinks fast, he codes fast, he generally talks fast... he's fast!
As the adage goes, "practise makes perfect".
I have to admit something... in the past, I used to evaluate packages by looking at the Github page to see when it was last updated. If I see something that is more recent, it gets my tick of approval.
Now substack doesn't do that. He just wants the most dependable, easy to understand and smallest module he can find (or make) to fulfil his objective.
In other words, he subscribes to the UNIX philosophy. I thought I did as well, until I talked to him.
So as an example, everyone sees nodejs as quite progressive. Features like domains, streams, etc. are being improved upon at the moment.
However, substack wants to see nodejs as 100% complete and dependable one day.
That means no more work on it and zero issues, just like the UNIX tools we use - cat, grep, date, etc.
Hopefully what I said makes total sense to you. But for me, what he said sounded like crazy talk at first. I mean, can't we have nodejs v42.6.7 one day?
Over time, it eventually sunk in and made total sense.
This goes on to my next point - substack practises extreme modularity.
He tries to keep each module he writes under 200 lines of code, although he knows it's not easy in all cases.
But he doesn't say it's impossible. To him, it's about taking the time to understand the abstractions. And once you do, refactor to modules.
If this is done right, you have modules that are:
Wow, doesn't that sound awesome! Why doesn't everyone code like that?
The more astute among you might say, "That sounds great, but if you go crazy modular, you're going to have massive dependency graphs with replicated functionality everywhere."
Sure you might, but substack says he's never really encountered that. I haven't encountered that. Therefore, we're right!
No, jokes aside, a smart package manager (i.e. npm) with a whole bunch of micro-libraries is usually still a lot smaller... and more importantly, easier to understand than an all-purpose framework.
So what about all-purpose frameworks?
My heading was a play on the words "convention over configuration". When I queried substack about his thoughts on CoC, he was slightly perturbed. He then gently explained that how you glue modules together essentially is the "configuration".
To summarise, Dominic Tarr put it well when he came over at one stage and briefly quipped, "configuration is a smell".
There were other topics discussed, but this post is getting a bit past 100 lines :-). All in all, it was super interesting to talk to substack.
If you learnt something useful (or think I'm full of it), I'll happily receive your comments below!