Hacker News new | ask | show | jobs
by joelbluminator 1895 days ago
You mean simply running Discourse (a Rails app) is so complicated no one wants to do it? And if it was simply PHP boom business would have been booming ? I find that a bit hard to believe.
4 comments

Deploying a Rails apps is, in general, harder than deploying a PHP app.

I'm not convinced that Discourse is the right example here, though. Arguably the actual steps for installing Discourse aren't significantly more complicated than WordPress's install, because they've gone out of their way to make it as easy as possible. (It does suffer from "you must use Docker for this," which would likely intimidate non-techies who could otherwise suffer through a WP install, though.) Also, I don't think Discourse can remotely be described as an abject failure, given that virtually every forum I've seen go up in the last five or six years runs on it, and I can think of more than a few sites that migrated to it from legacy PHP forums in that time.

> Also, I don't think Discourse can remotely be described as an abject failure, given that virtually every forum I've seen go up in the last five or six years runs on it

Two thoughts and personal observations on that:

1. Nobody was ever fired for buying IBM. In my impression it's usually deployed as default for and esp. by very tech affine communities. It was the new, hot - and is now save - thing in town.

2. You see postings boasting how the Discourse forum is now powered by a new six core 8 GB RAM server improving performance ... for 200 concurrent active users and 80k posts. Yes, Discourse offers a lot of flashy features, but that's just borderline disgusting.

> how the Discourse forum is now powered by a new six core 8 GB RAM server improving performance ... for 200 concurrent active users and 80k posts.

I guess companies that use Discourse and have huge traffic can pay a bit more, nothing wrong with that.

> I guess companies that use Discourse and have huge traffic can pay a bit more, nothing wrong with that.

The point being that said numbers aren't big traffic, they should be handled by a Raspi.

But for the sake of argument: Discourse is a painless move upwards for big budget and/or big knowledge entities. Nothing wrong with that.

On the other hand Discourse isn't a replacement for low cost, decentralized, easy to deploy, engine-diverse, low knowledge communities which were served by a multitude of PHP solutions in the past.

There's an economic argument for a growing divide between "communities as a service" ala Facebook and high hurdle deployments ala Discourse, but one doesn't have to be happy about this development.

So not sure I'm following, the php solution can handle huge traffic at a low cost with a conmparable feature set? How do they achieve that then? Taking a look at phpBB it looks like they are not using a framework (e.g https://github.com/phpbb/phpbb/blob/master/phpBB/posting.php). This is good for performance but pretty shitty for an OSS proeject, anyone looking to contribute here needs to start from scratch. Discourse happens to have 4x as many contributors. Also I can't imagine the feature set of the 2 projects is even remotely similar.
To be more fair, the PHP forums tend to be much older codebases, before standout frameworks and index.php front controllers.

Much like Wordpress and phpMyAdmin, these projects are basically victims of their own success.

> This is good for performance but pretty shitty for an OSS proeject

I don't see how. The repository seems to be quite active and has plenty of current pull requests.

Well, an entirely non-profit -- at this point, in fact, unincorporated, with no assets to speak of at all -- writing group that I'm part of migrated their forum in 2019 from a PHP forum package (I think SMF, although I wouldn't swear to that) to Discourse, and it runs just fine on what I'm fairly sure is a $10/month Digital Ocean droplet.

I don't doubt that Discourse requires more resources than most PHP forum packages do, but it doesn't need that much more.

What's harder about deploying a Rails app? Generally interested. How does it go in Laravel land then? Rails have quite a few dependencis (Node, webpack), how is Laravel handling front end?
I'll preface this by saying I'm probably getting a little ahead of my skis. :) But, I think the issue is less how modern PHP is handling all those modern dependencies and more how "old" PHP didn't make you, the person installing the application, have to know anything about them. Those old-style apps, which include WordPress and many forum software packages, get "deployed" by

1. Downloading the application archive and uncompressing it

2. Creating a MySQL database according to the documentation

3. Either editing a small config file to give the application the database credentials, or even just going to the application's index page and filling in the details on a first run experience

And... that's it. Rails has no comparable experience, unless -- like Discourse -- you put in a lot of work to get it there.

Laravel -- and Symfony -- work basically like other "modern" frameworks do, for both good and bad. Laravel has "Mix," built on webpack, for instance. So if you're looking for that in PHP, it's there, but that's kind of a tradeoff in the context of small sites deployed/managed by a single person -- a use case that I think modern webdevs sometimes lose sight of. If we go back to the example of forums, those are very often that "one person wants to host a forum for their community" kinds of things. (And I'd like to see more of us get back to self-hosted blogs -- which is part of what led me down the road of "can you write something in a not-PHP language that's still easy for someone who doesn't know anything about web development to deploy and run." The answer still seems to be "reply hazy; ask again later.")

Developers underestimate how difficult it can be to deploy server-side code for web apps or dynamic websites, particularly for less-technically minded users.

As other posters have mentioned, PHP code can be as simple as uploading files to a folder on a server using a GUI FTP app. (And for some non-technical users, even that might be too complicated).

By the way, Jeff Attwood (co-founder of Stack Overflow and one of the founders of Discourse), had this to say about PHP:

"If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option." [1]

When did he say this? 2012.

It's now 2021 and has anything changed? Not really. Yes, we have Docker, Cloudtron, or Sandstorm etc but none of these are simple or easy to install or use. (A developer's definition of 'simple' and 'easy' bears no relation to the real definitions of these words).

Whatever you think of PHP, consider the following question: what language can match or beat PHP for ease of server-side deployment?

[1] https://blog.codinghorror.com/the-php-singularity/

But almost no one writes php alone. Maybe hobbyists or Wordpress users. When we talk about actual applications that talk to a db - people use frameworks. Is deploying a Laravel app so much cheaper or different than a Rails app? Yes if all you need a wordpress website PHP is obviously the way to go. If you're an app developer PHP loses this edge quite quickly. Also I'm not sure an ftp setup is easier than Heroku.
You "CAN" upload laravel to bluehost or any shared host and it will work, you may need to cut a few bits, or use external services for redis/sqs/etc if you want to use those things, or you could just use file/database for sessions/caching/etc.

I mean I started laravel on shared hosting, why did I use laravel for most of my career? Because the job I was hired for was to build a custom CRM for a book business, I was learning Rails so I spent 2 weeks on a rails prototype...

Boss gave me access to their hostgator account - shared hosting and told me to install it there. I stared blankly at them, um... okay.

Rails version I built in didn't match and I couldn't figure out for the life of me how to make it work...

Laravel 4.2 was almost a complete 1:1 match (in terms of directory structure) to rails and the language was just a bit different so porting what I had to laravel was a cinch and I had it done in 3 days and up on hostgator. No problems.

Also if you're like me and you freelance/consult, there's a TON more business in existing software/legacy than there is in new builds. Wordpress, Shopify, Laravel, Drupal, Magento, Salesforce are probably the FAANG of freelance platforms to learn to earn income from.

PHP is also generally faster than Ruby, and with Swoole it's sooo much faster (even than elixir/phoenix), so really why not use laravel/php. There's also tons of great packages out there and tutorials. The community is freaking HUGE.

Rails you even have to roll your own auth system or use devise which is a PITA. Laravel it's more opinionated but it's built for you including 2fa, social/oauth, etc..

Which isn't to say I wouldn't use fancier langs, I'm jumping at the bit to build some backend apis in rust or go for the hell of it, but only when I'm the decision maker as CEO/CTO on a side-project. For bread and butter I'll stick w/ what I know I can get paid for which is PHP/Laravel/Wordpress/Vue/Livewire/etc.

Shopify is Ruby based btw... But I'm not taking anything from PHP, it's a sound career choice with lots of big platforms (Wordpress/Magento). Just not sure I understand the deployment story. Deploying Laravel should be as easy or hard as deploying Rails.
Shopify is hosted.
> But almost no one writes php alone. Maybe hobbyists or Wordpress users.

What about that one guy who made https://remoteok.io/ using a single PHP file with no frameworks or libraries?

According to this live chart https://remoteok.io/open he made $88,000 last month from it alone with a 90%+ profit margin.

But more importantly it's a site that technically functions well and looks appealing. End users really don't care about which tech stack you used to build your site, they just want it to be fast, look nice and be easy to use which is achievable with pretty much any language or framework nowadays.

I don't know what this proves. Most people who talk to a db and grow their app will go for a framework, are you disputing that fact?
It 'proves' that a lot of people, yours truly included, do not use frameworks
As a front-end developer I can agree with that.

Many times when I've wanted to install something for my needs, like forum engine or something similar, I was looking only for an PHP option.

Why?

Because it really is a copy-paste process with typing credentials to your database into dedicated file. No need to know any language/framework-specific commands, and no need to be overwhelmed by missing dependencies.

And in huge addition to that, simple PHP hosting is extremely cheap - for years I've been paying for my personal server ~$20 PER YEAR, where servers that enables you to use Node/Ruby etc. costs around at least $10 per month. This is a huge game changer for me.

Discourse is a pretty complicated piece of software (relatively). They do: mailing list, discussion forum, long-form chat room, This isn't gonna be some static blog, it's feature heavy. It needs redis, it needs some real-time chat capabilities etc etc. Also the choice to use a framework (Rails in this instance) was sound since it's complicated. So when comparing deployments you need to compare it to the php equivalent (Laravel). I think deployment and memory footprint are gonna be quite similar then.
So is facebook, and they wrote a lot of PHP for their first decade.
Have you tried installing Discourse? It's not that straightforward. And then there's also the issue that you need a working e-mail setup, even if you only want to set up a local test environment.
And how would php solve the e-mail setup issue? I'm not saying it's straightfoward and I don't know Discourse at all. If they have dependencies like redis etc then yes it's gonna be more complicated. Just don't think a framework like Laravel would have been easier.
Obviously if the project requires working emails, PHP cannot solve it. If I understand the parent comment correctly, what it says is that sending mails with PHP is usually less problematic than other languages (IIRC from the last time that I used PHP -several years ago- their mail() function works OOTB almost everywhere, even on shared hosting, and is usually used by default or as a fallback).