6 ms·

Seems like the right thing to do for most CMS type situations is something that generates the site offline... and only uploads a static site to the web. Someth

by lsc 9y ago

Seems like the right thing to do for most CMS type situations is something that generates the site offline... and only uploads a static site to the web. Something like jekyll or something.

sphix0r 9y ago
This. Most websites are mainly read only anyway. No need to throw in a programming language and store the data in a database. The thing is, non-tech savvy people should be able to use(and deploy) and understand the static-web generators.
Roritharr 9y ago
That's of course a good solution but then you want your Ajaxy Web 2.0 Things in there, some more complicated forms maybe and you start looking at something that takes quite some effort to build compared to what you get from WordPress/Drupal etc. Funnily enough, having worked on all kinds of websites for the past 15 years, i'm still at a loss when asked what the all-round good solution is.
- andybak 9y ago
  Maybe the problem is the phrase "all round". There are trade offs to be made and complex cost/benefit calculations that are required. To further complicate things, things change. A website that was a perfect fit for a Wordpress template easily grows beyond that. And a site that seemed ideal for a custom Django/Rails backend might eventually settle into the kind of functionality groove where you begin to wonder if an off the peg solution might not have been a better idea.
- jlgaddis 9y ago
  WordPress at least automatically updates itself. There's been a few times when auto updates broke but, overall, it has been a tremendous help in reducing the number of exploited web servers out there.
stephenr 9y ago
Im pretty convinced static site generators should be the default first choice for most sites.
- bonesss 9y ago
  Especially if you're popular and want to scale. Turning that CMS into a distributed publishing platform is tricky, but scaling static content is easy-mode from top to bottom.
- StavrosK 9y ago
  I've recently found the perfect middle ground: Django with Wagtail and Bakery. Django is Django, Wagtail is a very well designed CMS, and Bakery allows you to export Django views as static files. That way, I managed to convert my dynamic website to a static one with a few lines of code (basically a loop that iterates over all URLs on my site).
jmknoll 9y ago
I'm a big fan of Jekyll (and more recently, Gatsby), and I think you're correct in saying that in most cases where a CMS is used, a static site generator would be a better option. However, I see a couple of problems standing in the way of more widespread adoption of static site generators: 1) I've never seen a static site generator that non-technical users felt comfortable with. Programmers like terminal interfaces. Your average user in 2018 has probably never opened the terminal. 2) Possibly even more significant, I don't think the people making the choice to use a CMS for a simple business-info or blog site are aware of the trade-offs that they're making, or of the benefits that a static site will provide down the line. For a lot of small business owners I've spoken with, Wordpress is basically synonymous with "web presence." I wonder if there's a market for a web-based GUI like what Wordpress provides, but which runs jekyll under the hood and uploads the files to s3 or something like that. Is this what companies like Squarespace and Wix do?
- benaiah 9y ago
  The project I work on, Netlify CMS (https://www.netlifycms.org/ https://www.netlifycms.org/), is almost precisely what you described in your last paragraph.I say "only" because it only officially supports GitHub as a backend at the moment, from which you can deploy to a host. (I'm also currently working on supporting more backends, so that will change soon.) The CMS is an open-source (MIT license) CMS built as a static web page which connects to an API for an arbitrary backend from your browser and edits the content stored there - from there, you can build the content with whatever static site generator you want. This lets you build sites that non-technical users can keep up-to-date without tying yourself to a specific tech stack for the actual website. (disclaimer: Netlify employee)
  - StavrosK 9y ago
    Please put that description somewhere on the site. I tried to try out Netlify CMS there times because I love Netlify the service but couldn't figure out what it is any of those times. That said, it didn't help that you don't support Gitlab, which is where all my sites are, and which is the more important reason why I couldn't get it to work.
scandox 9y ago
Whenever I try to sell this internally we fall down on plugins. Marketing are using hundreds of them that we can’t replicate.
- arbie 9y ago
  Hundreds!? Is there significant overlap in their functionality?
  - scandox 9y ago
    I have no idea. We more or less took one look at all the crazy sh*t they were doing with pixels, trackers, inbound marketing, outbound marketing, SEO, sitemaps, special codes for FB, GA, dynamic landing pages... You know it's all trivial garbage...except if you want to replace it you need to support it, train them to use these tools and at every point you're going to encounter this resistance about WHY you're doing it and you say well security and speed and they're like it's fast enough and we've never been hacked. So until the site grinds to a halt and they get also get hacked they basically view you as a blocker.
tenken 9y ago
Grav CMS is interesting.
- pathartl 9y ago
  I've always wanted to try it. I'm more interested in Statamic which is premium, but seems better supported and I'd be more comfortable putting clients on it. From an outside perspective without having used either, that is.
arca_vorago 9y ago
As a sysadmin who has seen and fixed drupal/wp/joomla/dreamweaver etc nightmares, I personally have settled on a combination of emacs org-mode html export (don't forget how beautiful the latex export can be!, and that you can run programs inside org-mode, and the google calendar integration, etc) and asciidoc and asciidoctor(nicer default html export settings, but I suggest custom pure css3/html5 no js!). That said, back on subject: Look, this is the main reason you devs tend to hear disdain from us sysadmins when we hear you want to run some new webservice in whatever language fad of the day (node, python, perl, php, asp.net, ruby, scala, go, etc) instead of generating files with your app that can then be serviced to the user using the tried and true tools (apache, nginx, hiawatha, haproxy etc) that have had sometimes decades of public internet exposure to claw thier way through. Ah, but what about $functionality. Most webdevs think they need a scripting language backend when they really don't. There are uses for it and it has it's place, but it's been way overdone. Relevant discussion: https://groups.drupal.org/security/faq-2018-002 https://groups.drupal.org/security/faq-2018-002 Sidenote: I think everyone should check out hiawatha webserver, over at (https://www.hiawatha-webserver.org/ https://www.hiawatha-webserver.org/). Hugo wrote it with security in mind and it by default addresses many things that no other webserver does. It's also gplv2 (which is a big deal for me), and it's performance is second to none. I'm not a big php person, but if I were to be doing a webapp where a backend like that would be needed, I would probably try to go PHP-FPM with hiawatha(mbed TLS)/haproxy and a really nicely hardened boxen and edge firewall(you are using nftables now right?).
- indigodaddy 9y ago
  Source for the Hiawatha performance claim?
  - arca_vorago 9y ago
    Well it's a bit old now but a few years ago on the Hiawatha blog a test of load under attack was done and Hiawatha was able to handle a simulated (d?)dos very well. I'm on mobile but a quick ddg show: https://www.hiawatha-webserver.org/weblog/64 https://www.hiawatha-webserver.org/weblog/64
- 9y ago
bastawhiz 9y ago
Somewhat tangential anecdote: I used to work a LONG time ago for a company that built Yahoo Small Business ecommerce websites. They used a tool called RTML ("Robert T Morris Language"), which was essentially HAML, powered by Perl, and constructed using a GUI (no text editor interface). Select where you want a node > New node > select node type > Save...each action was a full page load. The process was excruciating, and I was in charge of developing tools to automate the upload of "template" files from the developer's machine to the client's Yahoo Small Business store. At the end of the day, the customer would load up all their goods into the Yahoo database and hit "Publish", at which point a multi-hour job would kick off to run their RTML against the database. The result was a completely static ecommerce website. Only the cart/checkout pages were dynamic, and those were using shared code. The development process was a nightmare. The client experience was really bad (want to fix a typo? You're going to wait a couple hours). But I'll be damned if it was possible for anyone to hack those things. There was nothing to hack.
dreamfactored 9y ago
That's how the early CMS's like Vignette worked and they evolved to solutions like WP and Drupal which are better for the web publishing use case - easier to maintain, develop, and capable of real-time UGC and publishing (real-time is crucial for SEO in commercial publishing). Static site generators are simply a file-system caching layer. Drupal used to have one of those and it was a terrible idea as the number of page variants on a commercial site very quickly hits file-system limitations and performance is appalling. Better to use a proper CDN for a similar result but with massively reduced latency due to content being served from the edge.

by lsc 9y ago

Seems like the right thing to do for most CMS type situations is something that generates the site offline... and only uploads a static site to the web. Something like jekyll or something.

sphix0r 9y ago

This. Most websites are mainly read only anyway. No need to throw in a programming language and store the data in a database. The thing is, non-tech savvy people should be able to use(and deploy) and understand the static-web generators.

Roritharr 9y ago

That's of course a good solution but then you want your Ajaxy Web 2.0 Things in there, some more complicated forms maybe and you start looking at something that takes quite some effort to build compared to what you get from WordPress/Drupal etc. Funnily enough, having worked on all kinds of websites for the past 15 years, i'm still at a loss when asked what the all-round good solution is.

andybak 9y ago
Maybe the problem is the phrase "all round". There are trade offs to be made and complex cost/benefit calculations that are required. To further complicate things, things change. A website that was a perfect fit for a Wordpress template easily grows beyond that. And a site that seemed ideal for a custom Django/Rails backend might eventually settle into the kind of functionality groove where you begin to wonder if an off the peg solution might not have been a better idea.
jlgaddis 9y ago
WordPress at least automatically updates itself. There's been a few times when auto updates broke but, overall, it has been a tremendous help in reducing the number of exploited web servers out there.

stephenr 9y ago

Im pretty convinced static site generators should be the default first choice for most sites.

bonesss 9y ago
Especially if you're popular and want to scale. Turning that CMS into a distributed publishing platform is tricky, but scaling static content is easy-mode from top to bottom.
StavrosK 9y ago
I've recently found the perfect middle ground: Django with Wagtail and Bakery. Django is Django, Wagtail is a very well designed CMS, and Bakery allows you to export Django views as static files. That way, I managed to convert my dynamic website to a static one with a few lines of code (basically a loop that iterates over all URLs on my site).

jmknoll 9y ago

I'm a big fan of Jekyll (and more recently, Gatsby), and I think you're correct in saying that in most cases where a CMS is used, a static site generator would be a better option. However, I see a couple of problems standing in the way of more widespread adoption of static site generators: 1) I've never seen a static site generator that non-technical users felt comfortable with. Programmers like terminal interfaces. Your average user in 2018 has probably never opened the terminal. 2) Possibly even more significant, I don't think the people making the choice to use a CMS for a simple business-info or blog site are aware of the trade-offs that they're making, or of the benefits that a static site will provide down the line. For a lot of small business owners I've spoken with, Wordpress is basically synonymous with "web presence." I wonder if there's a market for a web-based GUI like what Wordpress provides, but which runs jekyll under the hood and uploads the files to s3 or something like that. Is this what companies like Squarespace and Wix do?

benaiah 9y ago
The project I work on, Netlify CMS (https://www.netlifycms.org/ https://www.netlifycms.org/), is almost precisely what you described in your last paragraph.I say "only" because it only officially supports GitHub as a backend at the moment, from which you can deploy to a host. (I'm also currently working on supporting more backends, so that will change soon.) The CMS is an open-source (MIT license) CMS built as a static web page which connects to an API for an arbitrary backend from your browser and edits the content stored there - from there, you can build the content with whatever static site generator you want. This lets you build sites that non-technical users can keep up-to-date without tying yourself to a specific tech stack for the actual website. (disclaimer: Netlify employee)
- StavrosK 9y ago
  Please put that description somewhere on the site. I tried to try out Netlify CMS there times because I love Netlify the service but couldn't figure out what it is any of those times. That said, it didn't help that you don't support Gitlab, which is where all my sites are, and which is the more important reason why I couldn't get it to work.

scandox 9y ago

Whenever I try to sell this internally we fall down on plugins. Marketing are using hundreds of them that we can’t replicate.

arbie 9y ago
Hundreds!? Is there significant overlap in their functionality?
- scandox 9y ago
  I have no idea. We more or less took one look at all the crazy sh*t they were doing with pixels, trackers, inbound marketing, outbound marketing, SEO, sitemaps, special codes for FB, GA, dynamic landing pages... You know it's all trivial garbage...except if you want to replace it you need to support it, train them to use these tools and at every point you're going to encounter this resistance about WHY you're doing it and you say well security and speed and they're like it's fast enough and we've never been hacked. So until the site grinds to a halt and they get also get hacked they basically view you as a blocker.

tenken 9y ago

Grav CMS is interesting.

pathartl 9y ago
I've always wanted to try it. I'm more interested in Statamic which is premium, but seems better supported and I'd be more comfortable putting clients on it. From an outside perspective without having used either, that is.

arca_vorago 9y ago

As a sysadmin who has seen and fixed drupal/wp/joomla/dreamweaver etc nightmares, I personally have settled on a combination of emacs org-mode html export (don't forget how beautiful the latex export can be!, and that you can run programs inside org-mode, and the google calendar integration, etc) and asciidoc and asciidoctor(nicer default html export settings, but I suggest custom pure css3/html5 no js!). That said, back on subject: Look, this is the main reason you devs tend to hear disdain from us sysadmins when we hear you want to run some new webservice in whatever language fad of the day (node, python, perl, php, asp.net, ruby, scala, go, etc) instead of generating files with your app that can then be serviced to the user using the tried and true tools (apache, nginx, hiawatha, haproxy etc) that have had sometimes decades of public internet exposure to claw thier way through. Ah, but what about $functionality. Most webdevs think they need a scripting language backend when they really don't. There are uses for it and it has it's place, but it's been way overdone. Relevant discussion: https://groups.drupal.org/security/faq-2018-002 https://groups.drupal.org/security/faq-2018-002 Sidenote: I think everyone should check out hiawatha webserver, over at (https://www.hiawatha-webserver.org/ https://www.hiawatha-webserver.org/). Hugo wrote it with security in mind and it by default addresses many things that no other webserver does. It's also gplv2 (which is a big deal for me), and it's performance is second to none. I'm not a big php person, but if I were to be doing a webapp where a backend like that would be needed, I would probably try to go PHP-FPM with hiawatha(mbed TLS)/haproxy and a really nicely hardened boxen and edge firewall(you are using nftables now right?).

indigodaddy 9y ago
Source for the Hiawatha performance claim?
- arca_vorago 9y ago
  Well it's a bit old now but a few years ago on the Hiawatha blog a test of load under attack was done and Hiawatha was able to handle a simulated (d?)dos very well. I'm on mobile but a quick ddg show: https://www.hiawatha-webserver.org/weblog/64 https://www.hiawatha-webserver.org/weblog/64
9y ago

bastawhiz 9y ago

Somewhat tangential anecdote: I used to work a LONG time ago for a company that built Yahoo Small Business ecommerce websites. They used a tool called RTML ("Robert T Morris Language"), which was essentially HAML, powered by Perl, and constructed using a GUI (no text editor interface). Select where you want a node > New node > select node type > Save...each action was a full page load. The process was excruciating, and I was in charge of developing tools to automate the upload of "template" files from the developer's machine to the client's Yahoo Small Business store. At the end of the day, the customer would load up all their goods into the Yahoo database and hit "Publish", at which point a multi-hour job would kick off to run their RTML against the database. The result was a completely static ecommerce website. Only the cart/checkout pages were dynamic, and those were using shared code. The development process was a nightmare. The client experience was really bad (want to fix a typo? You're going to wait a couple hours). But I'll be damned if it was possible for anyone to hack those things. There was nothing to hack.

dreamfactored 9y ago

That's how the early CMS's like Vignette worked and they evolved to solutions like WP and Drupal which are better for the web publishing use case - easier to maintain, develop, and capable of real-time UGC and publishing (real-time is crucial for SEO in commercial publishing). Static site generators are simply a file-system caching layer. Drupal used to have one of those and it was a terrible idea as the number of page variants on a commercial site very quickly hits file-system limitations and performance is appalling. Better to use a proper CDN for a similar result but with massively reduced latency due to content being served from the edge.