State of Self-Serve Website Building in 2020
sprune.com
sprune.com
It's basically the missing glue for the manual operations you would normally do on your own computer if you went the Jekyll/Hugo static site generator way. But you don't need to maintain a development environment on your machine.
After the initial setup, a non-developper can use forestry as easily as Wordpress.
The past few years has completely changed the way I execute this strategy. Leaning heavily on products like these that allow us to develop software with very little or sometimes no code at all. It's nuts what you can build in a few days.
Discovering Rails in 2009 was the last big shift for me in this way, with tools like scaffolding to build out the skeleton of any dynamic CRUD section in a few seconds. Still, it wasn't uncommon to subsequently spend days or weeks getting specific sections of the site to reach parity with designs.
Some people talk about how this trend is a threat to web developers like me. While it's true that it's never been easier for anyone to build high-quality dynamic websites, that position completely overlooks the benefits for traditional web developers. This new toolchain is like having superpowers for a very specific type of development. Pairing that with solid knowledge of web fundamentals and the ability to "grow up" beyond the limitations of the system is a recipe for delivering work faster than ever before. For most early-stage startups, fast & cheap is #1, but if you can deliver quality on top of that, you're golden.
One of our coolest features especially for the HN crowd is a code editor built into the browser that updates the website in real time.
Something that I felt was missing from all the other website builders at the time and still is.
Zola is written in rust, has a single binary, great support for multilingual sites and a bunch of great features compared to other static website generator[1].
[1] https://github.com/getzola/zola#comparisons-with-other-stati...
It feels pretty restrictive sometimes (probably my lack of understanding what to do) but it is simple to use and it's easy to tweak the themes.
I just checked for Hugo, and it certainly has so many more compared to Zola. Something to keep in mind for future, but I am more than satisfied with Zola for now.
I've taken two different approaches: 1. Maintain a local WordPress instance that builds the site using all the theme/plugin magic that WordPress is famous for, but have a static-export of that into Github -> Netlify.
2. Small sites being powered by Cloudflare Workers - using pure JS.
The jump to React.js / Vue / Go / Ruby et.al for an old PHP/HTML/CSS hack like me was too hard (and I tried them all!), so I settle for WordPress (the devil I know) for the build/back-end, and incorporate and embrace static on the front end. This separation is key - in my mind - for speed and security.
I think one of WordPress' biggest issue is that I have not really found a good how to to really set it up (they advertise their "5 minute deploy", but it leaves a lot of things lacking). If I set it up, I have a series of articles I used to set it up.
The other issue I've anecdotally seen is when someone installs a bunch of plug ins then gets into a dependency hell when trying to update.
The people (probably like me) who would call WP the devil is people who have had to maintain 15 year old intertwined WP instances riddled with outdated portions of the platform, insecure hand-coded modifications, terribly functioning custom plugins, horrible data hygiene for exporting and re-appropriating content, and terrible, clunky infrastructure setups. WordPress makes all of those easier, and encourages them when it’s anything more than a simple blog or product page or something. It’s easy for new features to be requested and sold and horrible to sell fixing any of the above problems. It goes on deaf ears once people get used to the web products just being there. And once clients get used to the blog interface, you dare not recommend any change no matter how good for the business.
I’ve seen smart, talented people just give up in the face of that kind of monstrosity, shelve all their plans for improvement and just buy into the duct-tape patch jobs of yore and developing one-off plugins for every request because it’s fast and needed to be done yesterday because something else has been requested or broken.
After my rambling let me reiterate that Wordpress is great for its intended application. But it is horrible for the extrapolated purpose many companies and teams have bent, twisted, and surgically manipulated it to be used. It’s not Wordpress’s fault exactly. It’s those who’ve recommended wp as a tool to solve problems it wasn’t meant for, and industry that has built up around that to make it appear as if it’s a viable solution.
The plugin ecosystem however opens you up once again: here the devil is in the details. Every plugin you install might be the giant blinking red light that says: hack me, steal my data, etc.
On balance though wordpress is pretty good these days.
In truth, most software at any given time probably has serious security vulnerabilities that just aren't as obviously exploitable, and I wouldn't say that the volume of published exploits related to Wordpress is indicative of a poorly managed or written piece of software.
The demo site uses Algolia though https://mmistakes.github.io/minimal-mistakes/
Comments, contact forms and other features that "creates" content are more difficult.
But they assume some context, which I’ll give you: At compile time, Gatsby is capable of making a list of all the posts on your site that you can query with GraphQL (at compile time) or use in the JS of your pages. In fact, saying it makes a list of all “posts” is selling it short, because Gatsby can store and manipulate arbitrary data structures. So if you’ve got a Documentation site with a table of contents and three levels of content within it... that’s all queryable at compile time too. It’s extremely flexible.
Now, it’s not like your pages will actually be using GraphQL to query a DB when the user arrives on the page: all the data is basically “baked in” to the page when it is compiled. But for a static site where the “data” only changes when you add/change some content and recompile, this works really well.
https://duckduckgo.com/?q=site%3Ayour-site.tld+the+user+search+stringWhat is the simplest way to get these single file HTML sites hosted? Preferrably without having to teach another tool or language?
We have a code editor built into the platform.
A lot of our customers learnt basic HTML/CSS using it.
And it is something I wish existed 9 years ago when I first started learning HTML at university. Design is a huge barrier when learning HTML as everything looks terrible.
By using Bootstrap and a website builder you get to create great looking websites easily.
use aws command line tools to sync to your local repo
easy way:
aws s3 copy index.html s3://<mybucketname.com> --profile <awskeys for this client>
hard way:
cd <mywebsiteroot dir>
git pull ## if needed
<website builder> ## i.e. webpack, angular, whatever
aws s3 sync public_html s3://<mybucketname.com>/ --profile <awskeys for this client>
I don't even truly know Git but easily got the hang of committing via Github's Desktop app GUI.
edit: Oh right self-serve means self-host, not just self-build.
The single big plus for me is, that it allows me (as a DEV) to provide the typical non-DEV user (aka my mother) with a simple, non markdown user interface to edit and update the page on her own.
Same here.
Funny thing is, just a week ago I read that some people would say WP is "no code". I had the impression almost all of WP's success was based on countless web agencies coding customizations for it.
I also like Tachyons [2] for utility-based classes, which is pretty small (14kB gzipped).
[1]: https://tailwindcss.com/docs/controlling-file-size
[2]: http://tachyons.io/
http://blog.almonit.eth.link/2020-05-21/Introduction_to_Dweb...
Squarespace but with an actual layout editor like Word.
Ironic that we are moving back to static websites, but I think that's actually a good thing.
What I'm looking for is a lean and nice CMS that comes with some batteries included, and can generate good static sites and also work for dynamic ones.
I have recently switch from Wordpress to Hugo with Gitlab and I never complain about speed and performance anymore.
11ty is gaining more attention and it looks like a good choice for the one considering static site.
A Go app that doesn't need to hit a database has response times nearly as fast as static, and you can still do things like including related content ("more like this") at the bottom of a post, or pagination/filtering on the index page.
One of the good things about Wordpress is the familiarity to it from the people who have to use it. (Authors/Editors/Contributors). (Though, I'd say Gutenburg might stir that up a bit).
Also, once you learn how to write plugins, the sky's the limit really.
I just make sure that my images, and assets, aren't "too big" and add them to git. If they were >1Gb then I might reconsider, but the git-repository which contains my blog goes back to 1st January 2005 and is only ~50Mb in size so it hasn't been a real concern.
The original idea of Ghost was made by John O'Nolan, then a lead dev at Wordpress Foundation.
Whole setup: https://github.com/maple3142/Blog
They all have a templating language, and sometimes I just wanna write a quick function to do something like read a file, chop something out and wrap it in some html -- something that would take 8 lines of Python.
Though, we switched over to Next recently to take advantage of SSR.
https://www.joelonsoftware.com/2001/10/12/what-does-citydesk...
The site pagews.com is generated using the service for example (including capture forms back to the sheets).
Having hosted a ghost blog before, this is the wrong way to think about it. You'd need to run a separate instance of a database which costs $15 on Lightsail with periodic backups.
Running the database instance on the same $5 machine is one disaster away from a lot of pain. It is so much better to use github pages or static page generators over Netlify, since a database really seems like an overkill for simpler blogs.
Someone wiser than me once said [0]: Why are you doing all this? Your entire database fits in RAM.
Depending on your requirement you can use any instance of MySQL/MariaDB - managed or self-managed. You could run a separate $5 MariaDB DigitalOcean droplet. Ghost Foundation provides their 1-click Ghost droplet bundled with MySQL, but you're not restricted to it.
And yes, SQLite is also an option.
Suggesting a "need" to run fault-tolerant database operations doesn't quite concile with running it in RAM only.
Yep and then you'd be subject to what they call https://en.wikipedia.org/wiki/Single_point_of_failure.
> Suggesting a "need" to run fault-tolerant database operations doesn't quite concile with running it in RAM only.
The wisdom is: You don't need a database at all to avoid SPOF. Use static pages and let Netlify and others cache them in their CDNs world-wide ("RAM").
> Ghost Foundation provides their 1-click Ghost droplet bundled with MySQL.
And how much does that cost?
It's a blog, not a mission critical site. I suspect MOST blogs get so few views that it really isn't a huge deal. If you have the need for more stability and availability, then paying extra isn't a huge deal.
There, that was my point: One could pay exactly somewhere in the region of $0 to Netlify and still have that.
To your point: Yes, Ghost is much more than Hugo / Jekyll will ever be, but then again, most people aren't building a News site to actually want the features Ghost has to offer.
I mean, there's absolutely a market for software like Ghost and WordPress (or they wouldn't exist, especially in WordPress' case they absolutely dominate that market), but if you're the kind to run Ghost with SQLite then may be you should instead give static site generators a look.
It offers a good experience for e-commerce and blogging.
As soon as you're self hosting now you're doing server admin etc and that would be outside the scope of the article.