It's really just a (bad) static site generator, it's just that every static site generator I've run into so far was way more complicated than I need and so it was faster to write my own with only the three features I want than to learn a big complicated tool.
I guess I have mixed feelings here. It makes sense to invest time in a complicated setup for a personal website as a hobby project, and I am quite clear that I am not a software person so that's just not something that really interests me as a way to spend my time. Spending a ton of time "developing a blog" feels to me like it's just a big roadblock in the way of actually, you know, blogging. I acknowledge that a good part of that is personal preference.
On the other hand... much of the post really concerns me. The author talks about React and TS like they're the only alternative to writing bare JS. Well, for one, there are other, simpler options even within the TS ecosystem. For another, the website doesn't really seem to have any behavior that requires JS, so I'm not sure why JS needs to be involved in the first place.
The rejection of using MD along with React seems like... a damning condemnation of React? Is it really that hard? People tolerate that?
The assertion that most CMSs require two round-trips to deliver the content speaks of someone who has not really seen the world outside of modern JS front-end... It would be very uncommon for a CMS in another language to require more than one round-trip, as the content is prepared server-side before delivery of any kind of front-end.
I guess, if I am to be opinionated (which I certainly will be), my feeling is that the author should have spent their hobby time exploring the world outside of React rather than hammering what seems like a rather round peg into a rather square hole, and then presenting it as "ideal."
I address the fact that the site, as it currently exists, doesn't need any of this currently. I tried to be clear in my "criteria list" that I'm designing for power and flexibility; I don't want to limit myself down the road.
I definitely could have verbalized my stance on headless CMSs better. I'm very aware that there are ways to use them without requiring two round trips. But in the very next paragraph I say "I want every page of my site to be pre-rendered to a set of fully static assets". The solution you allude to (a headless CMS with server-side rendering) requires a server and doesn't meet that criteria.
I also know you can do generate a static site with Next/Gatsby + a headless CMS that's integrated into your build step. I didn't do that way because it seemed overkill - I'm happy using my file system as my CMS.
You mention that I reject using "MD along with React". Which bit of the post are you alluding to? I do reject the idea of putting React components inside of `<script>` tags inside of a Markdown file. Based on my criteria, the "React + a sprinkling of Markdown" makes more sense than "Markdown + a sprinkling of React". Otherwise it's an uphill battle (with a fair bit of boilerplate) to use React Hooks, import styling libraries, etc.
I'm not sure I follow your logic w.r.t this being a damning condemnation of React. There a build step (either Babel or TypeScript) required to use cutting-edge React. That additional layer of separation is what makes it so hard to do React+TS inside of these Markdown-centric CMSs. I don't think that impedance mismatch reflects poorly on either React or the SSGs - they each have their uses.
Could you elaborate on the "other, simpler options even within the TS ecosystem"?
The boundary between a 'headless cms' and a 'static site generator' can get somewhat fuzzy. The approach that I usually take here, when it's less of a hobby project, is to use a full-featured-editor-included CMS and then aggressively cache the pages so that behavior is just delivery of static files in the 99% case. This is an extremely common pattern with WordPress, for example---I would never call WordPress a paragon of performance but it is quite fast with the commonly used caching plugin that essentially reverts it to a static site generator for common cases. It's even better to do the caching in a web server or other in-between layer which is generally going to be faster at shuffling files than whatever language your CMS is in.
When it comes to simpler options with TS, I would just write what you need in bare TS. That gets you the advantage of typing without the weight of a framework. It does make it more difficult (though of course not impossible) to rely on framework components but I don't feel that really need them in your use-case.
Finally, totally with you on relying on the file system as a CMS. In my case I actually use the file name verbatim as the post title, one of those things that seemed too simple to work up front but is actually basically fine. The only constraint is that "titles" (e.g. file names) must start with the date because I just sort them to order posts - this is all so that posts can just be plaintext files (or markdown files, but I stick to plaintext as a stylistic decision) without needing to be parsed for any kind of header metadata or something. It is a limitation but I'm pretty happy with it a self-imposed one.
I also, to be fair, have a bit of a negative gut reaction to React in this kind of situation. In my line of works (operations or, to be more fashionable, DevOps), I have had more encounters than I can easily count with "react apps that should be static files" and are significantly more complex to deploy and maintain than they ought to be as a result. There's nothing like fighting with the TypeScript compiler in the build chain for, well, a static file. I'd be less harsh on this if I hadn't also experienced so many cases of developers shrugging when it ends up doing something undesirable, because they don't even understand the React part of it all well.
I'm not really convinced that it can deliver faster development but I'm also not unconvinced. I am pretty convinced that it ends up adding significant complexity that can really bite you when you encounter what ought to be trivial problems, and there's such a large push towards "batteries included" frameworks in JS, combined with the very fast turnover in popular frameworks, that it seems excessively common for developers to be building on top of a framework that they don't really understand well (because they just learned it and it does a lot under the hood) and that just has rough edges to deal with (because it's relatively new). It's enough to make you a little bitter after growing up on Python and, of all things, PHP, where frameworks and libraries tend to stick around for a long time, most developers have longer background with the language and framework, and the build-test-deploy toolchains are generally simpler. Not necessarily easier to use, but simpler---these two do not necessarily come along with each other, see 'create-react-app' and its 'eject'... a solution that is easy to use but so complex that it has a tendency to explode when you look askance at it.
I kinda blacked out and came to 5 seconds later, and thanks to autocomplete and muscle memory, the whole skeleton of a document was there. HTML and Head and title and body and all that. It was so fast & fluid.
I'm ashamed to say I'd kinda forgotten how easy it is to just write fucking HTML. It's even got me reconsidering things like Markdown—I mean, fine for webforms and such, but if I'm just writing a document, is it of any use? Toss in a script to add a menu & header to every page & dump the output in a folder and I'm not sure I need more, now, and I can write that in Perl or Bash or Python or whatever in a minute or three and it'll run everywhere, nothing to install.
Edit: Bonus! I did the same for my brothers website: https://schnittfest.gmbh/ Just if you're curious.
A workplace of dreams. What else do you need anyway?
Turns out html covers pretty much everything. Learned a few cool things along the way like:
- `@media (prefers-color-scheme: dark)` (Still working on nailing down color contrast there)
- doing footnotes via anchor tags that (a) automatically number themselves in text with counters and (b) automatically highlight the footnote using the `:target` selector.
not a single line of JS. The biggest perf issue by far is a font that's 64KB, which is probably including more than it needs to.
Deploying is 1 line of `scp`. Recently I got all fancy and added 30 lines of bash to support flags for only deploying assets or posts.
all of it is so fast. Coming from rails and react and all of that, it's refreshing.
If I ever make a static dev blog, I'm doing the same. I've tried hugo, and it just felt way overcomplicated for what I was trying to accomplish.
nc txt.anderspitman.net 3838 <<< /txt/19
If your plain text document has line breaks to enforce some column width it will rarely match a browser's viewport width. This means the browser will break lines to fit in the viewport but still respect line breaks. So you get lines broken by the viewport and then line breaks a few words later. The text does not flow well at all.
If you only have line breaks at the end of paragraphs the text might flow better but the default viewport width on mobile browsers is (usually) 980px. Desktop browsers set their viewport width to the window width. In either case text ends up hard to read because lines end up really long.
You also lose hyperlinking which makes the web...a web.
If you want a plain text website just make it HTML with a minimal or no stylesheet. A single viewport meta tag will keep the page readable everywhere. Setting it to the device width will make mobile browsers reflow the text based on the screen size.
No one is going to read your blog with netcat or just curl into a pager.
I have an HTML version of my blog for people who want to read it in browsers.
> No one is going to read your blog with netcat or just curl into a pager.
No one is going to read my blog, period.
Idk, maybe we should revive the world of information served raw over TCP or telnet. HTTP is out of control.
You can make an argument that HTTP should be replaced with another application later protocol but just raw sockets everywhere is ridiculous.
HTTP has eaten the world of application layer protocols because it is flexible and expressive. It's also relatively easy to implement and there's lots of good FOSS server packages available. Most servers make it really easy to plug in back end applications. Combine that with ubiquitous HTTP clients and it's a super low barrier to entry.
You're not going to replace that ecosystem easily and you definitely won't replace it with raw sockets.
Well eventually the hosting provider no longer supported such an old version of php and the old cms did not support the new php... So it was either re-code the whole site for the new cms or dump it to html and html (with php header and footer) won.
I did a basic html page, using an open source css lib, cirrus. Changes are very simple, and I use gitlab pages. My blog is still backed by ghost. But I think raw html is still very powerful.
"The ideal tech stack for a personal developer blog in 2020 where the author is a React front end developer who loves TypeScript"
I said, out loud, at the first heading: "are you insane?"
With the stack described as I understand it, the front-end flexibility is preferable to what the likes of what WordPress will give you, and the stack will allow a developer to decouple the CMS backend from whatever plans he or she has for the frontend.
I suppose one can complain about React all they like. I'm not the biggest fan of React, but component based rendering has it's advantages, so I can't see the issue with that choice.
The only thing I don't like, is 'JS all the way down'...
Not because I hate the language (I think the language is fine, and TypeScript is overrated). But just because I'm still not quite sure what the effect on SEO and accessibility might be, when developers go 'full JS'.
Next.js also provides a very useful function: getStaticProps. This function will be called at build time - and will provide your (now static) build with dynamic data! It's pretty cool.
Going down the JAM stack route provides a number of opportunities to improve on many of technical aspects common to the development of a CMS backed website.
For a start, you'll miss out on opportunities cheaper hosting with 'serverless' deployment. But I think the chance to decouple the frontend from the backend is valuable enough, fwiw.
The tech stack therefore mirrors your interests.
It feels great to use tools built by _yourself_ for _yourself_. Doubly so if the stack is janky (rust / org-mode for me).
The feeling that you've made something makes you want to invest more into it. To make sure the tools were worth making in the first place.
My stack for the blog is Org Mode compiled by Emacs into HTML, which then gets parsed by my Common Lisp static site generator. It's a weird setup, but it came to be because:
- The rest of the site, and the overall template, is generated straight from Common Lisp (using a much saner syntax for markup and styling than HTML/CSS),
- writing a parser for Org Mode for anything but the most basic features is a rather complicated endeavor, so it's better to let Emacs deal with it and then clean up the exported markup,
- I also imported posts from my old Wordpress blog, as HTML dumped from a database, so I had the tools to slice and dice DOM in my CL generator anyway.
I really hate how bad this design is. It needs rewriting from scratch into something designed closer to a build system, but that would take a lot of time, so I procrastinate on that endlessly. On the other hand, writing blog articles in Org Mode is super fun, so the frustrations cancel out with the benefits.
What libraries / frameworks do you use in Common Lisp to generate the site?
LASS - to generate CSS
colorize - to colorize source code snippets and embed documentation links in them
Plump, Plump-SEXP, CLSS - for occasional fixing of imported HTML documents "on the fly"
Making my blog from "scratch" is a source of motivation for me to actually write articles. The experience so far has been overwhelmingly positive.
The main changes since that article is I use systemd services to manage caddy / webserver instead of tmux sessions.
The short of it is: rocket + tera + org-mode html export + some amount of parsing. There didn't exist high quality org-mode parsing crates when I made the blog.
You can learn more about the org-mode parts from the source code: https://github.com/dpbriggs/dpbriggs-blog/blob/f4936fa2dafea...
Even with high quality parsing libraries, when you dip into the most advanced features of org-mode (like literate programming via babel), you end up needing emacs anyway. And it's much more pleasant to tweak existing export code, than figuring out how to reimplement it from scratch.
I thought about doing batch export but ended up being too lazy to integrate it in my release flow. My compromise is to use this snippet:
(defun make-blogging-mode ()
(add-hook 'after-save-hook 'org-mode-export-hook)
# -*- find-file-hook: make-blogging-mode -*-
“I want to build the site in React and TypeScript. I love them both wholeheartedly, I use them for my day job, and they're gonna be around for a long time. Plus writing untyped JS makes me feel dirty.”
That preference is not true for others and I feel like that makes the article’s title misleading.
how many months does that translate to in frontend dev time?
Typescript is here to stay. No question.
React has been a thing now for what, six years? And it feels like 80% of FE job opening require React. And no major shift on the horizon.
We went through all the ‘here to stay’ a few times over already.
Cordova, Bootstrap, Backbone, Coffeescript, Angular, Grunt, Gulp, Require.js/AMD, I think we already moved into and out of React Native lol, that whole Mongo thing, everyone had to be a D3 expert almost at one point, isomorphic apps almost became the thing - Meteor, they were all here to stay.
The question wasn't addressed to me, but I'll answer anyway. I started in 1993 and released some widely used web software in 1994.
In your last paragraph you list 13 technologies that supposedly "were all here to stay". If you asked me during the heyday of each technology whether it was here to stay, I would have answered "no" to 12 of them, and "I'm not sure" to meteor. I would have been wrong about Bootstrap because it appears to have been here to stay. I would have been similarly wrong about PHP and Wordpress. My bias appears to be to think things are not here to stay.
React hasn't reached jquery status yet. It does seem like it will be here forever but the next generation of frontend tools will look very different. Will react be amoung them? It's hard to make that jump because React is so great now why change it to match the next fad? But if they skip all fads will they miss the boat.
Is react good enough to say we can stop working on it? I don't think we know what react will end up like. It's doubtful it will be around in 20 years like php. I wouldn't bet on facebook being around after laws are passed limiting how they profit.
But perhaps the frontend developer community has accepted typescript.
All technologies you listed were either a framework or something that made you bend your solution around it. For comparison you can add a type annotation to your vanilla JS code to start using TS goodies.
Comparison to Closure Compiler would be more fitting, but it was a bit awkward and it never achieved a significant fraction of TS's adoption. It probably is still used, but there is no competition between them. Also it never had as good an IDE.
I'm still using Angular at work, and I rather like it. If I needed to make an SPA outside of work I'd probably use it over React at this point. But that's a web framework, and those seem to come and go with the wind.
Dart was a push by Google but went nowhere.
TS drives Angular, has first-class support on React and soon in Vue. Most libs have TS typings. Nextjs (amongst others) provide easy TS integration. It’s being pushed by M$, C# and Java like seem to like it and Enterprise (tm) adopts it.
It’s an entirely different beast.
I am not opposed to Typescript, but I am trying to show that we’ve been here before many times.
Sorry for the sarcasm, I've been trying to learn web development for some months, starting with the basics (HTML, CSS, plain JS) and slowly adding more modern frameworks (Bootstrap, NodeJS, ...).
The course is a few years old already and it feels like 80% of what I learn is now completely irrelevant. I just wonder how frontend developers keep up with that pace.
If I'd write a blog, I wouldn't want to spend half of my time into refactoring and migrating to newer versions, frameworks, etc. But maybe that's just me.
You learn the newest hotness right now (and hope you're right), evangelize it like a Southern Baptist at a tent revival, ride the wave for a few years until it's obvious the wheels are coming off in one of the three or four predictable ways, then pick up the new, new thing and pretend the past never happened.
It helps to change jobs every nine months or so; otherwise, someone will ask you to do something to that ancient archaic legacy stuff. Nobody wants that.
It's a full-time job. I have a cynical theory that this pace is beneficial to webdevs, because as long as they can keep convincing their employers and customers that they need bleeding edge frontend tech, they can enjoy their absurdly high salaries (as compared with the rest of the industry).
Understand the principles behind these frameworks, see that they hit just some point between conflicting tradeoffs, understand problem domains and how they interact with these tradeoffs. It's not like jQuery is accomplishing something fundamentally different than React, it's just that they make wildly different design choices that have implications on composability, maintainability, etc.
After you've learned a few of these (and the principles they are built on top of), you'll understand that it's going to be pretty easy to learn the next 10 of them.
Don't mean to pick on the author, but these sorts of comments scare the shit out of me. React is fine for what it was originally billed as (a library for building UI components), but the way people use it to take over the entire web stack is bananas. Definitely not needed for a static blog, LOL.
P.S. Use LitElement anyway, not React. The future is Web Components.
Writing posts in Markdown is also totally reasonable, as is wanting to support small amounts of interactability in future posts. A couple of comments mention that you could just add raw HTML to a Markdown file and call React from there, but that doesn't solve the compilation problem. A lot of comments also missed the desire for interactivity. It's for a developer blog! I'd love an interactive inline demo or explanation!
The blog title might have been a little overstated (the ideal tech stack), and the "zero memory of how we used to build forms in the pre-React times" isn't a great look, but I do think the actual content is solid.
This is the total opposite of overengineering. The stack the author is running is way simpler than one where you have to spin up a webserver, database, caching solution, etc...
If the blog is not much more than a .PLAN file, sure is overkill. But having access to a DB and programming language opens up a few possibilities – and cleaner code compared to hacking some bash scripts doing text manipulation magic.
Now, starting with a database from day zero? I'd say it is a case of YAGNI. Don't add stuff you don't need now. If you need it in the future, then add it. But don't go paying for a hosted DB if a SQLite would suffice.
Oh, and even then, a database would be more useful for the site generation step. Having a DB being called for every page rendered is a recipe for going down with HN traffic (or Slashdot in the older days).
Being able to save anything and retrieve can be useful.
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:
What a wild ride it's been.
Yes yes, old man yells at cloud etc, but I'm a strong believer in "less is more".
cat header > index.html
cat page >> index.html
cat footer >> index.html
cat header page footer > index.html
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.
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.
However, something that requires more functionality - syntax highlighting, tags, version control, easier deployments - I recently switched to Markdown + Hugo. 
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.
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.
Around the same time, Vladimir Agafonkin (perhaps in response to the above??) released tinyjam, https://github.com/mourner/tinyjam, which bills itself as "an elegant, zero-config static site generator in 100 lines of code, an experiment in radical simplicity."
Maybe the above two links will resonate here :)
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.
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)
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 can take a look at our client libraries  and at this sample  for now. The js client is the most complete one.
From the sample:
Client initialization: https://github.com/Special-Tactical-Service/wiki/blob/master...
Reading an article: https://github.com/Special-Tactical-Service/wiki/blob/master...
If you want to intermix markdown and react, check out MDX. You can write a file that’s 99% vanilla markdown, and just drop in a react component at the appropriate point.
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 think I'll keep it at Hugo for now, with just HTML and CSS.
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!
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.
I'm still bloated, but performance is a lot better. Thanks for the link!
Still using Jekyll.
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.
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.
Once it’s set up it’s just markdown, no ruby required.
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.
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.
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."
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 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.
Haven't yet seen a reason to switch to anything else.
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.
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.
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.
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.
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?
I am also using a CMS instead of just plain markdown - in this instance it is NetlifyCMS.
Netlify CMS is the perfect go-between of a fully-fledged CMS, and a much too basic static site with just markdown - I dislike the experience of writing markdown and would rather use an editor.
With NetlifyCMS - the blogging flow is as follows:
- User logs into NetlifyCMS
- User updates content
- Content is 'pushed' to the repo as a commit.
- CI / CD picks up changes on master branch
- CI/ CD publishes changes
- The site is updated!
The example code can be found here: https://www.netlifycms.org/docs/nextjs/
It is extremely simple to get up and running - but also offers great flexibility if, as the author has stated, you wish to use your website to demo components - visualise data, anything custom really!
The only difference with my implementation is instead of using the `public/` folder, I created an 'admin' folder within 'pages', with an index.js file for the HTML contents, as referenced here: https://www.netlifycms.org/docs/nextjs/#adding-netlify-cms. The only reason being, I didn't want to have to specify '/admin/index.html' every time i want to edit the content.
My only gripe with this blog post - is its insuniation that it is 'ideal'. I think its pretty clear from the post, it is only 'ideal' for the author. Unfortunately, the HN community has taken the opportunity to rip apart the authors opinion - which is disappointing. Thanks for the content, Colin!
NetlifyCMS looks really cool. It definitely took me a while to come around to writing MD directly (basically until I discovered VSCode's hot-reloading Preview), but I understand the appeal of a rich editor.
I'd definitely get rid of the word "ideal" if I could post this again It attracted a little (read: lot) more vitriol than I expected. I submitted this right before going to bed so by the time I woke up it was too late to edit the title.
I think from the context of your writing - it was fine. I found it pretty clear it was from your 'personal' view. As they say however, all publicity is good publicity - I look forward to any more content you will be posting!
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'm perfectly happy using Hugo + git hooks. It's easy as
1. Write a post in markdown
2. Commit and push
3. A post-commit hook runs hugo. Refresh your page and the post is live.
The friction to create a new post needs to be as low as possible. I can't get it any lower than this.
It's dead simple to set up too - https://blog.nindalf.com/posts/setting-up-this-blog/
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 :)
Can someone comment on the latest version of Next vs Gatsby?
I have one site running on Wagtail (Django) for the past 3 or 4 years, and two other sites currently built with Hugo (LotsOfOpps and BuiltRigs). I've put together lots of other sites with Hugo, Wordpress, and other Django CMSes.
The Wagtail site is definitely overengineered, and I usually dread making updates to the code a few years on.
I've messed around with other generators like 11ty and Gridsome (both pretty cool projects!), but I mostly keep coming back to Hugo. It's pretty simple, and so far I haven't had to worry about a 3rd-party package breaking stuff.
I just started the same type of project: a personal website with a homegrown framework that makes everything easier. It was hard! Picking these technologies with no constraints and imperfect knowledge is tricky. Ultimately, I went with tools I wanted to learn more about, but that I was pretty confident would get me to a static site.
This ended up being webpack + loaders/plugins (some homegrown). Plus I'm writing content in Google Docs and exporting it to HTML after being inspired by the wave of Google Docs articles on HN.
Like Colin, I eventually want to put animations or data transformations on there. Fun process.
But hey, I guess it's a lot more fun to talk about how somebody's hobbying wrong and they should've used Jekyll or Hugo or PHP or a shell script or a Python script or a Makefile or just hand-write everything and use framesets like it's still 1997 and the concept of user experience hasn't been invented yet. Carry on.
Everything has its place, and I am not sure react+ts is the right thing.
(and this was exacerbated by the post title.. The current title is nice, but the HN submission title made it sound like this is ideal for everyone)
Everything is quite outdated, mind.
More concretely: I try to address that in my list of criteria section under "React + TypeScript". I couldn't shake the feeling that doing anything complex in the future was going to be even more complicated if I have to fight against an SSG framework to do it. I also address the fact that currently this is wildly overengineered currently :D
It takes less than ten seconds to type `npm update`.
It took me 4 hours to redo a static HTML and CSS mockup, learning a bunch of great new things about CSS Grid and Vars... then another week to convert that static into a Gatsby static-generator site.
It's sort of insane how over engineered we've gone on this stuff. HTML and CSS are pretty great tools for a blog. We can skip the React, GraphQL, etc.
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.
Also, to be fair, it's my second post.
Precisely. If it was your first post, I wouldn't have posted that. Also, please don't take it the wrong way, this is just humor. I appreciate you sharing knowledge with the world, it's something I haven't done in a long while so I respect that.
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.
Built on Laravel + Vue + Tailwind.
It's trivial to add React into a Markdown page, since Markdown allows you to include html tags.
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%.