Of course you won't write anything that you hate at first, because it's for fun. But hating something for some days or weeks is part of the fun, too. You are challenging yourself, not doing it the easy way, to appreciate how well the others are doing.
If you want to turn it into a business, so yeah, don't write a graph visualization engine, or crypto stuff, or anything really. Get a job, that can be fun too, and let the entrepreneurs figure out the rest.
I think you and I agree. I'm not being crass, but I'd if you had more thoughts on what I'm trying to say about what you're trying to say I'd be interested in further discussion.
It did a lot of performance wankery, like templating system (not my lib, I just used available one) being just Go code embedded in HTML that needed to be compiled with the rest of the app, or pre-generating HTML from Markdown on load. Using same language to write app as to write templates was nice tho.
Most of it was mostly "how far I can go without cutting features" because really going from 10ms per page to 0.2 ms per page has no difference after client RTT is involved.
Hell, even on localhost for some reasons Chrome always have few ms delay before starting download compared to any cli client, chrome shows anywhere between 3 and 8ms to start downloading, while FF sits at 0ms
I originally planned to have some fun with HTTP2.0 PUSH but, well, while I kinda believed on authority that it is useful for something it turned out to be entirely stupid idea which apparently nobody bothered to test before pushing it into standard so I didn't get to do it. Maybe I should try again with HTTP3.0 hints.
I'm asking this for rhetorical purposes. I know, I know deeply why. heh. I'm glad you came out of it ok. Thank you for your honest response.
I wanted something simple that was just markdown for actual content, no database or anything more fancy. I have considered static gen and even eventually migrated my old blog to it as archive (not in english, and cringe anyway). But it really started as "well, it looks like fun thing to do and I will be scratching the itch I had, why not".
Mind you, that was in 2012, the first version was in asynchronous(!) Perl, Ghost didn't even exist at that point (and I didn't wanted to touch JS anyway), let alone any other alternative. It even did respectable ~3ms per render of the page.
I rewrote it in Go to learn some stuff and in the process also yeeted comment processing and just farmed it out to externals (self hosted, not written by me) app, as that's probably the most annoying and thankless part of blog engine when you include all kinds of spam detection that would need to be written.
On the nearby cementery I also have unfinished Go z80 emu (I did learn a bit about using Dear ImGui from it) and it rewrite in Rust (because what's better first project than that?), just coz I wanted to see just how much faster C<->Rust is compared to C<->Go interop(answer = a lot, rendering part got from >4ms to below 0.5ms).
I did it to the point where it could run some code, and quite fast too, I think it was down to few ns per instruction, and 8 byte prog ran in like 11 ns, which I kinda didn't expect from Go. It didn't emulate instruction delay tho, which would be required to emulate it with peripherals.
Program decoder was just...256 byte array with function pointers generated out of operator list, which probably helped
In the context of this article, I agree. Professional products should probably not try to build everything from scratch. But I do think it's important to acknowledge that building things from scratch as personal projects is one of the absolute best ways to gain a deep understanding of a topic. Even if you go on to use graph visualization engines built by others in all your future work, that doesn't mean you shouldn't give it a go on your own time if you're interested in trying it out.
Not trying to be contrarian or criticize the article, just my 2 cents. In general I agree with the sentiment of using existing solutions wherever possible.