> I worry that many developers (maybe even you, dear reader) are settling for suboptimal, restrictive static-site generators that place limits on the interactivity and flexibility of your website.
I wonder what sort of interactivity you want on your text?
> This degrades page load speeds and user experience, which accordingly degrades your rankings on Google. Instead I want every page of my site to be pre-rendered to a set of fully static assets
Oh, you want a static site. That's what I want too.
>I wonder what sort of interactivity you want on your text?
In case you glossed over it, I think he said it in his post:
"But down the road, I may want to build a page that contains an interactive visualization, a filterable table, or a demo of a React component I'm open-sourcing."
Yes. You can go crazy with static sites. I use Github Pages for this. On one I've done a single-page Javascript-driven text adventure. On another I've embedded a Unity application that runs a dynamic 3D starmap with WebGL. I've also seen roguelikes. What you can't do is run server-side logic, but you can do an -awful- lot on the client.
When workplaces were still slowly still migrating to GIT, we had Git and SVN.
SVN rocked because you could run static sites in it, a little bit of jquery and whatever and I was building a ton of simple business productivity tool as single page apps. All with the peralta guarantee of support.
I wonder if he actually tried embedding HTML into Markdown, because that's as simple and straightforward as it can be: just start writing HTML in the Markdown document, and after the closing element, continue with the markdown text.
This should completely cover the requirement to embed interactive elements into markdown using a static site generator like Hugo or Jekyll without having to deal with an overly complex dependency like React.
Here's an example of embedding a WASM home computer emulator with just a few lines JS (and I'm not exactly a web development expert, so with a bit more knowledge and experimentation I'm sure this could be made much more fancy):
I'd like the ability to embed arbitrary React+JSX into my Markdown, something which can theoretically be done (i.e. with the Hugo Babel plugin). But then I immediately realized I would have issues with importing my styling libraries (I used a custom-built Tailwind-esque set of emotion[0] classes) and using React Hooks.
As you can probably tell I have a hard time letting go of the power/flexibility of the React/SPA approach since it's all I've used for several years now.
I agree, but then really you're not interested in creating blog content per-se, but in exercising your engineering skills. I think it's important to be honest about that intention both with your audience and yourself when writing articles like this.
+1 for this. I use Posthaven because it's the simplest way for me to publish blog posts plain and simple (and has been for years.)
A lot of devs get excited by the idea of building a blog and not of actually writing the content. You've got to actually have ideas to share and be prepared to put in the time to write posts.
I wouldn't even think about tech before you've got a backlog of at least 2 or 3 posts.
Hi! John from Ghost here - Ghost has no bloated styles or scripts which are injected by default. You have full control of the frontend and can make it as minimal (or maximal) as you like.
My answer to the OP would be:
If you want to write (on a blog) then do literally anything but turn your blog into a development project that you'll definitely never finish - because it just becomes the excuse for not writing. (almost all developer blogs)
If you want a fun developer project to experiment with your personal website, and messing with new technology is the goal, then this stack sounds like a lot of fun. It also sounds like it will be obsolete and no longer shiny in 12 months, but again, if this is your goal then you probably don't care.
TLDR: developer tools will usually end up being great for development, publishing tools end up being great for publishing. Pick the one that suits your desired outcome best.
You can write your own theme still. I wrote my own. Mine serves 2.6kB for CSS and 16kB for app-specific javascript--mostly for highlighting of code blocks
I recommend reading through some of my criteria (ability to use npm modules, TypeScript React components, etc). May be possible with Wordpress (haven't tried it) but sounds like an uphill battle.
I use Jekyll too. It just works and I'd happily use it on future projects.
Even with ~300 posts and ~100 drafts it only takes 2 seconds to see auto-reloaded updates when I'm actively writing. That's within WSL 1 too (room for speed improvements are there with WSL 2).
It also has nice plugins to process SCSS and bundle your CSS / JS, along with md5 tagging all static files for cache busting without having to use Webpack or do anything complicated. You just reference them using a specific plugin's template tag. But at the same time you can choose to use Webpack if you'd like.
I'm not sure why the author mentioned Jekyll is too restrictive. You can write plugins to do some pretty custom things. Like, I wrote a few lines of Ruby to parse out time stamps from a list to make them clickable links so that I can jump to that position in a custom audio player, very similar to how clickable time stamps work on Youtube. You can pretty much do anything.
Another Jekyll fan chiming in. It was a good sign for me that it's not super-actively maintained, yet still commands a strong following in an arena with fairly low switching costs. Out of the box, it has most things you want and very little that you don't.
Principle 1 on the Jekyll philosophy is 'no magic', and that's why I love it. It tends to behave as expected, and what it provides is simple enough that I maintain a feeling of full control over the output. I've wrote some little bits of JS to add minor client-side enhancements, and the Jekyll plugin system is easy to dive into if you want to add some site-render features. Great tool.
Kudos to the author for putting something up for discussion. Replace the word 'The' with 'My' in the title and it's a nice exploration of where React tooling for static sites is at.
Keep publishing and sharing mate, you're good at telling a story and have more good content ahead of you.
You lost me at "plugins" I'm afraid. I looked into ways to mix in React + TypeScript into both Hugo and Jekyll and it just seemed like an uphill battle. Based on my criteria (which I'm realizing aren't very popular on HN!) the best approach is to build everything "React-first" with Markdown mixed in, instead of the other way around.
Plugins are optional. If you used Webpack directly to manage your static files you could just tell Jekyll to load them from whatever directory Webpack outputs them to and then you can build your SPA to render blog posts however you see fit.
If you're using React you would want to use a native Webpack config right? This way it works anywhere, and isn't tied into any specific static site generator.
I'm looking in to Jekyll as well, since it's what github recommend and I really can't be bothered with templates and re-learning all web stuff when all I need is to be able to write text and show pictures.
Haven't really gotten started with it, but I wonder where the limitation of the tool will be felt? Do you need to know Ruby and the things around it too?
I were thinking of also suggest it to my SO who have past experience in web design but no programming skill at all (I can at least set up her github account). My guess she would be more picky with how the page looks though.
> but I wonder where the limitation of the tool will be felt
I use it and I don't feel any limitation. One can always add Javascript (AFAIK) if they want new functionality.
What bothers me is that adding new functionality should be attempted first in the idiomatic (for the platform) way, which in the Jekyll case, is the Liquid language. I personally don't like it, but it's not a big deal to add small features (e.g. tagging).
Wordpress (AFAIK; I don't use it) has a large amount of plugins. If the intention is from the beginning to customize the blog functionality - as opposed to styling - probably Wordpress can be easier. But we're not talking anymore about a minimalistic design.
> Do you need to know Ruby and the things around it too?
Not at all! Just write in plain markdown with Front Matter.
One of my goals is to maintain that same authoring simplicity. All I need to do is create a new `.md` file in the right directory and a new blog post is created - just like you. I just don't want to fight an uphill battle every time I want to leave that lane.
Here's my stack: I write .html files in GNU Nano, and serve them with Apache. I've done that for about 20 years (with varying editors and servers), and I don't see why it needs to be any more complicated putting words on the internet.
Yes yes, old man yells at cloud etc, but I'm a strong believer in "less is more".
Someone has a workflow that they know like the back of their hand and has low friction... that's less. Good for them.
Folks get worked up on developer choices so much, if it's a blog and it's not doing something seriously bad ... it's their site and their call IMO.
When I was into photography one of the biggest lessons I learned was you use the tool... you're going to use a lot. It doesn't matter what it is as much as the tool should allow you to do the thing and not get in the way because you think you "should" be using something else.
There's nothing wrong with that approach tbh; when you think about it, the only reason to make a dynamic website is to prevent duplication, things like headers, menus, styles, etc. But there's ways around that, like frames.
as a non web developer who needed to get a static site with a consistent header and footer up I just made a makefile which watches an src directory and cats the header and footer onto each file
The only true path is mine, I write .htm files in vim and serve them with nginx.
Yes, I agree, cloudyelling or not, no stack is better.
I recall in my teenage years, I built 2 or 4 "CMS" in PHP/MySQL, at the end, added all that AJAX when browsers blessed us with the possibility of making HTTP calls from JavaScript!
But in the end, migrating from server to server, learning more about everything, the only thing that seems somewhat stable are plain text or pure html. I know I can edit them in 2000 years, if I am still alive by then.
Hmm, you're right, but I do use the nginx as reverse proxy for some of the other sites which are not static :P
I'm also running everything in docker containers, so I'm closet-hipster I guess xD
It becomes more complicated as soon as a you have a sidebar with "Last articles" in which case you would need to edit each single HTML files to edit the sidebar consistently. Even with a single archives page you need to think about updating the archive for each new article. Also Markdown is definitely more author-friendly than HTML, but that's more like an extra.
I think that personal sites are usually the ideal grounds for exploring a new technology or learning a new language/framework/cloud/fill-in-the-blank. That's why a lot of them run on often-times ridiculously over-engineered tech. If you have a site that is working for you - great! Could every developer's blog be a set of HTML files and a script? Sure. But many developers prefer to tinker and build on new technologies, and their personal site or blog is a great place for that tinkering.
I'll make a basic UI eg. menu/side panel/body/basic write interface and then use LAMP. I can add additional capabilities eg. commenting/stats(view counting) if I want... don't think I personally need anything more than that. My stuff is dynamic eg. using TEXT for body through MySQL. I use Node now as a backend but for something quick I can still use PHP which is where I came from/started with. I can host images wherever/maybe add free CDN account.
That's what I do with my website[0] as well (just on nginx and with vim via SSH).
However, something that requires more functionality - syntax highlighting, tags, version control, easier deployments - I recently switched to Markdown + Hugo. [1]
I find it all to be very subjective. The above author clearly favors TypeScript and React, and for a personal blog, I see nothing wrong with slightly over-engineering it. His blog loads quickly, doesn't require an absurd number of network requests, and doesn't include any trackers. Fairly minimalist as far as the endproduct is concerned.
As a non-React developer: forms, before React, were actually super simple. The author mentions they forgot how to do forms the normal way, but like, can you imagine how excited they'll be by the simplicity?
Well, think about time just for a second. Take your average 25 year old frontend developer, for example. Five years ago in 2015, we were sort of coming out of Jquery. That means all these people had to be doing professional modern web development at the age of 20. What’s the likelihood of that for most people? Take you average bootcamper, by definition they didn’t know modern web development when they were about 22. If they graduated recently, that means around 2015 they were maybe 17 years old, and if they went to a bootcamp post college, they sure as hell don’t know anything from the 2009-2016 era.
So that’s who writes this stuff. They literally don’t remember a world where you can build very simple things without state management, without scoped styles, without jsx.
I’m not an agist, but it’s like c’mon dude, it’s a blog, when did you start web development? Don’t write your own blog posts yet please, mature a little first. Way too much noise out there now days.
Why do you need type checking for your blog? You really going to double check that you’re posting a string or something? Do whatever you want, but stop posting about it like it doesn’t sound unnecessary to the rest of us.
You don't have to live through something to be aware of it. I'm not a web developer, and in 2015 I think I might have started programming, but even I have figured out that HTML forms are a thing that exist.
Haha, 23 year old developer here. First professional dev job at 18, coding since very young though.
> "Five years ago in 2015, we were sort of coming out of Jquery."
And HTML5 was still freshly standardized, Angular meant Angular.js, and your average web app was SSR MVC with view templates injected with controller variables, made interactive with jQuery.
Rails and MongoDB was the move, GraphQL would've been released the same year, and everyone would be convinced it was a fad and huge meme.
The React that would start to gain popularity around that time was a completely different ballgame. Redux wasn't hip yet, people were still using Flux from FB or Ken Wheeler's Flux plugin:
Creating your own stack for your personal blog seems to be the modern-day equivalent to creating your own programming language: it's a huge time sink with virtually no sane justification, yet developers are drawn to it like moths to a flame.
A personal blog should be whatever the author wants it to be of course, and a developer should play with whatever technology he/she wants. But as a backend developer, I don't want any Javascript on my site, because I hate writing it and I don't like browsing it.
These statements indicate to me that this "ideal tech stack" is rather personal to the author:
> I want to build the site in React and TypeScript
> I don't want limitations on what my personal website can be/become. Sure, my current site consists of two simple, static blog posts. But down the road, I may want to...
> I literally have zero memory of how we used to build forms in the pre-React times.
I think I'll keep it at Hugo for now, with just HTML and CSS.
Hugo is awesome! (Apart from the Go templates, before you get the hang of them..)
A year or two back, shouting REACT at everything and everyone could actually land you a new job, but now... I'd just stick to Hugo and focus on my content if I wanted to impress any recruiters.
the built in image processing is kind of a big deal for Zola that's handy. a cut above all node based pipelines that have horrible native modules for that. I kinda just want to write Vue components for posts rather than markdown so turn between trying Zola it nuxts new content cms
As a full-stack developer who spends a good proportion of my time at my day-job working with React, I totally agree. My personal website is Hugo, and entirely JavaScript free.
Same here, even a lot of my personal projects are now just SPA free by default. I do use Node on the backend, but most of the time, a templating language like pug gives me everything I need.
Came here to say Hugo is the correct answer for a Personal Developer blog, unless you're using it to showcase your skills in a particular technology, at least in my experience.
Finally dived into Hugo and it's just so easy to get going with making Markdown content and turning it into a static site with one of the themes from their gallery. There's a bit of a rabbit hole to go down if you want to get more custom than that, but it's extremely customizable and you can learn a lot about how to do so just looking at the source code from themes in the gallery.
The only tech I really have to worry about is HTML, CSS, Markdown, and a little bit of template scripting for ranges and reading variables from the config files, if I want to customize the theme.
I've gotten excited about building my personal website again because I don't have to screw around with the technology hardly at all, I can focus on just making content. Which is what you want for a personal site. You don't want a bunch of friction slowing you down from actually getting content out there.
I don't have to worry about dependency hell with Hugo either, it's just an executable.
I've been using Github Pages which has Jekyll support and that's worked fine, but I'm curious where people host their Hugo sites (or how hosting works when you run the server yourself).
Is it AWS? Dreamhost? or something else? Do you have to manage a proxy or handle load/cost spikes? Can a surge of traffic take down the site?
I haven't read a ton about this, but I'm curious about it. It'd be neat to have full control over my own publishing if something ever happened to github pages.
That's the beauty of a static site generator -- github just expects valid HMTL to be generated and pushed to a specific branch. Github has no more Jekyll support than it has support for Hugo or a custom static site generator written in bash.
Github does have special Jekyll support, but you just generate the hugo static files locally and only push those up to where Github expects them to be?
I think with Jekyll Github will re-generate the static files for you and works with the RSS plugin automatically.
Good to know though - might be worth checking out Hugo, thanks!
I haven't actually made it live yet, but it's just a static site once it's generated. I'll either push it to my github pages (probably what I'll do), or I'll upload it to my webhost, which I also have (but has been dormant for awhile).
100% Agree. But let's be honest. For most developers, the 1st priority of a personal blog is not page views, but job offers. So it makes sense to make your personal site using the tech that matches your skills.
We've been using Gatsby for a blog. Writing the layout in React gives us backend devs experience with it whilst staying relatively simple.
Markdown then gives us a nice way to write content and separates layout and presentation from that content.
Gatsby has loads of plugins and examples so getting started is easy. There's a plugin for an RSS feed.
I'm completely with you that a blog can be HTML and CSS, but I can clone a Gatsby starter blog and add some markdown files within 15 minutes. I see this approach as a low cost alternative to Wordpress.
You don't need Gatsby for any of those things you want to do. You can accomplish the same goal with a much simpler toolkit, like Eleventy. Or my favorite, Bridgetown, for the Rubyists out there.
> I literally have zero memory of how we used to build forms in the pre-React times.
This is honestly quite a disturbing trend with a lot of front-end developers these days.
I recently asked a front-end dev why they chose React for a simple app over simple server-side templating, he's reaction was "we don't need SEO, so why do we need React SSR", like how does that argument even make sense. They seem to have forgotten you can build stuff without a JS framework.
The default has to be SPA + API, even when you don't actually need it.
> I recently asked a front-end dev why they chose React for a simple app over simple server-side templating
I don't really get this argument. What makes "simple server-side templating" better than React components? I'd argue that these React components effectively are templates. If someone is proficient in React, why are we suggesting they have to learn some other random templating language? Not to mention deal with additional things like file organization, transpiling, etc.
If the argument is "what makes ERB / JST / some other templating language better than React for server-side rendering" then sure, there's not really much difference.
What I suspect was the intent of the original question was "why does a simple app need to be an SPA with an API on the backend", which I do feel is something that adds significant complexity to any project. It's sometimes worth it, but I'll never be convinced that having to maintain an API alongside client-side rendering is faster or easier than a traditional server-rendered application.
Complexity is one thing, but more importantly is choosing the right tools for the job. There definitely are cases where you want SPA + API, but this wasn’t one of them.
The point was that they choose React by default instead of thinking about other tools which might be better suited. There was no reason to make this an SPA, they didn’t even consider not using React.
I agree about learning new things, but this isn’t a new language or syntax. At best you spend 10 minutes at the documentation and you know everything you need to know.
Is it really? You might as well say it's been a disturbing trend that developers aren't familiar with assembly language anymore.
As abstraction on top of abstraction is created, it becomes easier and easier to write software, so naturally there are now more frontend devs who aren't familiar with web dev basics. And if all you have is a hammer, every problem will look like a nail. Similar trends happen for backend devs and in devops. Is that really a problem? Only if you are a company that hired them with different expectations.
React solves multiple problems, sure. But I would say that templating isn’t one of them, and it definetly isn’t an abstraction to something more obscure.
You have this on the backend and devops side as well, but I would argue that most competent developers there know that there are other solutions.
Maybe my experience is more skewed towards front-end developers, but I would make the same statement about backend devs if they instantly choose one technology over the other, simply because that’s all they know. (Not even because they can defend that technology with reason)
Surely this is meant as satire, the title is clearly tongue-in-cheek.
I’d worry that some less experienced folks might take it at face value, rather than as a salient warning about the dangers of grossly over-engineering for no discernible
benefit.
> As much as I love the Jamstack, it doesn't cut it from an SEO perspective.
Static generation is a big part of JAMstack. Headless CMS means that the CMS only does the CMS part, and then you can plug Hugo, Gatsby or anything that you want with it.
I'd add to use Jekyll now (https://github.com/barryclark/jekyll-now) for a few more out-of-the box conveniences. Sadly, it's unmaintened, but the it gives a sufficient base as-is.
Github pages has out of the box support for Jekyll and I think that's the dominant way people use it.
I've heard good things about Hugo though (generally people seem to like it better than Jekyll), but I set up my site before it existed and I think Pages still only supports Jekyll.
"Hard" is the wrong term. But I'm certainly not alone in being rusty on this stuff. Uncontrolled components, form actions, imperatively reading all the <input> values, `x-www-form-urlencoded` data, etc. If you use this stuff on a daily basis, then I'm sorry for your suffering. I haven't touched it since 2015.
My main problem with blogging is not really the tech stack itself, but rather getting into the flow to consistently write and complete stuff. Every slip-up which happens on the way from brain to page drastically reduces the chance something will get published.
e.g. troubleshooting a broken deployment script because something broke after an update? -> no post. needing to manually manipulate images? -> no post. page rebuilding taking too long? -> no post.
Hugo + Org mode is my jam. I find org-babel incredibly helpful for posts containing code snippets because they get authored and run inline, with any output captured directly into the blog-post.
Earning my daily bread with writing React with TypeScript and using next.js, this is exactly what I would use for my personal blog.
Sorry for the many negative comments. I'm not sure if many people here do websites for a living, but I can't imagine doing stuff any other way anymore. It's just so convinient from a developer standpoint. Is it overkill for some websites? Maybe, but in the end you are dead on with your sentiment that it needs to be fun for YOU to use. So I hope you are not disencouraged by the many negative comments.
It’s using tech mostly used on the frontend (React), but using it on the backend via Next.js to generates static files that you can serve with any simple host you like.
True. I briefly mentioned Headless CMSs but didn't really give them the time of day. I didn't want to do anything that required a server/db/CMS, but I didn't do a good job of justifying that decision.
I do think the term "tech stack" has come to be used more broadly than your definition.
Regardless of the dependencies, the point that it is the 'simplest, most elegant way to generate a static version of a React-based website' applies. Next.js is ridiculously simple to get up and running with - even for JS rookies.
What point are you making? The linked blog post just defines simple and easy. I am not sure how this relates to your previous comment regarding dependencies.
> In essence simplicity is about reducing then amount of waste in development and increasing the longevity (service life) of the system we build.
I would argue the implementation of nextjs in the context of static, react-based a blog falls under this definition in your linked blog post. Unless I'm missing something?
"The ideal tech stack..." goes on to rattle off half a dozen or so components, ranging from languages to libraries.
Ugh.
It's a personal blog. A small amount of mostly static text and images served on demand in a couple different formats. Maybe some search/tag capabilities and maybe a comment section.
This problem is essentially the foundational problem that the web was initially trying to solve twenty-five years ago. And to be honest, twenty-five year old server-side solutions still do a pretty good job of it. (Although admittedly, the format of the resources served by those solutions are now far richer than they used to be.)
274 comments
[ 1401 ms ] story [ 3977 ms ] threadI wonder what sort of interactivity you want on your text?
> This degrades page load speeds and user experience, which accordingly degrades your rankings on Google. Instead I want every page of my site to be pre-rendered to a set of fully static assets
Oh, you want a static site. That's what I want too.
In case you glossed over it, I think he said it in his post:
"But down the road, I may want to build a page that contains an interactive visualization, a filterable table, or a demo of a React component I'm open-sourcing."
SVN rocked because you could run static sites in it, a little bit of jquery and whatever and I was building a ton of simple business productivity tool as single page apps. All with the peralta guarantee of support.
With Hugo/Zola I set my generator to include MathJax javascript if I enabled it in the front matter of the post. Etc.
Here's an example of embedding a WASM home computer emulator with just a few lines JS (and I'm not exactly a web development expert, so with a bit more knowledge and experimentation I'm sure this could be made much more fancy):
https://floooh.github.io/2019/01/05/wasm-embedding.html
Haven't yet seen a reason to switch to anything else.
I'd like the ability to embed arbitrary React+JSX into my Markdown, something which can theoretically be done (i.e. with the Hugo Babel plugin). But then I immediately realized I would have issues with importing my styling libraries (I used a custom-built Tailwind-esque set of emotion[0] classes) and using React Hooks.
As you can probably tell I have a hard time letting go of the power/flexibility of the React/SPA approach since it's all I've used for several years now.
A lot of devs get excited by the idea of building a blog and not of actually writing the content. You've got to actually have ideas to share and be prepared to put in the time to write posts.
I wouldn't even think about tech before you've got a backlog of at least 2 or 3 posts.
My answer to the OP would be:
If you want to write (on a blog) then do literally anything but turn your blog into a development project that you'll definitely never finish - because it just becomes the excuse for not writing. (almost all developer blogs)
If you want a fun developer project to experiment with your personal website, and messing with new technology is the goal, then this stack sounds like a lot of fun. It also sounds like it will be obsolete and no longer shiny in 12 months, but again, if this is your goal then you probably don't care.
TLDR: developer tools will usually end up being great for development, publishing tools end up being great for publishing. Pick the one that suits your desired outcome best.
Still using Jekyll.
Even with ~300 posts and ~100 drafts it only takes 2 seconds to see auto-reloaded updates when I'm actively writing. That's within WSL 1 too (room for speed improvements are there with WSL 2).
It also has nice plugins to process SCSS and bundle your CSS / JS, along with md5 tagging all static files for cache busting without having to use Webpack or do anything complicated. You just reference them using a specific plugin's template tag. But at the same time you can choose to use Webpack if you'd like.
I'm not sure why the author mentioned Jekyll is too restrictive. You can write plugins to do some pretty custom things. Like, I wrote a few lines of Ruby to parse out time stamps from a list to make them clickable links so that I can jump to that position in a custom audio player, very similar to how clickable time stamps work on Youtube. You can pretty much do anything.
Principle 1 on the Jekyll philosophy is 'no magic', and that's why I love it. It tends to behave as expected, and what it provides is simple enough that I maintain a feeling of full control over the output. I've wrote some little bits of JS to add minor client-side enhancements, and the Jekyll plugin system is easy to dive into if you want to add some site-render features. Great tool.
Kudos to the author for putting something up for discussion. Replace the word 'The' with 'My' in the title and it's a nice exploration of where React tooling for static sites is at.
Keep publishing and sharing mate, you're good at telling a story and have more good content ahead of you.
Plugins are optional. If you used Webpack directly to manage your static files you could just tell Jekyll to load them from whatever directory Webpack outputs them to and then you can build your SPA to render blog posts however you see fit.
If you're using React you would want to use a native Webpack config right? This way it works anywhere, and isn't tied into any specific static site generator.
Haven't really gotten started with it, but I wonder where the limitation of the tool will be felt? Do you need to know Ruby and the things around it too?
I were thinking of also suggest it to my SO who have past experience in web design but no programming skill at all (I can at least set up her github account). My guess she would be more picky with how the page looks though.
Once it’s set up it’s just markdown, no ruby required.
I use it and I don't feel any limitation. One can always add Javascript (AFAIK) if they want new functionality.
What bothers me is that adding new functionality should be attempted first in the idiomatic (for the platform) way, which in the Jekyll case, is the Liquid language. I personally don't like it, but it's not a big deal to add small features (e.g. tagging).
Wordpress (AFAIK; I don't use it) has a large amount of plugins. If the intention is from the beginning to customize the blog functionality - as opposed to styling - probably Wordpress can be easier. But we're not talking anymore about a minimalistic design.
> Do you need to know Ruby and the things around it too?
Not at all! Just write in plain markdown with Front Matter.
Yes yes, old man yells at cloud etc, but I'm a strong believer in "less is more".
Someone has a workflow that they know like the back of their hand and has low friction... that's less. Good for them.
Folks get worked up on developer choices so much, if it's a blog and it's not doing something seriously bad ... it's their site and their call IMO.
When I was into photography one of the biggest lessons I learned was you use the tool... you're going to use a lot. It doesn't matter what it is as much as the tool should allow you to do the thing and not get in the way because you think you "should" be using something else.
The only true path is mine, I write .htm files in vim and serve them with nginx.
Yes, I agree, cloudyelling or not, no stack is better. I recall in my teenage years, I built 2 or 4 "CMS" in PHP/MySQL, at the end, added all that AJAX when browsers blessed us with the possibility of making HTTP calls from JavaScript! But in the end, migrating from server to server, learning more about everything, the only thing that seems somewhat stable are plain text or pure html. I know I can edit them in 2000 years, if I am still alive by then.
nc txt.anderspitman.net 3838 <<< /txt/19
However, something that requires more functionality - syntax highlighting, tags, version control, easier deployments - I recently switched to Markdown + Hugo. [1]
I find it all to be very subjective. The above author clearly favors TypeScript and React, and for a personal blog, I see nothing wrong with slightly over-engineering it. His blog loads quickly, doesn't require an absurd number of network requests, and doesn't include any trackers. Fairly minimalist as far as the endproduct is concerned.
[0] https://chollinger.com/ [1] https://chollinger.com/blog/
So that’s who writes this stuff. They literally don’t remember a world where you can build very simple things without state management, without scoped styles, without jsx.
I’m not an agist, but it’s like c’mon dude, it’s a blog, when did you start web development? Don’t write your own blog posts yet please, mature a little first. Way too much noise out there now days.
Why do you need type checking for your blog? You really going to double check that you’re posting a string or something? Do whatever you want, but stop posting about it like it doesn’t sound unnecessary to the rest of us.
> "Five years ago in 2015, we were sort of coming out of Jquery."
And HTML5 was still freshly standardized, Angular meant Angular.js, and your average web app was SSR MVC with view templates injected with controller variables, made interactive with jQuery.
Rails and MongoDB was the move, GraphQL would've been released the same year, and everyone would be convinced it was a fad and huge meme.
The React that would start to gain popularity around that time was a completely different ballgame. Redux wasn't hip yet, people were still using Flux from FB or Ken Wheeler's Flux plugin:
https://github.com/kenwheeler/mcfly
What a wild ride it's been.
Can someone comment on the latest version of Next vs Gatsby?
These statements indicate to me that this "ideal tech stack" is rather personal to the author:
> I want to build the site in React and TypeScript
> I don't want limitations on what my personal website can be/become. Sure, my current site consists of two simple, static blog posts. But down the road, I may want to...
> I literally have zero memory of how we used to build forms in the pre-React times.
I think I'll keep it at Hugo for now, with just HTML and CSS.
A year or two back, shouting REACT at everything and everyone could actually land you a new job, but now... I'd just stick to Hugo and focus on my content if I wanted to impress any recruiters.
Finally dived into Hugo and it's just so easy to get going with making Markdown content and turning it into a static site with one of the themes from their gallery. There's a bit of a rabbit hole to go down if you want to get more custom than that, but it's extremely customizable and you can learn a lot about how to do so just looking at the source code from themes in the gallery.
The only tech I really have to worry about is HTML, CSS, Markdown, and a little bit of template scripting for ranges and reading variables from the config files, if I want to customize the theme.
I've gotten excited about building my personal website again because I don't have to screw around with the technology hardly at all, I can focus on just making content. Which is what you want for a personal site. You don't want a bunch of friction slowing you down from actually getting content out there.
I don't have to worry about dependency hell with Hugo either, it's just an executable.
I've been using Github Pages which has Jekyll support and that's worked fine, but I'm curious where people host their Hugo sites (or how hosting works when you run the server yourself).
Is it AWS? Dreamhost? or something else? Do you have to manage a proxy or handle load/cost spikes? Can a surge of traffic take down the site?
I haven't read a ton about this, but I'm curious about it. It'd be neat to have full control over my own publishing if something ever happened to github pages.
I host my hugo-based blog with github pages.
Github does have special Jekyll support, but you just generate the hugo static files locally and only push those up to where Github expects them to be?
I think with Jekyll Github will re-generate the static files for you and works with the RSS plugin automatically.
Good to know though - might be worth checking out Hugo, thanks!
This problem has been solved a thousand times over with much simpler tooling.
> I literally have zero memory of how we used to build forms in the pre-React times.
:(
Markdown then gives us a nice way to write content and separates layout and presentation from that content.
Gatsby has loads of plugins and examples so getting started is easy. There's a plugin for an RSS feed.
I'm completely with you that a blog can be HTML and CSS, but I can clone a Gatsby starter blog and add some markdown files within 15 minutes. I see this approach as a low cost alternative to Wordpress.
This is honestly quite a disturbing trend with a lot of front-end developers these days.
I recently asked a front-end dev why they chose React for a simple app over simple server-side templating, he's reaction was "we don't need SEO, so why do we need React SSR", like how does that argument even make sense. They seem to have forgotten you can build stuff without a JS framework.
The default has to be SPA + API, even when you don't actually need it.
I don't really get this argument. What makes "simple server-side templating" better than React components? I'd argue that these React components effectively are templates. If someone is proficient in React, why are we suggesting they have to learn some other random templating language? Not to mention deal with additional things like file organization, transpiling, etc.
What I suspect was the intent of the original question was "why does a simple app need to be an SPA with an API on the backend", which I do feel is something that adds significant complexity to any project. It's sometimes worth it, but I'll never be convinced that having to maintain an API alongside client-side rendering is faster or easier than a traditional server-rendered application.
I agree about learning new things, but this isn’t a new language or syntax. At best you spend 10 minutes at the documentation and you know everything you need to know.
As abstraction on top of abstraction is created, it becomes easier and easier to write software, so naturally there are now more frontend devs who aren't familiar with web dev basics. And if all you have is a hammer, every problem will look like a nail. Similar trends happen for backend devs and in devops. Is that really a problem? Only if you are a company that hired them with different expectations.
That is a disturbing trend.
You have this on the backend and devops side as well, but I would argue that most competent developers there know that there are other solutions.
Maybe my experience is more skewed towards front-end developers, but I would make the same statement about backend devs if they instantly choose one technology over the other, simply because that’s all they know. (Not even because they can defend that technology with reason)
I’d worry that some less experienced folks might take it at face value, rather than as a salient warning about the dangers of grossly over-engineering for no discernible benefit.
(It’s not the tech stack I’d choose, but I see exactly why it’s being chosen.)
https://hackerspring.com
Static generation is a big part of JAMstack. Headless CMS means that the CMS only does the CMS part, and then you can plug Hugo, Gatsby or anything that you want with it.
When you already know Git & GitHub, you get an all-in-one experience with your code & website side by side.
I've heard good things about Hugo though (generally people seem to like it better than Jekyll), but I set up my site before it existed and I think Pages still only supports Jekyll.
https://aravindh.net
No JS tinkering. Just simple HTML and CSS to customise the theme for my taste. Not as simple as editing raw HTML with vi, but I'm good with it.
e.g. troubleshooting a broken deployment script because something broke after an update? -> no post. needing to manually manipulate images? -> no post. page rebuilding taking too long? -> no post.
I definitely wanted to use srcset to serve a performant website, but i was too lazy to do that manually or to make a script for it.
Now it doesnt matter anymore :)
Sorry for the many negative comments. I'm not sure if many people here do websites for a living, but I can't imagine doing stuff any other way anymore. It's just so convinient from a developer standpoint. Is it overkill for some websites? Maybe, but in the end you are dead on with your sentiment that it needs to be fun for YOU to use. So I hope you are not disencouraged by the many negative comments.
I'll hazard a guess at >90%.
No point in learning "the ideal" stack, if you can use something you know that is as good as any other stack.
Let's be honest. You can develop and deploy static site anyway you want.
I do think the term "tech stack" has come to be used more broadly than your definition.
There's nothing simple about this crapton of dependencies. Sure, it may be easy to build things this way, but let's not conflate the two terms.
> In essence simplicity is about reducing then amount of waste in development and increasing the longevity (service life) of the system we build.
I would argue the implementation of nextjs in the context of static, react-based a blog falls under this definition in your linked blog post. Unless I'm missing something?
Ugh.
It's a personal blog. A small amount of mostly static text and images served on demand in a couple different formats. Maybe some search/tag capabilities and maybe a comment section.
This problem is essentially the foundational problem that the web was initially trying to solve twenty-five years ago. And to be honest, twenty-five year old server-side solutions still do a pretty good job of it. (Although admittedly, the format of the resources served by those solutions are now far richer than they used to be.)