Hacker News Reader

Comment by bikamonki | Hacker News Reader

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...

* Yeah, I made that stat up.

View on HN

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.

You can deploy node on IIS.

To be fair, if you're using a web server other than Apache, PHP involves an equal amount of pain.

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.

The problem with making things simple for newbies is the knock on effect of making it hard for non-newbies to do non-newbie things.

Sure, we can then work around the allowances we make for newbies, but complexity is the bane of reliable software.

>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.

You are totally right that GitLab used to be hard to install, it took about 10 pages of commands https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/inst... Since a year we have Omnibus packages that solve that problem completely. It takes two minutes to install or update. For more information please see https://about.gitlab.com/downloads/

Deploying Python on my school's web hosting service involved writing this horrendous mess of a .fcgi file: https://github.com/dheera/web-sustainabilitysummit/blob/mast...

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

in order to function (like, WTF)

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.

http.createServer(...

Easier than /var/www/, in my opinion.

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.

cPanel claims to have support for RoR. Who knows, they might support node too one day. Won't hold my breath waiting, though.

Yes exactly :) I was fed up about using an 18-wheeler for each small project-website I had to set up ;)

If you like stats in the same fashion as yours: http://www.thisisvoid.org/article/04 ;)

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 :)

Reply on news.ycombinator.com