[HN Gopher] Building a personal website in 2021
___________________________________________________________________
Building a personal website in 2021
Author : mkosmul
Score : 316 points
Date : 2021-05-16 13:54 UTC (9 hours ago)
(HTM) web link (origami.kosmulski.org)
(TXT) w3m dump (origami.kosmulski.org)
| papito wrote:
| I spent some up front time setting up Supervisor, Jekyll, and a
| light server listening to Github actions that, upon an update,
| just pulls the latest on commit and reruns the static publisher.
| I even have a staging branch/subdomain.
|
| The first point - easy to update - is critical. If there is any
| friction to the process, you will just never do it. Your personal
| time is inherently much more valuable than your work time.
|
| And if you are creating your new personal site, I highly
| recommend scrapping everything you know and doing it with Grid
| and Flex.
| robbiemitchell wrote:
| Hosts like Netlify also do this magic. Pushing to Master on
| Github runs any Jekyll plugins you want and deploys the site,
| including things like image optimization and CDN if you want.
| ______- wrote:
| I don't have a personal website, but I operate various online
| services like pastebins, image uploader sites, and other online
| tools that many people use. People would get more utility out of
| those than a personal blog, since I learned (a bit late) that I'm
| not especially good at writing and communicating my ideas very
| well.
|
| I can get across an idea, but it usually misses nuance and I find
| writing personal stuff very embarrassing later on down the road,
| when I start regretting ever hitting _publish_. Out of all the
| personal blogposts I have written, roughly three I am proud of,
| the rest just embarrass me.
| codebolt wrote:
| The main argument for static site for me was the simplicity and
| price of hosting. It's also CDN friendly which means a huge
| performance boost.
|
| Hosting a static site on Azure costs me 2-3$/mo which is well
| within the free credits I get from my work-sponsored MSDN
| subscription.
| ignoramous wrote:
| In 2021? I'd prefer serverless and low-code. If I only need a
| blog (and not a website) I'd consider posting on substack.com,
| dev.to, or hashnode.com instead.
|
| > _Easy to update: I usually post 1-2 pictures to social media
| each week, and I wanted adding a picture to my site to be as easy
| as posting it on any other platform... I could buy a domain and
| redirect it to my flickr, facebook, or instagram feed_
|
| There exists no-code apps that post your social media feeds to a
| weblog. One of the better ones I know is milkshake.app
| https://news.ycombinator.com/item?id=20154181
|
| > _The best approach would be to have data separated from
| presentation as much as possible, i.e. for each model to just
| define a few fields such as: name, model type, image, etc., and
| use some kind of templates to present this data to the end user._
|
| Low-code builders like onuniverse.com, glideapps.com,
| draftbit.com (mobile apps), and pory.io come to mind, though none
| of them let you publish websites via another provider.
|
| > _Longevity: since I would be putting in a lot of work, I wanted
| to be able to expand and maintain the site for at least 5-10
| years without major overhaul._
|
| Sound like serverless services like netlify.com,
| pages.github.com, vercel.com, pages.dev fit the bill to deploy
| the site to?
| hyakosm wrote:
| I like the satisfaction to manage my proper website and tools.
| It's like building it's own chairs, I could maybe find better
| furniture for a better price, but there is a pleasure to make
| its own things without depending on other services. It's a
| matter of choice, but for these reasons for a personal website
| without high availability requirements, I prefer servermore and
| high-code. =)
| askonomm wrote:
| The person specifically mentions longevity and yet you mention
| a myriad of third-party tools to depend on.
| ignoramous wrote:
| I don't see your point: The author settled on _Jekyll_ ,
| which is a third-party tool?
|
| Besides, they mean longevity in terms of having to maintain
| servers. Serverless abstracts away the server, and its
| maintenance along with it. More likely that Cloudflare would
| be here up-to-date with all the security, network, and
| hardware upgrades in 10 years time than a home server.
| vbezhenar wrote:
| I would try to use github.com to host sources of the website
| and cloudflare pages to publish the website. It's completely
| free and probably as reliable and fast as possible.
| hedora wrote:
| Using cloudflare breaks tor.
| jtbayly wrote:
| Can't you turn that off?
| __turbobrew__ wrote:
| It took me about an hour to set up an AWS static website backed
| by S3 and cached by cloudfront. I use Jekyll and simply sync the
| _site folder to s3 to update my website.
|
| Some nice things about this setup:
|
| 1.) AWS static sites don't insert trackers 2.) There is zero
| maintenance 3.) Cloudfront + static website is very fast 4.)
| Setup can scale near infinitely (so can your bill)
|
| Downsides:
|
| 1.) You are locked into AWS. Although migrating to another
| provider to serve static files would be trivial. 2.) If your
| website took off in popularity the bill might be more than you
| are comfortable with.
| rectang wrote:
| > _Longevity: since I would be putting in a lot of work, I wanted
| to be able to expand and maintain the site for at least 5-10
| years without major overhaul (but, technology being what it is, I
| was aware I would probably have to perform some maintenance work
| onhttps://news.ycombinator.com/item?id=27173728ce every 3 years
| or so)._
|
| With that criteria, I wonder about the choice of Jekyll, which is
| huge and complicated. I'd be looking for something with fewer
| moving parts.
|
| I suppose one nice thing is by that limiting yourself to static
| html output it becomes easier to switch from one generator to
| another.
| axegon_ wrote:
| I've always adored the idea of personal sites which do not
| require any build systems or databases, or in other words
| static sites. On multiple occasions over the years I've had the
| ambition to start working on my own and maintain it, hence the
| reason I created(shameless advertising, I know)
| https://rorigami.site/
|
| But really my main motivation was to have something that's
| self-contained and does not require any maintenance whatsoever.
| Ironically every time I decide to make improvements or use it,
| something urgent immediately pops up... Oh well...
| [deleted]
| mkosmul wrote:
| Yes - with all contents stored in nice Markdown-formatted
| files, switching to an alternative site generator should be
| relatively easy.
| temp8964 wrote:
| Should be, but all the customizations (themes, logics) will
| not transfer.
| temp8964 wrote:
| Exactly for longevity (5, 10, 15 years), I will not use any
| static site generator. I know it sounds ridiculous, but I have
| better confidence of longevity on Wordpress / Mediawiki than
| static site generators.
| actuallyalys wrote:
| None of the popular static site generators match Wordpress or
| Mediawiki for how long they've been around. Although for me
| personally, the established ones are old and popular enough.
| E.g., I use Pelican, which has been around since 2010.
| mjthompson wrote:
| A static site generator that works now will probably still
| work in 10 years, even if updates cease. And it will be safe
| to use. After all, it just churns out HTML that you put
| somewhere.
|
| The same can't be said of WordPress or MediaWiki. You will
| not be able to run these at all if they become unsupported
| and will have to migrate, or risk facing security issues.
|
| Sure, SSGs are not for everyone, but the potential for
| deprecation isn't a major issue, at least for a personal
| site.
| simion314 wrote:
| I pay for hosting and Wordpress, is super cheap, I wrote
| soem blog posts in 2-13 then got bored, the site is still
| up and is up to date, with no effort from me, no code or
| sysadmining about. If I need I can start blogging again
| tomorrow from a browser or I could get a fancy app but if
| you used some non-standard thing you need to keep admining
| it, and if you maybe stopped like me for 8 years when you
| get back you probably forgot all the details about what
| stuff you used.
|
| If for some reason all those companies selling and
| supporting Wordpress would not be allowed to continue using
| it by magic I am sure they are capable enough to migrate it
| for me.
|
| My only experience with Wordpress is with a simple blog and
| not complex sales pages or other stuff that require using
| SEO/sales/magic plugins. Worst case scenario if you are a
| developer you can dump the wordpress database into a file
| then write a script and generate plain html files or
| migrate to some other format.
| temp8964 wrote:
| Wordpress has export function. I am almost 100% sure, if
| Wordpress dies its replacement will be able to import
| Wordpress exports, or even its database.
| shaicoleman wrote:
| I've recently upgraded a MediaWiki website (colemak.com) to
| the latest version from version 1.5.3 (released Dec/2005).
|
| Besides a few minor configuration updates, it worked almost
| out of the box after the upgrade on a new server.
| temp8964 wrote:
| Thanks! Really good to know. I have being struggling with
| choosing between Wordpress and MediaWiki for a side
| project.
| nojito wrote:
| Jekyll is almost as old as Wordpress.
|
| 2003 vs 2008
| temp8964 wrote:
| I have never used Jekyll, so I Googled jekyll backward
| compatibility and I found several breaking changes.
|
| Also I realized another issue with SSG, the setup is on the
| desktop, not on the server. I have problems with this too.
| ValentineC wrote:
| WordPress's core APIs might be very well-supported, but most
| of their plugin ecosystem doesn't have such guarantees.
|
| I recently tried to revive a 2014 backup of my local
| hackerspace's website so that I could staticize it, but it
| wouldn't look right even with the same PHP and MySQL
| versions, because many of the plugins stopped working.
|
| I think I would have been better off scraping a copy of the
| site from Archive.org.
| nucleardog wrote:
| A similar worry has led me to use the PHP-based PicoCMS.
| Basically a thin glue between Twig templating and markdown with
| minimal dependencies.
|
| Even if it goes totally abandonware, PHP tends to pretty
| carefully manage backward compatibility and it should continue
| to function for quite a long time, and much longer with minimal
| patching.
|
| No major infra dependencies (database, pipelines,
| serverless...) or special config requirements. Throw it at any
| bog standard host with no config and it will just go. Like...
| `pkg install nginx php-fpm php-mbstring` and drop it in your
| web root and it's working kinda simple.
|
| And, worst case... it's Twig and Markdown. There are a dozen
| other things I could migrate that to without much hassle.
|
| Because, yeah, something with as many moving parts as Jekyll
| sounds a little heavy and complicated for "a decade of
| longevity with minimal support".
| swayvil wrote:
| For my site this is index.php <!DOCTYPE html>
| <html> <head> <link rel="stylesheet"
| href="../style.css"> <meta name="viewport"
| content="width=device-width"> </head> <body>
| <div class="main"> <?php include
| "../Parsedown.php"; $pd=new Parsedown();
| $mc=file_get_contents("../contentHeader.md"); echo
| $pd->text($mc);
| $mc=file_get_contents("contentMain.md"); echo
| $pd->text($mc);
| $mc=file_get_contents("../contentFooter.md"); echo
| $pd->text($mc); ?> </div> </body>
| </html>
|
| The rest is Parsedown.php, markdown content and some images.
| Arranged in a directory tree. An index and a contentMain.md in
| every directory.
|
| After trying several "simple" Content Management Systems, this is
| where I arrived. I wish I did it 10 years ago.
| roachpepe wrote:
| Thanks for the article, it's a very readable journal, sharing
| experiences and writing up also the reasoning behind decisions
| contributes to future builders.
|
| Maybe someone already said it but I'll echo anyway - unless it's
| all about going outside the comfort zone to learn new tools, the
| person building should always first picture what needs to be
| built, then pick the right materials and tools for the project.
| Taking their own skills into account when using said tools of
| course.
|
| Preferably even think a little ahead about your content to come
| if the site is meant to last for years when picking the tech. Ask
| yourself some "whatifs". Like what if you want to later on make
| some trade for yourself and set up shop for your crafts or
| skillset, can it be done easily enough as well?
|
| TL;DR - Useful and well written article, there's never enough
| easy-read, non-commercial, experience-based journals about site
| building basics to help newcomers. Cheers!
| forgotmypw17 wrote:
| I agree with most of these sentiments. I've often wished I
| started doing something like this 20 years ago, and have a
| website which has been around for that long. So I decided to do
| the next best thing: Make a website which COULD HAVE been around
| for 20+ years, and make it compatible with the 20+ years worth of
| browsers since 1995, around when I started using the Web and
| HTTP/1.1 became common (the latter allowing support of cheap
| shared web hosting using the Host: header)
| primaryobjects wrote:
| I also went with a static site generator during my own blog
| upgrade and chose Hexo.
|
| My tech stack is: Hexo Markdown Node.js Heroku
|
| Here is my whole story!
|
| http://www.primaryobjects.com/2015/12/15/a-tale-of-migrating...
| rikroots wrote:
| I discovered Hexo when I decided to build myself a micro-
| blogging site about my code learning experiences 3 years ago. I
| was impressed with the whole experience then - I was after a
| simple-yet-not-stupid static site generator and that's what
| Hexo gave me. I did have to write my own tooling to get the
| site to deploy to AWS S3 but I assume that they will have a
| plugin for that sort of scenario nowadays.
| snowwrestler wrote:
| It's a good example of how each person's experience guides their
| sense of simplicity.
|
| This person felt like Wordpress was too complicated, despite it
| being a system you can use to set up a site with literally no
| coding at all (using Wordpress.com or one of the many hosting
| providers with one-click installs). You can live-swap themes to
| see which one you like, again with just some clicking.
|
| Meanwhile he is hand-editing .htaccess files to get the URL
| structure he wants and switching from JPG to WebP (a change with
| no real-world SEO value) to try to help SEO.
|
| This is not to condemn or criticize! It's just that when people
| have experience with having their hands directly on software
| development, they may be more likely to prefer a web stack that
| mimics that feel. "Easier" for a coder is going to be different
| from "easier" for an artist with no coding experience. Look how
| many artists use Squarespace or Wix for example, which did not
| even make the list for this effort apparently.
| hnedeotes wrote:
| I agree, but I also think that when developers talk about
| simplicity it's in terms of understanding the bits and moving
| parts that make the whole.
|
| Like creating a nextjs app, or a wordpress website, those
| things are all "simple" to execute - as in easy - you type a
| command/click somewhere and it's done, you've got the structure
| and all plumbing done. You can understand all the pieces after
| working with them for a while and they mostly cover everything
| you need for their use case (which in this case makes some
| things simple, creating a new page, or blog entry, uploading an
| image, etc).
|
| With Squarespace and such it's the same, it's simple, specially
| for someone who isn't a webdev - but what it's doing is not
| simple and when you need to stray from what it does and how it
| works (specially in visual builders) simple things become very
| complex or even not doable. They're probably still the best
| tools for a given range of websites/purposes, even if you know
| how to code, but definitively running transpilers, pre and post
| processors, chunking files, merging code, scoping blocks of
| html and css, stacks of middleware, etc, is the opposite of
| simple.
| beckingz wrote:
| squarespace is especially painful for leaving the happy path.
| ______- wrote:
| > Using Wordpress.com
|
| Just be careful. The free version of wp.com embeds AD-Code and
| tracking scripts into your page so they can make money. The
| paid version is without ADs however. If you want privacy, the
| one-click installs (like you said) on the majority of hosting
| providers is better.
| arkitaip wrote:
| The free version of Wordpress.com has become gnarly in recent
| years. They even use a dark pattern to trick you into
| thinking you have to buy a domain for your blog when in fact
| you can always just use a wordpress.com sub domain.
| brtkdotse wrote:
| > switching from JPG to WebP (a change with no real-world SEO
| value) to try to help SEO.
|
| Nitpicking, but it _will_ have SEO value once Google rolls out
| Core Web Vitals this summer. Not massive, but it's a very easy
| way of scoring a few perf points.
| ______- wrote:
| There are other ways of getting traffic besides Google. Sure,
| tweak your site to please their algorithm and achieve better
| SEO, but always be scouting for other traffic sources.
| lrem wrote:
| That's shaving half a hair, isn't it?
| brtkdotse wrote:
| Hence the initial "nitpicking" in my post
| snowwrestler wrote:
| WebP offers basically no advantage over good ol' JPG in lossy
| compression of photos, which was the use case for this site.
|
| I hear you on Core Web Vitals, but most sites will have a
| long list of more impactful changes to make before they could
| expect to see any measurable rank improvement by switching
| from JPG to WebP for photos.
| mkosmul wrote:
| Very true. Simplicity is in the eye of the beholder.
| betenoire wrote:
| Reminds me of Rich Hickey's talk on "simple vs easy". Wordpress
| is easy, but not simple if you really want to grok it.
| roofwellhams wrote:
| Who in their right mind would work with php?
|
| Variables from lops can bleed through all code imports.
| Nightmare!
|
| You find a bug in wordpress... Good luck ever finding it.
|
| You got virus on wordpress. You'll never be able to get rid of
| it.
|
| You want to add a form? Easy, plugin. Next week upgrade, all
| broken. Good look making things working again.
|
| Actually all these problems above are solvable... But now you
| wasted three same time as doing it properly. And you still end
| up with a piece of $hit...
|
| I think it's more about the type of things you want to waste
| your time: hacking wordpress or doing beautiful robust
| engineering.
|
| One is pleasant, other is a nightmare. That's my view, might be
| different for others.
|
| I'm just building websites with gatsby with some extra features
| that can reused in new websites: when I fix one website, all
| websites will get that fix. With wordpress it's not really
| easily doable.
|
| I'm running more than 100 websites this way and more and more
| people and business come to me because they want 100 Google
| page speed and don't want to be bothered with wordpress or
| doing their own gatsby (even gatsby is not great out of the
| box).
| rustybolt wrote:
| Yeah, agreed. For me 'easier' meant making some scripts that
| build my personal site.
| minimaxir wrote:
| If you're building a personal website from scratch in 2021
| (especially a blog), I _strongly_ recommend Hugo
| (https://gohugo.io) over Jekyll. I had used Jekyll for a decade
| and very often hit random quirks that have been completely
| eliminated with modern Hugo. However, there's a bit of a
| migration process if you are moving from Jekyll to Hugo despite
| both being Markdown-based blogs.
|
| If you want a more advanced framework for a personal website, I
| recommend Wowchemy (https://wowchemy.com/) on top of Hugo, which
| gives the tools needed out-of-the-box like lazy
| loading/SEO/object-oriented collections, albeit with a massive
| learning curve.
| kstrauser wrote:
| I agree completely about Hugo. It's so fast (1099ms for 502
| pages) that I have a publishing pipeline like:
|
| * Edit a page on my laptop or iPad with iA Writer.
|
| * Commit it to git and push it to a repo I host.
|
| * Every 5 minutes, a cron job runs on the server that does `git
| pull && hugo && rsync` to update the live site.
|
| Jekyll took half a minute to do the same build that Hugo does
| in 1 second, and now the process is so fast that this workflow
| is practical.
| arp242 wrote:
| IMO one of the big advantages of Jekyll is that you can extend
| and modify it to no end, which is a lot harder in Hugo. The
| choice of language plays a big part here: Ruby just makes this
| kind of stuff a lot easier than Go.
|
| On my website I do stuff like:
|
| - Run Vim to add syntax highlighting (with :ToHTML).
|
| - Add a tag to include a code example from an external file
| (much easier to test/run when writing!)
|
| - A tag to list "related posts" based on tag.
|
| - Overwrite the standard date formatting function so I use my
| own date format, and add a custom number format function which
| uses a thin space to separate thousands.
|
| - Generate pages for my Go "vanity paths" based on just an
| Array in a Ruby plugin.
|
| - A tag to include images as base64 inside the page itself.
|
| - Run some regexps on the generated HTML to add/change some
| things.
|
| - Aside from the .html page, it also generates .txt files for
| people who prefer this and/or usage on Gopher/Gemini (actually,
| I removed this as it never worked quite how I wanted, but with
| a little bit of extra effort it would have, I just couldn't be
| bothered).
|
| Maybe it's crazy to do some of these things like running Vim,
| but I like the Vim colour scheme and semantics and it's a lot
| easier to use this than configuring some library. I wrote much
| of this years ago and has been working without problems ever
| since, and it didn't even cost me that much effort.
|
| Either way, my point is: this is a major advantage of Jekyll.
| Hugo probably has some of this by default, but last time I
| checked you couldn't even add a custom template function. Once
| you reach the limits of what you can do with Hugo: you're going
| to have a hard time. If you hit the limits with Jekyll: no
| problem, lemme just whip up some Ruby code.
|
| I never hit "random quirks" though, in spite of all my hacky
| stuff.
| hnarn wrote:
| There are some cases where re-writes in Go or Rust are just so
| good that the "originals" become almost entirely obsolete. Hugo
| is one of those tools, ESbuild seems to be another, or ripgrep
| for Rust for example.
| nickjj wrote:
| > There are some cases where re-writes in Go or Rust are just
| so good that the "originals" become almost entirely obsolete.
|
| Why's that?
|
| I use Jekyll here and even with over 500+ articles (posts +
| drafts) it takes around 2 seconds to get live reload feedback
| in Jekyll while writing. Jekyll also handles the entire asset
| pipeline complete with md5 tagging of assets without using
| Webpack or any build tools. It also lets you write plugins
| with a few lines of Ruby to add new template filters and
| other things.
|
| For example I wrote a custom Jekyll plugin that lets me write
| bullet lists like this after a specific type of header:
| - 0:45 -- Something - 1:45 -- Another thing -
| 1:03:31 -- And another thing
|
| And it automatically converts the timestamp numbers into
| clickable links that jump to that point in an audio player.
|
| AFAIK Hugo has no way to do anything like that, at least no
| where near as easy as Jekyll. With Hugo wouldn't I have to
| compile a custom build of Hugo for such a thing? But with
| Jekyll it was adding 1 file into a directory and writing 20
| lines of "business logic code" to add a new filter. Now I
| just do {{ content | audioseek }} when I want clickable
| timestamps.
|
| I also wrote another plugin that automatically adds certain
| rel attributes to external links by adding {{ content |
| extlinks }}.
|
| Things like the above are why I continue using Jekyll because
| personally I haven't found another SSG that comes close to
| how easy it makes it to add custom behavior. I don't mind the
| 2 second live reload wait and I wouldn't switch away from
| Jekyll for a speed boost alone. At some point the speed is
| "good enough". Sure I would love a 100ms reload but I
| wouldn't give up everything else for that.
| minimaxir wrote:
| Hugo has one-file creation of shortcodes + config params
| too, which IIRC is the same workflow as doing it in Jekyll:
| https://gohugo.io/templates/shortcode-templates/
|
| Extending the Markdown rendering appears possible without
| building Hugo itself, albeit not for lists:
| https://gohugo.io/getting-started/configuration-
| markup/#mark...
| nickjj wrote:
| I'm not sure if either of the things you linked would
| solve this specific problem but I also only skimmed the
| pages you linked.
|
| For example the Jekyll plugin for the timestamps:
| 1. Looks for a specific type of post and then it scans
| the body of the post 2. Looks for a specific
| header on the page and then grabs the list right after
| that header using an xpath selector (no special classes
| needed) 3. Goes through all of the elements in
| the list 4. Parses out the timestamp from the
| line and changes the timestamp into a link with a data
| attribute containing a specific timestamp format
|
| The code for this is here: https://github.com/nickjj/runn
| inginproduction.com/blob/maste...
|
| There's no custom Markdown or even classes added to the
| list or post because it lets you naturally write your
| Markdown list how you would if the feature didn't exist,
| and the plugin's goal is to add in that new behavior
| behind the scenes. This lets me keep all of my posts
| really clean[0].
|
| It would be super interesting to see a Hugo equivalent
| for the audio_seek custom filter. I don't expect you to
| spend your Sunday afternoon writing such a thing but it
| would be cool to see a direct comparison of how you would
| implement it with Hugo. It might get more folks to move
| to Hugo too, because the main thing that keeps me using
| Jekyll is the ability to create adhoc customizations
| without needing to fork Jekyll.
|
| [0]: https://github.com/nickjj/runninginproduction.com/bl
| ob/maste...
| minimaxir wrote:
| That particular example could theoretically be replicated
| with rendering the content to HTML via .RenderString
| (https://gohugo.io/functions/renderstring/) + replaceRE
| (https://gohugo.io/functions/replacere/) + an ugly regex,
| with a layout override to call that modified filter
| instead of the normal content.
|
| Not 100% sure if that would work, but on paper business
| logic LOC would be about the same and using a regex is
| the more canonical way to handle this sort of processing
| anyways.
| edoceo wrote:
| > using a regex is the more canonical way
|
| Yuck.
|
| I also ran into similar issue with Hugo, where I'm out of
| the happy-path. Those short codes didn't work, complex
| processing of some unique bits of content was easier in
| Jekyll (but also other script-lang based tools) than it
| was in tools like Hugo.
| nickjj wrote:
| > with a layout override to call that modified filter
| instead of the normal content
|
| Would it apply to all content in a specific layout or
| only specific bits of a certain layout?
|
| With the way I have it set up with Jekyll, only a
| specific post gets the audioseek timestamps added to it,
| because I wouldn't want it to apply to all lists on the
| site. I also happen to share a single layout for both
| podcasts and interviews and interview lists shouldn't get
| processed with audioseek'd timestamps.
|
| With Jekyll this is super easy to pull off because it's
| only a custom filter. It can be applied to the specific
| content I want without having to worry about layouts.
| ploden wrote:
| I'm using Hugo for my blog, so this is good to hear. My only
| complaint so far is having to embed front matter in my .md
| files. Mixing JSON and Markdown feels wrong.
|
| Question: my blog is a git repo of .md files that I run through
| Hugo and then rsync to my host. Wouldn't it be possible to
| write a web app that just hits the repo on Github and renders
| to HTML, and skip Hugo altogether? Are there downsides other
| than performance?
| brabel wrote:
| The main point of a static website is that you don't need a
| web app to serve it, any web server that can serve files (all
| of them) will do.
|
| I use my own static site generator to generate the final
| HTML/CSS (but could be using Hugo or Jekyll or anything
| else)... when I push the generated files on my gitHub repo,
| Netlify automatically detects it and starts serving the new
| files. That's pretty much what you probably actually want.
|
| Takes less than 5 minutes to get it setup.
|
| Note: I have no afilliation with Netlify, just a happy
| customer.
|
| https://www.netlify.com/blog/2016/10/27/a-step-by-step-
| guide...
| ploden wrote:
| That's good to know, thanks!
|
| Couldn't I hit Github using just statically served, client
| side JS?
| asr21 wrote:
| Checkout GitHub pages.. it might be useful for you
| minimaxir wrote:
| Front matter is the same with both Jekyll and Hugo, and it's
| certainly better than the alternative for per-post config
| which is an unavoidable constraint.
|
| It's theoretically possible to do automatic-render-on-commit-
| and-sync with GitHub Actions, although I haven't investigated
| it. There wouldn't be much of a performance hit either.
| poglet wrote:
| Jekyll GitHub intergration works for a quick website.
| roofwellhams wrote:
| It's suggest gatsby. You'll need javascript at some point and
| you don't want to deal with generated javascript or some hacked
| together javascript.
|
| Anything else that's not js, imo you're making the biggest
| mistake... Eventually you'll need js...
| bmitc wrote:
| I've been having decision paralysis about setting up my own
| personal website. I would personally like to avoid some bloated
| frameworks or tools like Wordpress, Squarespace, Wix, etc. I'm
| also not really sure I even want a blog. I'd like to have a
| collection of articles that aren't just written once and then
| moved on from but rather are updated and refined over time. I've
| looked at static website generators, but don't really feel
| they're that simple.
|
| So I've been looking to just do things from scratch. Maybe it
| would be nice to write articles in markdown and have a custom
| static website generator that takes these and publishes them. It
| could be a fun F# or Racket project. The idea of simple HTML and
| CSS being loaded for maximum speed and old school web with a
| little something for interactive graphs and other things is
| something that sits well for me.
|
| Although, I just took on a new Elixir job, and something with
| Liveview and Livebook for interactivity could be really cool.
|
| Anyone else struggle with this and end up coming up with a
| solution or finding one?
| barrucadu wrote:
| > Maybe it would be nice to write articles in markdown and have
| a custom static website generator that takes these and
| publishes them.
|
| This is what I do. I have three static websites, each has a
| small (few hundred lines of code) Python script rendering them.
| I find it worlds easier than existing static site generators,
| where going even slightly off the happy path is usually a huge
| pain.
|
| Some examples of custom things I've implemented, which were
| basically trivial due to doing it myself:
|
| - A probability table renderer, which produces output like
| https://i.imgur.com/siNN5Tu.png from a CSV of values and
| probabilities.
|
| - A custom syntax for acronyms, which get the mouse-over text
| and a link to a glossary entry inserted (with automatic
| pluralisation too).
|
| - Custom rules for rendering markdown code blocks, to handle
| things like rendering GraphViz code to an SVG and inserting
| that in the page.
|
| I usually use jinja2 for templating and pandoc or pymarkdown
| for rendering the content.
|
| I've intentionally NOT made one static site generator to handle
| all three sites, as this is where the complexity and
| inflexibility of existing static site generators comes from.
| Specialised tools which can evolve independently are inherently
| more flexible than one complex tool which tries to do
| everything.
|
| People often say that using a pre-existing static site
| generator means you don't have to implement features like
| hashing assets, rendering feeds, or handling tags/categories
| yourself. Which is true. But those are all very easy to
| implement, so it's not much of a selling point.
| mkosmul wrote:
| This blog's author wrote his own minimalistic static site
| generator: https://prog21.dadgum.com/
|
| But, I think, doing things from scratch can be risky: ready-
| made solutions have a learning curve, but they also do lots of
| useful things which you might need, and writing all of that
| from scratch is really lots of work.
|
| For me, it's always about find the right point on the spectrum
| between "write it myself to do exactly what I need" and "huge,
| bloated thing that claims to do everything anyone might ever
| need"
| ahmedfromtunis wrote:
| An hour was more than enough for me to learn eleventy and used
| this basic knowledge to build a simple home online.
|
| This was the first time I ever touched a static site generator.
| It was harder than I expected, but my expectations were
| probably unrealistic.
|
| I was so happy with what I got that i decided to replicate my
| more-than-10-year-old Tumblr with what I just built as a test.
|
| I "host" it for free on Netlify. And if anything goes wrong
| with them, I can just move it anywhere I want.
|
| My only pet peeve is that I'm not yet used to committing
| content with git alongside the code, but that's it.
| vbsteven wrote:
| I chose Jekyll as a static site generator because it was simple
| enough to understand what it does. Its build step is just
| taking a directory of markdown files and converting them to
| html pages using a template. It feels like the next logical
| step after writing all pages in html by hand.
| jdthedisciple wrote:
| I am struggling with the exact same problem at the moment.
|
| I am currently contemplating using just http and php, whereby I
| just save my posts as textfiles along with maybe 1 image file
| in a folder ( say /posts/{id}/) and the php just takes all
| those and turns them into HTML using some type of template like
| the author mentioned. Then do some basic SEO to improve
| visibility.
|
| I'm no webdev myself and have no experience with building
| anything on the web but I think this could suffice.
| simplify wrote:
| I feel the same about static site generators, which is why I'm
| working on Lancer[0]. It's designed to be as close to plain
| HTML as possible, with _just_ enough features to support
| generating static sites, and even SSR and server endpoints.
|
| For example, Lancer doesn't have built-in support for markdown.
| However, it supports _arbitrarily transforming your <template>
| tags_ so you can add markdown support to your website with
| effectively a one-liner[1]. It's this type of approach that I
| hope to build a framework that requires as little framework
| knowledge as possible, while being flexible enough for all
| content-based websites.
|
| [0] https://lancer.studio/blog/the-fight-against-complexity
|
| [1] https://lancer.studio/docs/guides/markdown-support
| tasogare wrote:
| I used PHP for writing a personal page that can make use of
| functions to avoid repetition. Then I generate static pages
| (one per language) with a shell script. Another script to scp
| the static pages to production. Simple and efficient, no
| framework, no bullshit, two files of helper functions and one
| CSS.
| ChrisMarshallNY wrote:
| I think that what you do is really cool:
| https://origami.kosmulski.org/about
|
| I'm a big fan of "do what you love."
| mkosmul wrote:
| Thank you
| darekkay wrote:
| I've migrated [1] my blog to Eleventy this year and it is a
| pleasure to work with. I especially like the data model and the
| flexibility.
|
| [1] https://darekkay.com/blog/hexo-to-eleventy/
| austincheney wrote:
| If a personal website for a software developer should reflect
| current capabilities or employment trends then it should conform
| to this checklist:
|
| * Use React. Every paragraph, yes each one, should be a JSX
| component. If anybody asks you about this just respond with
| something unrelated about test automation.
|
| * A fancy logo front and center above the fold over a gradient.
| Catch that eye but leave the user hanging on what the site is
| actually about because pausing for dramatic effect is most
| important.
|
| * Mention somewhere that accessibility is important and stand
| behind that statement with great pride. In the next statement
| forget about accessibility completely like a bad case of mania
| and add a bunch of unnecessary JavaScript and specifically
| describe how much you hate JavaScript.
|
| * Something about Agile. This should compromise the bulk of all
| human consumable content. It doesn't have to any make sense and
| can be completely out of order.
|
| * Actually push all content to the end and just worry about which
| tools to use then use Twitter feeds for all content.
|
| Sarcasm aside actual content comprised of words makes for a good
| litmus test to discriminate interested users from people who find
| such things a chore. It's the difference between employment
| recruiters and internal developers filtering those potential
| candidates.
| anoncake wrote:
| > It doesn't have to any make sense and can be completely out
| of order.
|
| No, the order of paragraphs is important. A/B testing is
| necessary to find out the best one.
| avilay wrote:
| Surprised not to see ghost in here. They have a paid managed
| version at https://ghost.org and it is fairly easy to set up with
| any of the public cloud providers. I have set mine up with
| Digital Ocean (https://ghost.org/docs/install/digitalocean/).
| majewsky wrote:
| I love how the first comment at the end of the page asks which
| CDN and which load balancer the site is using, as if he's filling
| entire racks with this simple static website. Absolutely
| hilarious.
| kstrauser wrote:
| Turns out Nginx can serve _a lot_ of static pages very quickly.
| The largest page on my blog is 70KB. On a VPC with a gigabit
| connection, I should be able to push about 1,400 requests per
| second.
|
| My blog is never going to be so popular that I need to support
| more throughput than that.
| toto444 wrote:
| Has anyone noted the use of Github for commenting at the bottom ?
| That is quite a nice way to have social features without being
| too 'social'.
| 32gbsd wrote:
| That is a long article only to end up with a website that looks
| like every other website. Could as well be wordpress or a
| facebook page.
| arp242 wrote:
| I think the big number 1 that trumps all others when building a
| person website is: focus on writing content.
|
| This is by far the hardest part. All the other stuff: it's just
| tangential. Wordpress, Blogger, Jekyll, Hugo, Medium, hand-
| written HTML files: IMHO it doesn't really matter _if_ you don 't
| have any content. Just use whatever is easiest to get started
| with and gets out of your way when writing. For me, personally,
| it would be writing Markdown in Vim and converting that. For
| other people, it's something else.
|
| Later, when you actually have some content going you can start
| focusing on tooling, layout, and so forth. Converting things to
| another platform usually isn't too hard. But chances are, you
| will never actually get any content going. I've seen a lot of
| people create personal websites, write one or two things on it,
| and then basically don't do anything with it.
|
| I've built some websites for various friends/non-profits over the
| years, and about 90% of the time they never actually wrote any
| content. These days I ask people to write content first, and then
| I'll build the website for them. Most of the time I never hear
| about it again. That's okay, it's really hard to write content
| and a lot of people (myself included, before I had more
| experience with this sort of thing) tend to be way too optimistic
| about it and underestimate just how hard this can be.
|
| And people will read your website regardless if your content is
| good. Is Paul Graham's website the peak of web design? Not
| really. People still read it. Dan Luu's website? Pretty much the
| most basic HTML file you can get. Still widely read.
|
| That being said, if your goal is also to _learn_ more if you 're
| young or inexperienced: then sure, muck around with these tools
| all you want. I learned a lot from building my personal website
| over the years in all sorts of tools (geocities, hand-written
| HTML, shell scripts, PHP, Python, PHP again but this time with
| MongoDB, back to shell script, and finally settled Jekyll) and
| for much of this time I didn't have a lot of content. That was
| okay, because I learned a lot from the process.
| blacktriangle wrote:
| Christ Lattner's (the Swift guy) homepage:
| http://nondot.org/sabre/
|
| One of my personal favorite shite pages with great content.
| arp242 wrote:
| I think Sheldon Brown's website is another great example.[1]
| It's a fantastic resource if you're into cycling, and Sheldon
| made it to Wikipedia with that site[2], which is more than
| most people with fancy sites can say. Actually, it's probably
| a better example than Paul Graham, Dan Luu, or Christ
| Lattner's sites as it shows that not _only_ tech folk will
| read your basic looking website as long as the content is
| good.
|
| [1]: https://www.sheldonbrown.com/
|
| [2]: https://en.wikipedia.org/wiki/Sheldon_Brown_(bicycle_mec
| hani...
| jayd16 wrote:
| If you blog about your blog's bike shedding, is it content?
| edoceo wrote:
| Yes. I rather enjoy tales of I tried these six things but
| then chose number seven.
| karaterobot wrote:
| I don't know how many times I've had this conversation with
| friends:
|
| Me: How's that game you were making?
|
| Friend: I realized I should probably write some tooling to make
| my life easier. So then I started on that, and I got pretty
| far, but then I ran into some limitations with the engine I was
| using, so I decided to write my own. I got pretty far on that,
| but then I had an idea for a different game, so I shelved the
| first game and now I'm working on this other one.
|
| Me: Right on, how's the second game going?
|
| Friend: Well I'm investing some time to build tooling before I
| really get started on it.
| an_opabinia wrote:
| Why write content no one reads?
|
| It's 2021. Build a cathedral of a website for a single tweet,
| it will say a lot more about you.
|
| Although I wish, obviously, we all read more.
| andrewzah wrote:
| Once I added stat tracking to my website I realized I had
| more hits than expected.
|
| Also, in general, it's not really about the number of people
| that read it. If it's important enough to spend time writing
| about it, then if even just 1 person reads the post that's
| good enough.
| heavyset_go wrote:
| One of the best things I've done is keeping a wiki and log of
| my notes. Turns out that other people found them useful, as
| well. These days there are many easy to deploy options for
| hosting wikis and notes, especially if you're fond of
| Markdown.
| arp242 wrote:
| Because it's fun and useful. I actually wrote a thing about
| this: https://www.arp242.net/why-write.html
|
| Later I discovered others have expressed similar sentiments
| long before I was even born, e.g. "writing is thinking". Ah
| well, always nice to feel validated when you independently
| arrived at essentially the same conclusion as other people
| who are probably smarter than you :-)
| harterrt wrote:
| Writing is useful even if nobody reads it. Writing clarifies
| and sharpens my thinking. I have ideas I wouldn't otherwise
| have.
|
| I wrote for the void for a long time. At the time, some folks
| on my immediate team found it useful. Now, a few years later,
| I'm still referencing those posts.
|
| The important hard work was actually writing and polishing
| the idea until it was good enough to publish.
| pgwhalen wrote:
| Agreed. I currently publish a bit of writing about my
| software engineering opinions to a website that only a
| couple of my non-software engineer friends know about. It
| doesn't make much sense to them, but their playful
| criticisms help me hone my ideas and hopefully simplify my
| writing (something I have a big problem with).
| lolc wrote:
| So true. I have stories both private and professional where
| people got angry at the site I built for them. Because it was
| empty. I have learned the hard way to insist on content before
| sinking time into a site.
| clairity wrote:
| as a corollary, i wish the writing experience for more varied
| environments was much better. it's hard when you want to jot
| something down on the go and keep drafts in sync across devices
| without getting caught in some cloud subscription service. the
| tablet writing experience without a keyboard is still subpar,
| not to mention phones.
| dundercoder wrote:
| I agree. The problem is the tangential stuff _feels_ important
| and leads you to want to perfect it before even starting
| content.
| agumonkey wrote:
| > I think the big number 1 that trumps all others when building
| a person website is: focus on writing content.
|
| > This is by far the hardest part. All the other stuff: it's
| just tangential. Wordpress, Blogger, Jekyll, Hugo, Medium,
| hand-written HTML files: IMHO it doesn't really matter if you
| don't have any content. Just use whatever is easiest to get
| started with and gets out of your way when writing. For me,
| personally, it would be writing Markdown in Vim and converting
| that. For other people, it's something else.
|
| This is why I find the quest for availability of anything (as
| opposed to the old world where everything had a high cost to
| entry) is mostly bad. It's easy to push out noise. Maybe that
| comment is noise too though :)
| dna_polymerase wrote:
| Exactly, look at all the free blog websites, medium,
| wordpress.com, blogger, etc. They are filled with tons of low
| signal noisy posts of people with nothing to say. It really
| makes discovery of good content harder, not just for me as a
| user, but also for the platforms to highlight that. Most
| often I get good stuff from websites without any styling,
| just plain text hosted on a little box under the desk.
| hnal943 wrote:
| have you checked out 11ty? It's similar to Jekyll but doesn't
| have dependencies on Ruby.
| ochronus wrote:
| It depends on NodeJS instead.
| mkosmul wrote:
| No, I didn't know it - thank you. It's probably too late to
| switch at this stage, but I'll have a look. It's always good to
| know some alternatives/replacements.
| rayrag wrote:
| Two tips:
|
| - don't justify text, it doesn't look good and it makes text
| harder to (https://designforhackers.com/blog/justify-text-html-
| css/)
|
| - 'On this page' section is too long. And once I scroll down I
| don't see it anymore so I can't use it for navigation. Look at
| https://getbootstrap.com/docs/5.0/getting-started/introducti...
| or https://tailwindcss.com/docs/installation to see how useful
| can it be.
| mkosmul wrote:
| Thank you for the tips. As for justification, I actually
| compared my "before" and "after" layouts and found the one with
| justification better for my taste. The link you posted has some
| very interesting thoughts, though, and certainly justified text
| on a web page is a completely different level of typography
| than text justified e.g. in LaTeX.
| forgotpwd16 wrote:
| Maybe it was intentional but bullet points aren't justified
| although the rest of the text is. Also text looks pretty big
| for me.
| forgotpwd16 wrote:
| Ironically I find the first article easier to read when
| justified (side-by-side comparison at https://ibb.co/9tvZ75W).
| When not justified the uneven lines get my attention and I'm
| losing my reading rhythm. As the article lacks a published
| date, I do not know whether this is result of technology having
| advanced since. Nevertheless there're spaces that look bad
| around the images but maybe a better web design could help with
| this. Also there's the usual lack of any surveys that articles
| on design tend to have.
| bruce343434 wrote:
| The very first support link it gives disproves the article:
| hyphenation IS widely supported. In my opinion the article
| reads as if the author collected evidence to support his
| preference. Now, it does seem as if text justification is a
| highly subjective matter.
| Pazzaz wrote:
| I think you should justify text. The article you linked is old
| and hasn't caught up to the development in browsers. It is
| correct about text being ugly if justified without hyphens but
| most browsers nowadays support hyphens [0] and have for some
| time. For a good example of justified text together with
| hyphens, see: https://www.gwern.net/Holy-wars.
|
| [0]: https://caniuse.com/css-hyphens
| aoloe wrote:
| When you justify text for print, you almost always have to
| manually tweak the result to avoid wrong spacing, bad
| hyphenation, rivers, ... Justified text and automatic layout
| do not (yet) go hand in hand.
|
| Left aligned text has also its issues but, most of the time
| you won't notice them on screen.
|
| The article you're linking looks better than average, but it
| feels a bit too much like a text wall to my eyes... I guess
| that the lines contain a number of characters and words that
| is big enough to allow a more even distribution, at the price
| of longer lines that are less comfortable to read.
|
| For me the rule is still that text that is automatically
| formatted should be mostly left aligned. But indeed, if you
| correctly setup the hyphenation, you can produce something
| that is somehow OK.
| Veen wrote:
| I suspect the wall-of-text effect isn't caused by
| justification. Gwern is using first-line indents to signal
| a new paragraph instead of spacing them, as is more usual
| on the web.
| hyko wrote:
| +1 for skipping justification, which universally looks like ass
| on screens.
|
| "What about books and newspapers?" I hear you ask, to which I
| reply: print had expert typesetters eyeballing the whole
| thing...and even then, some books and newspapers look like ass
| unless you're squinting from 10ft away.
|
| Trying to make text fit in a box is an aesthetic choice, but it
| is technically inferior from a _readability_ standpoint. It was
| usually paired with columns, which improve readability and
| would do so without justification.
| TacticalCoder wrote:
| > - don't justify text, it doesn't look good
|
| It certainly does look good for books and for LaTeX documents
| though. For the Web the problem is that it requires learning
| several new CSS properties and learn about some typesetting
| issues ("rivers" and "ladders").
|
| The following does definitely look very good to me:
|
| https://generatedcontent.org/post/44751461516/finer-grained-...
|
| We're 25 years in, at some point browsers have to get a proper
| hyphenation and justification algorithm. With a proper H & J
| algo and high DPI screen, I don't see why it couldn't look
| great.
| The_rationalist wrote:
| Maybe it require some training but on my phone I find this
| example low readable, my speed of reading is slowed and my
| cognitive overhead/eye movements are increased. To me it's
| the kind of UX thing that look good if you don't look at it
| well but once you have to it's just plain inferior.
| arp242 wrote:
| Previously, people have mentioned that good hyphenation is
| hard in HTML/CSS due to the way the box model works:
| https://news.ycombinator.com/item?id=19473277
|
| I haven't looked in to this, so I can't judge the veracity of
| this claim.
|
| However, in general I find that hyphenated text on screens
| never looks quite right to me, even when done right (even
| though it looks fine in newspapers and magazines). I'm not
| entirely sure why; I think that it's because on the web lines
| tend to be a lot longer than in newspapers and magazines,
| which are usually very narrow columns by comparison. Or maybe
| it has to do that the screen is typically further away from
| you. Or maybe both, or something else entirely.
|
| I do think it's valuable to have, especially for narrow
| columns (e.g. sidebars) or smaller screens. But it's not
| something I'd want to use on my website like in the example
| you mentioned.
| bruce343434 wrote:
| I recently redesigned my personal website and it looks very
| fine. The trick is to actually learn about the tricks
| you're using, as with everything in life. Oh, and you need
| to set `<html lang='??'>` . #content {
| font-family: "AtkinsonHyperlegible", sans-serif;
| text-rendering: optimizeLegibility; font-
| size: 0.5cm; line-height: 1.4;
| max-width: 70ch; } @media screen and
| (min-width:70ch) { #content { word-
| break: break-word; text-align: justify;
| text-justify: inter-character; hyphens:
| auto; hyphenate-limit-lines: 2; }
| }
| inamiyar wrote:
| Iirc the reason browsers don't have knuth-plass justification
| is because it runs in O(n^2), but even so my research tells
| me justification reduces retention because your mind retains
| the "shape" of ragged text. I don't have the article on hand
| but if I find it I'll add it later.
| bruce343434 wrote:
| Do add, because citation is needed.
| finiteseries wrote:
| That looks absolutely terrible and amateurish on iOS Safari,
| strengthening the point about browsers needing a consistent
| justification engine.
|
| It actually distributes space between characters rather than
| words as is the norm in print (and is partly why books and
| magazines don't look like a teenage yearbook editor's first
| day with InDesign).
| wodenokoto wrote:
| "It's just bad typography".
|
| If you want to say that you need to argue against over 100
| years of newspaper and book typography.
|
| Granted, this isn't print, but if you want to make blanket
| statements like that, you need to defend them against a very
| long lineage of design.
| leetrout wrote:
| We aren't doing text layout for a fixed physical space.
|
| I don't think it needs any more justification than that.
|
| It was good typesetting. It was probably never good
| typography.
| minkzilla wrote:
| Why does fixed space make it so that justifying is good and
| non fixed makes it bad?
| true_religion wrote:
| In fixed space, like newspapers, human editors would add
| or remove words in order to make the end result
| aesthetically pleasing. Non fixed space lacks this
| feedback loop, so you can end up with text that is both
| justified and awkward more often.
| [deleted]
| yakubin wrote:
| LaTeX doesn't do any of that and the end result is
| beautiful. It's even better than what human editors
| produce.
| RobertKerans wrote:
| Because if it's fixed, can, starting with the first
| character, go through the text adjusting the space
| between words and letters (carefully and subtly so that
| optically it doesn't look as if there has been adjustment
| unless you look very closely) and swapping out
| words/changing sentences/re-ordering until the text fits
| almost perfectly in the space.
|
| (This is also why justification can't ever really _fully_
| work on the web in a general sense, can only have an
| approximation and the question then becomes if it's
| worthwhile to have that or whether it's just more trouble
| than it's worth)
| rusk wrote:
| > any more justification
|
| [flagged]
| kevincox wrote:
| > I also spent a little time on redirecting the addresses of
| [...] my old website to [...] the new one. Failing to do this
| would have cost me a lot in search engine rankings since all the
| incoming links collected over the years would be gone [...]
|
| I was disappointing that the main reason that they valued keeping
| past links alive was SEO. To me the innate benefit of not
| breaking links and bookmarks on your readers (or future readers)
| should be enough.
| mkosmul wrote:
| This is a very good point - good you brought it up. I do care
| about not breaking links, though I did not mention that in the
| text. Actually, you can still reach my site by using the
| address it used even before the previous one, and there are
| still links on the web using that very old address, thanks to
| two levels of redirects.
| m01 wrote:
| I was glad to see the author start with the context &
| requirements, rather than with the tech stack.
| BayesianDice wrote:
| I agree with comments saying that a key point is producing
| content. I'd spent a couple of years of considering starting a
| blog (with no commercial/monetisation, but somewhere to post
| thoughts on technology / games / books I find interesting) and
| trying out various platforms/solutions and producing very little.
| Then I finally got started with a simple Hugo/Github/Netlify
| setup, with the plan of adding more technology bells and whistles
| if readership or my inspiration to continue producing content
| justifies it.
|
| A question on which I'd be interested in views: how important or
| otherwise do people consider the ability to sign up for a mailing
| list / newsletter to be informed of new content? I dislike the
| in-your-face modal pop-ups etc. - but am wondering if readers, if
| they like existing articles on a site, would appreciate a low-
| key, unobtrusive option of signing up for an email notification.
| Siira wrote:
| Give us RSS, and we'll pull if we want to. Email pushes, which
| is user-hostile.
| BayesianDice wrote:
| Thank you for the comment. The site already has RSS, and I'd
| agree there are good technical grounds for preferring it, but
| I get the impression that its use among users is declining,
| which is why I was considering other mechanisms. I find it an
| interesting point of view to consider a feature which
| alternatively allows users to opt-in to email notifications -
| but which doesn't disadvantage them at all if they don't - as
| "user-hostile". (But of course I've seen sites which want to
| coerce visitors to hand over an email address to be able to
| access the content they were expecting, and depending on
| context, I can see cases where that could be considered
| aggressive.)
___________________________________________________________________
(page generated 2021-05-16 23:00 UTC)