Yessss! Except I get heartburn when I eat PHP :) Maybe I can port the 100 LOC to JS and try a node version! Code flavor aside, your logic is right on point: for 99,99% sites out there* a CMS like WP is like using an 18-wheeler to go do grocery! Why did that happen? My only explanation is that The Home Depot is behind this whole DYI website non-sense...
My solution is called Statico: a json file with all the site content and front-end magic to display it. A locally run software allows me to edit the pages, upload images to S3 and update the json file. The additional advantage in my opinion: no server. All hosted on S3 :)
As much as I too hate PHP is as a programming language, I'd say it's fine for this though, where it's being used effectively as a more powerful version of server-side includes.
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.
Sure, but newbies don't care about "web servers other than Apache". They will just use Apache, or whatever can deliver instant gratification.
And non-newbies, in general, don't use PHP to start new projects.
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.
As someone who helps people to learn programming, I'd like to challenge your statement that PHP "is an easiest door to open.. by a long shot".
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.
>Python/Ruby/Java/node ... all PITAs to production-deploy thanks to poor documentation/tutorials
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're deploying several tomcat apps at work. Each of them have to have apache in front to proxy from 80/443 to 8080/8443. We tried to get jcvs(or whatever it's called) working, and it did not work. Thus, deploying java apps is a pain. Seriously, do they expect me to ask my users to add the port number to the url?
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.
Okay, I don't know much about Java, its vast and sparsely connected ecosystem scares me and I am not going that way yet.
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.
The vhost does not really need to be configured if you have just one of them. I'm sure the default apache config handles that just fine (listening on any address port 80). Also for "run node app.js" don't forget "add a script that runs 'node app.js' at server startup".
I think Kibana 4 is a node app, right? Like lmz says, you have to write a script to tell it to start at boot. I ended up using Monit for that, but if I didn't know about Monit, I'd end up having to write a custom init script. Oh, and Tomcat apps can end up like that as well...
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
Not to mention I had to know to include the python3 plugin
plugins = http,python3
No tutorial told me that the 'python' plugin couldn't handle python 3.x. Yep, definitely not newbie-friendly ...
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 as a developer perhaps. Does that not require init scripts to keep it running if the server is restarted? (I'm not sure how the typical node package is configured).
Yes, also, this requires being able to, having access to, and having money for a virtual machine. Most newbies start with free or nearly-free shared hosting services.
I like that Google App Engine can run Flask, for example, while abstracting away all production logic; we need more things like that.
Interesting. I built something almost identical except used JSON for the parameters at the top, used plain old HTML for the content and did all the beautifying with CSS, and powered it with Python+Flask instead of PHP.
I have nothing against PHP but it would be great if this is built in a language like Go so that anyone can download a static binary without any dependencies.
Looks nice but when I click "Install" on home page of gohugo.io, I see: "brew install hugo". Another tool that I don't know: "brew", and that I probably cannot install on my shared hosting server.
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).
Immediately above that it has a big button that says "Download", which takes you here (https://github.com/spf13/hugo/releases). Above the `brew install hugo` part, it asks "Using Homebrew?", implying that option is for people already using that tool.
I definitely agree that less complexity is better, but I think levelling that complaint against (this part of) Hugo is unfair.
I believe the CMS should build on your local machine and then be pushed to your hosting after it builds the static files. Like Jekyl. That's how I'm reading it, and brew references Homebrew, an OSX package manager.
Hugo is a static site generator much more fully featured than Void, so IMO its not fair to compare on LOC. As far as brew goes, that is just for convenience. You can might as well download the static binary from the releases page - https://github.com/spf13/hugo/releases
How far along is hugo? I tried and failed to make the blog I wanted with it and had to hack around its deficiencies. I appreciate the fact that it's a single static binary, but its directory structure is overly complicated and arbitrary things don't work.
A PHP file has less dependencies than a Go binary. There's over half a billion websites. There are probably under 20 million people in the world who know what a "static binary" is, fewer still who have the knowledge and resources to deploy one on the web. The vast majority of people with websites can use this PHP file as-is, with no additional learning or work -- just FTP it over to any penny host in the world. They'd not be able to do anything useful with a binary file.
I respectfully disagree. A PHP file may have lots of dependencies. And worse, these dependencies are mostly hidden. (Think of libraries used from within the PHP file). You can't tell if you have resolved all dependencies until you have fully tested all of the functionalities of a PHP file!
Anyway, since the code takes only 100 lines, this project could very well be written in any number of languages, I suppose.
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).
* 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.
You only have to install Jekyll locally, it generates plain-jain html files. Thanks for the info on the differences. Congrats on making a neat tool, I was just legitimately curious as to how they would compare. Cheers!
> * 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.
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.
> Do you need to understand the internals of every tool you use?
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?
Oh, it's controversial, somewhat edgy, political nonsense, but I might end up using this for some other project as well, and then I'll certainly share the URL :)
Having 100 lines of code is not something to be proud of, especially if the lines (3 examples picked arbitrarily) look like this:
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)
Though I really hate to blame the programmer, projects like these is what gives PHP a bad name; "Oh look another undocumented, untested, write-once piece of PHP not confirming to any standards whatsoever!"
"Static site generators seem like music databases, in that everyone eventually writes their own crappy one that just barely scratches the itch they had (and I'm no exception)." [1]
(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).
I am pro PHP, but this is honestly an awful display of PHP usage. Templates mixed with logic inside the main php file? Check. Not using Composer for dependency management? Check. Reinventing the wheel when it comes to routing instead of using a battle-tested component like the Symfony Router? Check. Three strikes, you're out!
One of it's features is that it's "A single PHP file of less than 100 lines of code." - Adding all these things you listed would just make it more complicated for no good reason. I'm all for sticking to best practises but in that case it'd make no sense. This is supposed to be deployed easily on shared web hosts, installing dependencies wouldn't work there.
Well it could be 5 lines of code. To edit the output you would have to fork the project for no good reason. Templating exists so you don't have to do stuff like that. Regarding dependencies, you can provide a pre-built zip archive with the dependencies installed already. Then it's just a matter of uploading the folder.
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...
If the OP is claiming copyright they only need to claim the year of original publication. Technically, not even that. To print the copyright as the current year doesn't make sense. Unless:
- The copyright is on specific content, made in the year indicated.
- The content is substantially revised (should just add a year, not replace it.).
For the entire website as an entity, 2015 is fine as the copyright notice and original date of publication.
Related - anyone have the link to "the last anonymous hosting service"? If you send him a dollar & a un/pw he would set it up for you. I think "void" was in the URL, too.
66 comments
[ 3.3 ms ] story [ 53.8 ms ] thread* Yeah, I made that stat up.
If you like stats in the same fashion as yours: http://www.thisisvoid.org/article/04 ;)
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.
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.
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
in order to function (like, WTF)Not to mention I had to know to include the python3 plugin
No tutorial told me that the 'python' plugin couldn't handle python 3.x. Yep, definitely not newbie-friendly ...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.
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.
Kudos for shipping!
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.
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 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.
(the polemic part of my answer was related with the other message "The answer is awfully: ..." )
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?
It has search, sitemap, comments and moderation etc. but still just a static site generator.
(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]: https://news.ycombinator.com/item?id=7747651
[2]: https://staticsitegenerators.net/
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...
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.