Void – A website creation tool
thisisvoid.org
thisisvoid.org
(And neither am I!) See this massive list of static website generators [2], though it, too, probably barely scratches the surface.
My homepage is static and generated in raw PHP. Being originally a templating language, I found it well suited to static generation, even without any framework or tool on top of it. This especially applies if you don't need a lot of "common" features, and have some other specific requirements (in my case, I mainly needed pjax with non-pjax fallback, which keeps the music playing while changing pages - surprisingly badly supported by existing generators).
1/ if (count(array_slice(array_reverse(glob("./article/*.txt")), $_GET['start'], 11)) > 10)
2/ error_reporting(0);
3/ if (trim(dirname(parse_url($_SERVER['PHP_SELF'], PHP_URL_PATH)), '/') === $requestedpage)
I have a math research background: if you can prove something in 2 pages with no extra tool, it's far better than doing the same by invoking a big difficult Theorem.
Moreover, I am not a profesionnal developer. And for me, installing Apache+PHP is enough. I don't want to add more tools, more layers. The list could be endless: Let's use Symfony, Composer, Brew (random name here, I don't know what is Brew)... and at the end I'll have a big big thing...
I really want to keep it simple...
Each new layer is like "minus 10 points" for my project ;)
I read your post, and empathize with the notion of "less is more". The problem arises when you want to extend Void. Instead of providing a good way to do so (using templates and a hook system), you force people to code in a single file without structure that quickly becomes a mess. If you never plan to do anything else with Void than what is provided, that's fine, but in my experience website development just doesn't work like that.
* Adding code highlighting? 3 lines of code to add in index.php
* Adding analytics (unique visitor count)? 3 lines of code to add in index.php
* Adding Disqus comments ? Less than 10 lines to copy/paste.
Is it this you call a mess?
I've used at least 10 CMS before, and what I call a mess is more: having to create a SQL DB, having to login/logout all the time, having to understand how the marvellous "install-a-plugin-to-extend-the-CMS" system works...
It has search, sitemap, comments and moderation etc. but still just a static site generator.
Kudos for shipping!
Anyway, since the code takes only 100 lines, this project could very well be written in any number of languages, I suppose.
You are literally trying to nitpick on PHP's greatest strength, ease of deployment.
The point of Void is minimalism: apache+php, nothing else required. < 100 lines of code in a single php file (+ the markdown parser lib of course).
I definitely agree that less complexity is better, but I think levelling that complaint against (this part of) Hugo is unfair.
The answer is awfully:
1) I don't see how it generates static websites. It generates pages on-demand: http://thisisvoid.org/article/05-perf.
2) The documentation is a tribute to it's name: null.
3) PHP (AFAIK) doesn't do nice URLs like "/articles/article-7", so my guess is that there's some additional configuration done to the web server. Ugly (compared to Jekyll's stupid-simple solution to this).
4) You seem to need to fork it in order to use it (rather than being able to install it and use it as you would any other tool).
You compare :
* Jekyll which is a great tool, with lots of features, but which has at least 50 files & probably 1000s of line of code. It's great but I wouldn't be able to understand 100% of how it works in 2 hours. Impossible. Moreover I cannot install gem (and probably not Jekyll) on my shared hosting. Huh...
* Void, my toy-website-creation-tool (yes, I have no problem with that: it's a toy tool): you can understand 100% of how it works by reading less than 100 lines. Nothing more. You can install it on a shared hosting, only requirement: Apache + PHP.
Yes, you need to open and hack the PHP file of Void to customize. What's the problem with that? It's done on purpose.
Is it mandatory nowadays to use many tools like Brew, Composer, Gem, Symfony, etc. to set up a simple website? (I mixed random names that are required in lots of CMS/static generators I found).
My answer is no: you can do something simple with a "hack it yourself" philosophy. And less of 100 lines of code.
Do you need to understand the internals of every tool you use? Do you know how the PHP interpreter works, the kernel, etc?
> Moreover I cannot install gem (and probably not Jekyll) on my shared hosting. Huh...
Why would you install a development tool on the server? Do you install gcc on servers too? That makes no sense at all.
> You can install it on a shared hosting, only requirement: Apache + PHP.
This pretty much reinforces my point: it does not generate static pages, and actually generates them on request-time.
> My answer is no: you can do something simple with a "hack it yourself" philosophy. And less of 100 lines of code.
Indeed, you can do that. You can also hack your own. gp's question was how this compared to Jekyll, and that's what I answered.
If possible, I like to understand. For Wordpress, I can't (too big). For simple projects, I can and I enjoy it!
> Why would you install a development tool on the server? Do you install gcc on servers too?
At the moment of my last comment, I didn't know at all how Jekyll works, and knew nothing, zero, about Ruby. Never used in my life. Thus my comment. I had a quick look, in the meantime.
> it does not generate static pages, and actually generates them on request-time.
Exactly. Like a CMS, like a blog, like a Wordpress. I never said my tool generates static HTML that should be uploaded to server after each new article. I don't want this by the way. (True that some people thought it was a static generator. My bad, because few documentation yet (currently writing it...))
> gp's question was how this compared to Jekyll, and that's what I answered.
Sure, no problem. I just don't understand why the awfully in your comment. The point of this tool is not to be a static generator. I never said that. Why is it "awful" to just drop .txt files into the server, and let the server and PHP generate content on request-time?
(the polemic part of my answer was related with the other message "The answer is awfully: ..." )
Mine supports arbitrarily nested pages, customisable templates, metadata in YAML at the top of the file and automatic ToC etc.
Largely thanks to the insanely good PyMarkdown library.
For the entire website as an entity, 2015 is fine as the copyright notice and original date of publication.
That's my understanding anyway. Not legal advice.
* Yeah, I made that stat up.
Python/Ruby/Java/node are all awesome to develop on at first (and have excellent development servers) but all PITAs to production-deploy thanks to poor documentation/tutorials, lack of any kind of project cooperation from the major production HTTP servers, and lack of shared hosting services that have built infrastructure to support these.
PHP is easy to production deploy. Drop .php files into /var/www/html. This is unfortunately what keeps PHP going, because newbies like the simplicity of deployment.
I don't get it. I am not a professional programmer or devops and I was able to deploy multiple servers for ruby(rails on webrick, puma and unicorn) and node apps without any significant problems. Over time, I used do/linode prebuilt images, stock ubuntu server, docker containers with and without nginx and did not spend much time or effort in any configuration.
There are multiple easy "git push" heroku-like paas alternatives, docker is available on most popular iaas platforms.
Can you elaborate what exactly cooperation from http servers do you need to deploy ruby/python?
We love GitLab at work as well. But a few years ago it was real pain to set up. Mainly due to having to figure out how to get the correct Ruby version installed. GitLab fixed this issue with documentation describing exactly what version to compile, and how to compile it. The fact remains, though, that I'm not using Ruby from the distro repos, and thus, if a major security issue arises, I won't get automatic updates. If it was more than one server, I'd not be happy...
I once deployed a python app. Then tried to deploy it again, and could not figure out what the heck I did the first time. I still have no idea how to do so. And I never did find a decent tutorial on the subject.
So, ultimately, I prefer PHP. You install mod_php, php, configure your vhost, and drop your files in the correct directory. Done.
As for how experienced I am, I run 50+ vmware vm's, most of which run different applications than the others. Thus, I've had to deploy many different applications over the years. PHP apps are always the easiest.
But how "install mod_php, php, configure your vhost, and drop your files in the correct directory" is easier than "sudo apt-get install node, drop files in the correct directory, run node app.js"?
Your example requires two distinct entities written in different languages using differerent config formats: apache server and php code to run.
Node requires node runtime that doesn't have to be configured and a node app.
Also if you are not ok with configuring apache to forward ports, why ios it ok to configure your vhosts?
PHP apps may be the easiest but deploying single server php apps it is insignificantly easier than deploying single server javascript apps.
Also, if I didn't want to configure a vhost, I don't need to. Just "apt-get install libapachemodphp(always forget the real package name...); copy app to /var/www;" Done. Apache is even automatically told to start at boot.
Deploying Python+uwsgi+nginx on AWS involved another mess of a setup, wiresharking to figure what the hell port uwsgi was running on (the first tutorial I read had a typo ...), and a mess of pythonpath variables. Including requiring both
pythonpath = /usr/lib/python3/dist-packages
pythonpath = /usr/lib/python3.4/dist-packages
Not to mention I had to know to include the python3 plugin
plugins = http,python3
Can't servers just have an auto-configure command? I'll just drop a Flask app in /var/www. uwsgi should detect that it's Python, try to execute it as python2 and python3 (or just read the damn shebang lines and use the correct plugin) and just use whichever doesn't give errors. The server should just figure out what ports things are running on, where plugins are located. Auto-scan the newly dropped code for all import lines, search the file system for the right paths, and cache the result; if it still fails, try to just pip install it, and if pip fails, try to apt-get install python-* it.
Save the final auto-configuration result.
Manual configuration will always be an option, but in 99.9% of applications most of this deployment process seems pretty easy to automate.
Easier than /var/www/, in my opinion.
I like that Google App Engine can run Flask, for example, while abstracting away all production logic; we need more things like that.
Part of my point is that I think if we, the development community, want to popularize frameworks with better engineering design, e.g. RoR, Python+Django/Flask, and so on, we'll need to think more carefully about what the newbie experience is like. Because newbies look for instant gratification with something (anything!) and then build up and out from whatever that something is. If the easiest door to open is PHP, they'll keep building with PHP for years. Unfortunately, the easiest door to open is still PHP by a longshot.
The reality is that the easiest way for a beginner to do a finished product is a make as static HTML webpage with Javascript fetching dynamic data from a remote datastore/website. The cognitive load of request-response model from the client side view is much smaller than from a server side and you actually write your first code in any browser console.
Sure, we can then work around the allowances we make for newbies, but complexity is the bane of reliable software.
If you like stats in the same fashion as yours: http://www.thisisvoid.org/article/04 ;)