The complexity of modern sites is insane. It's also insane to relay on other peoples services ('cloud' and 'server-less') for simple websites, like publishing articles or blog-posts. Those services could be gone tomorrow!
A lot of users may also chose to disable JavaScript in the future, as more and more malicious actors use JavaScript to exploit people (the latest trend is to hack sites and js- libraries to make other people mine crypto-currency).
I believe the answer to many of todays challenges is to move on to static sites, and to make most sites work without JavaScript. You only need JavaScript if you make a site that is basically an application. A blog or a newspaper is not an application.
For a blogger, another feature with static sites is that they don't require a specific back-end (like wordpres or drupal). As a static site, their thoughts and ideas can live on for millenniums, long after the last wordpress or drupal instances has shut down.
Disclosure: I'm not un-biased here. I'm actually so biased that I wrote my own static site generator last year to make it simple to publish blogs that works great on both mobile devices and PC's.
>You only need JavaScript if you make a site that is basically an application.
You may not even need that. As part of the process of learning Nim, I've been making a package repository that's designed to accept artifacts from a CI system, store them, and allow searching by a variety of different package metadata, including a web interface to manage all your artifacts. Not a complex webapp, but also not a trivial one.
Anywho, I decided to set myself the challenge of using no javascript anywhere on the site. It's really not been much of a problem. The UX is different, which means the application UX design is different. But it isn't worse.
The only thing I've run into and been unable to solve without javascript is that when you use the file picker to manually select a file on your computer for upload (rather than using the API), I can't update the page to show you which file you picked.
Based on my experience, javascript is like a fine spice. A little bit of it added to your page in just the right amount can make an average web experience fantastic. Taking the cap off the JS shaker and just pouring it in is almost certainly going to make the experience far worse.
This is true of any hosting service. Unless it's your machine in your rack in your building attached to your pipe, there's a company that could suddenly shut down tomorrow and leave you in the lurch.
I believe the answer to many of todays challenges is to move on to static sites, and to make most sites work without JavaScript
The second part I agree with. The first part... meh. I've built a lot of database-backed websites, and have been doing so since the days when people used the term "DHTML" to refer to using JavaScript in a web page. The patterns for doing it are well-understood, the tools for doing it are solid, and for anything bigger than a brochureware site I'll basically always turn to a database (and even for the brochureware, I'll usually do it, since I don't want to train non-technical people on how to edit files and run a static generator).
It's a lot easier to just 'scp ~/blog/. new-server:/var/www' than to set up a database server, go trough configuration and hardening of apache and php (or whatever) and make everything play together, again. Some of my sites have been down for 6 months now, because I never found the time to do that.
> since I don't want to train non-technical people on how to edit files and run a static generator
Some friends of mine and I are planning a hosted service for this, where users can push sites trough git, scp, ftp or interactively maintain the site trough a panel (using JavaScript) - and download the entire site at any time as a zipfile (or git clone). The sites will be static, but there will be (optional) comments, using a 3rd party service.
It's a lot easier to just 'scp ~/blog/. new-server:/var/www' than to set up a database server, go trough configuration and hardening of apache and php (or whatever) and make everything play together, again.
Well, you need to do some configuration and hardening no matter what. And while I don't use PHP anymore, I've found that for what I do the deployment story these days is easy enough.
Some friends of mine and I are planning a hosted service for this, where users can push sites trough git, scp, ftp or interactively maintain the site trough a panel (using JavaScript) - and download the entire site at any time as a zipfile (or git clone). The sites will be static, but there will be (optional) comments, using a 3rd party service.
So after suggesting people don't trust third-party services, you're going to start and advertise your own, and integrate someone else's service into it? :)
Oops, I remember checking this out quite awhile ago. Seems it has gotten awesome. What an excellent way for less technical people to build their own website!
We host high target content (politician sites + dns + email) and I've been moving to static html on siloed s3+cloudfront when clients dont need to use cms themselves. It's also much less bloated with a goal of really fast load times on mobile.
The problem is of course most of our staff - and definitely all of our clients that want to be able to edit themselves - still rely on WordPress and worse a bunch of plugins that are impossible to lock down.
I've wondered if others have setup WordPress in a separate environment to let clients do what they want and then host the static html elsewhere. Like maybe wp-supercache could give a zip download of the static content.
> I've wondered if others have setup WordPress in a separate environment to let clients do what they want and then host the static html elsewhere. Like maybe wp-supercache could give a zip download of the static content.
I was looking into this recently and seemed like Simply Static[0] was something that could be used for this, as per something like this writeup[1]. I never tried it out, but I think it could be really powerful. Limitations are of course stuff like forms, which made it less useful for me than I first realised. I guess one could use some other form-service which is implemented with js, or maybe there are some plugins available which implements forms with js.
I think more people need to know about tools like https://forestry.io/ - it is a way to have an end user update content, it gets committed to github/gitlab/bitbucket and then you could have it deployed on a commit hook or via forestry.
Why not just use contentful (linked article is written by contentful) + static gen? My company has used contentful + middleman for almost 2 years now. It took a while to hone in (payloads used to be extremely large), but once it's dialed, the experience is better than WP for both writers and designers.
I haven't looked into it more than the five minutes surfing around after reading this article, so maybe I should look into it more.
It was hard to find info on their visual cms like editor in the few minutes I poked around Contentful's site. Maybe their CMS like editor is really simple/similar to wordpress I will read some more.
Another quick thought is wordpress has a huge amount of plugins that these non-technical clients are used to, so probably some retooling would be needed to reproduce what they want.
I have no problem creating and updating static sites myself so the only need really is to provide clients a way to add content and mess around with site through a visual cms (e.g. use a visual editor plugin to add new slideshow type content and change layouts).
Without wanting to plug my own software too much too soon, I've been building a self-hosted static publishing CMS (that sits on top of a git repository rather than a database). Not ready for prime time just yet, but getting there
In sum: static sites will keep the scary hackers away. Here's how you build a self-hosted static site with Contentful, starting at just $250/month for the privilege of using our editor. What a great deal!
anyone knows if Netlify CMS can be used in a free, self-hosted solution? (they allow free use and are open-source, but i see lotsa reference to their backend api's in docs)
I was just thinking the other day, while upgrading Django LTS and dependencies for the second time now, with its endless list of reverse incompatible changes (on each intermediate version) that I need to consider, on I site I currently maintain to be responsible but don't have a lot of time to invest on: oh, this is why people use static site generators.
Come to think of it, it would be nice if I could specify a dynamic site in some way that is reverse compatible forever the same way flat files are. Ah, but the march toward progress.
You just need to decouple your thinking about the "website" and the "admin of the website". Ultimately, reading the content is a completely separate activity to writing the content. You can have a completely static site, with all the advantages that brings, with exactly the same backend management system you would if it was a dynamic website.
Some static site generators will even do most of the work for you. For example, GatsbyJS has a data connector for Wordpress - https://using-wordpress.gatsbyjs.org/
A lot of users may also chose to disable JavaScript in the future, as more and more malicious actors use JavaScript to exploit people (the latest trend is to hack sites and js- libraries to make other people mine crypto-currency).
I believe the answer to many of todays challenges is to move on to static sites, and to make most sites work without JavaScript. You only need JavaScript if you make a site that is basically an application. A blog or a newspaper is not an application.
For a blogger, another feature with static sites is that they don't require a specific back-end (like wordpres or drupal). As a static site, their thoughts and ideas can live on for millenniums, long after the last wordpress or drupal instances has shut down.
Disclosure: I'm not un-biased here. I'm actually so biased that I wrote my own static site generator last year to make it simple to publish blogs that works great on both mobile devices and PC's.