[HN Gopher] My website is one binary (2022)
___________________________________________________________________
My website is one binary (2022)
Author : greenSunglass
Score : 237 points
Date : 2023-10-21 07:49 UTC (2 days ago)
(HTM) web link (j3s.sh)
(TXT) w3m dump (j3s.sh)
| otikik wrote:
| 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
|
| > i have very high and unusual standards,
|
| Which was kind of funny TBH :)
| beebeepka wrote:
| Thought the same. Good they are proud of themselves, tho. I'll
| just not read what they have to say.
| 4gotunameagain wrote:
| Not catering to mobile could be construed as a part of the
| owner's values :)
|
| I certainly think that "mobile first" was a mistake that got
| everyone addicted, and made kids oblivious about tech.
| screamingninja wrote:
| > I certainly think that "mobile first" was a mistake
|
| But I think it was very intentional
| laserbeam wrote:
| 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.
| mirkodrummer wrote:
| 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
| jehb wrote:
| 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]
| hk__2 wrote:
| > 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.
| themoonisachees wrote:
| Countee-counter-counter argument:
|
| 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.
| imiric wrote:
| "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.
| fstokesman wrote:
| 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.
| izoow wrote:
| 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/
| f233f2 wrote:
| That website contains <meta
| name="viewport" content="width=device-width, initial-
| scale=1">
| xigoi wrote:
| So does the OP's website.
| xigoi wrote:
| There is a difference between not being focused on mobile and
| deliberately making your website unreadable on mobile.
| hahahacorn wrote:
| Also there is 0 formatting with the safari reader which is
| likewise impressive.
|
| I've often seen _weird_ formatting, but _zero_ formatting is a
| new one for me.
| Aeolun wrote:
| I found that scrolling left and tight to read the text was
| fairly usable.
|
| If it fit the screen that would be better, but I've seen worse
| failure modes.
| MattRix wrote:
| In what world is that "usable"? I mean sure it technically
| works, but the usability of it is horrible.
| albedoa wrote:
| That classic definition of "usable" we know and love: "I've
| seen worse"
| _kblcuk_ wrote:
| 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` -\\_(tsu)_/-.
| madeofpalk wrote:
| `white-space: pre-wrap` is the solution to this. It's pre,
| but with wrapping when it's needed :)
| _kblcuk_ wrote:
| cc @j3s (I wonder if this even works here), here's your
| line breaks fix :)
|
| (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
| montroser wrote:
| 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.
| gherkinnn wrote:
| The author's reasoning and not building for the platform are at
| odds. I don't get it.
| badsectoracula wrote:
| Desktop view in both Firefox and Chrome seem to work for
| viewing the full text without horizontal scroll, at least here.
| livrem wrote:
| Firefox Mobile reader mode fixed it, so in practice only as
| inconvenient as tapping one button. Still not a good first
| impression.
| geon wrote:
| In iOS reader, the line width was fixed, but there were still
| no paragraphs.
| streakfix wrote:
| Thank God for that
| aputsiak wrote:
| 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.
| every wrote:
| You get exactly the same result if you look at it with an
| actual text browser such as lynx. One giant brick of
| text...
| Retr0id wrote:
| I had this even on desktop Firefox.
| augustk wrote:
| The crucial viewport meta element is included though:
| <meta name="viewport" content="width=device-width, initial-
| scale=1.0" />
| dbalatero wrote:
| Likely copypasta.
| btbuildem wrote:
| Not just mobile, it's doing the same thing on my 30" desktop
| monitor
| executesorder66 wrote:
| > i have very high and unusual standards,
|
| Proper capitalization of letters didn't make the cut either.
| Dwedit wrote:
| "my website is one binary"
|
| <link rel="stylesheet" href="/static/style.css" type="text/css">
|
| Well then...
| r00tbeer wrote:
| I think that URL gets served by the same single binary. Might
| look like multiple files and connections to you ...
| teddyh wrote:
| But why? Why not serve all needed content inline?
| manx wrote:
| Sometimes browser caching and ease of development is the
| reason here.
| Aeolun wrote:
| 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.
| teddyh wrote:
| I sincerely doubt that the assets on the site in question
| are large enough to warrant this.
| chrismorgan wrote:
| 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.
| chefandy wrote:
| 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.
| piperswe wrote:
| The static files are probably a directory embedded into the
| binary with Go's embed package, and mounted on /static.
| LordDragonfang wrote:
| 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.
| smolder wrote:
| It's still pretty strange to not have the css inlined.
| jxf wrote:
| Why is this a counterexample to being one binary?
| mattlondon wrote:
| Yep source here: https://git.j3s.sh/j3s.sh/blob/main/main.go
|
| It just uses go's built-in http.FileServer(..) to serve files
| from a directory.
| hiAndrewQuinn wrote:
| Very cool!
|
| > 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.
| alexdunmow wrote:
| What do you consider to be tilting in the opposing direction?
| fullstackchris wrote:
| probably making mobile friendly websites :)
| tczMUFlmoNk wrote:
| I really enjoyed reading this article.
|
| 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.
| walteweiss wrote:
| 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.
| badsectoracula wrote:
| Desktop mode will help you read it
| ruune wrote:
| 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
| nine_k wrote:
| 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.
| cxr wrote:
| > 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.
| skotobaza wrote:
| > The whole piece is self-congratulatory
|
| How so? The author just describes their values and how they
| shape their workflow. How are they not honest with
| themselves?
| hackish wrote:
| 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.
| walteweiss wrote:
| Impossible to read on a mobile, not even reader mode helps. Good
| bye, end of the discussion.
| ruune wrote:
| It's not impossible, but I definitely found myself losing my
| line while scrolling left
| Ono-Sendai wrote:
| My blog is a single binary also: https://forwardscattering.org/
|
| Src code: https://github.com/Ono-Sendai/blog
| fuzzfactor wrote:
| Computer people should take a look at this blog, it's quite
| advanced.
| bradley13 wrote:
| 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.
| arrow7000 wrote:
| 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
| crabbone wrote:
| 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.
| lanstin wrote:
| 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.
| userbinator wrote:
| 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.
| mattlondon wrote:
| 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.
| f1shy wrote:
| 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!
| devjab wrote:
| 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.
| ruduhudi wrote:
| This website is not readable on my phone at all.
|
| Thanks to the odd scroll container i cannot zoom to a view where
| i do not have to side-scroll anymore.
| mr-karan wrote:
| 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.
|
| [1]: http://motherfuckingwebsite.com/
| crashmat wrote:
| Why is it unreadable? I don't know about desktop, but on my
| phone it's perfectly readable
| maleldil wrote:
| Check out the rest of the thread. For most people, including
| me, zoom doesn't work and you have to scroll horizontally to
| read the post.
| crabbone wrote:
| 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.
| corbezzoli wrote:
| No. If you drop all the style and stop manually wrapping text
| via \n, the website would work fine on mobile.
|
| 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.
| cgriswald wrote:
| 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.
| crabbone wrote:
| 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.
| wiseowise wrote:
| > mY vALuES
|
| Apparently accessibility isn't one of them, given that increasing
| zoom level on Safari does jack shit.
| csomar wrote:
| > i have very high and unusual standards,
|
| > 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?
| baz00 wrote:
| Unusual would be crazy in this circumstance.
|
| Tell, don't ask.
| bsza wrote:
| git fetch is basically just one string comparison if there are
| no new commits [0], I don't think it's as costly as you make it
| sound.
|
| [0] https://stackoverflow.com/a/44476803
| csomar wrote:
| 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.
| janto wrote:
| If he breaks the server, then a callback/webhook
| notification for the fix won't work either.
|
| If you want to use a callback for this I'd recommend still
| polling periodically anyway.
| whizzter wrote:
| Problem with self-hosting though, if his server breaks, so
| does the callbacks.
| Kwpolska wrote:
| It might be a string comparison, but one of the strings
| usually comes from a remote server, which can be costly.
| p4bl0 wrote:
| 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.
| ralferoo wrote:
| 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.
| quickthrower2 wrote:
| Did you remember that number from Rent?
| corbezzoli wrote:
| 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.
| assimpleaspossi wrote:
| The <center> element has been marked obsolete for at least 15
| years.
| corbezzoli wrote:
| It was a snarky comment due to the "manual" centering done on
| the website (i.e. it uses spaces)
| gorgoiler wrote:
| [2022], but specifically April 1st.
|
| [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.]
| philosopher1234 wrote:
| April 6th
| gorgoiler wrote:
| 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.
| distances wrote:
| 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.
| eviks wrote:
| Look at the bottom
| eviks wrote:
| Thank you for noticing, fell for it
| Retr0id wrote:
| 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)
| block_dagger wrote:
| Very high and unusual website. Unreadable. 100% bounce.
| mrlonglong wrote:
| 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.
| pyrolistical wrote:
| This would be fun to do in zig. Imagine using comptime to bake
| the static vs dynamic. Then concat it together when streaming the
| bytes.
|
| You get all the power of templating and minimal cost
| urbandw311er wrote:
| I'm torn.
|
| I admire the determination to "own" and control the entire stack.
|
| Equally parts of this smell of "not invented here" syndrome.
| quickthrower2 wrote:
| The trick is to not build it yourself but judge what will be
| enduring.
|
| 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.
| eviks wrote:
| > have very high and unusual standards
|
| Unusual yes, but very low given the awful resulting design of the
| website that can't even present text to fit your screen properly
| forgotpwd16 wrote:
| Kinda confused. So like the text is inside the binary? And
| whenever they change any text they've to recompile and serve the
| new binary?
| fsiefken wrote:
| Tiddlywiki is a single selfcontained javascript executable, would
| make more sense to me. As of yet I'm very happy with my simple
| obsidian and hugo setup. What exactly is the problem with hugo or
| ssg in general? I think they are fantastic. You want a webserver
| to host only static files, some javascript/wasm for dynamic stuff
| if needed and if really needed sqlite for persistent shared
| storage.
|
| It reminds me of the guy who coded and compiled his impressive
| crypto exchange in c by hand to get the attack surface low and
| the performance extremely high. Does anyone remember the name of
| the site? I think he mentioned (years ago) he was on the brink of
| giving up.
| 28304283409234 wrote:
| "(2022)"
| snickerer wrote:
| You showed us yours, I show you mine.
|
| My website, game engine, and webserver is one binary. The source
| has 1000 lines of C code. The binary has a size of 164k (I don't
| know why it is so damned big).
|
| I included my own webserver. The existing servers add way too
| much (hidden) complexity.
|
| You can check out the result, an interactive fiction game in
| German, here: http://vmd34232.contaboserver.net/ (no tracking, no
| ads, not commercial)
| arcastroe wrote:
| Reminds me of my site :)
|
| https://toldby.ai/
|
| Mine is not a single binary though. It's asp.net
| fsiefken wrote:
| Ah that's nice, long ago I used parchment.js to load a inform7
| created z5 file on my website. You could try to compress your
| executable with upx https://upx.github.io/
| danpalmer wrote:
| What even does "keep it simple" mean. What even is
| "understandable". Every article about this sort of thing skips
| past the interesting arguments and assumes that their approach is
| the simple one, that their aim is simplicity.
|
| If you are presented with the option of an abstraction - perhaps
| a library or framework, perhaps a service or API - is it
| "simpler" to use it or to not?
|
| If you don't use it, and you build the alternative, you know more
| about how the system works as a whole, and therefore arguably
| it's simpler. But complexity is still introduced, and in some
| cases the abstraction layers still need to be built (but maybe
| not all of them).
|
| If you do use it, you can consider the system to be simpler
| because you hide the complexity, and on the happy-path of usage
| that may be true, but the complexity still exists and you don't
| understand it because it's hidden. Arguably it's simpler, but
| it's easy to point to how it's more complex.
|
| I've met engineers who strongly prioritise one or the other of
| these sorts, and to them that way is _obviously_ simpler, but the
| problem is that both approaches are _obviously_ simpler when you
| look at them in a certain way, you have to get past the obvious
| to realise that there are trade-offs.
| nine_k wrote:
| Imagine that you want to make an apple pie. Normally you would
| buy all the components and utensils, then bake it in a pre-
| existing oven.
|
| But if you want to make an apple pie _from scratch_ , you first
| need to create a Universe, and you likely go for the simplest
| Universe that supports apple pies. The overall stack would be
| simpler (especially if you pursue simplicity and ease of
| understanding as a goal), but the last step, making the actual
| pie, may be more involved, and the taste of the resulting pie
| may be not top-notch. In exchange, you have a pie which you
| completely understand from first principles.
| latexr wrote:
| > In exchange, you have a pie which you completely understand
| from first principles.
|
| If you ever get to it, with trying to create a Universe and
| all. It's like the drum loops joke:
|
| > I thought that using loops was cheating, so I programmed my
| own using samples. I then thought that using samples was
| cheating, so I recorded real drums. I then thought that
| programming them was cheating, so I learned to play the drums
| for real. I then thought that using purchased drums was
| cheating, so I learned to make my own. I then thought that
| using pre-made skins was cheating, so I killed a goat and
| skinned it. I then thought that was cheating too, so I grew
| my own goat from a baby goat. I also think that this is
| cheating, but I'm not sure where to go from here. I haven't
| made any music lately, what with the goat farming and all.
| throwaway167 wrote:
| I don't get your comment in regard to this article.
|
| The author finishes by very explicitly saying do your own thing
| your way. Moreover, they suggest they're not happy using
| systems that they find understanding obscure/a burden.
|
| I suggest reading beyond the opening paragraph.
| beebmam wrote:
| One of the article's themes is simplicity and its
| relationship to how we design software. So no, I think the
| comment you're replying to is totally apt and welcome
| discussion of the idea.
| danpalmer wrote:
| I did read the article. My comment is not a criticism of the
| article, it's a general point that I think about a lot and
| which I think was worth discussing in the context of this
| article.
|
| I think this article is a fairly clear example of one side of
| the debate, and while it's somewhat open to the idea that
| there are other ways of doing things, it is also somewhat
| dismissive of using other peoples' abstractions.
| remram wrote:
| I think you are alluding to the difference between "simple" and
| "easy". You might enjoy this talk from Rich Hickey:
| https://paulrcook.com/blog/simple-made-easy
|
| You can add stuff to make something _easier_ to build or deploy
| (faster, more automated), while the addition makes the whole
| more _complex_ (less understandable, harder to troubleshoot).
| tetsuhamu wrote:
| I agree wholeheartedly with all of the points made in the
| article, but this website kinda sucks as an example.
|
| - The website is "one binary", but the deploy strategy involves
| compiling it instead of running a binary artifact
|
| - Won't rely on github pages, but depends on external resource at
| openlibrary.org
|
| - Writing your own stuff lets you take advantage of open
| standards, but the .html files in thoughts/ are structured as
| plaintext with a false file extension
|
| - When people go this route, they usually try to cram everything
| into the initial page load. This has several static files served
| dynamically.
|
| - The Golang code does not cache any responses, and does not
| store templates in memory.
|
| - Several dependencies in the go.mod file, all of them seem
| unused?
|
| Most importantly: No discussion about the technical benefits of
| the "single-binary" ethos compared to modern infrastructure.
|
| It's my humble opinion that it's a great idea, and this is a poor
| example.
| tetsuhamu wrote:
| It's not actually a single binary.
|
| It's a single binary working with the filesystem.
|
| All content is on the filesystem.
|
| The "single binary" is a lightweight golang webserver that
| serves content from the filesystem.
| dsQTbR7Y5mRHnZv wrote:
| No it isn't. You can try compiling from source and running it
| yourself: https://git.j3s.sh/j3s.sh/tree/c4517e8484a68c734d2f
| 17c17c546...
| shhsshs wrote:
| The code uses `//go:embed` which actually embeds a fake
| filesystem into the binary. It's really easy to miss that
| part, but it truly is one single binary, despite seeming to
| reference files by paths.
| tetsuhamu wrote:
| Oh dang, that's neat! Thank you!
| gildas wrote:
| Shameless plug, my homepage on GitHub is also one binary (self-
| extracting ZIP) file which run on client-side, see
| https://gildas-lormeau.github.io/
| notfed wrote:
| I guess this would be neater if it demonstrated multiple pages?
| Otherwise unclear how it's an improvement from a single html
| file.
| gildas wrote:
| It's a kind of demo of SingleFile and the self-extracting ZIP
| format [1]. The self-extracting ZIP format is an improvement
| when you want to archive web pages and read them without
| relying on an extension. The fact that resources are
| compressed also considerably reduces archive size.
|
| I agree it would be "great" a complete website in the ZIP. I
| think this is technically possible, someone just have to code
| it.
|
| [1] https://github.com/gildas-lormeau/SingleFile#singlefile
| JodieBenitez wrote:
| > i have very high and unusual standards,
|
| Apparently latency is not one of them.
| apatheticonion wrote:
| I was hoping this was a wasm binary being used as an entry point
| for a website (skipping the HTML and JS entirely and going
| straight to wasm).
|
| Nope. Just a static HTML website... Cool...?
| gildas wrote:
| Mine is not a WASM file but is a ZIP file, see https://gildas-
| lormeau.github.io/
| runlaszlorun wrote:
| I've been working on something like that but, and I'm not sure
| if you've used WASM much, but WASM has none of the web APIs so
| you need to lean on JS to do UI or local storage, etc.
|
| I've been fiddling with my own 2D canvas UI, and would like to
| get WebGL thrown in the mix but that's a learning curve of it's
| own.
|
| The effort to build my own input widgets and intercept click
| events, etc was actually less then I would have imagined.
|
| I find WebAssembly a fairly odd duck though and highly
| disappointing. As the quote goes, there's little actually "web"
| or "assembly" about it. Performance seems on average no faster
| than JS- sometimes worse. The driving factor being how and how
| much you need to serialize/deserialize into its TypedArray
| memory space. And while you can port legacy codebases over,
| they then will be using various kludges to use the existing JS
| API's instead of the POSIX-style interface they're likely
| expecting.
|
| If anything, I have a newfound respect for the performance of
| current JS engines. And am about to go all in on HTML Custom
| Elements for the UI. Once I ignored the various features most
| tutorials talk you through and looked at them as just a class
| overriding HTMLElement, they made a lot more sense to me.
|
| Just my 20 cents...
|
| ---- edited for spelling ----
| apatheticonion wrote:
| > but WASM has none of the web APIs so you need to lean on JS
| to do UI or local storage, etc.
|
| Yeah, haha I am eagerly waiting on these additions. I'm
| following the spec quite closely and would love it if one day
| an index.wasm could replace index.html as a web application
| entry point.
|
| > I find WebAssembly a fairly odd duck though and highly
| disappointing.
|
| 100% agree. It was introduced about 8 years ago and we still
| can't use it to make a div appear (without heavy JS
| thunking). The consortium is discussing how to use web
| assembly in serverless functions and to replace docker -
| meanwhile in the web world, it's essentially a faster Web
| Worker.
|
| But hey, I'm still hopeful
| xyzzy4747 wrote:
| Just use Vercel + next.js + tailwind.css + typescript + node.js +
| pm2 and get stuff done quickly and sleep easy.
| tap-snap-or-nap wrote:
| If someone needs to host less than 10 static pages then HTML is
| perfectly good.
| ljm wrote:
| If you wanted a quick and easy dynamically served website then
| you could just as well do it in PHP and rsync your changes over.
| aae42 wrote:
| I share a number of the same values as the author. I also have a
| hard time with not understanding things and relying on others.
| But I guess I understand Hugo and GitHub pages (I use gitlab
| pages) well enough that I'm happy to use them.
|
| I wonder if the author owns a car, and if he does, which?
|
| Locking my Hugo build with something like Nix makes that
| comfortable. I can upgrade as I discover bugs but can always go
| back if it ain't broke. I do wish sometimes they would stop
| adding features.
|
| What it's driving me to do in this same vein is build my own Hugo
| theme.
|
| Also, tend to agree about dynamic sites vs JavaScript behemoths.
|
| Disagree with the authors styling, and am a big fan of classless
| lightweight CSS, of which there are a number to choose from these
| days (I keep a list).
| tromp wrote:
| Related: Redbean - Single-file distributable web server [1]
|
| [1] https://news.ycombinator.com/item?id=26271117
| yoav wrote:
| If this isn't parody I don't know what is.
| drawkbox wrote:
| I like the thinking and dependencies are a weight that make at
| least personal projects more maintenance long term, even if they
| help in the short term.
|
| This doesn't fly at clients/customers usually but what you
| control needs to be highly maintainable and simple. Whatever
| works for you to achieve this is good. In regards to personal
| projects or internal products, in that case a framework with
| massive dependencies just isn't easier to maintain long term over
| simple web standards and market standard formats like
| HTML/CSS/JSON/Markdown/etc.
|
| My only complaint is the lack of capitalization on the content,
| so many tech/devs do this, just don't. Even Sam Altman...
|
| How dare you not capitalize in a capitalist system. /s
|
| Seriously though, just capitalize your sentences.
| sotix wrote:
| It's always refreshing to see someone's personal and unique
| website that isn't full of paywalls or newsletter pop up spam
| while you scroll that most articles linked on HN contain[0]. I
| particularly like the fish bouncing around at the top like the
| DVD logo on idling DVD players. The site could use a few fixes to
| the formatting to fit the content into the device's width, but I
| applaud the author for making the website in their own manner.
| Truly the spirit of a hacker!
|
| [0] I would be in favor of getting rid of the modern atrocities
| of website design that frequently make the front page of HN.
| Simpler, more effective designs without distractions should be
| boosted.
| iamafk wrote:
| small I triggers me
| kosolam wrote:
| I came in here to write the same. :p
| runlaszlorun wrote:
| To OP:
|
| I see a lot of very critical posts on here.
|
| With all due respect... screw them.
|
| Perhaps they may be right in their critiques, but as an industry
| we're rapidly heading off into mass stupidity in order to follow
| a bunch of collective "ought to"s and "shoulds". Many of which
| have the current validity of an urban myth.
|
| What passes for "engineering" these days would be laughable if we
| weren't actively building our future on it. My father was an
| aerospace engineer and I feel I can hear him rolling over in his
| grave at was passes for engineering in modern software
| development.
|
| Yes, this is a comment section so everyone is free to comment.
| But personally it's taken me 25 years in the industry to finally
| ignore all those chattering voices and actually do what I feel
| makes sense for those few opportunities where I can.
|
| And on a personal site no less? That old "here's to the crazy
| ones" line in the Apple commercial sure rings far from true.
| Given what the internet has become and that once startups are now
| literally the largest corporate behemoths on the landscape- it
| should not be a surprise.
|
| Teddy Roosevelt's quote about "the man in the arena" is so true
| these days.
|
| I say rock on, OP, rock on...
| mortallywounded wrote:
| My website is also a single binary (assets, styles, html and
| everything is embedded in it). It's scp'd onto my server and
| restarted with systemd.
|
| It has been great.
| marcrosoft wrote:
| It is Go not golang. Golang is used for search it is not the name
| of the language.
| quickthrower2 wrote:
| How can you use Golang for search if no one is using it in the
| corpus?
| slmjkdbtl wrote:
| Reminded of me once also wrote my websites in C using only POSIX
| compliant system libraries, with assets embedded in the single
| binary as base64 / hex arr. The worst part is I bragged about it.
| Eiim wrote:
| I quite like this! I see a lot of people quoting the line "I have
| very high and unusual standards" and only paying attention to the
| first adjective. It's obvious that many of the things people are
| complaining about are simply not important to them, which is
| fine! Part of the magic of the personal website the author talks
| about comes from how different people prioritize different parts
| of the website creation and usage experience differently.
|
| Where I do think the article misses the ball is on static vs.
| dynamic websites. If you need a dynamic website (for example, to
| display the user's IP), build a dynamic website. If you don't,
| build a static website. There really isn't another argument
| presented here beyond "some things you can't do with a static
| website", which is really just the fundamental tradeoff of a
| static site.
|
| Anyways, a neat glimpse into a particular development philosophy
| that I will very likely never do but I will share with some
| similarly-minded friends :)
| wutwutwat wrote:
| Golang has a ton of single binary websites out there. The two
| that come to mind off hand are Gogs/Gitea only because I
| contributed to them
|
| https://github.com/gogs/gogs
|
| https://gogs.io/docs/installation/install_from_binary.html#d...
|
| https://github.com/go-gitea/gitea
| zzo38computer wrote:
| Disabling CSS gets rid of the line breaks, unfortunately.
| fullstackchris wrote:
| Lot of (IMO) useless hot air comments saying this or that in
| here...
|
| You can do your fancy build process, single binary, whatever. The
| bottom line is if you want to call yourself a (good/strong/solid)
| web developer, your site needs to be accessible across all form
| factors.
|
| I'm on mobile so I can't check, but I would bet this thing
| doesn't get even close to a good score on a tool like Lighthouse.
| Then the fact that some people are applauding OP and turning
| around making fun of "modern" software development (whatever that
| means) don't even realize they're part of perpetuating that
| problem (applauding sites which are missing key peices of
| accessibility and functionality)
|
| This isn't really opinion or up for discussion either, this is
| quite literally the benchmark of living in our reality. We have
| accesibility guidelines and standards built over the years by
| hundreds of dedicated folks who worked hard to make those
| standards and guidelines clear - SO USE THEM! (meaning
| HTML5/CSS3/WCAG) Software is for humans, to be used by humans.
| Sure, I get the aspect that there is a bit of artistic freedom
| which OP has taken and by no means has to follow any guidelines
| at all. But this is definitively NOT a high standard or normal in
| any sense of what decent modern web development is.
| rurban wrote:
| That's what the various ruby, python or perl compilers are good
| for. Single huge binary, huge RAM savings, easy deployment and
| updates.
___________________________________________________________________
(page generated 2023-10-23 09:01 UTC)