It's an interesting piece, and lots of good reasons to "go static".
But. They're developer reasons.
What almost everyone who piles into this support of static stuff seems to completely ignore is the audience here.
Who do you think is editing your website? Amy the developer who has no problem committing stuff to Git or learning Markdown or Dave, who is a marketing manager and spends most of his life in Word writing press releases and social media posts?
The entire point of a WYSIWYG editor is that it doesn't require any developer experience.
If you genuinely think a corporate website can be run out of a Git workflow or a requirement to learn Markdown, you're basically in the wrong room. This is the whole "IT bottleneck" that content teams have been battling for years: it's back to the early 90's days of "yeh, we want to update our homepage but we need IT to do it for us".
Somewhere in the middle is the holy grail: performant sites that are also editor friendly.
I keep coming back to this: we keep underestimating our coworkers, users, bosses etc.
Even as an engineer people keep on underestimating me (although sometimes they overestimate me : ). Here are some examples:
- telling accounting a number of times that they've forgotten a rather large PO.
- telling a network vendor they have a huge hole in their firewall only to be ignored until I contacted one of their huge customers which I also knew. They could have saved themselves a good deal of embarassing attention I guess.
- etc etc
Last year at JavaZone theee was an interesting talk by someone who was an early employee at a crowd funding company. He was a non-dev but talked about how he enjoyed being able to update copy in the web app (not just front page IIRC) directly after the devs had set up git, an editor and explained the basics.
If you are making the next google you'll want things to be extremely easy-to-use.
Making a google.com level UX for business apps might be smart. Or it might be insulting.
I've tried Gatsby on a couple of occasions due to the page load speed promise. With netlify it seemed like using it almost made sense.
I do see the compromises wp puts us into but for me, the benefits of static seem awfully abstract at the end of the day. If you want me to buy it, please show me an authoring experience I actually want to live in. I haven't seen one yet.
It's not about over- our underestimating people. It's about whether the technocentricity you are selling is worth it. For some of us, it is, sure.
For one, I just hate writing with markdown. Compared to WYSIWYG (i.e. just writing), markdown's syntax is a distraction. Writing is both visual and storytelling to me, why should I exclude the visual to a separate stage of the process? Just doesn't make sense to me.
the benefits of static seem awfully abstract at the end of the day. If you want me to buy it, please show me an authoring experience I actually want to live in.
Authoring is about input to the system, static is about how the contents is given to the visitor. There is no technical reason a rich author experience cannot be coupled with a static approach to content delivery.
In fact, the article focuses mostly on page bloat, not so much server-side processing. The amount of bytes a Web page weighs in at should mostly depends on its contents, not on the author tools used to create its content.
How would you allow a user, while creating a blog post, to add commenting to the post in a way that enables progressive enhancement i.e. doesn't require javascript, with static site generators?
If you can't, what is your justification for the sacrifice in accessibility?
If you can fulfill this basic requirement, please show me the experience of using the system and show me how it is better than wp as a whole.
An iframe is a possibility; the fixed box size is an user experience tradeoff. I really believe in the vision of a read-write web, i.e. for me the default should be all involved parties being able to comment on any given content.
Of course this should be possible to turn off for certain content and moderated, but it still seems artificial to not have the discussion on the same page, compared to the original post. HN is beautiful, for instance. :)
Please elaborate? Not sure what you're referring to. In any of your paragraphs, in fact.
Isn't the ascetic authoring experience provided my markdown just as much a result of deciding on which set of personal values are and are not important for your users?
Although I tend to agree with you, some business apps benefit significantly from a "dumbed down" interface, as it's easier to provide business rules and validation layers when input is more constrained. I've worked on systems that take an Excel spreadsheet as input and providing decent error messages for every edge case is nigh on impossible.
> I keep coming back to this: we keep underestimating our coworkers, users, bosses etc.
guess it depends who you work with. Had a recent experience where I spent half an hour for an user who has trouble with basic filesystem navigation - even though he's been using computers since close to three decades.
I don't think that a static website necessarily requires a developer workflow that a marketing manager can't use. You just need a tool that turns things into static HTML once.
Completely agree - with this and previous couple of comments. The frustration for me is not that it can / can’t be done, it’s the fact that developers and content people are still (I’m 20+ years in the web industry and this was a problem in 1995 too..) not properly understanding each others’ skills and needs.
The more generic point here is that developers build better tools when they properly understand their audiences. In this case, the audience is almost always “a non technically skilled editor”.
IMO most young technical startups would do well to remember this too.
Co-founder of https://forestry.io here. The author describes how writers can use branch logic (i.e. merging as an editorial tool). We're currently building multi-branch support into our CMS for just this. If you want early access, reach out to scott[at]forestry.io
> What almost everyone who piles into this support of static stuff seems to completely ignore is the audience here.
Checkout Jekyll admin, it provides a simpler interface than Wordpress, but with WYSIWYG editing capabilities for a static site. It is very powerful and can be designed to scale large-sized projects.
What do you think a product which basically turns Microsoft Word into something like WordPress?
Basically it's a file manager for .docx files, but more importantly, it can generate static site* out of your Word documents, and style them nicely with bootstrap.
Yes, that's something I'm working on and I'm close to the end of a beta release! https://docxmanager.com/
Somewhere in the middle is the holy grail: performant sites that are also editor friendly.
Remember Dreamweaver? Made great static sites. Good WYSIWYG editor. Nothing but static pages on the server. "Round trip HTML" - it took in HTML, edited it, and put it back out. If you created the HTML with Dreamweaver, it could put in some comments which told Dreamweaver not to change certain parts. This let you have page templates.
We can't have that any more. CSS is too much of a mess. The era of CSS flush/clear/div layout broke WYSIWYG editors, and the web took a big step backwards. We went through the "tables are bad" era, and eventually got them back as "layout tables". It might be worth defining a modern subset of HTML/CSS and having a Dreamweaver-like editor for it.
Markdown? Markdown is comparable to HTML 1.0. Or BBcode. It's gaining features and complexity as people demand more HTML features in Markdown.
I think everyone should learn some basic HTML. You still need a professional for design and templates though. If you already have an example page of what you are going to publish, its not hard to figure out the semantic elements. I think CSS helps as you only have to figure out what elements h1 p img, etc to use and the CSS will take care of the layout. My experience with visual editors CMS/ builders is that they are more complex and harder to learn then semantic HTML. As a web programmer that can also make some design, I hand code CSS gradients etc and use SVG for when CSS becomes too hacky, Im a bit slower then the Photoshop wizards, but then its already converted to web format, and as everything is hand coded its small too. Its always frustrating when another designer edits my SVGs in Photoshop blowing them up 100x in unreadable blob riddled. Just as when back in the days some other designer would edit the page in Dreamweawer.
Yeh, asuming we are still talking about hand written html and css, and not about auto generated and minified source. Complex layout tend to turn into a div nest. But most web pages can do fine or even better without the complexity - and get responsiveness and mobile support for free.
I work for a large organisation and a small part of our website is still maintained by a couple of non-technical editors using an old copy of Dreamweaver. Works great, though the sysops complain about keeping FTP going. Eventually they'll be moved onto our more modern but complicated CMS.
I agree. From my perspective, I try to make the most secure website but have to know that the end user will be our marketing team.
I've tried both static only and WordPress.
Both are good for each side. BUT what I've found to be the best compromise is Webflow.
Honestly; it's such a great tool. It produces website in as pure HTML as possible (you can export the Webflow site as pure HTML/CSS/JS. Or have Webflow host it on their S3 and Cloudfront setup with AWS. The best part is that the CMS editor is really good and easy for the non techy.
The designer tool is great for non tech too. It's simple. But at the same time has the functionality to be flexible for tech developers.
Now it's not perfect. But I think it is the actual real balance between both.
One might say that whether the website is served statically or dynamically, is orthogonal to the content editor's user experience. You can have a WYSIWG editor and still serve generated content statically.
Unless there is a compelling reason, don't do at runtime what you can do at build time.
Gatsby can pull content from WordPress[1], so nothing changes for your content workflow but you get all the speed and security benefits of a static site. It's a pretty common workflow these days.
But. They're developer reasons.
What almost everyone who piles into this support of static stuff seems to completely ignore is the audience here.
Who do you think is editing your website? Amy the developer who has no problem committing stuff to Git or learning Markdown or Dave, who is a marketing manager and spends most of his life in Word writing press releases and social media posts?
The entire point of a WYSIWYG editor is that it doesn't require any developer experience.
If you genuinely think a corporate website can be run out of a Git workflow or a requirement to learn Markdown, you're basically in the wrong room. This is the whole "IT bottleneck" that content teams have been battling for years: it's back to the early 90's days of "yeh, we want to update our homepage but we need IT to do it for us".
Somewhere in the middle is the holy grail: performant sites that are also editor friendly.