So what, you rewrite a templating engine every time you want to make an application that outputs user data? Or are you reliant on making damn sure you always call htmlentities every time you echo something to prevent XSS? Are you sure you've not slipped up anywhere?
What about CSRF? Do you write your own filtering mechanism every time you make a web app to check for the existence of a CSRF token in all state-altering (e.g. POST) requests?
There are reasons people use frameworks. Security is one of them - I _love_ assessing apps which are written in plain PHP because they're almost always a trainwreck. You don't tend to see SQLi from devs who tend to use ORMs, nor do normally you see stuff like LFI if they're using a well-known templating engine.
Can you write secure code in PHP? Absolutely. But it's more effort and easier to get wrong.
Your client may not care about the technical details, but when the security assessment report says your PHP app has a stored XSS and an equivalent ASP.NET MVC app is safe..
Frameworks are much better at handling most security needs.
I'm constantly shocked and amazed at the beginner mistakes riddled throughout these hip cool kid frameworks. And the dependencies of that code, and their dependencies, and the build system, and the management of the build system. It's a 5,000 hour a week job fixing all that and someone else will just go in and break it again.
So no, don't tell me to stop my life and fix everyone's mistakes. This is why there's 10 person teams to build an ecommerce site these days. This used to be a weekend project before all these slick stylish tools took up everyone's time.
Most people are incompetent and the more complexity you have, the greater your chances of getting crap code tearing your system apart
Why would I use something as a core piece of infrastructure written by people I'd never even consider hiring in a million years?
All too often you're standing on the shoulders of people tripping over their own shoelaces.
No thank you.
It’s totally OK for a prototype to be a trainwreck because its purpose is to give you the ability to launch it in front of potential users, show them a few features and get their feedback.
I'm unsure anyone here is disputing this - my original comment said as much:
> Can you write secure code in PHP? Absolutely. But it's more effort and easier to get wrong.
It's undeniably more work to get right, though. As an example, if I create a new django app "the CSRF middleware is activated by default in the MIDDLEWARE setting" - you're safe by default.
I mean, even as a basic DiD measure PHP could use SameSite cookies by default for its sessions - but does it?
Yes there's convenience in "somebody already thought about everything you need before you did" but there are also security libraries, checklists, tutorials, and other tools besides a full framework with all its baggage to help developers write secure code.
> True speed comes when you don't have to deal with other people's bugs and poorly designed mistakes.
PHP is often, in practice, a language where bugs are more likely compared to these "stylish" other languages you mention. [0]
[0] http://delivery.acm.org/10.1145/3130000/3126905/p91-ray.pdf?...
" For [languages] with positive coefficients we can expect that the language is associated with a greater number of defect fixes. These languages include C, C++, Objective-C, Php, and Python. The languages Clojure, Haskell, Ruby, and Scala, all have negative coefficients implying that these languages are less likely than average to result in defect fixing commits."
Actually, the link is not working on mobile. Maybe it will work on my desktop.
There's nothing less "vanilla" or "standard" with python/go/RoR/whatever vs. PHP. It just so happens that you know PHP well, so, by all means, YOU should use that.
you've understated it.
And while I'm not a huge fan of working in PHP, it has its place— my remark is unrelated to that.
I guarantee someone who knows how to work a framework can turn out the same work much more quickly and more maintainable than someone who is working from Vanilla PHP and having to implement basic logins and email templates on their own. And a "throwaway project" can also be turned into something customer facing much more quickly as well.
I agree, you don't need to pick bleeding edge tech, but you should pick something stable and well documented and run with it rather than basically having to rewrite the same project in the framework once you've got it up and running in vanilla PHP.
Don't get me wrong, I am very fond of sqlite, but to use it efficiently you have to manage the connections to the database and from what I have heard, that doesn't work particularly well with PHP.
This doesn't mean that the above recommendation is wrong (in fact, I used similar approaches in the past), I just thought that it should be mentioned and if someone wants to build something that has a lot of concurrent users by design, he knows which part will be the first bottle neck.
However, I'd personally always use postgres in this case, myself.
Yes, but the person who has to code it cares. No reason to choose the worst of widely used programming languages and the worst possible database for asynchronous read/write patterns inherent to web apps, except as an exercise in masochism.
Oh, you mean javascript?
...it is also why php is not really any significantly better choice than any other framework/language combination.
The benefits of ‘plain php’ (simplicity) disappear quite quickly when you’re doing anything non trivial.
I would never choose php without one of those framework stacks; it doesn’t scale, its prone to hideous security issues and its a fugly mess of reinventing the wheel.
Frankly, anyone doing this these days has no idea what they’re doing.
So there is never any scrutiny, no experienced person is going to expose themselves to ridicule so all the problems are discovered years later only for a new one to take its place.
Ruby for instance has huge deployment problems, why the hell do you need a build environment on deployment and expose end users to installing hundreds of gems that may need to be compiled and can fail anytime? Same with the wild lands of NPM. It's as if people have endless time to go down all the rabbit holes.
On the other hand Facebook, Wikipedia, Wordpress, Slack and some of the most scalable sites online today use PHP. Yet according to the the hivemind PHP is somehow a disaster, and the next over-engineered complexity is the panacea. This is just not credible.
Unless there can be a way to apply scrutiny during the hype phase the cycle of over-engineering, needless complexity and offloading bad engineering on end users is going to continue.
Like Rails, you can get a a site/app up in minutes. .
Throw in the utterly fantastic documentation (that is both more detailed, thorough and better organised) and I'm not sure why Laravel took off the way it did.
I used Laravel for 3 years at a previous job (from 3 to 4 to 5) and I still think Symfony is the better basis for anything that isn't a relatively small application.
Also Symfony components are genuinely de-coupled, documented on how to use them stand alone and useful for that (I gradually brought them in on an inherited project with few issues).
I hadn't upgraded sooner because it had worked, but then due to issues with my stack. I decided recently to start from scratch and upgrade my toolset as well.
So I was deciding to either go symfony or laravel. Laravel won by a huge margin. From the perspective of a newbie. Even though I have 10+ years developing in PHP, I like to debase myself and approach with no baggage.
Laravel has so many more tutorials than Symfony 4 on Youtube. I wanted to learn and very very fast. So going through videos in 2x speed and getting the gist of how things worked was great.
Continuing on, there were many tutorials which had actually built apps using Laravel 5.5/5.6. So I was able to quickly get up to speed using Validation, Eloquent, Passport, Middlewares, Query Builder, etc.
On the documentation side. It's very easy to use and describes simply how to get things done.
Next was that Laravel had VueJS integration. So out of the box, I could have an SPA and use Laravel effectively as an API. Of course, right now I am one developer so 1 codebase is fine. But later on, if I need to split and have two codebases (VueJS front-end, Laravel API), then I can do that.
With Laravel I've gone from writing straight SQL to using the ORM. Which surprisingly for me, reduced my codebase by a significant margin and surface area for bugs.
I have found that there are a lot of Laravel composer packages compared to what I was using before and again makes my life so much easier.
Finally, there is a bit of synergy between Vue and Laravel. For example, I'm able to post a form with Vue using Vee-Validate for the validation. Then get laravel to post back any errors for Vee-Validate to consume. In jQuery and using my old codebase. I had to jump through hoops to get it done and much more code.
I will also say, that I had actually decided to go with Symfony in the beginning. The main reason was that Symfony was more pure and I have developer friends who recommended it as the way forward.
> and I'm not sure why Laravel took off the way it did.
It took off because with Symfony, try as I might. I just couldnt get on with it. It wasn't as pleasant experience with Laravel and honestly. Even if I persisted. The time that I took to go from zero, to duplicating my own stack was a few weeks.
I don't think I could have done that with Symfony. Yes, I could probably achieve the same result with Symfony. But not in the same amount of time.
As still a new laravel developer. I want to be able to deploy new features very fast. I can do this now.
In a year or two when you have a bit of time it might be worth going back and having a look at Symfony anyway, you'll likely find that going from Laravel to Symfony will make more sense than CI to Symfony (underneath Laravel uses a fair few symfony things).
Also it is super flexible too (much like JavaScript and babel) as in you can write strict OOP code or you can write plain php code inside Html in static files.
The second paragraph is correct, but it's just equally correct for Python, Ruby, Perl, Lisp, Shell languages etc., as they all support multiline strings and string interpolation too. The only difference is that you'll have to wrap strings in delimiting markers, instead of code with <? ?>.
That being said, doing server side templating in node.js is even worse since it usually wrecks the entire event loop with long lived CPU-bound operations flushing your server performance doing the toilet.
Is the 10-15 minutes you might save looking up a quick setup tutorial for the system provided packages really worth the later problems? Postgres is slightly more complex (but pays for itself with additional capabilities), so I can see avoiding that unless your are already familiar with it.
As for PHP, at this point it's not really any easier or harder to get up initially then Python, Ruby or Perl, so it really comes down to personal experience. Whichever one you know best, use it. Whichever framework you know best that has some solutions for what you want to do, use it. That will be quickest.
1. You don't necessarily want to develop in the same environment you deploy to.
2. You don't want to install some things on your development machine.
Together, those are dictating some development directions for you. That's fine. Those are perfectly valid choices. But I think it's easily summed up in your case as "You use sqlite because it fits well with your current development pipeline."
On the flip side, I do development on remote servers using vim. For me, sqlite provides little-to-no additional benefits, since MySQL or Postgres are a package install away (if not already installed), and that's a small price to pay for their additional benefits (for example, a much richer set of data types). At the same time, this type of development pipeline makes certain types of development harder (there's lots of tools for vim/emacs, but some things graphical IDEs provide are harder to achieve).
There is a middle ground, which is emulating the target environment through a VM on the development machine. It should provide the best of both worlds, for a cost of a little most complexity. I've never really gone for that, as I'm happy with the remote dev setup I have, and it's easier not to have to devote local resources to that for me. It's a popular choice as I understand it though.
And in fact Sqlite is linked with the application, so it presents a development environment much more consistent with production (if that's also using sqlite of course) than any mysql or postgres ever will.
I'll just let you read this: https://www.sqlite.org/whentouse.html
Why not Python?
What? Half the programmers I know in NYC write PHP. The other half write a combo of Java/C#/Python. These aren't programmers working for startups - they are working for companies and the government.
PHP is used everywhere. Except maybe in SFO (and surrounding area).
I mean look at the job listings for NYC, DC, Miami, Baltimore, Louisville, etc, etc.
Look I know this board is focused on Silicon Valley, but it's a big world out there.
And even if they did what is wrong about choosing PHP?
I don't get the logic here.
Another thing is that, if it it worse for you, it is automatically worse for the client. I am not sure why it is so hard to see. if your tool is bad, then your work ll suffer, and thus the client. So it is worse for them also..
If you don't like PHP that's one thing but what you said is just wrong.
It's not all bad once you're on the ass-end of history. I'm sure you can easily identify a few negatives being the language de jour bring (such as lots of shitty programmers joining the community all the time). Welcome to middle-age. ;)
I'm a 25yo, so when I started programming Perl hatred was the hot thing already. Well, luckily as a curious person I discovered its just baseless cargo cult. Perl is one of the best tools to have in your toolbox.
No start up became a unicorn because of the programming language they used.
Wal-Mart is pretty big into Clojure these days, but they were already huge.
Everyone else here is trying to be stylish and fancy.
Your customers don't care what language it's in or whether the code is beautiful.
No cutting edge incomplete frameworks, convoluted tooling, piles of inaccurate documentation to read, inexplicable cryptic error messages with a bunch of incorrect solutions on stack overflow, or other incompetently over engineered bullshit.
Just go as vanilla, basic, and standard as possible.
True speed comes when you don't have to deal with other people's bugs and poorly designed mistakes.
Don't rely on code written by flocks of people you'd never hire in a million years.