Website width isn’t calculated correctly for mobile and you need to scroll left and right in order to read the text. I was doing that right after reading
There's a big difference between "mobile first" and "mobile hostile" (even if the hostility is unintentional). Here, for example, the website is just 10-15 characters too wide on mobile, regardless of orientation. It forces you to scroll left and right constantly just to read the lines. And regardless of orientation actually feels hostile, if I flip my phone to landscape, the font size increases and thus I still can't read the whole line.
I agree that designing for mobile first is annoying for the web in general. But... This is text! Most of the website is text, and it doesn't wrap or resize properly for a small screen.
Here, it's likely just a bug with the window width calculation, not a "mobile first" argument.
If a website is 99% text and it can't be read from every screen size from a phone to an ultrawide monitor... Than it's a bug, not a design choice.
Counter argument: content is mostly consumed on mobile device nowadays, why should I require users scroll horizontally to keep reading and in doing so losing focus of the actual row? “Mobile first” was a more of a methodology, aka start designing from the small device and going up. And this website clearly failed at keep me reading from my mobile device. While I don’t necessarly think “mobile first” was a mistake, I believe today an adaptive layout it’s a more appropriate methodology for the existance of a ton of different devices, screens, ratios and pixel density. Like most websites still sucks on my 32’’ external monitor, it’s not a mobile only problem
Counter-counter argument: A person creating a personal homepage has no obligation to cater to any particular audience. See, for example, jwz.org [NSFW when linked from here, very much on purpose]
> Counter-counter argument: A person creating a personal homepage has no obligation to cater to any particular audience.
That’s irrelevant. Most of the Web users are using mobiles, so if you decide to set a website up, the very basic thing is to ensure it’s readable on mobile. And since plain HTML is already readable on any device by default, it would be quite strange to voluntarily make it unusable on these devices.
The mobile crowd may not be your desired or intended audience though. It's fine to publish a website in Icelandic even if more people could read it in English.
You are right that nobody is beholden to creating pages that can be viewed on any device. However, it is not unreasonable to say that a person has mismatched interests when they say they care a lot about quality, interoperability and values in general, but then don't care about making the document explaining this viewable on most devices.
Yes, ultimately it's not important. But if you only publish your website using Gopher, at some point you have to accept that you're interested by making cool things rather than the other things mentioned.
"Mobile first" means that the design is accessible on all devices and resolutions. Traditionally websites would be built primarily for large displays, and a separate mobile version would be tacked on, if the authors cared about those users.
In 2023, there's no technical reason websites should be inaccessible on any device. Doing so intentionally is needlessly user-hostile.
This is a very first-world opinion. Low-end (second hand) smartphones are some of the only available computing devices available for a large part of the world.
All that's needed for a blog site to be mobile-friendly is to just not actively break it. Plain html articles with no css read great on mobile, e.g. http://motherfuckingwebsite.com/
Because it's not a text organised into sections, paragraphs and whatnot with html, it's just a plain text file rendered into one big paragraph with whitespace set to `pre` ¯\_(ツ)_/¯.
It's arguable whether this is better or worse, because now you'll have the text wrapping where needed _but also_ again where it would have on a wider viewport, even though it already wrapped. So on mobile you'll have a full line, then half a line, then a full line, then half a line, and so on, wrapping alternatingly at the natural edge of the viewport, and again at the original line end terminated by a line break.
It probably changes from person to person, but while I find wrapping like that harder to read than seeing it all normally, for code it is still much better than scrolling back and forth for every line.
Using Firefox Mobile reader mode turns the page into one, continuous brick of text. No way of discerning sections, lists, or anything since no newlines seems to work. I might have missed something, but that ain't a fix. I'd prefer scrolling sideways.
Because that means every page request downloads all the static content. It’s generally nice for people if they only have to download the shared assets once.
The stylesheet is just under 3KB even with no minification or compression. At that size, the cost is negligible, and inlining will consistently be faster to load even than a warm cache of an external stylesheet. In most conditions, you’ve got to get towards 100KB before it even becomes uncertain. Loading from cache tends to be surprisingly slow, vastly slower than most people expect. (Primary source: non-rigorous personal experimentation and observation. But some has been written about how surprisingly slow caches can be, leading to things like some platforms racing a new network request and reading from disk, which is bonkers.)
Seriously, people should try doing a lot more inlining than they do.
I think it depends on how you set your cache? If it’s not configured to re-check with the server it may be much faster.
Then again, for 3KB the overhead of doing a cache check after parsing the HTML for the first time and then rendering it again may already be too much :)
Exactly. Inline is just surprisingly much faster than a lookup by URL, which has to check “do I have this cached? What type (immutable, revalidate, &c. &c.)? Now (if suitable) fetch it from the cache.” before it can get on with actually acting on the resource’s contents.
Maybe. Seems odd that they'd use a vestigial 'static' directory in the request path, though. I didn't read it because the layout makes it useless on mobile browsers, but I have a feeling they mean that the whole site is coded into one binary like a self-contained ssg rather than the site only requiring one file to work.
Paths in a URL aren't actually accessing files on a hard drive. They're sending a request to a program to serve the client the content defined by the path. Many times, said "server" program then goes and looks at a path on its host drive and serves a file there, but that is by no means a requirement - it's just a string that serves as an identifier.
In this case, the content served in response to the identifier "/static/style.css" can very easily (and according to the author, is) baked directly into the (single) binary.
Maintainability is one of my core values too, down to doing my own bike maintenance, like you! But it is far from being #1 to such a degree that this would make sense for me.
The Framework laptop is a good divergence point for us. Whereas you continue to eke out 9s on the DIY side, I realize resilience by having a spare decade old ThinkPad lying around at all times on which I can run Linux and Neovim in a pinch, and trusting there will be a lot of sub-$100 ThinkPads in the future should that one break on me too. I carry around the bits of CS and mathematics needed to trust myself to write a slow, informal, bug ridden parser with Haskell's combinators from Markdown to HTML if I ever have to. I don't see that day coming any time soon.
I'd hire you if I could. You'd be the perfect counterweight to a great many folks who tilt in the opposite direction.
The author is honest with themself and earnest with the reader. They're unapologetically themself, and figuring out how to achieve their goals in ways that align with their values and bring them joy. If those values do not align with yours, that is okay. That is beautiful! Now you have a clue as to what path you might explore.
The article is kind and humble and authentic, and I think that the author and the article make the world a better place. Thank you for writing it, and thank you for sharing it.
Since you read it, do you mind sharing its contents with us? It looks like many of us, who came here from a mobile platform, gave up reading way too early.
Author wants to understand and control the whole toolchain used to build their website (of course excluding most basic things like CPU architecture up to the programming language), because they want to be able to fix it themselves and want it to work in 10 years too, so not relying on others. They tried Hugo, didn't like it because of that, writing plain html was too much work, so they built a single binary dynamic site generator with a webserver themselves
To me it's easier to think about this as an exercise, an aid for the author to achieve their internal goals, likely of learning, being in control, etc. It's only incidentally intended for the reader, so the reader experience, Spartan as it is, is not the point, the writer's experience is.
> The author is honest with themself and earnest with the reader.
Earnest certainly, but being honest with themselves? Very much the opposite. And humble? Very much the opposite. The whole piece is self-congratulatory with the occasional /r/confidentlyincorrect nugget here and there.
Similarly, I was recently itching to generate Github Pages-like static sites from my self-hosted Gitea instance to include a blog. I had set up a global webhook filtered for 'webdeploy' branch pushes that would send a request to a specific Caddy path whitelisted for Gitea. An exec function for Caddy would run a shell script (yeah, I know) that would clone/pull the repo into a known directory, create a proxied subdomain for it in Cloudflare, and push necessary changes to Caddy's config.
While I don't have the same hesitations about depending on a small chain of open-source projects, I really didn't like the idea of caddy-exec despite my basic precautions, so I abandoned this approach until I can ponder it a bit more.
I get it, to some extent. I serve one of my sites with my own web server. I detest using programs that drag in zillions of dependencies over which you have no control, and every modern web server does exactly that.
That said, compiling your web content into your server? That's a step too far. Data and the application that process that data are two very different things, and (imho) should remain separate.
That's an implementation detail. For all we know the author has a very firm split between their application folder and their blog posts folder, and they only get combined at the compilation stage. You don't need the content to be stored separately at runtime in order to maintain separation of concerns in your codebase
Compiling contents into server wouldn't be a viable strategy in many situations, like if users are allowed to upload stuff, or when you have too much content, so much that it doesn't fit in memory etc.
But for a blog that's a collection of couple dozens of text blobs few Kilobytes each -- meh, whatever. You'll get tired of your blog before it becomes a technical problem.
Deploying via go static binaries is nice, and putting a little html into the binary at compile time is a built in feature. I use that to package the swagger ui without getting complicated. But for real config, I have that in a separate file, so different flavors get different config.
This is how the configuration UI in a lot of cheap router firmware was (is still?) designed. A few hundred KB of RAM and a MB or two of flash doesn't leave much room for inefficiency.
So the tl;Dr is they have all of the complexity and bugs of a static site generator, and all of the complexity and bugs and security risks and runtime cost of a dynamic website too.
I think they missed the point of a static site generator: you "compile" your site once, and then you have static assets that never need any maintenance ever again (unless you decide to change something) and which can be served by anything, anywhere.
This approach seems to take the worst aspects of static site generators and dynamic sites and bundle them together: you now have a binary to maintain (that has to generate the HTML et al anyway) and you have the potential for security/other bugs and you now have extra CPU/RAM/IO load on your server and you need specific hosting that allows you to run your binary.
Don't get me wrong this is fun and all and nice that it works for the author, but I don't think it is a sensible way to make things simpler, more reliable, or easier maintain (the opposite in my mind).
I will agree that Hugo is terrible IME - so so so much complexity for very little benefit when compared to Jekyll et al.
For me single binary website is like single line program.
You can do it, but will not be the most scalable thing.
I like to have separate things independent: server and content; so I can switch any of the 2 at whim.
As said before BTW the format in Mobile is horrible!
I work as an external examiner for CS students from time to time and I always find it sort of humorous when they draw the topic on decoupled architecture. Not because the theory is wrong in any sense, but because I’ve never seen it used the way that it is taught. I bring this up because your “switch any of the two at a whim” sort of caught my interest. When would you ever want to switch your content?
Don’t get me wrong I would absolutely separate my content and my “webserver” but I suspect from the cron job that the author has done so. A single binary doesn’t mean single file.
With just really minimal efforts of styling, a webpage can be looked so much cleaner. This[1] is a really good example of it. This website is simply unreadable and shows lack of care for their readers, which makes me spend even lesser time on it than I would.
To all those complaining about "mobile hostile": the site has horizontal scroll on desktop too. Probably just a miscalculation somewhere on the author's side.
Also, however way you spin it, mobile is a hostile environment compared to desktop. It's inconvenient to have to deal with tiny screen and defective keyboard. So, any usability defect that also exists on the desktop risks overflowing the cup of patience.
To be clear, on desktop the horizontal scroll exists but the site is perfectly readable regardless. On mobile you have to utilize the horizontal scroll to see the content.
Well, I don't browse Web on my phone because it's always a frustrating experience.
But, you sort of confirm what I wrote: mobile display, interactions, navigation are a lot worse in general, so any small detail that goes wrong has larger impact in the already painful environment.
I guess that would have been fine if we didn't have alternatives (ie: callbacks). He is already running a web server, so he could listen through that for updates.
Maybe, but Git has hooks. The author could deploy on push to do it only when needed, and immediately when relevant, rather than having to decide on a trade-off between immediacy and doing a lot of useless operations.
Obviously, this approach might not work for everyone, but I like to self-host my repos and use a git hook (post-receive) like this:
#!/bin/sh
BUILDDIR=/home/buildhook/.ib-build
BUILD=`grep build |cut -d" " -f2`
if [ -n "$BUILD" ]
then
touch $BUILDDIR/$BUILD
fi
And then the buildhook user has a job that runs every minute by cron:
#!/bin/sh
BUILDDIR=/home/buildhook/.ib-build
BUILD=`ls -t $BUILDDIR | head -1`
if [ -n "$BUILD" ]
then
rm -f $BUILDDIR/$BUILD
(
echo Building $BUILD on builder...
ssh builder time ./build $BUILD
) 2>&1 | mail -s "Building $BUILD on builder" build@example.com
fi
For my use case, on this repo, pushing to a branch with the word "build" in its name will trigger a build of that commit, which builds and packages it into a dpkg, and the build server hosts a private apt repository so I can just `apt-get update; apt-get install blah` on all the servers.
An alternative strategy is pushing to a different repo on a build server, etc.
you're making a lot of assumptions about how my deployment works here!
my git repositories are all on the same server that hosts my website - git is not doing a remote fetch - it's a local fetch, which makes it basically instantaneous.
even if it were a remote fetch, i would be fine with it. 525,600 http requests per year is less wasteful than NetworkManager's heartbeat (which defaults to 1 heartbeat request per _30 seconds_ on Arch)
for some context, a stock nginx server with 8 cpus can handle ~500k+ http requests _per second_.
I gave it a quick look and I am almost certain that this person is trolling us. The website literally mentions it uses “plain HTML” when in reality the website is “plain text”. There’s zero formatting HTML here. No headers, no paragraphs, no lists, not even a <center>
The little HTML and CSS it uses actively renders the website worse. The poster is a troll.
Thanks, I didn’t see those other dates. I was taking mine from the “closing arguments”:
> the web needs more weirdness. and more excitement. and more personality. SO GET OUT THERE AND MAKE A FUCKING DYNAMIC WEBSITE. THERE'S NOTHING STOPPING YOU. YOU WILL BE GLAD YOU DID. 10/10 WOULD RECOMMEND. WITH MUCH LOVE. JES ~2022-04-01
A lot of people here are criticizing this article as if they too hadn’t been through a phase like the author’s. I very much doubt it’s the case that the commenters have all been forever wise — that they have never had a partly formed, more naive, sophomoric era of their lives. A lot of people just aren’t brave enough to document them online. Kudos to JES for that, honestly.
Thanks for pointing this out. I was unnecessarily harsh in my mind when reading this, and your comment reminded me of my own first websites. I still have them in my personal archives, and I'm very happy that the Internet Archive doesn't know anything about them.
i'm in my 30s & have been in tech for a decade, how long is this "phase" expected to last? ;)
> I very much doubt it’s the case that the commenters have all been forever wise
representing and sharing my internal, authentic self with the world _is wise_ imo. i think the world deserves more expressions of authenticity.
i don't stuff of my personality into a shoebox before presenting myself to the world on _my own website_. if it seems a little manic or expressive, well, that's because i am a little manic and expressive.
To be honest the next phase could well be described as old and boring. It’s certainly a phase in which the positive side is being more confident in oneself, but on the other hand being much less malleable to the dynamics of the world around you.
The next change will come from within so one could argue it’s almost deterministic from here onwards. Set your course well!
Maybe it's just not the kind of thing I do, I'm not sure I see the huge need for dynamism.
For my personal blog, I wrote a simple static site generator in Python. It converts markdown files into articles, an index page, and an RSS feed. The HTML templates and CSS are written by hand. It's required minimal maintenance over the years, and for the most part Just Works. After an edit, I rebuild the site on my local machine, and deploy with `rsync`.
I do have a couple of "dynamic" things hosted behind the same domain. For those, I configure nginx to reverse-proxy to a local service - which could be a python script, or anything else.
The only real advantage I can see to my setup, beyond personal preference, is that redeploys come with precisely 0 downtime. Presumably, if you're updating a binary, there's a brief moment where the old one shuts down and the new one starts up (unless you're doing some kind of clever reverse-proxy switchover)
Idea is good, write-up not so good. You need to cater for people using differently sized reading devices and rewrite the article to be more readable. If it alienates people then you've lost the battle.
177 comments
[ 742 ms ] story [ 3735 ms ] thread> i have very high and unusual standards,
Which was kind of funny TBH :)
I certainly think that "mobile first" was a mistake that got everyone addicted, and made kids oblivious about tech.
But I think it was very intentional
I agree that designing for mobile first is annoying for the web in general. But... This is text! Most of the website is text, and it doesn't wrap or resize properly for a small screen.
Here, it's likely just a bug with the window width calculation, not a "mobile first" argument.
If a website is 99% text and it can't be read from every screen size from a phone to an ultrawide monitor... Than it's a bug, not a design choice.
That’s irrelevant. Most of the Web users are using mobiles, so if you decide to set a website up, the very basic thing is to ensure it’s readable on mobile. And since plain HTML is already readable on any device by default, it would be quite strange to voluntarily make it unusable on these devices.
You are right that nobody is beholden to creating pages that can be viewed on any device. However, it is not unreasonable to say that a person has mismatched interests when they say they care a lot about quality, interoperability and values in general, but then don't care about making the document explaining this viewable on most devices.
Yes, ultimately it's not important. But if you only publish your website using Gopher, at some point you have to accept that you're interested by making cool things rather than the other things mentioned.
In 2023, there's no technical reason websites should be inaccessible on any device. Doing so intentionally is needlessly user-hostile.
I’ve often seen _weird_ formatting, but _zero_ formatting is a new one for me.
If it fit the screen that would be better, but I’ve seen worse failure modes.
(assuming that since HN is mentioned in git repo [0] for the site, the author does read this occasionally)
[0] https://git.j3s.sh/j3s.sh
Proper capitalization of letters didn't make the cut either.
<link rel="stylesheet" href="/static/style.css" type="text/css">
Well then...
Seriously, people should try doing a lot more inlining than they do.
Then again, for 3KB the overhead of doing a cache check after parsing the HTML for the first time and then rendering it again may already be too much :)
In this case, the content served in response to the identifier "/static/style.css" can very easily (and according to the author, is) baked directly into the (single) binary.
It just uses go's built-in http.FileServer(..) to serve files from a directory.
> you should do this too!
Absolutely not :)
Maintainability is one of my core values too, down to doing my own bike maintenance, like you! But it is far from being #1 to such a degree that this would make sense for me.
The Framework laptop is a good divergence point for us. Whereas you continue to eke out 9s on the DIY side, I realize resilience by having a spare decade old ThinkPad lying around at all times on which I can run Linux and Neovim in a pinch, and trusting there will be a lot of sub-$100 ThinkPads in the future should that one break on me too. I carry around the bits of CS and mathematics needed to trust myself to write a slow, informal, bug ridden parser with Haskell's combinators from Markdown to HTML if I ever have to. I don't see that day coming any time soon.
I'd hire you if I could. You'd be the perfect counterweight to a great many folks who tilt in the opposite direction.
The author is honest with themself and earnest with the reader. They're unapologetically themself, and figuring out how to achieve their goals in ways that align with their values and bring them joy. If those values do not align with yours, that is okay. That is beautiful! Now you have a clue as to what path you might explore.
The article is kind and humble and authentic, and I think that the author and the article make the world a better place. Thank you for writing it, and thank you for sharing it.
Earnest certainly, but being honest with themselves? Very much the opposite. And humble? Very much the opposite. The whole piece is self-congratulatory with the occasional /r/confidentlyincorrect nugget here and there.
How so? The author just describes their values and how they shape their workflow. How are they not honest with themselves?
While I don't have the same hesitations about depending on a small chain of open-source projects, I really didn't like the idea of caddy-exec despite my basic precautions, so I abandoned this approach until I can ponder it a bit more.
Src code: https://github.com/Ono-Sendai/blog
That said, compiling your web content into your server? That's a step too far. Data and the application that process that data are two very different things, and (imho) should remain separate.
But for a blog that's a collection of couple dozens of text blobs few Kilobytes each -- meh, whatever. You'll get tired of your blog before it becomes a technical problem.
I think they missed the point of a static site generator: you "compile" your site once, and then you have static assets that never need any maintenance ever again (unless you decide to change something) and which can be served by anything, anywhere.
This approach seems to take the worst aspects of static site generators and dynamic sites and bundle them together: you now have a binary to maintain (that has to generate the HTML et al anyway) and you have the potential for security/other bugs and you now have extra CPU/RAM/IO load on your server and you need specific hosting that allows you to run your binary.
Don't get me wrong this is fun and all and nice that it works for the author, but I don't think it is a sensible way to make things simpler, more reliable, or easier maintain (the opposite in my mind).
I will agree that Hugo is terrible IME - so so so much complexity for very little benefit when compared to Jekyll et al.
As said before BTW the format in Mobile is horrible!
Don’t get me wrong I would absolutely separate my content and my “webserver” but I suspect from the cron job that the author has done so. A single binary doesn’t mean single file.
Thanks to the odd scroll container i cannot zoom to a view where i do not have to side-scroll anymore.
[1]: http://motherfuckingwebsite.com/
Also, however way you spin it, mobile is a hostile environment compared to desktop. It's inconvenient to have to deal with tiny screen and defective keyboard. So, any usability defect that also exists on the desktop risks overflowing the cup of patience.
The problem is that OP probably doesn’t know the basics of HTML so they’re shoehorning whatever they know onto a webpage.
It’s very common to find amateurish websites that work correctly only if you delete code they added.
But, you sort of confirm what I wrote: mobile display, interactions, navigation are a lot worse in general, so any small detail that goes wrong has larger impact in the already painful environment.
Apparently accessibility isn’t one of them, given that increasing zoom level on Safari does jack shit.
> this script runs every minute on a cronjob, and rebuilds my site if the git repo has been updated.
He is pulling the git repo 525,600 times a year for the few commits he'll be making in that year... I guess that explains the "unusual" word?
Tell, don't ask.
[0] https://stackoverflow.com/a/44476803
If you want to use a callback for this I'd recommend still polling periodically anyway.
An alternative strategy is pushing to a different repo on a build server, etc.
my git repositories are all on the same server that hosts my website - git is not doing a remote fetch - it's a local fetch, which makes it basically instantaneous.
even if it were a remote fetch, i would be fine with it. 525,600 http requests per year is less wasteful than NetworkManager's heartbeat (which defaults to 1 heartbeat request per _30 seconds_ on Arch)
for some context, a stock nginx server with 8 cpus can handle ~500k+ http requests _per second_.
The little HTML and CSS it uses actively renders the website worse. The poster is a troll.
[edit: with hindsight, looking at the other content on their site, I don’t think the date being April Fool’s day is particularly relevant.]
> the web needs more weirdness. and more excitement. and more personality. SO GET OUT THERE AND MAKE A FUCKING DYNAMIC WEBSITE. THERE'S NOTHING STOPPING YOU. YOU WILL BE GLAD YOU DID. 10/10 WOULD RECOMMEND. WITH MUCH LOVE. JES ~2022-04-01
A lot of people here are criticizing this article as if they too hadn’t been through a phase like the author’s. I very much doubt it’s the case that the commenters have all been forever wise — that they have never had a partly formed, more naive, sophomoric era of their lives. A lot of people just aren’t brave enough to document them online. Kudos to JES for that, honestly.
i'm in my 30s & have been in tech for a decade, how long is this "phase" expected to last? ;)
> I very much doubt it’s the case that the commenters have all been forever wise
representing and sharing my internal, authentic self with the world _is wise_ imo. i think the world deserves more expressions of authenticity.
i don't stuff of my personality into a shoebox before presenting myself to the world on _my own website_. if it seems a little manic or expressive, well, that's because i am a little manic and expressive.
To be honest the next phase could well be described as old and boring. It’s certainly a phase in which the positive side is being more confident in oneself, but on the other hand being much less malleable to the dynamics of the world around you.
The next change will come from within so one could argue it’s almost deterministic from here onwards. Set your course well!
For my personal blog, I wrote a simple static site generator in Python. It converts markdown files into articles, an index page, and an RSS feed. The HTML templates and CSS are written by hand. It's required minimal maintenance over the years, and for the most part Just Works. After an edit, I rebuild the site on my local machine, and deploy with `rsync`.
I do have a couple of "dynamic" things hosted behind the same domain. For those, I configure nginx to reverse-proxy to a local service - which could be a python script, or anything else.
The only real advantage I can see to my setup, beyond personal preference, is that redeploys come with precisely 0 downtime. Presumably, if you're updating a binary, there's a brief moment where the old one shuts down and the new one starts up (unless you're doing some kind of clever reverse-proxy switchover)
i recently rewrote the backend, i didn't realize there was a zoom & scroll issue. happy to fix it when i find the time.
You get all the power of templating and minimal cost
I admire the determination to “own” and control the entire stack.
Equally parts of this smell of “not invented here” syndrome.
A bunch of html, css and js files will work in 100 year’s time and if no there will be an archeological AI bot to convert them!
For the short term, say 10 years Wordpress ain’t a bad choice for most.
Unusual yes, but very low given the awful resulting design of the website that can't even present text to fit your screen properly