Static web – back to the roots?(blog.callr.tech)
blog.callr.tech
Static web – back to the roots?
https://blog.callr.tech/static-web-roots/
108 comments
Can they figure out and are they comfortable maintaining their site with Jekyll now, like including images into their posts? Are they in for a surprise when you leave and they need to make an edit?
You usually can't just replace Wordpress with Jekyll and call it a day since non-technical people need to maintain the site. Though it's super nice when you can.
You usually can't just replace Wordpress with Jekyll and call it a day since non-technical people need to maintain the site. Though it's super nice when you can.
They couldn't maintain a WordPress site without him either.
The full story though is they had their Wordpress site done by a company from Singapore who charged them 1000's of dollars for what seemed to be a $50 template from Themeforest. And the worst part was it was hosted on top of a third grade shared hosting provider, with really low memory and RAM and the site would take about 15-20 seconds just to render the page. It didn't even include a year's worth of support which they would've easily gotten if they directly purchased from themeforest. This company then stopped answering their calls one fine day and abandoned them after taking their money.
The site itself was fine, until one day it broke and was completely inaccessible.
So, they were stuck in a limbo and the CEO happens to be my good friend, so while working on another project for him, he asked me if I could help. So, that's how I got incharge of maintaining it for them.
The site itself was fine, until one day it broke and was completely inaccessible.
So, they were stuck in a limbo and the CEO happens to be my good friend, so while working on another project for him, he asked me if I could help. So, that's how I got incharge of maintaining it for them.
Sorry if my original post wasn't clear. I'm running with Jekyll + Jekyll admin for one of them and I use Netlify Admin for another. So, they can still use a WYSIWYG interface to edit their content without having to deal with code.
What about keeping Wordpress under the hood to manage and update the pages, but then generate static pages off that?
I tried this last year for a Wordpress blog with ~1000 articles, and the time to generate the static pages was too long (several minutes) even for routine tasks like adding a new article. Simple things like a "New Articles" list in the sidebar can cause all pages to regenerate. I tried many different approaches (recursive wget, wordpress plugins, intercept wordpress output in PHP with ob_start() etc).
Ultimately, putting a Varnish cache seemed like the only logical answer to speed things a bit more, but that didn't avoid Wordpress security attacks.
For fun though, I built an experimental wordpress-clone dashboard that saved Hugo-compatible files instead, so I wouldn't miss Wordpress' editing features. The result was superb (<5 seconds to regenerate the ~1000 articles blog), but I missed the Wordpress plugins too much to switch to Hugo entirely.
But I still agree with you: "keep wordpress' editing experience, but generate static sites" is a pretty promising direction IMO.
Ultimately, putting a Varnish cache seemed like the only logical answer to speed things a bit more, but that didn't avoid Wordpress security attacks.
For fun though, I built an experimental wordpress-clone dashboard that saved Hugo-compatible files instead, so I wouldn't miss Wordpress' editing features. The result was superb (<5 seconds to regenerate the ~1000 articles blog), but I missed the Wordpress plugins too much to switch to Hugo entirely.
But I still agree with you: "keep wordpress' editing experience, but generate static sites" is a pretty promising direction IMO.
> I missed the Wordpress plugins too much to switch to Hugo entirely.
Do you mind if I ask which plugins?
Also, if you're missing plugins, it sounds like keeping the wordpress editing experience alone isn't going to be enough. The question then becomes, are you missing plugins themselves or what those specific plugins do for you that doesn't appear to be available in hugo.
Do you mind if I ask which plugins?
Also, if you're missing plugins, it sounds like keeping the wordpress editing experience alone isn't going to be enough. The question then becomes, are you missing plugins themselves or what those specific plugins do for you that doesn't appear to be available in hugo.
As someone who does a lot of WP at their day job and has looked into other platforms, plugins like Gravity Forms are indispensable. It is nearly feature complete at this point and I have full access to the underlying code for any customizations in logic or design.
Some hosted form solutions offer features like basic e-commerce which is useful, but then doing something after a submission is almost impossible or everything is in an iframe so customization is limited.
If someone could port gravity forms to Craft, I would likely switch all new projects before the end of this year.
Some hosted form solutions offer features like basic e-commerce which is useful, but then doing something after a submission is almost impossible or everything is in an iframe so customization is limited.
If someone could port gravity forms to Craft, I would likely switch all new projects before the end of this year.
I've been thinking about doing the same myself but with a direct tie-in from Node.js to MySQL to grab the post objects via mysql2... did you ping the WP JSON API for generating posts? I'm just confused as to how that would break things unless there's a serious bottleneck somewhere.
I imagine New Articles list would trigger all pages regeneration in any static setup, WP or not?
Yes it would. But pure static generation tools like Hugo are really fast. In my case, it was regenerating ~1000 articles in about a second, while doing it with wordpress was nearly 25 minutes.
Another similar approach is using “Serverless Pre-rendering” which is a fancy way to say serve stale and update in the background.
There is a demo using Notion as the “backend” which is kind of like Google Docs. I could see this being a great solution for less technical authors who only want to deal with content.
In the end, it’s like a static site but you don’t wait for a build step.
https://zeit.co/blog/serverless-pre-rendering
There is a demo using Notion as the “backend” which is kind of like Google Docs. I could see this being a great solution for less technical authors who only want to deal with content.
In the end, it’s like a static site but you don’t wait for a build step.
https://zeit.co/blog/serverless-pre-rendering
Yes, If you are fine with static pages it probably means that you would be fine using something like Varnish http cache.[1]
There might other options like caching at the DNS level with something like CloudFlare[2]
I don't work with Wordpress but generate static pages sounds like generating a cache, so these two option might be useful if you need to keep Wordpress but want the benefit of static pages.
[1] https://www.varnish-software.com/wiki/content/tutorials/word...
[2] https://wordpress.org/plugins/cloudflare-page-cache/
There might other options like caching at the DNS level with something like CloudFlare[2]
I don't work with Wordpress but generate static pages sounds like generating a cache, so these two option might be useful if you need to keep Wordpress but want the benefit of static pages.
[1] https://www.varnish-software.com/wiki/content/tutorials/word...
[2] https://wordpress.org/plugins/cloudflare-page-cache/
Varnish passes requests through to the underlying site (in this case Wordpress), which doesn't make it any more secure.
If the cache were fully populated (e.g. by spidering the site) and never became stale, then it would be roughly equivalent. Still, I'd rather disconnect Wordpress after spidering, so there's no chance of requests leaking through.
If the cache were fully populated (e.g. by spidering the site) and never became stale, then it would be roughly equivalent. Still, I'd rather disconnect Wordpress after spidering, so there's no chance of requests leaking through.
At some point your Wordpress installation version will be so far ahead that it may break your unmaintained theme eventually. Which is why I avoid this route if I can. It's hard to make promises to clients based off something so fragile.
Well, you have just built a custom theme to support the data from Netlify. I guess you could just as well have built a custom theme for Wordpress to avoid being stuck with an unsupported theme.
The difference is for my use case, Netflfy isn't a full CMS per se, the theme I built is for Jekyll which runs on top of netlify. It's just compiled static HTML files. There's nothing you can hack.
Why would your WP installation version be ahead?
If you're on WP and you forget about your website for say a year, WP version would be way high compared to the unmaintained theme that was built for an older version which would eventually break your site.
This isn't the case with a static website.
This isn't the case with a static website.
Whenever I read the word unhackable my neck hairs stand right up.
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.
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.
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.
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.
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.
If these are separate to you:
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.
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.
I'd probably put the comments and submission form in an iframe; possibly from a third-party.
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. :)
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. :)
> 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.
Have my upvote.
You can pay a teenager to set up WP or netlify or more. What people pay me and possibly most HNers for is knowing what and when etc.
In a small team or just for an individual this might boil all the way down to personal preference.
Have my upvote.
You can pay a teenager to set up WP or netlify or more. What people pay me and possibly most HNers for is knowing what and when etc.
In a small team or just for an individual this might boil all the way down to personal preference.
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?
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.
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.
You can have a static site and WYSIWYG editor. For example, you can use GatsbyJS (https://www.gatsbyjs.org/) as the static site generator and Contentful CMS (https://www.contentful.com/) as the editor.
I did exactly this for my last company and it worked great. Might need to use netflify cms moving forward because contentful is NOT cheap.
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.
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.
I'd also note that there are CMSs for static sites like forestry.io or Netlify CMS which gives more of a WYSIWYG for non-technical contributors.
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
Lektor[1] static website generator (Python) supports WYSIWYG
1 - https://github.com/lektor/lektor
1 - https://github.com/lektor/lektor
Also Movable Type, which has been around since 2001.
> 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.
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/
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.
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.
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.
That's the party line. Now do a View Source on some web pages.
That's the party line. Now do a View Source on some web pages.
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.
Unless there is a compelling reason, don't do at runtime what you can do at build time.
Haven't used it, but Forestry.io seems to be about helping end users with a good UI on top of git commits.
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.
[1] or dozens of other sources.
[1] or dozens of other sources.
There is a misconception in the article: static websites aren't guaranteed to be small and dynamic websites aren't necessarily big (in size of assets / load times).
Most of the bulk in modern websites comes from JavaScript (frameworks, tracking, ads), images, videos. All these can and are used both with static and dynamic websites.
Static websites may be mostly hassle-free for developers/devops, but they're typically more of a hassle for content producers. I don't see a convincing case for them overall, because one of their bigger advantages - that they are easier to cache (or rather: to keep cacheable when developers add stuff) upstream than dynamic websites - is mostly gone from the web infrastructure.
Most of the bulk in modern websites comes from JavaScript (frameworks, tracking, ads), images, videos. All these can and are used both with static and dynamic websites.
Static websites may be mostly hassle-free for developers/devops, but they're typically more of a hassle for content producers. I don't see a convincing case for them overall, because one of their bigger advantages - that they are easier to cache (or rather: to keep cacheable when developers add stuff) upstream than dynamic websites - is mostly gone from the web infrastructure.
I don't see why they would be more of a hassle. Why would they even care if the HTML is being rendered on demand or pre-rendered and stored?
Regarding cache, I don't agree - having your site cached by the edge nodes of a CDN is quite important nowadays.
Regarding cache, I don't agree - having your site cached by the edge nodes of a CDN is quite important nowadays.
> Regarding cache, I don't agree - having your site cached by the edge nodes of a CDN is quite important nowadays.
How many of the Alexa top 10K or so have cacheable HTML content (not JS, CSS, images, video) in CDN? Can you provide a few examples?
How many of the Alexa top 10K or so have cacheable HTML content (not JS, CSS, images, video) in CDN? Can you provide a few examples?
There was an article yesterday on a french tech web site about a member of parliament asking if there was a way to encourage developers to make less bloated softwares for ecological reasons (less power consumption).
The text was around 5.5ko on a page weighting around 3mo...
Edit : link to the post (in French) https://www.numerama.com/tech/518848-un-depute-souhaite-que-...
Edit 2 : replaced encline with encourage
The text was around 5.5ko on a page weighting around 3mo...
Edit : link to the post (in French) https://www.numerama.com/tech/518848-un-depute-souhaite-que-...
Edit 2 : replaced encline with encourage
In this article, another article in English is cited : "Software Disenchantment" already discussed on HN : https://news.ycombinator.com/item?id=18012334
Please share the link!
I currently have a static microblog, which is open source [1]. It's generated from a single mark down file with some custom stuff to separate articles. I've been using it for two months and so far I have been able to blog daily [2].
[1] https://github.com/john-bokma/tumblelog [2] http://plurrrr.com/
[1] https://github.com/john-bokma/tumblelog [2] http://plurrrr.com/
I tested it and even I am not a fan of mark down I am amazed
fast speed,simply customizing colors, nice templates and git pull I replaced Wordpress for this system..
- for the SEO part looks like it beats Wordpress -JSON is in there also Great job....used on http://www.werken.nu/blog
My current static setup consists of:
* Nginx [1] - Serve the content with some settings, such as compression and HTTPS.
* Pandoc [2] - Builds the HTML pages and throws a header and footer in there, as well as a comments section [3].
* Bash script [4] - Runs in a screen session, polls git for changes, pulls and rebuilds the content, then builds RSS feeds.
Whilst this works for me, I could see how WordPress could be desirable. Some online editor, ability to add "plug-ins" (i.e. some bits somebody else coded), tracking, comments, etc. I think there is space for some static page generation system/script that adds a light weight editor and the ability to add other people's scripts.
[1] https://www.nginx.com/
[2] https://pandoc.org/
[3] https://github.com/danielbarry/free-comment
[4] http://coffeespace.org.uk/projects/site-creation-v2.html & http://coffeespace.org.uk/projects/rss-feed.html
* Nginx [1] - Serve the content with some settings, such as compression and HTTPS.
* Pandoc [2] - Builds the HTML pages and throws a header and footer in there, as well as a comments section [3].
* Bash script [4] - Runs in a screen session, polls git for changes, pulls and rebuilds the content, then builds RSS feeds.
Whilst this works for me, I could see how WordPress could be desirable. Some online editor, ability to add "plug-ins" (i.e. some bits somebody else coded), tracking, comments, etc. I think there is space for some static page generation system/script that adds a light weight editor and the ability to add other people's scripts.
[1] https://www.nginx.com/
[2] https://pandoc.org/
[3] https://github.com/danielbarry/free-comment
[4] http://coffeespace.org.uk/projects/site-creation-v2.html & http://coffeespace.org.uk/projects/rss-feed.html
I do something close to the same, except each MD post is generated on request so I can update easily if needed. Probably not suitable for anything of demand, but my site isn’t!
I wrote a slapdash server in Go, stuck it behind Nginx, and can just add posts ad-hoc. Only requirement is I have to restart the server to rebuild the list of available posts in memory. After that posts can be edited at will. Post metadata comes from a four line header.
Deployment is pretty manual. Just store everything in a repo, pull changes in on the serving machine and run the Go server in TMUX.
No comments or anything, though. And I rarely write anything.
It was mainly an exercise for learning some Go. That may even change yet.
No repos to share yet as it’s not presentable but will gladly do the work to share in a gist if anyone’s curious.
I wrote a slapdash server in Go, stuck it behind Nginx, and can just add posts ad-hoc. Only requirement is I have to restart the server to rebuild the list of available posts in memory. After that posts can be edited at will. Post metadata comes from a four line header.
Deployment is pretty manual. Just store everything in a repo, pull changes in on the serving machine and run the Go server in TMUX.
No comments or anything, though. And I rarely write anything.
It was mainly an exercise for learning some Go. That may even change yet.
No repos to share yet as it’s not presentable but will gladly do the work to share in a gist if anyone’s curious.
> each MD post is generated on request so I can update easily
> if needed.
You mean each client socket? If so that would be awfully slow for high volume traffic.
> Only requirement is I have to restart the server to
> rebuild the list of available posts in memory.
This seems quite undesirable too, where does this requirement come from?
> pull changes in on the serving machine
Is this manually pulling or do you fetch in a loop?
> will gladly do the work to share in a gist if anyone’s
> curious.
I'm certainly curious now to see exactly how this Go program works.
> if needed.
You mean each client socket? If so that would be awfully slow for high volume traffic.
> Only requirement is I have to restart the server to
> rebuild the list of available posts in memory.
This seems quite undesirable too, where does this requirement come from?
> pull changes in on the serving machine
Is this manually pulling or do you fetch in a loop?
> will gladly do the work to share in a gist if anyone’s
> curious.
I'm certainly curious now to see exactly how this Go program works.
Haha oh man, I was speaking to you from a few versions ago and didn't realize it. I've been so caught up in other projects that I've forgotten some of the changes I've made.
They don't make a ton of difference, but deployments were slightly smoother than I mentioned.
I didn't include directory structure or any views, but I'm sure they can be derived—I wanted it simple. I also used Spectre CSS + overrides for the front so any inline HTML can be assumed to be using classes related to that for any styled elements. There is a couple elements hard-coded into the server itself for the home page.
Definitely not an effort in best practices! But have at it, and happy to hear if you have any input if you're more versed in Go (probable):
https://gist.github.com/robertfairley/f061df3a6a2fe15d429f82...
edit: Also—SSL is handled by Nginx. And god help us all if anybody uses this file as a model for any business web server
They don't make a ton of difference, but deployments were slightly smoother than I mentioned.
I didn't include directory structure or any views, but I'm sure they can be derived—I wanted it simple. I also used Spectre CSS + overrides for the front so any inline HTML can be assumed to be using classes related to that for any styled elements. There is a couple elements hard-coded into the server itself for the home page.
Definitely not an effort in best practices! But have at it, and happy to hear if you have any input if you're more versed in Go (probable):
https://gist.github.com/robertfairley/f061df3a6a2fe15d429f82...
edit: Also—SSL is handled by Nginx. And god help us all if anybody uses this file as a model for any business web server
If it works then it's not silly! Thanks for sharing :)
If I understand it correctly, you build locally and then upload to the server? I have this setup for a few webservers that I have limited control over, so just FTP/POST documents to upload content.
When I have proper control over the server, I much prefer to have the server build the documents. The benefit is that I can simply write a new blog or something from my mobile whilst in a meeting, commit and the server auto-generates the new content. I just need a web browser, GitLab, GitHub and BitBucket all support some form of basic editor for markdown.
Interesting take anyway. My feeling is that I want to do more experimentation on my server and build more "rough and ready" web projects, with the knowledge they will probably fall over more easily and have security flaws. The service goign down is one thing, the entire server being compromised is quite another. I think this points towards introducing some container system. I'll have to learn me some docker.
If I understand it correctly, you build locally and then upload to the server? I have this setup for a few webservers that I have limited control over, so just FTP/POST documents to upload content.
When I have proper control over the server, I much prefer to have the server build the documents. The benefit is that I can simply write a new blog or something from my mobile whilst in a meeting, commit and the server auto-generates the new content. I just need a web browser, GitLab, GitHub and BitBucket all support some form of basic editor for markdown.
Interesting take anyway. My feeling is that I want to do more experimentation on my server and build more "rough and ready" web projects, with the knowledge they will probably fall over more easily and have security flaws. The service goign down is one thing, the entire server being compromised is quite another. I think this points towards introducing some container system. I'll have to learn me some docker.
Yeah you pretty much summed up what I was doing. Fun to learn a new language, make something work to some low expectation I had. And it did/does.
I'll probably try and rewrite in another language again soon. The former version that looked the same was done in Django—but I wanted less overhead.
But yeah, I build locally via that script, but upload all relevant files via `deploy.sh`.
For "rough and ready" projects, I've enjoyed playing with ipkn/crow—I wish it was still maintained. https://github.com/ipkn/crow
And yeah, your take has been similar to mine. I'm okay with it goes down. But the Django system I ran before I was more susceptible to someone breaking in. This one is pretty well untouchable—which is reassuring.
I can safely as rarely look at or update it as necessary without worry—and I appreciate the opportunity to be humbled if I'm wrong!
Also yeah—my current setup would also be made smoother by docker, I was way too lazy to dig into it as I don't use it often.
I'll probably try and rewrite in another language again soon. The former version that looked the same was done in Django—but I wanted less overhead.
But yeah, I build locally via that script, but upload all relevant files via `deploy.sh`.
For "rough and ready" projects, I've enjoyed playing with ipkn/crow—I wish it was still maintained. https://github.com/ipkn/crow
And yeah, your take has been similar to mine. I'm okay with it goes down. But the Django system I ran before I was more susceptible to someone breaking in. This one is pretty well untouchable—which is reassuring.
I can safely as rarely look at or update it as necessary without worry—and I appreciate the opportunity to be humbled if I'm wrong!
Also yeah—my current setup would also be made smoother by docker, I was way too lazy to dig into it as I don't use it often.
Like I said, my site isn’t and likely won’t be in high demand. But to your point: yes. Performance would be bad at high demand.
(Also to note in case of confusion, when I said generated I meant rendered from MD to HTML)
Each time I start the server, it gathers the posts by searching the post tree which is a directory ordered something like
For the changes I just manually pull them and restart the server.
This wasn’t done as a proper engineering project. Just to learn some basic mechanics of the language.
If you’re expecting a proper scalable, professional project you’ll be dismayed.
That said I’ll happily see if I can get it cleaned up and add a link.
(Also to note in case of confusion, when I said generated I meant rendered from MD to HTML)
Each time I start the server, it gathers the posts by searching the post tree which is a directory ordered something like
Posts > YYYY > MM
For the changes I just manually pull them and restart the server.
This wasn’t done as a proper engineering project. Just to learn some basic mechanics of the language.
If you’re expecting a proper scalable, professional project you’ll be dismayed.
That said I’ll happily see if I can get it cleaned up and add a link.
For static site generators:
https://github.com/pinceladasdaweb/Static-Site-Generators
https://staticsitegenerators.net/
I keep all my resources for working with GitHub Pages, here:
https://infominer.id/web-work/github-pages-starter-pack/
and am most familiar with GitHub facilitated Jekyll:
https://github.com/planetjekyll/awesome-jekyll
MkDocs makes really nice pages that don't require fussing around with frontmatter, with auto generated navigation based on directory structure.
It also opens your publishing toolkit to python's universe of markdown related extensions, which you may already be familiar with.
https://www.mkdocs.org/
https://github.com/pinceladasdaweb/Static-Site-Generators
https://staticsitegenerators.net/
I keep all my resources for working with GitHub Pages, here:
https://infominer.id/web-work/github-pages-starter-pack/
and am most familiar with GitHub facilitated Jekyll:
https://github.com/planetjekyll/awesome-jekyll
MkDocs makes really nice pages that don't require fussing around with frontmatter, with auto generated navigation based on directory structure.
It also opens your publishing toolkit to python's universe of markdown related extensions, which you may already be familiar with.
https://www.mkdocs.org/
I think this is a reasonable thing to do. For Dercuano, I hacked together a basic static site generator in Python 2 in a weekend (70% of the current static site generator code dates from the first three days, according to git blame); I've spent more time hacking on the CSS than on the Python, and immensely more time writing the text than either.
In case it's useful to someone else, as inspiration if nothing else, it's at https://gitlab.com/kragen/dercuano, in the public domain. The latest version of the output is at http://canonical.org/~kragen/dercuano-20190525.tar.gz.
In case it's useful to someone else, as inspiration if nothing else, it's at https://gitlab.com/kragen/dercuano, in the public domain. The latest version of the output is at http://canonical.org/~kragen/dercuano-20190525.tar.gz.
Why Python 2 if I may ask?
I wrote my static site generator in Python 3.7 by manually translating the Perl version I had written earlier. Both are available at github https://github.com/john-bokma/tumblelog
Example of this set up: http://plurrrr.com/
I wrote my static site generator in Python 3.7 by manually translating the Perl version I had written earlier. Both are available at github https://github.com/john-bokma/tumblelog
Example of this set up: http://plurrrr.com/
No real reason for using Python 2 — it was just an expedient choice in the moment.
Amusingly, your tumblelog.py is about the same size as dercuano.py, while the intersection of features is almost exactly empty. We managed to do even the most basic things differently — for example, yours reads a single long file with % lines separating the entries (like a fortune file!) and produces a passel of output files, while mine reads a passel of input files and produces a single multi-megabyte output file. This diversity of choices perhaps demonstrates the need for experimentation to see what works best for different people and in different circumstances. (Or it could just mean I'm insane.)
Amusingly, your tumblelog.py is about the same size as dercuano.py, while the intersection of features is almost exactly empty. We managed to do even the most basic things differently — for example, yours reads a single long file with % lines separating the entries (like a fortune file!) and produces a passel of output files, while mine reads a passel of input files and produces a single multi-megabyte output file. This diversity of choices perhaps demonstrates the need for experimentation to see what works best for different people and in different circumstances. (Or it could just mean I'm insane.)
> WordPress was one of the most visible early proponent of WYSIWYG, but others joined.
I added inline editing to Surreal CMS back in 2013, but obviously it’s not a well-known brand (the keyword is “visible” I guess).
People love inline editing, especially non-devs. When you abstract content into forms or markdown you often end up with results that look different from what you intended. I get feedback from new users weekly about how easy inline editing is for them.
Fortunately, TinyMCE, CKEditor, ProseMirror, et al all support it and the trend is finally shifting. But as a developer, I can attest that inline editing isn’t easy to get right — even when the underlying lib supports it.
I suspect that’s why we still see forms for content in CMSs.
I added inline editing to Surreal CMS back in 2013, but obviously it’s not a well-known brand (the keyword is “visible” I guess).
People love inline editing, especially non-devs. When you abstract content into forms or markdown you often end up with results that look different from what you intended. I get feedback from new users weekly about how easy inline editing is for them.
Fortunately, TinyMCE, CKEditor, ProseMirror, et al all support it and the trend is finally shifting. But as a developer, I can attest that inline editing isn’t easy to get right — even when the underlying lib supports it.
I suspect that’s why we still see forms for content in CMSs.
Aren't static pages similar to a cache ?
Wouldn't you obtain the same benefits while still keeping Wordpress if you would use something like Varnish[1] or CloudFlare Edge cache[2] ?
[1] https://www.varnish-software.com/wiki/content/tutorials/word...
[2] https://wordpress.org/plugins/cloudflare-page-cache/
Wouldn't you obtain the same benefits while still keeping Wordpress if you would use something like Varnish[1] or CloudFlare Edge cache[2] ?
[1] https://www.varnish-software.com/wiki/content/tutorials/word...
[2] https://wordpress.org/plugins/cloudflare-page-cache/
Static website is a controlled cache to the extreme, when you prepopulate cache when you create the content.
Benefits on top of regular cache:
+ maintenance cost: you need to upgrade wordpress, why my static website doesn't require any work over years
+ security: small vulnerability surface
+ cost: hosting even popular static website is cheap
Benefits on top of regular cache:
+ maintenance cost: you need to upgrade wordpress, why my static website doesn't require any work over years
+ security: small vulnerability surface
+ cost: hosting even popular static website is cheap
You certainly would. I had very good results on clients' sites using a combination of varnish, cdn for images, and firewall to block any external probing - basically allowing only clean url GET requests to predefined set of urls, and blocking admin area access to anyone except whitelisted IPs. It's just as fast as a static site would be, and almost as secure. It takes more maintenance and costs a lot more to setup, but you get the benefits of CMS that all content authors/editors know how to use, so clients didn't mind it.
Agree. Hugo is a great tool for static sites, and GitLab offers free pipelines for the conversion and SSL with Let's Encrypt. Don't forget to gzip your content as the final step.
What I love best is that you don't need much to get started with generating a static web site, and you can be confident that once you deploy you don't have to worry that much about security or other production issues.
This greatly lowers the bar for entry, and I was doing this back in the 90s with Microsoft Access 95 and VBA for my school's website.
This greatly lowers the bar for entry, and I was doing this back in the 90s with Microsoft Access 95 and VBA for my school's website.
Bonus:
If you write plain, valid HTML your site will just work across all mainstream browsers and it will probably work reasonably wrt accessibility as well, -out of the box.
It will also be reasonbly fast. You might be able to eke out more performance from a site that has a lot of interaction but I'd not take that for granted.
If you write plain, valid HTML your site will just work across all mainstream browsers and it will probably work reasonably wrt accessibility as well, -out of the box.
It will also be reasonbly fast. You might be able to eke out more performance from a site that has a lot of interaction but I'd not take that for granted.
All I want in life (as far as web authoring goes) is a wysiwyg editor for static html that creates fairly clean code and can provide responsive templates.
I just want to type text and drop images in and see it in real time, and then I would like to be able to define one or more areas on a page that contain dynamic content.
That dynamic content can be served up when visitors reach the site, or can be compiled by the static site generator periodically, I really don’t care about that step.
I don’t want to abstract “templates” from content. I don’t want to abstract anything. I just want to type and drop in other media without extra steps.
Why does this not exist? Am I supposed to be using Dreamweaver? I just don’t get why all these other solutions are so disjointed.
Edit: Maybe I want to be using blocs
I just want to type text and drop images in and see it in real time, and then I would like to be able to define one or more areas on a page that contain dynamic content.
That dynamic content can be served up when visitors reach the site, or can be compiled by the static site generator periodically, I really don’t care about that step.
I don’t want to abstract “templates” from content. I don’t want to abstract anything. I just want to type and drop in other media without extra steps.
Why does this not exist? Am I supposed to be using Dreamweaver? I just don’t get why all these other solutions are so disjointed.
Edit: Maybe I want to be using blocs
I've recently purchased a license for Bootstrapstudio for $60 and I want to send a vote of confidence. Does exactly what you're describing. I wish they had a bit more integration for templates for webapps but you can only do so much at the end of the day.
There are similar other offerings (one that comes to mind is reactstudio, but has a bit more going on there with code and flow.
There are similar other offerings (one that comes to mind is reactstudio, but has a bit more going on there with code and flow.
sounds a bit like markdown tbh
the biggest problem with JAMStack (everything including Gatsby, Jekyll, Hugo, etc) is that there is no single place with a nice source code repo, CMS system and hosting.
Basically, to get your JamStack to work - you need to use Github + Github hooks -> Contentful/Cosmicjs -> Netlify.
I believe this is a missing and a killer product. People think "oh why reinvent Github". But a business guy who wants a fast website does not know what github is - he/she just need a single place to do everything.
the workflow that would work is - upload my code to dashboard (using git/FTP upload). Write content in CMS and see the website change within a few seconds. Reupload new code, and the website changes within a few seconds.
Basically, to get your JamStack to work - you need to use Github + Github hooks -> Contentful/Cosmicjs -> Netlify.
I believe this is a missing and a killer product. People think "oh why reinvent Github". But a business guy who wants a fast website does not know what github is - he/she just need a single place to do everything.
the workflow that would work is - upload my code to dashboard (using git/FTP upload). Write content in CMS and see the website change within a few seconds. Reupload new code, and the website changes within a few seconds.
You should check out Gatsby Preview which is currently in some sort of limited public beta. https://www.gatsbyjs.org/blog/2018-07-17-announcing-gatsby-p...
[deleted]
I hate WYSIWYG (although I am not trying to prohibit anyone from writing/using them if they want to, only to say that you should not be forced to use WYSIWYG), but certainly for a lot of stuff, static web pages (especially if do not require script and a lot of other external resources) would be helpful, and sometimes gopher would do better, too. (Use of other protocols is also sometimes helpful for non-static stuff too, such as telnet/SSH for interactive sessions, or remote virtual table protocol (or maybe a better protocol and implementation can be made up), for remote database queries.)
Static web is fine for some use cases.
For an admin dashboard, static web is stupid.
For an admin dashboard, static web is stupid.
Static is perfect for an admin dashboard since it doesn't have SEO requirements.
Static doesn't mean there isn't any dynamic content is just means the assets are static files that can be cached both server and client side. Dynamic content can be fetched by the client, it doesn't need to be fetched and delivered by the server.
Static doesn't mean there isn't any dynamic content is just means the assets are static files that can be cached both server and client side. Dynamic content can be fetched by the client, it doesn't need to be fetched and delivered by the server.
I guess that's one definition of static webpage. My understanding was that static webpages are static. Meaning it has no dynamic content and that everyone accessing the static page sees the same thing.
If dynamic content is client side driven, it wouldn't be "static" as each client could see a different page.
For example, even if you your webpage just displayed the client side time, it would be dynamic since people in different time zones will see a different time regardless of the time being generated on the client side.
Whether it is a static class or a static webpage, static has a well established meaning in the CS world. But I haven't done web development since college and it is possible the meaning of static webpage has changed as technology changes.
If dynamic content is client side driven, it wouldn't be "static" as each client could see a different page.
For example, even if you your webpage just displayed the client side time, it would be dynamic since people in different time zones will see a different time regardless of the time being generated on the client side.
Whether it is a static class or a static webpage, static has a well established meaning in the CS world. But I haven't done web development since college and it is possible the meaning of static webpage has changed as technology changes.
Static is a term to describe the assets that are delivered to the client. It means every user is delivered the same assets which means the server doesn't have to do any logic. The assets can be delivered from a CDN and cached on the client indefinitely.
Sending every user `document.write(new Date());` is static because its identical for everyone. The fact each user sees something different is completely irrelevant.
Sending every user `document.write(new Date());` is static because its identical for everyone. The fact each user sees something different is completely irrelevant.
Static webpages are served exactly the same to each user. As opposed to dynamically generated webpage. But that doesn't mean a static webpage doesn't use Javascript. It just means the actual content delivered is the same every time.
but sometimes you legit need dynamic capabilities. I'm now pondering about selling a few items through my website(built with Hugo). But, how? So, I'm stepping into Wordpress realm because that's where the payment processing stuff are.
Anyone here know/have done a shopping website built with Hugo and a simple third party service for payment processing?
Anyone here know/have done a shopping website built with Hugo and a simple third party service for payment processing?
I currently run a static website with a shop using Shopify's JavaScript SDK. All the benefits of Shopify's excellent backend and admin interface while still using a performant website that can be designed however I please.
Another option is Snipcart, which explicitely works as a drop-in shop for any website[2].
[1] https://shopify.github.io/js-buy-sdk/
[2] https://snipcart.com/
Another option is Snipcart, which explicitely works as a drop-in shop for any website[2].
[1] https://shopify.github.io/js-buy-sdk/
[2] https://snipcart.com/
You can use Stripe Checkout without a server - all you need is to configure the products on the Stripe account, then use JS on your site to pass the product SKUs when redirecting to the Checkout page: https://stripe.com/docs/stripe-js/reference#stripe-redirect-...
I haven't used them, but I was evaluating SnipCart as an option for adding e-commerce capabilities to a static site. Other requirements made us ultimately decide to port everything to Squarespace, but I've been thinking about turning on a small static site store of my own with these guys.
https://snipcart.com/
https://snipcart.com/
Snipcart has been mentioned a few times already, but you should check this tutorial on their blog:
> https://snipcart.com/blog/hugo-tutorial-static-site-ecommerc...
It shows exactly the use case you're mentioning with Hugo.
> https://snipcart.com/blog/hugo-tutorial-static-site-ecommerc...
It shows exactly the use case you're mentioning with Hugo.
What I understand: the most used solution, Wordpress, is an attractive market but has a slow UI and experience, please consider using my markdown solution which I positioned in a different page than this article.
The main issue I have with static sites is that publishing from mobile isn’t simple. That said I also have this issue with WordPress, so I’m using Known now
I checked out Known and it looks quite interesting. Surprised I’d never heard of it. How are you liking it? Is it well maintained/frequent releases?
Disable Javascript and you too can surf the WWW like it's the 1990s!
Admittedly just bikeshedding, but the author is using a blockquote tag instead of an h2/h3 right under the h1 title for the summary of the article. Makes me think he probably doesn’t have that firm of a grasp on the fundamentals of semantical HTML and markdown, let alone web development in general.
This is, by the way, something I see a lot out in the wild, especially in Medium articles but also in READMEs on GitHub. Please stop using blockquote tags for emphasis purposes.
This is, by the way, something I see a lot out in the wild, especially in Medium articles but also in READMEs on GitHub. Please stop using blockquote tags for emphasis purposes.
The lede is not a heading, why should the author use an <h*>?
I see your point, an h* would probably also be inappropriate. What would you use? Just a normal p tag with some styling?
`role="heading"`?
no, that's the same as <hX>
I'd probably go with just a styled text, maybe with an aria-label.
I'd probably go with just a styled text, maybe with an aria-label.
Once I audited their site, I found a ton of issues, particularly - their stale Wordpress version, themes and plugins. I updated them all one by one and migrated them to Wordpress.com which doesn't suffer this upgrading pain.
Then, I found out the theme provider had actually stopped supporting the theme and there were a bunch of security flaws in it. But, the client wanted something like push and forget.
So, I painstakingly migrated them off of Wordpress and made a custom Jekyll site with Jekyll admin running on Netlify. They're immensely happy now knowing that their site is virtually unhackable (it's just a static site).
Static site builders are more powerful than we think. I have a travel platform running on it right now actually and none of the end users know its a static site they're on top of. There's no plugins to manage, no software versions or security loopholes to keep track of. The only way someone can hack into your site if they hacked your identity provider (Eg. Netlify). Otherwise, it's simply just a boon.