Anyone using a web-based front-end dev workflow? (Eg GitHub Codespaces)

Hello to those who code. I am a designer who used to write a lot of front-end code. Now I only focus on UXD at work (Figma in place of coding) and haven’t worked on personal web things for roughly 5 years. This week I’ve been trying to get back into coding to customize my blog. I understand that many things may be done with injecting CSS, or using plugins, but I’m looking to see what control over an entire theme looks like.

In my prior experience, I had everything local to my Mac, your homebrews, your npms, etc, and sync’d up to GitHub. For the Mac people, I used BBEdit exclusively.

I understand now that front-end dev is achievable in the cloud with GitHub’s code spaces and web-based VS Code. Further more, GitHub’s Copilot could probably assist me in shaking off the rust and maybe take better advantage of things like flex box and grid that I never had much chance to dive into before as they were “new”.

My first goal is to bring the design of my woefully out-of-date portfolio (customized Hyde/Poole Jekyll theme) back to my personal blog on Micro.blog. After achieving this, I have several next projects, such as bringing my portfolio into MB itself (as a separate blog), and maybe building some additional themes.

Is anyone in this community using these web-based tools by chance, who may be able to share anything about their setup?

There’s nearly no advantage to this versus local without having a really sophisticated set of services/setup, security rules, or need for crazy compute. Your experience will be better and cheaper to just use VS Code locally if that’s what you want. CoPilot has a pretty deep integration there so it should not be a problem. And for micro.blog, all you need is the right version of Hugo installed, which is small, easy to get a binary for, and runs incredibly fast locally.

I appreciate your input Jason. I have a new Mac and I am looking into this because I do not want to install a whole subsystem of stuff, which then needs to be maintained. I did this for Jekyll, and now that stuff is so out of date, I couldn’t even figure out how to get it running again. This feels like a way to prevent that from happening locally. Also, it appears to be free to use on GitHub for low usage such as mine. (I have run the editor a few times so far, I just don’t know what I need to install—and this goes for a local install too—in the image to be able to run Hugo.) I assumed no one was doing this here, so I’ll just hack through it myself (I have some dev friends local to me I can pester), but I figured I’d ask first before figuring it out on my own.

Thanks.

The Hugo setup is significantly less involved than Jekyll. I think working with and maintaining a codespace is going to be harder. I have used both.

This is 100% what you need, you can do it with the binary, though I do recommend using homebrew.

You just install it once and you’re done. Micro.blog has updated Hugo 2x in its many years and always had years of overlap with the old version. Hugo and Git are all you need to build everything from scratch in VS Code if you want.

So, brew install hugo is all I would need to have an install and be able to preview locally?

Correct. You then just go to the blog directory and type hugo server and that will build the site (and rebuild with most edits) and you go to localhost:1313 (which it will say in the terminal) to view your site being served locally.

I’m back… installed homebrew and then brew’d hugo… and it installed 0.128.2 — which is several revisions newer than the latest on MB. Is this something to be concerned about? Are there meaningful changes from 0.91 that would effect porting my theme from jekyll to an MB-compatible Hugo theme? (Greg, in his post earlier this year recommended 0.91, which I see is “default” in the MB Design tab) — thanks.

Fairly unlikely to matter— you’re going to run into a couple of small things that are MB specific potentially but easy to help out with. Most changes are brand new, very advanced build-time pipeline features that may not work on MB but aren’t going to fundamentally change porting templates and CSS.