4 ms·

I think it’s perfectly fine to do whatever you want because it’s fun, but some of the other justification for accepting and rejecting dependencies seems a bit w

by ratorx 5y ago

I think it’s perfectly fine to do whatever you want because it’s fun, but some of the other justification for accepting and rejecting dependencies seems a bit weird. For example, one of your reasons for rejecting Hugo is that you can’t read all the code including dependencies and future updates yourself. However, you have no problems with using Go, which has a pretty large standard library and a lot of code for its implementation. Have you read through all of it? Sure, choosing Hugo is strictly worse by this metric (because it’s written in Go), but is even the goal of reading all source code and keeping up with changes tractable if Go is a dependency? Another one is your rejection of GitHub pages for uptime and future maintenance. There are many reasons you might not want to use it, but I don’t think those in particular are compelling ones. If you just use it to host plain or even templated HTML, then the migration cost if and when they fail is pretty low right? Just switch to one of the other HTTPS hosts or do the self hosting thing then? The maintenance tradeoff for not using GitHub pages is quite high too. I see your website is using HTTPS. In my opinion managing certificates is more maintenance than using GitHub pages. And then there are security updates. Dynamically generating websites has a security tradeoff too. Are you keeping your toolchain up to date? Go has had vulnerabilities in the past. BTW, I’m not not criticising your approach, just some of the justification for it. It sounds pretty neat to have a single binary website, but I’m not too sure about all the other justification.

spicybright 5y ago
Definitely agree with all the above. However, personal websites are neat because the only requirements are your own, so you don't need to justify it. I love seeing solar powered websites, retro computers hosting modern sites, etc. Having a single binary is a neat idea too, even if it's a bit pointless. It almost reminds me of the woman that came up with binaries that could run on different OS's unchanged. Definitely neat stuff!
- cyberge99 5y ago
  Ada?
  - tomcam 5y ago
    The inimitable Justine Tunney, aka jart on HN! See http://justine.lol http://justine.lol and be ready to get your mind blown.
- rob74 5y ago
  Yeah, it would have been perfectly fine to just write "I wanted to build my website as a binary, so I did it, and here it is" - but for some reason the author felt they needed to justify it, and I agree with the OP that those justifications feel a little bit artificial. I mean, if you're scared of Hugo having too many dependencies, I advise you to steer well clear of any Node.js projects...
deleted 5y ago
[deleted]
strken 5y ago
There's a difference between trusting Go without reading its source (no dependencies other than the previous version of Go and maybe a C compiler if you want to bootstrap it from version 1.4, run in production at big tech companies, actively maintained by Google) and trusting Hugo (1200 deps, huge plugin ecosystem with less battle-tested packages, unaudited templates that could inject anything they want into your site unless you read each release carefully). Golang is "only" 2 million lines of code, and it's quite easy to go look at the implementation of something, as the docs link directly to the code. It wouldn't be impossible to read through it, particularly if you skipped architectures other than x86 and parts of the standard library you didn't use.
- jamal-kumar 5y ago
  Getting really familiar reading the golang source code is a great way to understand how to write better go code. It's one of the thing I recommend to new programmmers in this language all the time because it's so accessible from a properly configured editor which will actually go to the definition in the standard lib at the whim of a couple of keystrokes.
jamal-kumar 5y ago
I'm a big fan of single-binary websites like this one which rely on as little dependencies as possible (Small, well-written, auditable libraries). What I've found in the go ecosystem as of the past few years is just this enormous graveyard of projects that didn't really seem to get the zeitgeist of keeping as much as close to the standard lib as possible, and included all the batteries. Now you open those old projects written in such frameworks and the batteries are all leaking all over the place and you got some of the juice on your hand, and the github issues page is just a bunch of people asking if the project is still alive yet. You really don't see that with the ones that kept it as simple as, and relying on as little as possible. My old stuff I wrote like that is still chugging along. My only dependencies to track in this case are go, my webserver frontend (openbsd httpd) and the OS updates. Wow! The applications I've written to this end aren't the kind of thing you can host on github pages, they're really dynamic and do all this image processing or handle tons of money a day. Turns out people throw more money around at stuff like that and this alone justifies the means. Hell I know people who even do this in C or C++. That's right, web applications, usually in even more constrained environments like embedded or for game consoles. They get paid more than me, too.
Humphrey 5y ago
But it's not an apples to apples comparison. Generating static files has a smaller attack vector than running an executable on a server. Keeping a service up and running over a long period of time is much more work than using generic static site hosting. HTML that works today will likely still work in 10 years time, but a binary you compile today most likely won't, or at least, you'll have wanted to have changed up your server.
- jamal-kumar 5y ago
  I've got some golang projects I've maintained for very nearly a decade now for the oldest one, which I deliberately wrote to keep to the stdlib and a few small dependencies. All of these are either web facing or consuming. They definitely still compile today. Nine years feels like a pretty sweet benchmark for me. The biggest thing to have to deal with really was the mod system. I think that fucked a few dependency-heavy projects out there which you're going to have a hard time compiling today, yet which hilariously still get recommended as if the github issues page isn't full of confused people. That said I love static site generation when I don't need anything special, but Hugo definitely has that bloated rotten whale smell to it for me after reading other's experiences with it. SSG is like some shit I've done with shell scripts even. It's just at its most basic, slapping html together, with maybe some templating.
zamadatix 5y ago
I feel you're looking a few levels into the decision tree of Hugo then using that level as the root of a decision tree to review all the other choices. There's not really a feasible way an individual can cut out a programming language or rebuild large portions of the stdlib like HTTPS and end up with something that's easy to maintain or reliable (or time feasible). There ARE easy ways an individual can generate static HTML without pulling in 1200 dependencies. Should there not have been a reasonable alternative to generating static pages that better aligned with the author's stated goals then sure, Hugo+Github would make just as much sense as pulling in the Linux, bash, and go dependencies did. With GitHub I didn't catch that the reasons revolving around SLA/uptime percentages rather non-breaking change intervals and probability the service will exist usable as is in 10 years. Migrating to another host doesn't necessarily fix this unless there is a particular one to mention that will guarantee existence of the exact method of operation for the next decade and have a solid guarantee for the service to be offered as is for that long. The choices of Golang's stdlib and Linux provide reasonably solid choices in this regard as neither is going to change in a way that breaks deploying/running the site unless they _absolutely_ need to and both have about as big of support backing as one could reasonably expect to find so are unlikely to pull the rug out from the site on the premise of moving on to something newer and shinier like business offerings are often changed/deprecated for. Certificates I definitely see a closer balance/argument on. On one hand the Github Pages way is really easy, they do it for you. On the other hand they are trying to avoid services that can disappear from them and are probably using ACME which seems to be pointed at Let's Encrypt right now. If for some reason Let's Encrypt did disappear though, which I'll be honest I'm on the side of that being less likely than some breaking change in the way an automated Github Pages hosted static site would function but I can see that being debated either way, at least it's not particularly hard to change the ACME provider for such a case. There may also be some personal sway on whether it's better to manage your own security certificates or not but I also can see that falling to either side depending on the person. Regardless of choice the toolchain is going to have to be kept up to date to stay secure. There isn't any option to choose which is indefinitely secure and without security bugs.

by ratorx 5y ago

spicybright 5y ago

Definitely agree with all the above. However, personal websites are neat because the only requirements are your own, so you don't need to justify it. I love seeing solar powered websites, retro computers hosting modern sites, etc. Having a single binary is a neat idea too, even if it's a bit pointless. It almost reminds me of the woman that came up with binaries that could run on different OS's unchanged. Definitely neat stuff!

cyberge99 5y ago
Ada?
- tomcam 5y ago
  The inimitable Justine Tunney, aka jart on HN! See http://justine.lol http://justine.lol and be ready to get your mind blown.
rob74 5y ago
Yeah, it would have been perfectly fine to just write "I wanted to build my website as a binary, so I did it, and here it is" - but for some reason the author felt they needed to justify it, and I agree with the OP that those justifications feel a little bit artificial. I mean, if you're scared of Hugo having too many dependencies, I advise you to steer well clear of any Node.js projects...

deleted 5y ago

[deleted]

strken 5y ago

There's a difference between trusting Go without reading its source (no dependencies other than the previous version of Go and maybe a C compiler if you want to bootstrap it from version 1.4, run in production at big tech companies, actively maintained by Google) and trusting Hugo (1200 deps, huge plugin ecosystem with less battle-tested packages, unaudited templates that could inject anything they want into your site unless you read each release carefully). Golang is "only" 2 million lines of code, and it's quite easy to go look at the implementation of something, as the docs link directly to the code. It wouldn't be impossible to read through it, particularly if you skipped architectures other than x86 and parts of the standard library you didn't use.

jamal-kumar 5y ago
Getting really familiar reading the golang source code is a great way to understand how to write better go code. It's one of the thing I recommend to new programmmers in this language all the time because it's so accessible from a properly configured editor which will actually go to the definition in the standard lib at the whim of a couple of keystrokes.

jamal-kumar 5y ago

I'm a big fan of single-binary websites like this one which rely on as little dependencies as possible (Small, well-written, auditable libraries). What I've found in the go ecosystem as of the past few years is just this enormous graveyard of projects that didn't really seem to get the zeitgeist of keeping as much as close to the standard lib as possible, and included all the batteries. Now you open those old projects written in such frameworks and the batteries are all leaking all over the place and you got some of the juice on your hand, and the github issues page is just a bunch of people asking if the project is still alive yet. You really don't see that with the ones that kept it as simple as, and relying on as little as possible. My old stuff I wrote like that is still chugging along. My only dependencies to track in this case are go, my webserver frontend (openbsd httpd) and the OS updates. Wow! The applications I've written to this end aren't the kind of thing you can host on github pages, they're really dynamic and do all this image processing or handle tons of money a day. Turns out people throw more money around at stuff like that and this alone justifies the means. Hell I know people who even do this in C or C++. That's right, web applications, usually in even more constrained environments like embedded or for game consoles. They get paid more than me, too.

Humphrey 5y ago

But it's not an apples to apples comparison. Generating static files has a smaller attack vector than running an executable on a server. Keeping a service up and running over a long period of time is much more work than using generic static site hosting. HTML that works today will likely still work in 10 years time, but a binary you compile today most likely won't, or at least, you'll have wanted to have changed up your server.

jamal-kumar 5y ago
I've got some golang projects I've maintained for very nearly a decade now for the oldest one, which I deliberately wrote to keep to the stdlib and a few small dependencies. All of these are either web facing or consuming. They definitely still compile today. Nine years feels like a pretty sweet benchmark for me. The biggest thing to have to deal with really was the mod system. I think that fucked a few dependency-heavy projects out there which you're going to have a hard time compiling today, yet which hilariously still get recommended as if the github issues page isn't full of confused people. That said I love static site generation when I don't need anything special, but Hugo definitely has that bloated rotten whale smell to it for me after reading other's experiences with it. SSG is like some shit I've done with shell scripts even. It's just at its most basic, slapping html together, with maybe some templating.

zamadatix 5y ago

I feel you're looking a few levels into the decision tree of Hugo then using that level as the root of a decision tree to review all the other choices. There's not really a feasible way an individual can cut out a programming language or rebuild large portions of the stdlib like HTTPS and end up with something that's easy to maintain or reliable (or time feasible). There ARE easy ways an individual can generate static HTML without pulling in 1200 dependencies. Should there not have been a reasonable alternative to generating static pages that better aligned with the author's stated goals then sure, Hugo+Github would make just as much sense as pulling in the Linux, bash, and go dependencies did. With GitHub I didn't catch that the reasons revolving around SLA/uptime percentages rather non-breaking change intervals and probability the service will exist usable as is in 10 years. Migrating to another host doesn't necessarily fix this unless there is a particular one to mention that will guarantee existence of the exact method of operation for the next decade and have a solid guarantee for the service to be offered as is for that long. The choices of Golang's stdlib and Linux provide reasonably solid choices in this regard as neither is going to change in a way that breaks deploying/running the site unless they _absolutely_ need to and both have about as big of support backing as one could reasonably expect to find so are unlikely to pull the rug out from the site on the premise of moving on to something newer and shinier like business offerings are often changed/deprecated for. Certificates I definitely see a closer balance/argument on. On one hand the Github Pages way is really easy, they do it for you. On the other hand they are trying to avoid services that can disappear from them and are probably using ACME which seems to be pointed at Let's Encrypt right now. If for some reason Let's Encrypt did disappear though, which I'll be honest I'm on the side of that being less likely than some breaking change in the way an automated Github Pages hosted static site would function but I can see that being debated either way, at least it's not particularly hard to change the ACME provider for such a case. There may also be some personal sway on whether it's better to manage your own security certificates or not but I also can see that falling to either side depending on the person. Regardless of choice the toolchain is going to have to be kept up to date to stay secure. There isn't any option to choose which is indefinitely secure and without security bugs.