You know, I'll probably be bammed for saying this, but reading through this very well-made tutorial gave me the opposite reaction.
I am glad I learned and still use PHP and not RoR.
IMHO, there are way too many black-boxes and unnecessary abstractions for such a simple pattern as MVC, which is really nothing more then connecting HTML views to database fields view URI routes.
I recently struggled through my first Ionic mobile app, and all the prebuilt, "auto-magical" tooling stacks and opinionation I see in the tutorial leaves a sour taste in my mouth ie
gem 'rails', '5.0.0'
gem 'puma', '3.4.0'
gem 'sass-rails', '5.0.6'
gem 'uglifier', '3.0.0'
gem 'coffee-rails', '4.2.1'
gem 'jquery-rails', '4.1.1'
gem 'turbolinks', '5.0.0'
gem 'jbuilder', '2.4.1'
group :development, :test do
gem 'sqlite3', '1.3.11'
gem 'byebug', '9.0.0', platform: :mri
end
group :development do
gem 'web-console', '3.1.1'
gem 'listen', '3.0.8'
gem 'spring', '1.7.2'
gem 'spring-watcher-listen', '2.0.0'
end
group :production do
gem 'pg', '0.18.4'
end
All this for a "toy-app"?
Call me old-school (and I am I suppose, altho I feel I make an hell of an effort keeping up to date), but I cut my programming teeth in C and always respected the very limited but powerful instruction set that language implements, and I, over the years now, respect PHP for creating very powerful constructs (like its magical array handling) but also keeping some C-like simplicity at its core.
Yes of course PHP has its idiosyncratic issues, but I still feel that one of the primary reasons it's so disrespected, I'm very sorry to say, is the snob factor thrown off by serious motherfucking programmers whom seem to feel that the simplicity and power of the language lowers the bar so low that it allows the "unwashed" into the room or something...
No. With that stack you can build business and make money. Not a toy app.
That being said, if you were doing a toy app then you would take out PG. You don't need all the dev gems they just make your life easier / faster startup. If you come from php then you like to make your life hard, so webconsole and byebug are out. Your doing a toy app so you don't need turbolinks, coffescript, or Sass. It's a toy so what does it matter if a person downloads 3MB of javascript. Take out uglifier. You're not doing an API so jbuilder is gone.
This is the new Gemfile.
gem 'rails', '5.0.0'
gem 'sqlite3', '1.3.11'
People make Rails out to be some magical monster that know one knows what is going on. It's just Ruby at the end of the day.
Here is a single file rails boot, that includes downloading the gems and running a test.
That's an unfortunate viewpoint. The point of higher level languages is to provide abstractions. To say PHP is just the right combo of not too high level enough but not too low level is some kind of mental gymnastics to justify its existence. The same argument could be made for using C over PHP.
Also, consider that some languages' ecosystems have preferences for smaller vs larger standard libraries. Clearly most of the dependencies you listed are not actually required; they're made to be stripped out if you're not using them. It's disingenious to state that those are the minumum needed for a toy app.
Most of those are optional libraries and rails does a hell of a lot more than a base install of PHP. PHP is also only "simple" if you ignore the god awful language semantics and inconsistencies of both the language itself and the standard libraries.
First, Rails is not intended for toy-app. You can build it but RoR is production ready apps. So the stack you get reflect that.
Also, you can drop like half of those gems if you do not need them.
And finaly, if you are going to do any non-trivial app in PHP you will either reinvent similar libs yourself, or you will use Symfony, Laravel, etc. and get a comparable bunch of dependencies with Composer.
The other day on my way to the airport, I had an Uber driver in Portland who was telling me that he was just about to start a lengthy coding bootcamp in JavaScript and PHP. Not Node, just front-end JS. And Rails was one of the options, but he opted to do PHP with a focus on Drupal.
Kind of blew me away. I know Rails seems to have waned relative to when coding bootcamps first became big, but I had thought PHP was well past its attractiveness for new developers, despite the number of PHP systems that need maintaining in the real world.
This is probably not the popular opinion in this crowd BUT PHP is still the most used back-end language on the web. It has also come a long way since it's early days. Modern PHP is actually decent to work in and learning it will keep you gainfully employed in most areas outside the Bay Area.
For back-end, Python & PHP are still my go to choices. Both are stable, have tons of libraries, have good frameworks and allow you to get stuff done quickly.
While I would've also chosen Rails, the truth is that there's plenty more PHP jobs out there, even in cities like Portland so he'll be fine either way.
There are far more PHP and Java jobs for entry level devs in Portland. Since we don't have very many startups the tech jobs are mostly at financial institutions and non-tech companies.
PHP has a lot less "magic" in it, so using it will force you to learn a lot of concepts and conventions that Rails takes care of for you (which can have its negatives).
Nonsense. It makes great sense to compare some languages to some frameworks, for some purposes.
Yes, PHP is a language, and Ruby is a language. PHP does a lot more than that. A default install of PHP + Apache has routing logic, and HTTP parsing (what populates all those superglobals like $_POST?), it has templating (I'm sure ERB came up with all of its syntax independently), etc etc. In the Ruby ecosystem, you those are responsibilities of a "framework". Indeed, no one would argue that Sinatra is not a framework, but I'm not aware of any features of Sinatra that aren't already delivered by PHP out of the box.
If your goal is to build an artificial and incoherent taxonomy of "languages" vs "frameworks", then yes it's very clear that PHP and Rails are different types of things.
If your goal is to actually build web sites, comparing Ruby+Rails (which you might write as "Rails", since it implies the "+Ruby part) to PHP is a very reasonable thing to do. I think it's utterly clear that the GP was comparing "making a web app with PHP" to "making a web app with Ruby and RoR".
Please, tell me more about that routing logic built-in in PHP.
How does your HTTP parsing deal with Accept:? Does it populate $_PATCH and $_DELETE too? You are aware, that ERB is not the part of Rails and comes as standard library with Ruby? As does CGI module, so you get that "HTTP parsing" as well.
Yes, I was using the terms interchangeably - my bad. Still, Rails has a lot more conventions and magic than Laravel (I don't know about Symfony). Compared to Laravel, you have to deal with a lot less configuration to get up and running. That's what makes it such an attractive choice for beginners: you can work on developing features right away without having to fiddle with stuff. I say this as someone who has used both.
That's a fair point, but I don't think the whole class would've just been Rails. We would've talked about Ruby programming a bit too (the book does as well).
Here's why I think learning Rails would be good for undergrads: You get exposed to patterns like MVC and stuff like server vs client, requests, basic auth/security in a format that is practical and presents itself to fast iteration and quick feedback. I'd much rather learn MVC through Rails than the extremely dull and slow Java GUI apps we did in school.
I think the magicness of Rails is overrated for a beginner. A lot of people like to tinker with low level stuff, but in my experience in college most students wanted to build stuff. Having them build their own routing/template/controllers/etc or whatever would've been less interesting than just learning the high level concepts with Rails first.
As an added benefit, having some experience with Rails would've helped some students get internships.
