Get Static
meyerweb.com
meyerweb.com
1. Write your article in Microsoft Word.
2. Save as 'Web Page, Filtered'
3. Upload/Place in html folder on Webserver.
This solution is 100% wrong for us technical people, but for non-techies who just want to get the information out there it's a really good option imho.
https://github.com/therealglazou/bluegriffon
I guess the epub part isn't open source?
It actually is a half-decent solution for static HTML generation. Wish I knew that in the past.
I taught a class (10 people, master's degree, journalists) about web and publishing, with no prior experience. We used gitlab pages and hugo, with the intent of getting some hands on experience with web tech and owning an actual project and website.
Markdown writing and HTML/CSS hacking went smoothly but most of all, students were impressed by the experience of getting a website online, with their content, in a matter of minutes, all in the browser.
In comparison, registering for some HTTP/FTP plan somewhere and using a FTP client can be quite daunting.
There are some "dropbox based" website generator services that could make the publishing workflow even easier.
I just told him when to use the commands git init, remote, add, commit, and push and what the workflow looks like.
As a couple of people have mentioned, there is a drag and drop feature. How did I miss this!? Anyway it would have saved a couple of minutes of explanation.
This really really isn't anywhere near true anymore.
Also, as mentioned, the complexity of bullet point 3 is enormously understated. MANY MANY SaaS options like Squarespace or even Netlify or Siteleaf are in themselves much simpler than your step 3.
I am sort of surprised at how talk about static websites is only becoming top of mind as of recent. When I think of static websites used with success, I always think of Obama's campaign, it was built with Jekyll. There was quite a bit of talk around static websites around that time, and it seemed like quite a few people were on-board with the idea.
When people talk about static website generators though, I don't think many people are talking about tools like dreamweaver.
Had PHP hosting not got so cheap so quickly and subsequently early PHP CMSes become so common, it's possible there was an alternate universe where Dreamweaver or FrontPage continued to evolve into really interesting static site generating Content Management Systems.
1. If two users access the same page, do they see the same content?
2. How often do you update the content of the website?
Cases where the content is dynamic are social networks (FB, Twitter), search engines (Google, any ecommerce search feature), and any logged in content (cart, likes, friends…). For the latter, I've seen cases where the logged in content is only fetched via JS after the initial page load. This hybrid solution probably saves a lot of bandwidth.
The reason to ask yourself 2) is to know how long, as a content creator, you are willing to wait between updates. I can imagine that updates to a blog post or a hospital "about" page are allowed to take several minutes. In that case, static websites are favourable.
I guess the waiting time is correlated with the amount of updates: the higher the amount of updates, the shorter the waiting time you would want.
The reason why CMSs like WordPress are still popular is because of their ease of use. I've had several clients ask me specifically for a WP solution. I guess the issue is that it's hard to detach the dynamically-created content from a dynamically-served website. There are cache plugins, but I'm still looking for a custom solution where WP is only used as a non-public CMS, that then, at a push of a button, gets generated into a static website (or even a Gatsby one).
Given those criteria, I think a better solution to these problems would be some sort of caching layer, either built in to the CMS or perhaps a different server acting as a reverse proxy.
Instead of doing the obvious thing and build a database connected web application hosted in the cloud; I opted for a local application that generates static files for customer ordering, uploads them to a web server and polls for orders. On the server there's a simple PHP script that writes a chunk of JSON to a file when the order is created.
The main motivation was to allow them to continue taking orders in the restaurant and perform maintenance even if the internet connection isn't working. Generating files also simplifies the implementation of customer specific customizations.
And since the database isn't customer/web facing any more and therefore doesn't need to scale beyond a couple of simultaneous users, I opted for a simple file based solution.
The fact that the customer order part runs blazing fast is a nice bonus.
i one time made a html version that takes a query. js finds the line matching the text then hides everything before the previous seperator and after the next one. if a key is pressed it seeks the next match, if there isnt a (next) match foo-07.html forwards the query to foo-08.html which might not exist (haha) it shouldn't be so hard to update the js with a max value or check if it exists first but without such luxury it worked amazingly well for the amount of code involved
Still a lot nicer than paying for complexity you don't need before the system has even proved useful.
So the "local application that generates static files" is the one used by employees of the restaurant when a customer makes an order? Or is that used just for maintenance purposes when changing formats of the orders customers can do. But what I was confused most about was what "polls for orders" meant in this context.
The other thing I was confused about was the generation of "static files for customer ordering". So the application generates these files, which are presumably an html form (and/or corresponding PHP script) and uploads them to the server. And the server's html static pages that are used to order are accessed either locally on the box itself or through another computer on the local network connection (since you mentioned that it can run even when internet is down). Is my understanding correct?
Polls for orders means it reads the json-file that is appended to via the php-script when a customer makes an order from the web interface and imports new orders into the local database.
The application generates json-files, which are then read by static html files. This makes it easier to test with stub data and allows shipping the html/css to a designer if/when they want something nicer looking.
The html files and generated json data is never used locally.
I would suggest this route for organizations that are already using dynamic solutions like Wordpress.
> I can’t tell you how best to get static—only you can figure that out.
Okay. Is this helping? I guarantee anyone responsible for uptime of critical services is pretty overwhelmed right now, and not going to be immediately receptive to calls to make huge, abrupt architectural changes without any guidance.
Edit: this is how it should be done[1] (HN thread[2])
[1]: https://mxb.dev/blog/emergency-website-kit/ [2]: https://news.ycombinator.com/item?id=22657571
One can only hope that in the coming months, websites focus on reducing their bloat and catering to audiences with restricted bandwidth (if streaming services are already doing their bit to reduce traffic, so should others).
For truly static websites, the ones without a lot of dynamic or frequently changing content, what good CMSes exist that can easily adapt to or be used with SSGs (for self-hosting, not using Netlify or some other site)?
Generates static files while also providing an interface for edits.
1. Take a Markdown document
2. In PowerShell: ConvertTo-Html -Body (ConvertFrom-Markdown -Path .\README.md).Html -CssUri "stylesheet.css"
That results in a complete and valid HMTL document that can be published anywhere with its assets.
ConvertTo-Html: https://docs.microsoft.com/en-us/powershell/module/microsoft...
ConvertFrom-Markdown: https://docs.microsoft.com/en-us/powershell/module/microsoft...
But in the worst case it can take minutes and hundreds of megabytes to update my blog to S3, even for a simple text change.
Not amenable for quick updates, or updates in the field.
You can add layers of tools to improve it, of course. But then you're back to it not being much different to wordpress + CDN.
If your backend would be something else, you could use rsync to only move the changed parts, without uploading everything again.
If you want to edit it online and use CI, you would maybe need to cache megabytes of state between runs.
And that's for media files. For renderd HTML files, the smallest change could require rebuilding most of the pages.
Unless I missed something obvious, that's quite a trade-off.
It's not a criticism per se, just something from my experience which contradicts the orginal post.
I have written sites using CMSes that load lickety-split. The trick is to use simple, “bald,” basic themes, very few plugins, no JS libraries, and hand-write your own CSS.
Depends on what the site does, and, most importantly, where the content originates.
That said, Eric Meyer rocks, and it’s always a good idea to listen to him.
It works because the read/write -ratio is so heavily skewed towards reads.
It amazes me why every site seems to need the latest and greatest framework just to tell me a paragraph of text.
We have to stop teaching junior devs react and start teaching them more static site generators.
I personally use hugo and love it.
I’ve seen plenty of new devs take this approach.
You can turn some CMS content into static content, but it's pretty limited. Even something as simple as a contact form is going to fail.
Moreover, “getting static” is nice and a fine way to improve performance, but it seems to me that really the goal should be, “be available.” What’s wrong with using a CMS or anything else as long as you have the capacity to meet demand?
Like, from the practical perspective, if you have a blog with content that is requested 1000 times per minute, but updates once per month (23 microtimes per minute), why on earth would you setup a database (with geo-redundant replica, of course) and run overly complex code to render the same HTML over and over every single time it's requested? The only possible answer here is being oblivious of other available options, and I believe author of the post is trying to raise awareness that there is another option.
That's not an excuse for terrible performance either way. At this point it's trivial to handle hundreds (or thousands) of req/s on common hardware if you just choose the right software to run.
You can you lamba/cloud functions as webhooks for your CMS to ping when a rebuild of the static site is necessary. Netlify helps you set this up easily.
Even if you updated a dozen times a day, it would take only a few minutes or less to rebuild and deploy.
edit: yes per-user data is a primary use case for dynamically rendered sites.
But public pages that all users load make sense as static if possible
That's what caching is for.
That's not how a real audience works. If a web site overloaded, user will immediately skip to the next google result.
At times of panic you want to convey information as fast as possible and as efficiently as possible. Five nines availability.
What I take exception to is the idea that static pages are the one true way to achieve this goal, and TFA’s pronouncing that not using static pages is irresponsible.
Which means it was made into a static page. On the CDN. Wooo, progress!
> get it down to static HTML and CSS and maybe a tiny bit of enhancing JS, and pare away every byte you can.
HTML is a language used for building your DOM. CSS is a language used for styling. JavaScript is also a language that can do those things, and focusing on the language used isn't going to help.
If the goal is to save space and power you can do it much better with JS. A lot of server side rendering, html caches, and static content is focused on good SEO and low latency, not small download size and power consumption.
You can fit a much smaller download into a stripped-down Gatsby site if you have a nontrivial amount of content. It also makes things like serving only much smaller versions of any images way easier. You can go even smaller with vanilla JS if you want.
Never use a Turing-complete language to solve a problem that's already well-solved with a non-Turing-complete language. Especially when that non-Turing-complete language is already present on the client's machine. Most especially when you're talking about static sites for essential public information.
On the other hand, if you need a site to work even with spotty internet access, JavaScript is probably your answer.
But these are generalities, you can probably find a thousand exceptions. It is hard to give truly general advice because there are so many exceptions.
That said, there are many good reasons to have static sites when you have to scale up big. They typically can handle very large scales, and caching them the super easy.
Whether or not that actually meets the requirements of a site is a completely different story.