Comment by mhd | Hacker News Reader

Comment by mhd | Hacker News Reader

Parent Full thread

I would say that e.g. the current Rails stack actually is quite complicated, but that's because the current web stack is a horrible mess and Rails does the brave attempt of managing all, from providing images to delivering JS packages to friggin' websockets.

This isn't contrasting Ruby to PHP, this is contrasting the web that was with the web that is.

And actually, even when Rails was founded the PHP stack was inadequate for this -- which is why current practice includes all the parts that antirez is complaining about? Gems? PHP has composer, barely any serious project doesn't use it. Rack? Granted, once the PHP server is setup you don't have to account for an abstraction layer. Rakefiles? I don't think there's a standard task runner for PHP, but e.g. Laravel has envoy and I would assume that almost any project needs some kind of shim there, even if it's just shell scripts. YAML? Well, erm, ok, I won't defend that…

The times where PHP means directly accessing a `.php` file for every "page" have passed by. If you look for simplicity there, oh traveler, beware…

This is the app antirez was complaining about: https://github.com/antirez/try.redis

It's not even a Rails app. No idea what he was complaining about exactly, but certainly not Rails.

RoR shares the features he was complaining about and then adds some more. As do most other frameworks concerning the same type of web apps, including those written in PHP. And sadly most of it necessary, if you don't just serve templated HTML or provide an API. Once JS gets into play and you have to invite friendly Mr. Webpack, the blood-dimmed tide is loosed.

Looking at the original app, the Rakefile for example seems mostly to be there to start Redis? How would we have done this in the olden days of the *AMP stack, assuming the task has to run on both Windows dev machines and the Linux server? Heck, we might not have been able to do this at all, if we just had file and not shell access...

That's pretty much where I was getting at. The stack he complains about is very barebone, and I doubt he'd have anything simpler with PHP or any other stack.

> rake

As you say it's a simple task runner like make. Maybe use a shell script instead, but appart from that, hard to be any simpler.

> rack

That's just an interface, the equivalent would be mod_php & co, not any simpler in my book.

> gem

Not sure what's there is to complain about here. It's a fairly straightforward package manager. Unless you stick to the stdlib, I doubt PHP packages are any easier.

> yaml

Many people hate it, but for simple configuration it's not any worse than JSON or XML. Matter of taste I guess.

I'd be happy to hear or more detailed complaint from antirez, but I don't think anything can be inferred from that single tweet. This reads like someone who hasn't worked with Ruby in a while, and is grumpy he has to figure a few things out again.

It's true, the requirements for web apps became bigger. If you compare Rails to Spring it's actually very simple. It's comparable in time to learn to Django/Laravel

> This isn't contrasting Ruby to PHP, this is contrasting the web that was with the web that is.

Wait, are we really calling Ruby/Rails the "is" of web development in 2020?

I'm calling the current version of RoR able to provide what the "is" state needs, while staying within the Ruby world (like antirez' example did). My point was that basically any other stack would be at least as complex when it comes to the infrastructure than this, most likely even PHP.

Huh, I really don't see that. Modern web development usually means some Vue/react/angular frontend decoupled from a backend that could be running literally anything. I'd give php some performance props over other scripting languages but obviously there's go/Ruby/python/whatever in the mix and they all work admirably enough and are usually reverse proxies.

I don't know what you call 2020 web development but in last 2 years i'v been able to co-develop several web apps in Node.js and also complete "serverless" ones using only AWS services and oh boy.. Rails is still so far ahead

Rails is effective and nice to work with, PHP isn't half bad. I think these languages got a bad rep by frustrated Cobol developers or something...

Reply on news.ycombinator.com