Hacker News new | past | comments | ask | show | jobs | submit login

I do run my own site. Moreover, I do all the coding, styling, and layout manually and without any 3rd-party libraries or frameworks. Or even in-house libraries for that matter.

This works for me in terms of freedom. I can do interactive plots, quizzes, games and all kind of programmable things I can imagine. No restrictions.

In fact, I left Medium because I was restricted to text and images only. I want more. I want words and buttons: https://wordsandbuttons.online

But it's not really aligned with the reasons from the post. It's not a resume. It would have been an awful resume. I wouldn't hire myself by this resume.

And keeping record is, of course, nice. But it has nothing to do with running your own website. You can keep record on Medium, too. In fact, it would be more effective since it works wonders for the small notes.

Still, I totally agree that keeping your own site is a fascinating experience and it's well worth time and effort.

It's amusing to me that you seem to be struggling to vocalize why anyone would want a website like yours - as if a 'resume' or a 'journal' were the only reasons to keep one.

But, as a reader, I think a website like yours is like having a chance to explore that person's personality in a freeform way. The design reflects their aesthetic (similar to how fashion does for the physical form), the organization reflects their favored mental models perhaps, and the myriad of topics and links makes it a graph-like structure for a book/journal/life. It's strange to me that people question a personal website's purpose - but accept that of a coloring or sticker book. To me, that only says that our brains haven't quite caught up with how to use the medium. (Although, if you have read sites like philosopher.life, then I think you have a glimpse of what's possible.)

I like the design of your site. It's extremely easy to read, and there's no clutter. If I want art, I'll go to a museum, when I want to read I prefer a site like yours.

> I wouldn't hire myself by this resume.

I don't do hiring, but I can see your website being an item in the "plus" column if I was going to pick whether to hire you or not.

FYI your font-size is uncomfortably huge, I can see maybe 25 lines of text on my desktop screen. It feels like I should step backward a meter or two.

And on the other hand, I'm running a 12" notebook at 1080p with no scaling, and I find the text to be exactly the right size. If anything, I'm tempted to zoom in a notch or two.

Zooming on the web is a critical feature to me. I find pages all the time with nearly unreadably small text, and occasionally with text too large for me. Firefox remembers zoom levels for me, so I only have to adjust once per site, usually.

This is not meant to be a criticism, just sharing another experience for your awareness. Based on your comment, I don't think the author could make both of us simultaneously happy.

If you find yourself zooming in to new websites more often than not, it's possible to set the default zoom level in firefox. In about:config, set "layout.css.devPixelsPerPx" to the decimal zoom level you want. It will also grow the UI scale but you can reduce that by setting it to "compact" mode in the Customise menu.

think you could make yourself happy, by selecting a screen & scaling that allows default sizes to be readable. If I browsed from a Blackberry on a selfie stick, the onus wouldn't be on the developer to make me happy.

Enormous fonts is a trend in modern web design for some reason. I browse most sites at about 66% zoom. Get used to the Ctrl+- shortcut.

(Conjecture) It’s because of devs like me who stare at a screen all day and have tired eyes. It’s sized for ourselves. I keep my code at 16pt, and most websites at zoom of 150%. When I’m on my tiny laptop, I like to zoom to 200% (and usually need to go to full screen mode as a result). For context, my vision was recently tested and I’m slight farsighted. Still, just more comfortable that way. Please make your sites accessibility friendly, folks! Much appreciated.

I find the complete opposite to be true. In most text-based websites, I have to zoom in to around 120% or even 133% (e.g. HN) for the text to be readable.

I think it's poor implementation of "mobile first".

This is due to design as in what designers do. Usually website designs are fairly static with a mobile and a desktop reference design that frontend developers then have to implement.

Most designers do not work intimately with the content, so text is more shapes on the page than the main course. I do not mean this disparagingly, I have just seen a lot of designs in my time where the text is placeholder stuff in designs.

In reality text needs to be of a certain line length. If it gets too long then it can be hard to follow. Wall of text is a problem too.

The best way to do text is to make it proportional to the width of the browser window. If the lower font size is the 16px recommended by Google for accessibility then the maximum size can be what you might call enormous - on a 4K monitor. Everything can be just right in between.

If you do have a 4K monitor and you are using it for just one browser window then enormous is what you want - it will look good in the meeting room on a huge screen that everyone can see.

Some fettling of margins can go on too, so a small screen can have narrow margins, so 1rem on a phone and a lot more on bigger screens.

With these methods it is possible to make design a lot easier with everything proportionate to screen size. But if your designers are only thinking in terms of fixed with fonts and they produce the mobile and the desktop views with baked in font sizes that get signed off by the client then you are stuck with it.

It really is up to the design community to get with font scaling and to not be insistent on a couple of fixed font options.

This should be simple but in a multi-disciplinary team where most web design is then sausage-factoried with old layout hacks (so no CSS Grid or CSS variables) then progress is difficult if not impossible.

My personal page has a front end font size range in 30s and 40s.

ive done that because mobile reading the page would see microdots instead of characters at 14 pt font.

i read and access at the ass end, the front is for mobies i havnt wanted to use JS to check and set font as i really dont want to build a JS site.

You don't need JS to get a website that behaves properly on mobile. Just add one meta tag to set the viewport scaling and text will scale properly:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

i did that for a while, ill have to look into finer details, there were issues with screen rotation breaking the formatting, so i might have to redo the CSS; im looking at gridding the pages, as this seems to be the direction to go for the next version of the page. I basically want to make the navigation UX a first person RPG themed frontend. so that the files are accessed by e.g. moving to the library, talking to the librarian for help or searching for a document etc. finding the sword of git! slaying the maldragon [not necessary but if you want to side quest for fun it would be there]

and thanx BTW

It could have something to do with accessibility. My eyes aren't the best, so that font is about the smallest I can comfortably read.

It's everywhere but here in Hacker News, where I'm comfortably reading on screen at 133% zoom.

Are you using a low res display or high font scaling? On a modern high res display larger fonts work well.

Just to tack on with some more typographic constructive criticism (although I think the font size looks fine on my laptop), you should definitely increase the line-height of the paragraphs.

Yes, indeed. Thank you!

I tried spacing it a bit just not, it does look better this way.

I appreciate the amount of work and effort you've put in here.

I also maintain my own site which is statically generated and deploys to a VPS running docker via git pushes. I haven't written interactive articles yet, but having absolute freedom is imperative for me. I always end up fighting with whatever system I use, except here I can just extend it to do what I need.

What do you mean deploys to docker? Does it deploy in a container running the web server?

I have a container running on a VPS that uses Caddy's http.git plugin to check for new commits. Whenever I do a git push it pulls in the changes.

See my sibling comment [0] for links.

[0]: https://news.ycombinator.com/item?id=20366137

Oh cool! What did you use to build that? I did the same thing with blog.winricklabs.com

I used Zola [0] + Caddy [1] with the http.git plugin [2] and docker. I generate the assets with Zola, then rsync them to a separate repository and Caddy automatically pulls in the changes whenever I git push.

Source here: https://git.sr.ht/~andrewzah/personal-site/tree

[0]: https://github.com/getzola/zola [1]: https://github.com/caddyserver/caddy [2]: https://caddyserver.com/docs/http.git

Your website is fantastic! I love how minimal and fast loading it is. Could you please enlighten on how you manage to make an HTML page interactive (for e.g. on vectorization page where I can move bezier curve handles)?


It's simple, all the interactive plots are HTML canvases with a set of event handler assigned to them. I trigger init ialization functions right after the elements declarations, and they assign all the events: https://github.com/akalenuk/wordsandbuttons/blob/380c97f2535...

Almost every event changes the state somewhere and triggers the redrawing function: https://github.com/akalenuk/wordsandbuttons/blob/380c97f2535...

And that's all. It's a bit messy since it involves keeping state outside the functions, and it also requires a little boilerplate but it's manageable. Maybe if I would have hundreds of plots per page, this would have been a problem but for a blog-post size pages this works fine.

Your website is super cool, thank you for publishing the source on github. Would you mind elaborating on your creation flow for new pages?


It starts with an idea. The whole thing: writing and interactive elements working together. Thinking it through with drafts and sketches takes a few weeks. Then I copy-paste a ./drafts/stub.html file, and copy-paste the elements that looks like what I'm trying to achieve the most there. Then I maul it into an actual code for the page. Then I write the text that has already been formed in my head, then I edit, and then I edit again, end the next morning I edit the last time. Then I put it into ./pages, fill in the index.html and the rss. Then I upload it to the hoster. That's it.

Some of these things can be automated. There's absolutely no need to deploy things manually. Unfortunately, the automateable things take the least amount of time. Sketching and editing take maybe 90% of it, and the programming takes the 90% of the remaining 10%.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact