It's easier point to framework that's already using PDO and and making sane defaults and solving bootstrapping problems. Once you've learned bunch of new concepts like ORM in one framework, it's easy to understand other ORs and be able to compare it to DMs.
My own experience with Laravel has been really positive. Actually I was thinking about creating something similar until I learned about Laravel, so it solved lots of existing annoyances regarding PHP coding for me.
Everybody needs to start somewhere and I believe that by nudging towards Laravel, my young friend'll learn more in the long run and in the meantime can concentrate on making services instead of writing home grown PDO helpers and custom routing libraries. They are problems that have been solved already multiple times.
Also, Symfony and Laravel communities are encouraging and teaching about the better ways of doing things so that'll help him in the long run.
In many small project it's more fun and more easier to use $favorite_framework instead of searching for reinvented wheel. There are cases when it's better to do more custom solutions but for many cases frameworks are just awesome
Yeah, that's basically why I wrote EasyDB. https://github.com/paragonie/easydb
$rows = $db->run('SELECT * FROM comments WHERE blogpostid = ? ORDER BY created ASC', $_GET['blogpostid']);
foreach ($rows as $row) {
// etc
}
In a language that already has string interpolation you're telling them to use a crappier custom version of string interpolation that's safe for databases.
Tutorials need to be more upfront about that.
I may be wrong, so please correct me if so.
Over the years, we built one in-house at http://qbix.com/platform/guide/database because we couldn't find one. It does things like sharding out of the box, because it's able to understand the query's criteria and target it to the right shards.
As an interesting side note: Laravel's AR ORM (=Eloquent) is built on top of the Query Builder so you can leverage Query Builder with AR if you know what you're doing. Can also lead to big problems if you don't realize the possibilities and the caveats.
Chicken and egg.
Education is the security strategy that pays forward the most.
There's no technical reason the language couldn't make it so that string literals can be identified at runtime.
There are several good ways to put a stop to SQL injection. Better education is one, better APIs is another. There is no reason to just give up on the idea of using SQL queries directly because of injection attacks.
...
The answer is: Data being treated as an instruction.
Solution: Separate them so that data can never be interpreted as an instruction!
In SQLi, this solution is to use parameterized queries. You send the query in one packet, then the parameters in a second one. SQLi is thus prevented.
(Not that SQLi is the only vulnerability possible.)
So, yes, total agreement there. Parameterized queries are key. I find it crazy that anything else ever existed, let alone still gets used.
Most people don't realize how much these vulnerabilities have in common, in the abstract, until you frame it like that.
Some wants to learn from bottom up(analytic approach), others want to see cool stuff then tweak, modify, replace to find the limits (holistic approach).
IIRC there is a tendency that young people prefer the holistic approach while teachers either are selected for or grow into preferring the analytical approach.
"Make them suffer like us and they will learn the holy truth" ;D
It's not like you learned to speak with your parents reading you the dictionary beginning with the letter A.
Some do, some don't.
jQuery is a common way to learn to do front end programming. It saves a lot of time when used well. But it is important to extend the knowledge to core javascript and be able to write code when jQuery is not available (like when writing scripts to embed on different sites).
Can you name a few such annoyances and how Laravel addressed them?
And do you mean to say that Laravel addresses them, while other frameworks don't?
Depending on what you mean by "move faster", I may have to disagree. Besides a one-off script, I can't envision a scenario where using "tools and libraries" would allow you to move faster than using Laravel.
Laravel comes with an unbelievable amount of stuff done for you, right out of the box. Routing, Auth, Database, Queueing, Caching, Asset Pipeline, Templating, etc, etc. If your goal is to rapidly develop an application, there really is no better framework than Laravel to get that going. There's even a vagrant box that's all tooled for Laravel.
TBF, I may have misunderstood what you meant by "move faster".
I've been a PHP dev for 15 years and the biggest issue with frameworks in PHP is PHP itself. A request comes in, the PHP process loads up everything, executes the request and tears down...on every single request.
In just about every other language, the application boots up, loads everything into RAM and each individual request doesn't have to reload things.
There are definitely trade offs here. You can have a 1 TB hard drive filled up with PHP code on a 256mb of RAM server and everything is still going to run fine. There's a lot of value in that and most people who are PHP averse seem to be turning to Lamba from AWS to fill that gap. PHP scales down better than just about anything else out there.
When the other commenter mentioned doing lightweight scripts with PDO that's essentially what he meant though. Lightweight avoids reloading libraries and PHP is lightning fast when you do that.
A lot of progress has been made over the years to help PHP handle frameworks better, but there's a big reason why PHP grinds to a halt with heavy frameworks and that's it. Check out the techempower framework benchmarks.
Using PHP like Go, however, and just pulling in what you need can be extremely powerful.
Here's an entire presentation on it that I gave to a local PHP group. http://www.slideshare.net/barrywjones3/whats-the-right-php
FWIW, I do really like Laravel and even recommend it if you HAVE to use a big framework.
Wouldn't that make debugging much much easier? Since you get a clean slate for every request, bugs can now be tracked and replicated in a saner way. I personally prefer this method for building and maintaining a huge and complex application despite knowing that it may not be an efficient one.
Without a heavy framework, you get the best of both worlds.
It's called the "shared nothing architecture", and its by design. Nothing is shared between requests, so why _not_ tear down?
That model actually has a lot of benefits for web applications (it scales very well), and I consider it one of PHP's strong points.
Is Laravel really a Rails clone? I thought that was Symfony. I honestly don't understand why the most popular PHP frameworks are all Rails clones. In my own work, I made things more in a PHP style than Ruby.
The current implementation uses shared memory.
In addition, that does not mean retaining all the variables and data, only the compiled opcodes and that's the bulk of the startup time.
This guy said it better: “Frameworks invert control. They control the lifecycle of the app, and give you entry points where your code runs. You’re still responsible for the final code, but you’re not in control.” https://aerotwist.com/blog/the-cost-of-frameworks/
...why didn't you taught him about PDO, so he can start with something more universal, not tied to one particular framework that happens to be popular nowadays?!
Then he can learn whichever OR/DM or DAL he might like need (Eloquent, Doctrine, Redbean, IdiORM/Paris etc.), and also be able to pop the hood and debug it when needed.
I never get it why so many otherwise-good PHP devs have their heads full of framework-specific knowledge and have a propensity to fall in love with heavy frameworks like Laravel, or worse, with leviathans like Symphony or Zend ...instead of playing to the language's advantages and using light-weight tools and libraries that would allow them to move faster.