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.
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..
The other side of the coin is whether you do a full security audit of every framework and dependency graph before you use it? When you write your own code you know there is nothing hidden.
That's a highly simplistic and incorrect way of looking at it. Do you know what CSRF is? Do you want to implement it every time you create a website? And all the other XSS vulnerabilities that could occur because you weren't careful.
Frameworks are much better at handling most security needs.
Most of the higher level code like that is written by incompetent people who make amateur hour mistakes and only release overengineered under documented slow broken code that is never supported and gets deprecated in a week.
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.
>>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.
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.
If it is open to the public, your train wreck cannot be open to common vulnerabilities like sql injection. Full stop. You can avoid unit or integration tests, not complete features, or cut any corner you want aside from basic security.
Don't presume anyone writing PHP is a trainwreck. With PHP7+ you can write modern applications that are perfectly secure, as much as anything you'd write with any other scripting language.
> Don't presume anyone writing PHP is a trainwreck.
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?
Sure it can. Almost every website on the internet right now has undiscovered security holes. Obviously you won't be leaving them open on purpose, but not using a framework is a legit choice and "it provides security that you can't implement without one" is a bad argument.
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.
I'm not saying anything either way on frameworks. But SQL injection is into to web development stuff. You can worry about cross site scripting or other security stuff later for a PoC,but not SQL injection.
" 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."
I wish they included Haskell in the concurrency bugs section, given how popular Software Transactional Memory – which eliminates many concurrency bugs – is there.
You seem to know a lot about what everyone else's motives are :)
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.
One can put together a set of (Fast)CGI scripts in almost any language, given environment variables and some IPC is supported (IDK what IPC FastCGI uses exactly, bug CGI is envvars). Same goes with exposing a custom socket server. I guess people associate languages with frameworks and that's why they think these things are not possible in them. Or they like the <?php ?> style intermingling of 4 programming languages, which is a pathetic bad practice that turns the program into a pseudo-quine immediately. Just read the source of a WordPress plugin (keep a nylon bag handy because it's gonna give you nausea, to say the least).
As someone in a position who's primary job has [had] little to do with WordPress plugin work, but is at the same time increasingly exposed to that due to sales department directives...
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.
Except OP made no mention of Wordpress, its notoriously bad and any decent developer who also happens to use PHP knows not to touch it with a ten foot pole.
You're wrong. This is a case where whatever you're comfortable with is the best solution. Just because you personally don't know frameworks, or js frontends, doesn't mean the people who do are inferior or less secure.
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.
Please correct me if I am wrong, but as far as I remember the combination of PHP and sqlite fails fairly quickly when if comes to concurrent users?
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.
Sqlite's limitations have nothing to do with PHP. But you're correct that it's not intended for use as a multi user database. The limitation is in concurrent writes. If your app is read-oriented, then there is not a problem.
However, I'd personally always use postgres in this case, myself.
>Your customers don't care what language it's in or whether the code is beautiful.
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.
This might be true if you're creating a very simple web site that is never meant to be a real app. If you're creating a more complex web app, with authentication, user management, billing, admin pages, etc. you are better off with frameworks such as Laravel, Symphony or Slim if you are using PHP.
...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.
Let's be frank. This is a place for marketing the newest thing where skepticism and scrutiny is not welcome and likely to be dismissed as 'grey beards' and 'people scared of change'.
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.
Symfony 4 can be spun up as fast as Laravel 5 and (this is my opinion) Symfony has all the benefits of Laravel with a better ORM (if you want it) and they have never broken backwards compatability in my experience.
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 have a huge complex behemoth of an application which is written in CodeIgniter 3 with a whole bunch of changes that I have made over the years to the core. To call it CI 3 is a bit of an understatement.
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.
Fair enough, it founds like you found a good fit for your use case (and that's a good thing).
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).
PHP is like the Javascript of backend. Hate it all you want but there is nothing better to get shit done esp if you're a small team or working solo.
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 first paragraph is plain wrong. JS is the JS of frontend because there are no replacements. Use a language compiled to it, but still you'll have to know and use JS. PHP on the other hand is a caricature of a language that you can avoid.
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 <? ?>.
Agreed. I've worked with PHP for years. It's not my choice unless it's a requirement. There are plenty of other more durable and scalable languages for the backend (as you've listed) that are just as easy and quick to get going if not more so.
The reference implementation of PHP, Zend, is objectively not good (blocking I/O) and encourages server side templating, which is basically something you can perfectly do in the client and serve on a CDN at much lower cost (orders of magnitude lower, for processing, memory and transfer).
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.
What exactly is the benefit of using sqlite over mysql in this case?
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.
I don't run a MySQL server on my personal computer. I don't want to run one. If I want to start writing code right away to flesh out an idea, SQLite is the tool I can use, it enables me to develop locally with no SSH/FTP overhead or setting up a VM. It lets me start writing code instantly. And it's performant enough for most any MVP, and the SQL dialect is pretty standard so you can upgrade to Postgres or SQLAnywhere or whatever you please when the time comes.
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.
I think you should be able to understand that sqlite's "the database is a file, ONE file" is superior to getting a fully configured and setup mysql up and running in speed, ease, and simplicity. Of course, it presents limits in terms of scalability (however because it is linked into the application rather than using TCP, if you want to do 400 sql queries per page view sqlite will be MUCH faster than mysql or postgres is going to be)
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 usually go for Postgres, but I suppose one advantage is that backing up involves the filesystem rather than figuring out how to do a db dump. Not entirely sure if it's that simple though.
Isn't the "PHP works on cheap hosting" schtick a bit dated now you can get a dual-cpu VPS with 8GB RAM at hetzner.com for 8.90 Euros per month? Commodity hosting now makes JVM apps feasible at the lowest price points.
Ok, so yesterday's shared hosting prices are today's VPS rates. The point is they've both become commoditised so the PHP/cheap hosting argument is no longer valid.
Actually they do if they have to maintain it or want hire really good developers to maintain it. Not saying PHP doesn't meet those criteria, it might in a given region or situation, but just saying your dismissal of this consideration is way off base. Good luck hiring anyone passionate about good software development or recently graduating from decent CS department to work on your PHP apps. I'm sure you are a great developer with a real passion for your craft but you do realize that plus PHP makes you a very uncommon find, right?
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.
Calling out the regional dimension to the popularity of PHP is totally valid. I think the thing I'm really reacting to is people repeatedly saying "the client doesn't care" which I vehemently disagree with.
If the client does not not care, why suffer by using something that is worse for you? I mean, you might as well use something that you like.
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..
In many areas of the US (the entire west coast for example), PHP is dead - plain and simple. Independent of whether it is good or not, selecting dead or obscure technologies for your clients is completely irresponsible and leaves them with a maintenance catastrophe just because you like php. Yes there is a lot of hipster-ism out there in platform choice but there are plenty of mature, fast, and popular options out there. PHP is not one of them.
PHP isn't dead, and it will never be dead, but as a long time and continuing professional Perl developer myself, let me tell you that you're better off just accepting that your language of choice isn't in vogue anymore.
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. ;)
Perl 5 is pulling me like a superstrong magnet. I haven't had time to read the basics and things like choosing the correct sigil + accessor trim me up, but still, it has many niceties. To begin with, you can have a statement "use v5.x;" and be done with which interpreter problem: it can tell you it needs sth. different, and does not fail because you have python3 to be 3.x, but the script needs 3.x+y, or you have the shebang as python3.x but the system has 3.x+y which is compatible, but you can only have one full path in the shebang... Then the context variable $_ is just lovely. The availability of mature libraries for everything is a trait Perl shares with a small number of languages. Its integration to Unix and its expressivity are second to none. The documentation, while not as accessible as Emacs', is available on you computer offline in man pages, and perldoc can give you proper docs on functions (unlike crappy help() in Python which never shows you anything useful and you have to go to the docs, usually online), add to that POD being a very nice way to add documentation to your scripts and also view them (if its in the path you can "perldoc <script>" and get help. And once you know your way around perl* man pages, you can just program independently, with little or no need to go online for Perl stuff. All niceties other languages/communities could've had, but just don't, because, well IDK why.
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.
PHP is not dead - plain and simple. Independent of whether it is good or not, selecting technologies based on your biases for your client is completely irresponsible. There are plenty of mature, fast and popular options out there. PHP is one of them.
I don't know which planet you're living on but all you need to do is search Indeed.com for title:php and you'll find PHP is up there with Java, C# and Javascript in terms of the number of jobs. In some countries Java, JS and PHP are the only languages used in any significant numbers. Likewise in more technologically advanced countries once you get away from the tech hubs. I'm not a fan of PHP and I wish it was true but dead it certainly ain't.
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.