[HN Gopher] Go with PHP
___________________________________________________________________
Go with PHP
Author : eiiot
Score : 485 points
Date : 2023-05-11 03:23 UTC (19 hours ago)
(HTM) web link (gowithphp.com)
(TXT) w3m dump (gowithphp.com)
| BulgarianIdiot wrote:
| Sounds like a threat TBH
| ofrzeta wrote:
| We're now at Laravel 10. Take a look at the Laravel Bootcamp for
| a quick intro https://bootcamp.laravel.com/
| jwithington wrote:
| I hosted a phpBB forum as a kid in the early 2000s.
|
| 15 years later I joined a marketplace startup that was doing
| 10,000 transactions a day.
|
| Built as a PHP monolith.
|
| I was sooooo confused at first. "PHP??? That strange language I
| used to host a forum is powering this app??"
|
| Turns out the founding engineer was self-taught and PHP had the
| most tutorials or something lol
| openthc wrote:
| In 2001 I started a PHP project and it was cool, lots of people
| were going that way. In 2008 folk we telling me it's a terrible
| security risk. In 2014 they told me it's the WORST choice. In
| 2023 it's cool again?
| jchook wrote:
| PHP 8+ is filling-in a lot of the missing features -- type hints,
| attributes, named parameters, etc.
|
| Nowadays instead of using
| 'string_you_have_to_remember_and_might_mistype' or abusing
| associative arrays as in the given code sample, you can usually
| get full code completion luxury with PHP without magic comments
| or other workarounds.
|
| PHP 8 is still missing a few critical features such as generics
| and typed resource handles, and nikic left the project, but I'm
| still hopeful PHP 9 will deliver on those key additions.
| joering2 wrote:
| I think its a great reminder to code with whatever you feel
| comfortable. For example, my last project I did in
| Centos/Apache/PHP5/Code Igniter 3.1 with some WASP for protection
| I did for 12 years and sold few months ago. It checks out against
| Qualys Server test and ImmuniWeb very well. I sold it for close
| to $10MM with annual revenues of $1.6MM. The last question the
| new owner asked me was "what did you program it with?". They
| mostly want bunch of boring excel spreadsheets seeing where I am,
| how the sales are sustained, and how do I believe it can grow. On
| the final day, their IT guy showed up. He looked in silence
| through 45 minutes of my code's presentation, which is very much
| mix of OO and not OO, and his only words were "I don't like
| frameworks if that was me I would start the whole thing from
| scratch".
|
| So you never know what or whom you gonna get, but the bottom line
| is if you have sales and revenues and keep tabs on spending, they
| will come, and they will not care less about your fancy framework
| or newest code implementations.
|
| TLDR: code in whatever you feel comfortable but always consider
| security as top priority (not speed) because in production your
| code's/setup security mistakes can cost you serious legal
| troubles.
| sockgrant wrote:
| Gotta love engineers. 45 minutes of reading 12 years of
| someone's work and the first thing they say is "yeah I'd
| rewrite it".
|
| Every. Dang. Engineer. It's crazy.
|
| I try to work in a codebase for 3-6 months before coming to any
| wild conclusions. Usually you find that there's some warts but
| it does the job and there's complexity that was solved that you
| hadn't originally noticed, and it's not worth rewriting it just
| needs some love in some areas.
|
| People hate reading other peoples code.
| zdragnar wrote:
| A clean rewrite is almost always going to produce better code
| than what already exists in a project that has grown
| organically.
|
| The current project has had numerous iterations on
| requirements over the years, changes in project leadership,
| paradigm fads come and go, and all that time accumulating
| cruft and layers. Looking at it at a single moment in time,
| you have a fixed set of current requirements where all the
| discovery has already been done, plus whatever your current
| knowledge of future requirements is, possibly none of which
| may have existed when the original code was written.
|
| That doesn't mean that everyone is going to sit around on
| their thumbs patiently waiting for you to rewrite it to be
| perfect. The more lines of code there are, the more time it
| will take, and the more hidden features that nobody really
| remembers exist but are still crucial will crop up.
|
| Few situations are _actually_ best served by a full rewrite,
| but almost every project would be better off if the world
| could stand still long enough for it to happen.
| minusf wrote:
| a rewrite from scratch is a pipe dream for almost
| everything bigger than "hello world".
|
| just ask WordPerfect.
|
| any kind of home grown business app will have corner cases
| and requirements spaghetti that would take much more time
| to figure out than to write actual code.
|
| and if the person asking you to do a rewrite just shrugs
| when you ask "where is the test suite?" walk away asap.
| athrun wrote:
| Ideally, you want people deeply familiar with the original
| codebase doing the rewrite.
|
| What usually happens instead is that the rewrite happens
| because the original code has been handed off to a new set
| of people. They're not deeply familiar with the code. It's
| confusing to them. It's not obvious why things have been
| done in a specific way. And so they decide rewriting it
| from scratch is the better option.
|
| Unfortunately, they're not in the best position to come up
| with a solution that incorporates the right lessons from
| the original design.
| sourcecodeplz wrote:
| The fact that you can build a whole app inside just one index.php
| file is highly underrated and I understand how newbies finding
| this out are getting excited.
|
| I remember when Rails first launched and I wanted to try it but
| it was so complicated to get started.
| o1y32 wrote:
| [flagged]
| xigoi wrote:
| You can do that with any language using CGI.
| Tade0 wrote:
| The other day I finished a side gig I was doing - a Wordpress
| site recreated using the Wayback Machine - the site went down a
| while ago and the admin stopped answering phone calls, not to
| mention emails.
|
| It was a largely pleasant experience, taking me back to my early
| years as a "web developer". I had to modify some PHP files
| because the theme used didn't offer slots for widgets in places I
| wanted it to.
|
| That being said uncached the site takes over 20 seconds to
| render. CPU load wasn't high so I can't help but wonder what was
| it doing all this time.
| jwie wrote:
| I'd had a site in a similar state, and I did figure out what it
| was doing.
|
| Client had launched a product that was a bit more successful
| than typical. Nobody could access the site though. I dig around
| a little, come to find a neat little snippet of template
| looking for a featured user for some markup.
|
| The genius who set this up iterated through each record trying
| to find the featured item. One query at a time, testing each
| record in the application for the flag.
|
| Php is fine, some very inexperienced "developers" use it though
| so you find a lot of gems like that in the space.
| BulgarianIdiot wrote:
| The problem is this page advertises Laravel, not PHP. Ruby on
| Rails has many similar "demo worthy" snippets that make complex
| tasks seem readable and intuitive to the layman. Laravel and Ruby
| on Rails have something else in common: due to the focus on these
| "natural" interfaces, they compromise in every other way.
| Architecture, performance, testability and so on and so on.
|
| For those who know PHP, this code is full of singletons
| masquerading as static classes (which Laravel incorrectly calls
| "Facades") which mean no isolation and clear flow of dependencies
| in your code. In a nutshell, every line of code you write this
| way comes loaded with a pound of irreducible, unfixable tech
| debt. Enjoy.
| sjamaan wrote:
| > In a nutshell, every line of code you write this way comes
| loaded with a pound of irreducible, unfixable tech debt.
|
| And worst of all, you are stuck with a shitload of churn every
| time a new Laravel version comes out. But this is true for
| Rails and CakePHP and probably many others as well. At least
| Django seems to be moving a bit slower and not deprecating
| loads of features on every release.
| BafS wrote:
| Absolutely, having worked with Laravel I can only recommend not
| to use it, Symfony does a much better job.
| simonhamp wrote:
| Making "complex tasks seem readable and intuitive to the
| layman" is no bad thing - besides other engineers, _future you_
| could become a 'layman' easily. Readable, expressive code is
| something I've come to value highly after almost 20 years
|
| And from first-hand experience, while the specific code sample
| shown on this page shouldn't be treated as a practical example
| of how to architect a larger application, there's nothing
| compromised here in terms of performance or testability.
|
| All tech is tech debt at some level or at some time - what has
| happened to pragmatism? Laravel has actually helped me write
| the most performant, tested and least-refactored code I've ever
| written.
|
| Like any tool, used properly it will do its job well; simply
| grumbling and shooing it away does not stop it being a
| perfectly fine tool in the right hands.
| BulgarianIdiot wrote:
| I guess I wasn't clear enough? I said "it makes complex tasks
| SEEM". My point being, they SEEM SIMPLE in a DEMO. But in
| real application it quickly turns into a quagmire, due to the
| problems I already listed.
|
| Oh look, you even say so in your own comment: "the specific
| code sample shown on this page shouldn't be treated as a
| practical example".
|
| So... you're saying the page makes it SEEM simpler than IT
| IS, hmm? Is this what you were asking me about "why is it
| bad"? You don't think parlor tricks in demo code is a bad
| thing?
|
| So what are you even objecting to here? I said something bad
| about Laravel, and you use Laravel, so you have to go on the
| offensive out of loyalty? I don't know why people need to
| identify so religiously with their tools. If we start picking
| apart this demo code, you'll probably admit that every line
| contains an anti-pattern you'd avoid in a real project of
| more than a modest size.
|
| So what is this demo demoing then? It's essentially
| misleading people about what it takes to write a good app. If
| we'll go by simple demos alone, PHP needs no framework at all
| for a good demo: <?php echo "5 + 5
| is: " . (5 + 5);
|
| Boom, everyone understands this, now you can write your own
| Google!
|
| This is why RoR declined and it's why PHP with Laravel and
| WordPress as their poster boys is declining.
|
| PHP itself is no longer as terrible as it used to be,
| although all the good people seem to have left the internals.
| But the frameworks people use on it are terrible, incompetent
| and aggressively misleading people into bad practices for the
| sole purpose of marketing to newcomers.
| psihius wrote:
| I have one name for you: Symfony
|
| More or less directly opposite of what Laravel is
| preaching. It's the popular choice for anything that is
| being build long term. It is very popular in Europe and we
| have a far bigger community around it than Laravel does.
| BulgarianIdiot wrote:
| Symfony made many architectural mistakes early on,
| including with the way they used to do injection and so
| on, but to their credit, the community seems curious and
| strives for quality, so over time it has become a very
| interesting project. I stay away from frameworks, in
| general, but the Symfony components are excellent.
| minusf wrote:
| 5 + 5 = <?= 5 + 5 ?>
|
| why use echo? php _is_ html :D
| lostdesign wrote:
| > , they compromise in every other way. Architecture,
| performance, testability and so on and so on.
|
| Architecture: The default structure of the app is good to start
| out and can be changed at any time. You are not locked into
| that. If you apply your fancy patterns, you can do whatever you
| want. It's rather a devs fault than the frameworks fault.
|
| Performance: Guess depends on what you compare it to. Surely a
| rust service will be more performant, however you can scale
| laravel just fine if you are not writing shit code. There is
| enough apps built in laravel that handle more load than the
| average pro reddit coder will ever see.
|
| Testability: Not sure what you mean, you can test in different
| ways and anything you need to test. It's fairly simply too.
| Yes, there are sometimes issues where you can run into memory
| leaks but those can be fixable after some digging.
|
| You can but don't need to use facades, you can go full DI, you
| can swap the IC.
|
| The Irreducible, unfixable tech debt is created by the
| developer that wrote it and does not know php or laravel. Yes,
| laravel makes it easy for newcomers to get right into the traps
| you mentioned, but then again - we are talking about junior
| that would not know any better and probably would fail without
| it.
| BulgarianIdiot wrote:
| If you use facades there's no fixing that unless you
| reconstruct and reweave every component in your application
| to pass relevant context in and out, instead of lazily
| reaching into globals for it.
|
| What you call "full DI" in Laravel is still globals in
| disguise, because there's a single global container.
|
| Most defense of Laravel comes from people who have no idea
| how to write a good app. And unfortunately, due to bad
| frameworks, the number of those people is multiplying. I
| blame Spring and RoR. So much pain came from them. Laravel is
| just a pale copy.
| jszymborski wrote:
| I used to refresh nettuts.com obsessively in high-school and
| Jeffrey Way's PHP content was the highlight.
|
| Sadly the site got a refresh ages ago and is nothing like it used
| to be.
|
| Anyway, if you're reading this thread, thanks Jeff!
| blakblakarak wrote:
| I too learnt webdev with Jeffrey back in the jQuery days of
| 2011 - I subscribed to laracasts at the start of the year
| (primarly to evaluate Laravael for work) and was delighted to
| see that he runs the site - he's like the Bob Ross of webdev.
| krylon wrote:
| The last time I used PHP was in 2004 or 2005, PHP was at version
| 4.something, and I did not like it. That kind of formed my
| opinion on the language, even though I know it's come a long way
| since. OTOH, I have no reason currently to take another look.
|
| But it's nice to be reminded, I guess, PHP isn't the dumpster
| fire it was 18 years ago.
| taspeotis wrote:
| > It can handle more than 500,000 orders per month
|
| How many seconds in a month? 60 * 60 * 24 * 28 = 2,419,200.
|
| So basically, its performance is at least 0.2 requests a
| second...
| pier25 wrote:
| Yeah...
|
| OTOH it makes a point that it solves a real problem. A business
| processing 500k orders a month is not trivial.
| PetahNZ wrote:
| I know it's just meaningless numbers, but our php backend
| handles 10 orders per second peak. And obviously a order
| requires many more requests than just 1.
| Culonavirus wrote:
| Realistically, and speaking from professional experience of
| over a decade, "creating an order" can be one of the most
| complex tasks your frontend part (as opposed to admin/cronjobs
| parts) of the web app is going to do. It is not a rare thing to
| see dozens of records in a dozen of tables being
| created/updated at order creation time. All of these "order
| creation" examples are super naive. Once you develop for a shop
| that operates in $10M+/year range (i.e. there was probably time
| and money to bloat all the
| user/cart/stock/warehouse/sales/dispatch/marketing operations
| and metadata), god forbid a shop that has lots of legacy code
| and data structures, you will be fine with anything around 1s
| at order creation.
|
| (Not that I want to defend Laravel's speed, it's not really
| anything to brag about, and the typical "cache everyhing
| everywhere all the time" aswer is not that useful.)
| hu3 wrote:
| I have a client that handle peaks of 7k requests/s using php-
| fpm + nginx + MySQL. Using their own custom framework in PHP.
|
| It all sits in a single 5 year old machine with 8 cores and
| 16GB RAM. Their bottleneck is actually MySQL but they have room
| to spare so no need for upgrades right now.
| acomjean wrote:
| I help with an open studio event. We maxed out last weekend at
| about 350 visitors per minute (about 30%Wordpress and 70%custom
| php symfony pages) on shared hosting. We have a cdn helping
| with images and such.
| konart wrote:
| While 500k order does not sound as much - you have to remember
| an order != a request.
|
| Not to mention that as long as you have a direct sync query to
| a database - your code will have to wait, lol.
| mholt wrote:
| I'm in the group described halfway down: was on the Internet
| during PHP 5, lost interest in it, and moved on [to Go]. I
| haven't written anything in PHP newer than version 5. Even
| transitioning from 4 to 5 was quite a big deal, I definitely
| noticed improvements.
|
| But it wasn't enough.
|
| I couldn't fit the data set in memory with PHP. But I could do it
| with Go.
|
| I couldn't do parallel computations in PHP in order to respond to
| an HTTP request quickly enough. But I could do it with Go.
|
| I couldn't reliably and easily deploy to different systems with
| PHP. But I could do it with Go.
|
| Eventually, I couldn't write a web server with PHP. But I could
| do it with Go.
|
| A lot of my early websites were written in PHP and I was able to
| build them quickly and routinely. I didn't really have a problem
| with PHP as a paradigm, or even its security and consistency
| posture. I'm glad they've since made an actual language spec and
| fixed a lot of issues with it. And I don't judge or look down on
| PHP programmers. I just don't think it was the right tool for my
| jobs.
| _the_inflator wrote:
| I agree with every checkmark except for Go.
|
| PHP was the right tool at the time especially when everything
| on the web was somewhat Wordpress first. PHP felt like a blast
| with WAMP/LAMP.
|
| Since then I have moved on and honestly it never occurred to
| me, that PHP still could be an option in my tech stacks,
| neither one of my devs recommended it.
|
| No one hates or disliked PHP, there are simply other options.
|
| Looking back, recommending PHP today feels like "You can do
| this with jQuery, too" in the Frontend domain. Yes, you can,
| but maybe you shouldn't or only if you have the right people.
| And PHP is a rare skill now.
| asdfman123 wrote:
| I'm not defending PHP necessarily, but yes, obviously a
| language that's more performance oriented will be better at
| performance-oriented tasks.
| [deleted]
| Cthulhu_ wrote:
| I'd say PHP is great to get started, Go is for when you need
| more control, more mechanical sympathy.
|
| I did write a REST/JSON API in PHP 5.2 (two years ago, I'm
| aware there's newer versions out there but they aren't easily
| available in RHEL 6/7 used at our customers at the time - it
| was a slow moving industry); it's doable, and using best
| practices learned from other languages makes it look
| maintainable at least.
|
| Did run into some issue with large datasets though, but that
| was an implementation problem; the original author would read a
| CSV, convert it to XML using concatenation, then parse the XML
| to convert it into JSON because at some point a decade ago he
| found out that the X in XHR was no longer (and never was) the
| norm, all in memory. That broke when there were more than a few
| thousand rows in the CSV.
| codersfocus wrote:
| In terms of parallelization and reinterpreting every request,
| there is Swoole (implemented in Laravel as Optane) that fixes
| both of those issues. Most Laravel projects can handle 2x as
| many requests with a simple modification.
| [deleted]
| heywhatupboys wrote:
| When are these ever issues? In a real life scenario
| konart wrote:
| In almost any scenario?
|
| >I couldn't fit the data set in memory with PHP. But I could
| do it with Go.
|
| I guess this on is self-explanatory.
|
| >I couldn't do parallel computations in PHP in order to
| respond to an HTTP request quickly enough. But I could do it
| with Go.
|
| Consider the following (covers both statements above): you
| need to get some data from a few sources (databases etc) do
| some computation on each set and then do some sort of mapping
| to get the resulting set. You may want those computations to
| run in parallel and idealy you'd like to start mapping as
| soon as each computation function starts producing results.
|
| >I couldn't reliably and easily deploy to different systems
| with PHP. But I could do it with Go.
|
| I haven't been using PHP since 5 but I assume it's still much
| easier to just push you Go binary to a destination.
|
| Though with Docker and company deploying PHP code is not a
| big issue these days I assume.
| heywhatupboys wrote:
| > >I couldn't fit the data set in memory with PHP. But I
| could do it with Go.
|
| when would you ever have a website serve a request, and
| have to use gigabytes of memory to do so?
|
| > Consider the following (covers both statements above):
| you need to get some data from a few sources (databases
| etc) do some computation on each set and then do some sort
| of mapping to get the resulting set. You may want those
| computations to run in parallel and idealy you'd like to
| start mapping as soon as each computation function starts
| producing results.
|
| Again, why would you ever have an HTTP server do so much
| work in order to serve a request?
| konart wrote:
| >when would you ever have a website serve a request, and
| have to use gigabytes of memory to do so?
|
| I'm pretty sure that PHP is not only used for web sites
| otherwise comparing to Go is simply meaningless. There is
| little to no point in using Go to build something with a
| relatevely low load.
|
| >Again, why would you ever have an HTTP server do so much
| work in order to serve a request?
|
| http server != website. You can have two services
| somewhere down infrastructer that communicate via
| http(s).
| heywhatupboys wrote:
| > I'm pretty sure that PHP is not only used for web sites
|
| PHP is explicitly designed to serve web content. It's
| usage may vary, but it is unfair to expect it to optimize
| towards anything but as a web backend.
| creamyhorror wrote:
| > _you need to get some data from a few sources (databases
| etc) do some computation on each set and then do some sort
| of mapping to get the resulting set. You may want those
| computations to run in parallel and idealy you 'd like to
| start mapping as soon as each computation function starts
| producing results._
|
| This definitely sounds like a typical situation for
| handling the job in a queue (plus with an async library
| like spatie/async to retrieve data in parallel), though I
| see the advantages and convenience of using a natively-
| async language here.
| konart wrote:
| An example (not the best one maybe but I'm not the right
| guy to come up with good examples immediately) from a
| year ago:
|
| We have to integrate company M and W (one is a
| marketplace the other one is a big store, think Walmart
| or something).
|
| Company W mostly uses software similar to SAP-whatever
| and have a small team resposible for building 'helper'
| services in place where SAP can't do the job.
|
| Company W can't communicate with M in any other way
| except through your generic http API they provide.
|
| So every now and then M has to send a request to W and W
| has to prepare a pretty large XML response. (obviously
| the data is split in some way and we are not talking
| about tens of GBs but even so W has has to fetch the data
| from more than one data source, process it and send it)
|
| In some cases you can simply have a cache\a view\whatever
| for this (so you only have to fetch prepared data) but in
| some cases you can not.
|
| PS: this is if we are talking about HTTP communication.
| Or maybe some real-time communication where you can't
| really respond with "hey, we are getting your data
| prepared so just wait for a bit and re-request it with
| this nice jobID at a later time"
| creamyhorror wrote:
| Well, for that use case, it would be typical in my
| industry for party A to send a callback URL to party B,
| so that B can POST the required information back to A
| after doing the multi-step processing. It's not really a
| done thing to make a synchronous HTTP request and wait
| say a minute or more for the response. Maybe that's just
| different expectations in different industries, though.
| zmxz wrote:
| [flagged]
| xu_ituairo wrote:
| Your response here feels unkind and combative
| crazygringo wrote:
| If you had stuck to facts rather than being insulting and
| inflammatory, I don't think your comment would be downvoted.
|
| You make some interesting counterpoints but people aren't
| going to see them because of the counterproductive language
| surrounding them.
|
| You should take a look at the HN guidelines.
| kgeist wrote:
| I agree, the main problem with PHP in my experience so far has
| been that it's very memory-hungry and slow (even PHP7/8),
| especially when coupled with frameworks/ORM magic.
|
| I remember after spending some time with Go, I got used to
| being able to process tens of thousands objects in memory in
| milliseconds. When I proposed to do the same in PHP, during
| architecture review, PHP devs thought I'm out of my mind
| because that would take like a gig of RAM (which would compete
| with other PHP processes on the server) and considerable amount
| of time. You have to use a lot of hacks to make it all fit in
| memory and be fast.
|
| Our Symfony framework also initializes in like 300 ms on each
| request, while in Go it's below 10 ms. As every PHP process
| dies after serving a request, you have to reinitialize the
| whole dependency container on each request from scratch, and in
| large enterprise applications, that's a lot of dependencies.
| berkle4455 wrote:
| You're doing something terribly wrong. Sounds like caching
| isn't setup and your http -> php handler is cold booting the
| interpreter for every single request.
|
| Check these Go vs. PHP benchmarks. PHP is quite fast and
| stands up nicely to the performance you get out of Go.
|
| https://www.techempower.com/benchmarks/#section=data-r21&l=z.
| ..
| kgeist wrote:
| Isn't that synthetic benchmarks for toy projects? The
| amount of code which is run on every request grows with the
| size of the project in PHP/Symfony (which can take quite
| some time in a huge monolith), while in Go, everything is
| usually initialized once at startup.
| [deleted]
| ki_ wrote:
| All i see is that the php fpm based frameworks (e.g.
| laravel) are 100x - 300x slower. And this is the best case
| scenario. When projects grow, php-fpm gets slower and
| slower. Which is not the case for go. Im not a go-fanboy,
| my entire carreer has been in PHP. Im just saying, PHP is
| one of the most terrible languages for web servers. And
| it's all php-fpm's fault. On top of that, the PHP community
| seems to promote OOP and SOLID which are the last design
| patterns you want to combine with php-fpm. There's a reason
| why facebook created their own PHP transpiler.
| Thaxll wrote:
| This benchmark means nothing.
| withinboredom wrote:
| I've written PHP apps that process millions of entities
| without issue at my old job. We didn't use an ORM or anything
| magic. At my current job, using an ORM, my code has twice as
| much memory yet I can only load a few thousand entities
| before OOMing.
|
| If you're willing to give up magic, it's worth it.
| thaumaturgy wrote:
| FWIW: There are a bunch of ways to "do" php execution, and a
| lot of them are wrong. That's not exactly PHP's fault, just
| that there's been a lot of blind-leading-the-blind.
|
| Assuming that you're not spinning up and tearing down a
| container for every request, you want to be sure you're
| running php with a php-fpm configuration (preferably talking
| over a unix socket) -- this is the fastcgi process manager,
| which maintains a pool of "hot" php interpreters for you that
| are immediately ready to execute code for an inbound request.
| This is usually good enough for most applications without
| going into the weeds on things like opcode caching, but
| that's all available as options too.
|
| I'd be happy to help troubleshoot this with you if you're
| interested. I've also got a fully automated build script that
| works pretty well. You can find my contact info via the link
| in my profile. I _promise_ it doesn 't have to take anywhere
| near 300ms for php to reply to a request.
| jeroenhd wrote:
| My experience is that Symfony, in its fat, batteries-
| included form, does take quite long time to initialize on
| cold caches. The first request can take hundreds of
| milliseconds but usually the very next request is in the
| normal 10ms range. This is especially noticeable on (cheap)
| shared hosting which has always been a common place to run
| PHP.
|
| I've never found it to be a problem on a VPS but if you're
| developing on something slow like a Raspberry Pi I can see
| this happening regularly. If you're used to deploying stuff
| in containers and constantly throw out the cache the
| initialisation problem can happen very easily as well.
| jensensbutton wrote:
| PHPs language peers are things like Python and Ruby, both of
| which are slower.
| winrid wrote:
| Well that depends. There are like a dozen python
| interpreters and JIT compilers. PyPy is fast, albiet memory
| hungry.
| giaour wrote:
| The way developers are encouraged to structure PHP projects
| (mainly due to autoloader semantics) always felt more like
| Java or .NET to me than it did like python. The resource
| consumption comparison between a Symfony web app vs the
| same thing written in ASP.NET or Spring Boot has a pretty
| clear winner, and it's not PHP.
| naiv wrote:
| What you are describing only happens in dev environment
|
| The Symfony container does not rebuild in production and
| requests should easily be served within 5-10ms as well so you
| might want to check your deployment pipeline and that you
| correctly composer dump-env prod
| n0n0n4t0r wrote:
| If symphony takes 300ms in prod. Then you have a serious
| problem!
|
| Probably a configuration missing.
| acomjean wrote:
| We do a lot of work with large datasets. PHP 7&8 are so much
| better than 5 in terms of memory usage for large datasets.
|
| Its not magic though, and I'm not surprised a compiled
| executable is many times faster, especially for math heavy
| stuff. Slow is often "good enough" though and deploying is
| quite straight forward.
| mhitza wrote:
| That 300ms initialization time sounds like a cache-free
| execution (aka dev mode). I have symfony projects light on
| ORM usage (I dislike Doctrine from the bottom of my hearth,
| but what can you do it's the blessed symfony ORM) and after a
| cache warmup it handles requests under 100ms.
|
| Yes, the frameworks have obscene (java-like) class
| dependencies that build up during initialization (I'd prefer
| if there'd be a lighter function based framework nowadays),
| however for someone that knows how to manage PHP on the
| server there are OPCache tweaks, preloading facilities which
| help improve the request initialization performane (these
| steps are also expanded on in the symfony docs).
|
| The share-nothing arhitecture of each request is either a
| benefit or a downside, depending who you ask.
| kgeist wrote:
| It does run with caches enabled, my memory is murky but I
| remember Go processing requests on an order of magnitude
| faster (10x). Maybe it's about dependencies reconnecting on
| each request, or the large amount of classes in the
| monolith? I remember marking dependencies as "lazy load"
| helps.
|
| >there are OPCache tweaks, preloading facilities which help
| improve the request initialization performance
|
| I remember we disabled some of the settings for preload
| because we hit a bug which manifested as a segfault due to
| PHP's shared memory space for preload getting corrupted
| under a high load.
|
| In any case, everything is fast and usually doesn't require
| a lot of tuning in Go out of the box.
|
| However, I do love PHP's shared nothing architecture for
| the reasons of memory isolation: we have thousands of B2B
| tenants and with PHP, I'm confident we won't accidentally
| spill one company's data into another company's account.
| Things like when ChatGPT exposed your conversations to
| random people because a bug in the Redis connection pool
| inside Python's shared memory space returned a connection
| for a different user, due to a race condition.
| rob74 wrote:
| Well, that's the problem with all PHP frameworks: they're
| written in PHP! Yes, PHP has gotten faster thanks to
| OPCache and other tricks, but still, the less time your
| application spends executing PHP code, the faster it will
| be. And frameworks like Laravel just pile on additional PHP
| code to execute like there's no tomorrow. I mean, just look
| at the callstack when an exception happens...
| hparadiz wrote:
| I was running tens of thousands of jobs an hour with an
| asynchronous AWS SQS job dispatcher written in php that
| would launch php sub processes on the CLI. Super fast.
| Was able to get by with a very modest ec2 instance
| ($20/month) handling jobs for 300k users. Was auto
| scaling too.
|
| PHP 8.x has a ton of performance improvements that make
| what you're saying sort of not relevant anymore. I prefer
| PHP over Python these days on the Linux CLI. The code is
| cleaner.
| VWWHFSfQ wrote:
| That PHP code right there at the very top of the page that is
| supposed to be representative of how great it is has multiple
| TOCTOU authorization and validation bugs. In fact, nearly every
| piece of code on that entire page is riddled with transactional
| bugs
| keen_poincare wrote:
| If you may, could you point out what are the TOCTOU bugs you
| have mentioned?
| VWWHFSfQ wrote:
| Everything between checking if the user can "place-order",
| and then validating the inputs, and then finally creating the
| order.
| keen_poincare wrote:
| I don't think the request object can be modified by the end
| user or that it is modified by the server at that point. If
| my belief is correct, does this code still contain TOCTOU
| bugs?
| VWWHFSfQ wrote:
| It's the underlying state of the database that will
| change between these different checks. Not the end-user
| modifying the request object, which is in PHP memory
| njovin wrote:
| Do you mind elaborating? I can see how the user's ability to
| 'place-order' might be rejected between the access check and
| the order creation but that would be an extraordinary edge-case
| that does not need to be accounted for in 99% of applications.
|
| If you're developing an application that needs to account for
| such an edge case you could easily do so with an insert w/ join
| method on the Order model. The author isn't trying to show that
| the code is bulletproof for every scenario.
| VWWHFSfQ wrote:
| That's really the point. The code is deceptively simple for a
| whiz-bang "look how easy this is!" kinda presentation but the
| reality is that it's not useful for anything but a toy web
| store. Maybe it's fine that it only works 99% of the time if
| you're just trading Pokemon points, but not when you're
| dealing with people's money.
| njovin wrote:
| I'd argue that a vast majority of web applications are not
| "dealing with people's money" so there's not a need to code
| for such cases.
|
| The right tool for the right job, etc. etc.
| 5Qn8mNbc2FNCiVV wrote:
| I'd argue being able to stop worrying about your code
| after writing it and not making decisions like these is a
| good enough reason to just do it right. Especially when
| it's not much more additional work
| VaxWithSex wrote:
| https://jacobian.org/2022/sep/9/quality-is-systemic/
| lastangryman wrote:
| There's 2 things to separate here:
|
| 1. PHP the language and developer experience (frameworks, tools,
| community, docs, etc)
|
| 2. PHP performance at scale
|
| In my experience, PHP is much improved for 1. and fine to work
| with. Laravel and composer are great.
|
| For 2. I would never use PHP on anything above a few hundred
| requests a second. It's slow on its own, but more importantly
| it's blocking IO model will grind things to a halt at any level
| of concurrency when talking out to database, caches, or other
| services. You are also vulnerable to issues like saturating your
| database with connections due the programming model in php-fpm. I
| know async php exists but my impression is the mainstream
| frameworks dont support it (I could be wrong?) so why not just
| switch language at that point. I speak from experience of scaling
| a Laravel php app up 5k RPS+ and needing a LOT of EC2 instances
| to do it. Using Go was a revelation and delivered a 10x
| improvement in terms of resources required to serve the same
| number of requests.
|
| So yes, if your rps < 500, why not, PHP is fine. For anything
| above that, it's a not a great choice.
|
| (And defining your scale in terms of orders per month is a bit
| silly)
| pdimitar wrote:
| Weird that you get down-voted but I lose more and more respect
| for HN these days so I can only say I am not surprised that a
| common-sense post was given the gray treatment.
|
| I have the same experience as you, I've participated in
| migrating from PHP to JS, to Elixir, and to Golang. The
| transition to JS was mostly a performance disaster (not much
| performance was gained) but at least more devs could help so it
| was still a big win organization-wise, whereas the transitions
| to Elixir and Golang were a screaming success on every front:
| we immediately gained anywhere from 7x to 25x more req/s and
| the DB load was stable and the request timeout errors dropped
| by 97.9% on the first day (and were completely eliminated a
| week later), not to mention the cost of our hosting also
| dropped by at least 70%.
|
| I am past my phase of "hating" languages but honestly, saying
| "PHP is not the right tool for jobs X and Y" is a "hate" in the
| eyes of many anyway. And yeah it's not good enough for big
| scale. I mean, if you make $1M a month then you likely don't
| care much if you pay $50K in hosting, sure, but why do you have
| to spend 5% of your revenue on hosting? There are a lot of
| modern technologies with which you'd be hard-pressed to justify
| having more than 2 application servers and 1 DB server (with
| read-only backups and replicas if sh_t hits the fan).
| lastangryman wrote:
| Thanks, I was confused with the downvotes as I was just
| relaying the facts of my experience!
|
| Good to hear someone else has had a similar experience.
| Nothing against PHP at all, but it's definitely not suited
| for scale.
| codedokode wrote:
| I don't like that in the code validation rules are applied to a
| "request" (and written in a controller) but not to a model. This
| means that if you want to create a model somewhere else, you
| cannot reuse validation code.
| [deleted]
| kgeist wrote:
| I agree with the message, but the example has:
|
| - hidden global state
|
| - arbitrary string literals
|
| Is that Laravel?
| solraph wrote:
| It's been a long time since I had to deal with Laravel, but
| that code snippet looks very similar to the Laravel version I
| had to work with ~6 years ago.
|
| I hated it (Laravel) for those reasons, along with the madness
| that was the DI container. Guess I'm just not "web artisan"
| enough.
| o1y32 wrote:
| "500,000 orders per month"
|
| That's like, what, 12 orders per minute? Is this meant to be
| impressive or something? I bet any language run on a modern
| laptop can handle that.
| randshift wrote:
| I thought the same thing. PHP is a fine tool but that is not a
| value add statement. The code can "handle" anything, it's the
| underlying OS and related systems that limit the load.
| paledot wrote:
| Or smartphone.
| ceejayoz wrote:
| "when hosted on a $6/month server"
|
| Dropping half a sentence will often make it sound goofy, yes.
|
| The point being made is "you don't need a massive K8s
| infrastructure to handle hundreds of thousands of orders a
| month". Most people don't;
| https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
| is an oldie but a goodie on the subject.
| [deleted]
| pcnix wrote:
| That was a bad way to make the point, because you could serve
| five orders of magnitude higher with PHP, or node or go or
| python or pretty much any language right now.
|
| On top of that, You don't need massive k8s infra for any
| other framework either, so it isn't really a selling point
| for PHP itself.
| 5Qn8mNbc2FNCiVV wrote:
| Unpopular opinion: If you use k8s mostly for scaling, you're
| using it for the wrong reasons.
|
| Also the numbers are still irrelevant for the server because
| if you do 500k orders a month you owe it to the users to
| respond faster than 1s and also be highly available (just
| take 3 servers somewhere idc about anything else)
| smt88 wrote:
| > _" you don't need a massive K8s infrastructure to handle
| hundreds of thousands of orders a month"_
|
| This is true of many languages that are slower and faster
| than PHP. It's not useful as evidence of PHP being a better
| choice for anyone.
| ceejayoz wrote:
| It's not an argument of "this is the absolute best possible
| choice".
|
| It's an argument that raw language performance in this sort
| of context isn't going to be the problem for 99.9% of
| people developing code. If you have 500k orders a month,
| _you can afford more than $6 /month in hosting_.
|
| I sometimes see folks post on StackOverflow trying to
| micro-optimize things like string concatenation or single
| versus double quotes that make perhaps a second of CPU
| difference in a million executions. The point is directed
| at those folks; the ones who are thinking "language X is
| faster, and for that reason alone I should use that
| instead".
| giaour wrote:
| Boasting about 0.2 requests per second, even on a minimally
| spec'd VPS, is damning with faint praise.
| sgjohnson wrote:
| An "order" would involve far more requests than just one
| however...
| pdimitar wrote:
| > _" when hosted on a $6/month server"_
|
| So with hardware specs better than the Chinese laptop I
| bought second-hand for 150 EUR (which has a Celeron J CPU),
| the very same one that can serve 2000 req/s on Elixir and
| 5000 req/s with Rust, then?
|
| Sure, waiting on the DB is often 95% or more of the request,
| I get it, but 0.2 requests per second (which is the 500K
| orders per month when you do the math) is nothing to brag
| about regardless of which language or DB are being used.
|
| It's even below the level of having a bash script doing the
| heavy lifting.
| neurostimulant wrote:
| For every request that generates an order, there are probably a
| dozen or more requests that doesn't generate any order. Also,
| OS these days are so bloated a $6 vps will barely has any
| memory left on startup before you actually run any workload on
| it.
| winrid wrote:
| A $5 linode with debian 11 has like 950mb usable on boot?
| jsd1982 wrote:
| try a nanode from linode. $5/mo and as bare-bones as they
| come. no bloat there.
| SergeAx wrote:
| I see couple singletons calls in those examples. Is it considered
| a good practice in PHP now, or was it made to simplify the demoed
| code?
| motogpjimbo wrote:
| Laravel calls them "Facades". And no, they're not considered
| good practice outside the Laravel community.
| simonhamp wrote:
| Maybe you mean 'static' calls?
|
| Depends on the context but in most cases these are a
| convenience, syntactic sugar.
|
| Take SendOrderToVendor::dispatch($order)->onQueue('orders'),
| for example.
|
| This could also be written as:
|
| $job = new SendOrderToVendor($order);
|
| $job->dispatchOn('orders');
|
| (Exact function calls may not be correct, I'm on my phone)
|
| Functionally identical - same code path. The main gain is
| ergonomics, but it's entirely your choice how you prefer to
| write this code.
| motogpjimbo wrote:
| The issue isn't the exact syntax that's used to access the
| service object. It's the fact that any random chunk of code
| anywhere in the codebase can reach out to any other random
| piece of code. Syntactic sugar or not, that's considered to
| be an antipattern in pretty much any community outside of
| Laravel's.
| xcombelle wrote:
| I just don't get why people in php use lazy comparison when you
| know that "0e4"=="0e5" in php.
|
| and yes, Laravel use lazy comparison (hundreds of times). And yes
| at least three bugs where caused by this use.
|
| see: https://github.com/laravel/ideas/issues/698 for why I'm a
| bit grumpy with php ecosystem
| 12907835202 wrote:
| I'm mostly interested if this is a tiny hobby project by someone
| who wanted a nice example to use in arguments.
|
| Or an advert by someone involved with Laravel/Laracasts.
|
| As the former it's quite effective.
|
| The latter would be funny.
| 0xblinq wrote:
| Can anyone with experience in both compare modern PHP and Laravel
| vs modern Ruby and Rails? Which one would you choose and why,
| assuming you have the same experience in both?
|
| I'm asking because I keep hearing Ruby on Rails is the best for
| starting a SaaS, etc but from my little experience on it, it
| seems to me Laravel is way better. Is it just a "language" thing?
| That most people prefer Ruby to PHP?
| ChrisMarshallNY wrote:
| I've been writing PHP for over 20 years. I use it for my hosted
| (backend) programs.
|
| Works a treat. It's robust, fast as hell, easy to make secure,
| runs on the cheapest, crappiest hosting, and has an _enormous_
| support infrastructure.
|
| That said, I've never particularly liked the language, and have
| never become an advanced adept at it. I use it to manage the
| less-glamorous part of my work. I'm mostly a native Apple
| developer (Swift).
| Xeoncross wrote:
| I built and maintained open source frameworks in both. I left PHP
| for Go.
|
| 1. with http://sqlc.dev I don't have to write ORM or model code
| anymore. Define all your SQL in an easy to audit file and all
| your models and interfaces are generated for you.
|
| 2. with http://goa.design I can have well-documented OpenAPI
| API's that any team can generate a client for in any language. It
| also generates the HTTP JSON and gRPC clients/servers for me so I
| can focus on my logic.
|
| 3. with https://github.com/99designs/gqlgen I can define GraphQL
| revolvers that play well with sqlc (any RDBMS) or I can use a
| key-value store.
|
| 4. speaking of key-value stores, Go allows them to be embedded!
| Even SQLite now has the https://litestream.io/ project to make it
| super simple to use a durable, always backed-up SQLite database
| even in a serverless context.
|
| Go is faster, uses less memory, uses types, has built-in
| formatting, package management, benchmarking and testing. Go
| supports multiple cores in the same process, and has really-well
| designed stdlib without all the bugs I used to face trying to use
| the PHP stdlib.
|
| After writing millions of lines of PHP for years, there is
| nothing I miss anymore. Laravel still wants me to write models,
| controllers and views by hand and make all the client changes as
| by-hand code refactors.
|
| Go lets me focus on the actual logic instead of waste my time in
| PHP writing all the implementation details like controller
| requests handlers, db fetching logic, and input validation.
| devmor wrote:
| It sounds like you haven't touched PHP in a very long time.
| Your comment reads like a 2015 forum complaint - which, to your
| credit, certainly would have been all valid points 8 years ago.
|
| The language has evolved since. The ecosystem has evolved
| since. Most of the things you're complaining about are solved
| paradigms that no one does manually anymore unless they're
| trying to drastically improve on ecosystem tooling.
|
| Even your complaints about Laravel are solved by open source
| tooling in its own ecosystem.
|
| Nothing about your preferences are really unique to go - most,
| if not all of these tools exist in many popular languages.
|
| The one solid point you have is that go lets you do many of
| these things by default without adding anything. To which I
| say: Duh. Go doesn't have a massive ecosystem of backwards
| compatible projects to continue supporting. It was barely used
| outside of niche cases until 2-3 years ago. In 10-15 years
| time, I'm sure people will say the same things comparing Go to
| a newer language.
| Xeoncross wrote:
| You've made a lot of claims here without providing evidence.
| Care to post some links like I did?
| konart wrote:
| Why would you go with PHP+whateverframework instead of Ruby on
| Rails or Django?
|
| I haven't touched PHP since 5th version and I'm kind of sceptical
| it can offer anything RoR can't.
| nologic01 wrote:
| I don't know why you are being downvoted, this is a very
| legitimate question. These server-side frameworks are all alive
| and kicking and very competitive. When some other smaller
| ecosystem comes up with a good idea (like elixir/phoenix) there
| is a rush to replicate which happens rather fast.
|
| I think in the end the competition will lead to specialization.
| Python will almost certainly capitalize on its data science /
| ML links but its not clear (to me at least) how php and ruby
| will differentiate themselves.
| cutler wrote:
| Rails console, metaprogramming, elegant blocks, procs &
| lambdas, Turbo/Hotwire. Concise Ruby language vs PHP
| framework code with hideous inlined fully-qualified method
| paths.
| anonyfox wrote:
| all of that pretty much is available and arguably much
| better in Elixir/Phoenix
| cutler wrote:
| OP was comparing Ruby and PHP.
| pkphilip wrote:
| PHP 8 is a vast improvement over PHP 5. Also, the frameworks
| have become much better - I especially love the Yii framework
| as well as the Codeigniter framework if you are looking at a
| Rails replacement.
| konart wrote:
| I'm a Go dev these days and rather looking into TS and Rust.
|
| I was just curious to be honest. With RoR being what it is
| PHP frameworks has to offer something on the same level (at
| least) to be of any interest (as a I see it). Not to mention
| ecosystem\packages\gems\etc.
| pkphilip wrote:
| It is ridiculously easy to setup a full CRUD environment in
| frameworks such as Yii. It is as simple and selecting some
| options on a screen and then clicking on a button. The
| example below is from 7 years ago!
|
| https://www.youtube.com/watch?v=Xi0gH2izUy0
| mickael-kerjean wrote:
| Use the right tool for the right job. I always use plain PHP
| for all those things I want to keep running forever without
| having to spend time and brain space to maintain. You can't
| beat putting a file on a LAMP server and forget it's running. I
| have tons of public endpoint that do all sort of stuff , aren't
| core to my business and don't want to deal with the operation
| hassle that would come to keep such framework working and
| running in the long run.
|
| Just a few examples of such PHP script:
|
| 1. an endpoint that is being called by my CI to send messages
| on IRC and telegram when a new build is ready
|
| 2. the analytics bit of my project so I know who does what
| without relying on google analytics but by storing all that
| stuff in a mysql db. It's under 25 lines of PHP code and has
| worked a lot better for me than any analytics tools I've tried:
| https://gist.githubusercontent.com/mickael-kerjean/289d3d0be...
|
| 3. the target of the contact me form of my project
|
| 4. all the webhooks and other simple marketing automation stuff
| I need to process one way or another
|
| 5. all sort of online tools relevant to my niche to boost the
| SEO side of my OSS project
|
| 6. my status page which is an array of url I look after that is
| being curl around
|
| 7. crud cloud instance of my OSS project
|
| and many many more examples, got about a hundred random stuff
| running from a single cheapo VPS I don't have to maintain.
| konart wrote:
| Sounds like a scripted and slower (not trying to diminish)
| version of Go.
| chrismsimpson wrote:
| Go where exactly?
| latchkey wrote:
| > There is no need to compile anything.
|
| But I really like compilers, they catch a whole class of bugs,
| before I run things.
| mozey wrote:
| The compilation step, and the resulting binary, is also very
| useful if you need to distribute your software. As opposed to
| creating a ZIP file.
|
| There are tools for creating stand-alone executables from PHP
| source code, but they're not as nice to use, compared to
| languages that were designed for this. By distributing software
| I also mean making your latest code live in prod.
|
| I suppose the benefit of using PHP (or other interpreted
| languages) is that it's easier to create "plugins", just copy
| the new source files to the server.
| latchkey wrote:
| Correct. I had a use case where I needed to run an app on
| 30,000+ servers and the app would be updated regularly with
| new features. I wasn't going to use PHP for that because it
| would involve not only copying the PHP binary around (and
| maintaining that version), but also my own app code. golang
| ended up being a perfect solution because I could cut the
| binary down to about 3-4 megs with compression and build
| flags. More importantly, it was just one thing to install and
| maintain.
| apocalyptic0n3 wrote:
| PHP has a way to compile entire applications into single
| files, for what it's worth. You can compile it all in your
| CI/CD and then push the PHAR file to all the servers
| (instead of the thousands of regular files). I don't know
| if it accomplishes everything you're after, but it's been a
| PHP feature for over a decade.
| https://www.php.net/manual/en/intro.phar.php
| binhamstrr wrote:
| While you don't have a proper compilation step, you can run
| some very good static analysis on PHP.
|
| I can't imagine not having Psalm or PHPStan in our build
| pipelines.
| hakube wrote:
| Unit testing
| stackedinserter wrote:
| Not enough.
| Gigachad wrote:
| Unit testing is a poor mans compiler. Our medium size rails
| app has 40,000 unit tests and constantly we have issues where
| an updated library changed the name or parameters of a method
| without warning causing breakages.
| jjice wrote:
| Yikes. Is there a static analysis tool for Ruby (along the
| lines of MyPy or PHP Stan) that could have caught this?
|
| Also, out of curiosity, are all of those tests hand
| written, or is there some generation in there?
| Gigachad wrote:
| All hand written over 10 years. They catch a lot of
| stuff, but stuff still slips through. Generally the area
| of the breakage even has tests over it but didn't manage
| to catch the particular issue or they had mocked out
| parts which ended up being the issue.
|
| I can't see how static analysts could solve it really.
| latchkey wrote:
| imho, this is a huge reason why ruby fell off the
| popularity charts over time. i predicted this pretty
| early on and got a lot of flack from the ruby community
| as a result.
|
| nobody wanted to write tests to ensure that something
| would compile... let alone tell you what 'type' an object
| was. i can't tell you how many hours i wasted watching my
| pair trying to figure out what 'type' an object was, by
| using `print`. luckily i was working as a very expensive
| consultant.
|
| of course these things could be bolted onto ruby, but it
| never felt natural. running 40k tests to see if something
| compiles is absurd, takes forever and results in super
| brittle tests that have to be reworked when code changes.
| often people would use meta programming in the tests,
| which only made figuring out the errors even harder since
| the line numbers would be all wonky in traces.
|
| sorry you're saddled with that legacy of well intention
| and poor execution.
| oaiey wrote:
| And static typing, and linting, and code analysis, and security
| checks, and .. these pipelines are long nowadays
|
| Oh and the garantiert that no one can modify it post the
| compile step.
| CR007 wrote:
| I've been using PHP for about 19 years and what I can tell is
| that both the language and its community have evolved the right
| way. Writing modern PHP is a joy, IDE support is great and we
| have tools for everything.
|
| Modern PHP is about community standards, not about any particular
| framework and exposing Laravel as the best way to get started
| with PHP is questionable. I wouldn't recommend it to anyone
| wanting to learn (real) PHP.
|
| The article praises PHP but it is sad that doesn't link to any
| other resource or project which ditches the value of PHP
| community.
|
| Laravel is great for RAD which is attractive for small projects.
| The kind of stuff "business with 500K orders runs on a $6 VPS"
| thing. For clients wanting a robust software system you can use a
| better tool.
| mrunkel wrote:
| Yeah, I think phptherightway.com does a much better job
| introducing people to modern PHP.
| nologic01 wrote:
| Planet php has a strange and probably unique geography. It has
| its large continent of modern generic web frameworks but it also
| has these countless small but thriving islands of specialized
| platforms that solved specific problems.
|
| But islanders and continentals dont talk or help each other.
|
| You can obviously build from scratch a blog, a wiki, lms, forum,
| analytics, e-commerce, survey etc. etc. site in Laravel. The
| funny thing is that it is quite likely that the _leading_ open
| source solution for what you want to do is already in php
| (wordpress, mediawiki, etc) yet you cannot benefit much from it.
| You definitely cannot import it, but you cant even learn easily
| from it unless you dig deep into a complicated codebase.
|
| Because php is so old and so adapted to web development people
| went on and built wonderful things with it, capturing complex
| domains with all their peculiarities. But that valuable knowledge
| base remains fragmented and locked within each one of these
| monoliths.
|
| Going forward there is ever more intense competition between open
| source language ecosystems. A lot of improvement efforts look
| inward (making languages faster, safer).
|
| The php community might also be able to draw unique advantage
| looking more "externally", taping the enormous domain knowledge
| of all these projects. How that could be done in practice is an
| open question, but it could become the USP for php, the way data
| science has become for Python.
| danielinoa wrote:
| There is a syntax error in the example shown by that article. If
| you must use any time to find it then you should not go with PHP.
| minusf wrote:
| what this page means is: go with laravel.
|
| wordpress is also php. dont go with php.
| mekoka wrote:
| Any programmers here who've used PHP to build command line tools
| in PHP? What is the experience like compared to, let's say Python
| or node.js? How good are the facilities? What are the
| limitations?
| muglug wrote:
| I have rewritten more-or-less the same tool, 100KLOC, in Rust
| and PHP. I can't tell you about Python or Node.js
|
| Use PHP if
|
| - you're in a hurry and you already either know PHP, or the
| script is going to call other PHP code you've written
|
| - execution speed is not important (ditto for Python and Node)
|
| If neither of the above is true, give Rust a whirl.
| porker wrote:
| It's really good. Using the Symfony Console component you get
| sane argument and option parsing and validation
| (optional/required, single or array values), output styling,
| interactive inputs, tables etc.
|
| If you're wanting to build a TUI I haven't seen any libraries
| as advanced as the Python or JS ones.
| demurgos wrote:
| I tried to write a CLI tool for orchestration by wrapping some
| sub-processes. I found PHP very limited in its ability to
| handle subprocesses (streams, error handling, signal
| forwarding). I tried to avoid using frameworks, but eventually
| used Symfony's "Process" lib. It helped with Linux but Windows
| support is very limited.
|
| This experience was pretty disappointing, but also pretty
| niche. Overall I agree with the general sentiment that PHP is
| very nice to use nowadays, especially for web development.
| nunodonato wrote:
| here's a nice goodie https://github.com/nunomaduro/termwind
| naiv wrote:
| Symfony command is great for this
| https://symfony.com/doc/current/console.html
|
| But it really depends on what you need the command for.
|
| I use Symfony command for general things, Node.js for eg PDF
| generation, Python for ML, Rust for calculating Ranks/Scores
|
| Development time is the same for all of them.
|
| For whatever reason Node.js scripts always feel dirty to me. I
| can not even pinpoint why.
| pkphilip wrote:
| Very easy to do. Check out the getOpt function for argument
| parsing etc.
| marcrosoft wrote:
| No thanks. Those code examples are full of indirection and the
| bottom example reminds me of the object nested spaghetti mess of
| large PHP frameworks.
|
| Just because code reads well doesn't mean you can understand
| easily what it actually does.
| qprofyeh wrote:
| There's joke amongst PHP companies that modern PHP has finally,
| completely become Java.
| krapp wrote:
| (sits quietly in the corner wishing Hack had taken off, or at
| least that one of the things PHP took from it was native XHP.)
| rrdharan wrote:
| They're not wrong... PHP7+ is blazing fast, has a huge library,
| gradual typing support, etc.
|
| If starting a new project in the space where they all "compete",
| I would choose PHP7 or PHP8 with Laravel or Symfony (or maybe
| even WordPress) over Rails, Django and probably over NodeJS.
| jszymborski wrote:
| You lost me at WordPress haha...
|
| Ive a lot of love for WP, but I don't really get the appeal of
| extending it past blogging... if you're doing anything more
| complicated it's pretty trivial to implement blogging functions
| in your site.
| inconceivable wrote:
| wp's appeal is the admin/cms backend which can be used by
| nearly anyone. it can also be deployed nearly anywhere,
| easily.
| tobinfekkes wrote:
| The days of WordPress being used for only blogging are long
| gone. I have many, many multimillion dollar clients using it
| as the hub for their whole company (none of which have
| blogs). It's crazy how it just...works. A little PHP-FPM
| tweaks here, a couple NGINX tweaks there, and you're off to
| the races. Very little maintenance, almost no downtime ever.
| [deleted]
| jszymborski wrote:
| No doubt you're right, but the "just works" part kinda just
| seems like it's to be attributed to the LEMP stack no?
|
| I just wonder if a lot of these shops would be better off
| starting from something like OctoberCMS or all the Laravel
| add-ons like Nova or Spark which give you Admin and Billing
| UIs pretty instantly?
| zelphirkalt wrote:
| You are probably the cleanest WP + PHP developer in
| history, who contrary to the messed up ecosystem of WP
| plugins has clean coding style that puts everyone else in
| the WP ecosystem to shame then, or those multimillion
| dollar companies don't actually need that much
| functionality on their sites.
|
| Even the data structures in a default WP setup, making
| everything as post types is silly for anything not a blog
| and I wouldn't build anything on top of that ever again.
| Most of the examples (all I ever saw?) for themes are
| silly, because they use concattenation for HTML templating,
| instead of composition. Not long and a theme will become
| messy, unless one is very vigilant, but then code reuse
| inside the same theme obviously suffers.
|
| Basically the whole ecosystem is full of anti patterns that
| one would avoid usually, but that somehow have become the
| tutorial samctified way to do things in WP.
| unity1001 wrote:
| > You are probably the cleanest WP + PHP developer in
| history, who contrary to the messed up ecosystem of WP
| plugins has clean coding style that puts everyone else in
| the WP ecosystem to shame then
|
| When you give people the power to do anything and dozens,
| or even hundreds of millions of people start doing
| anything and everything they can think of, many will
| create major messes. That happens with anything that
| becomes extremely widely used.
|
| > or those multimillion dollar companies don't actually
| need that much functionality on their sites.
|
| The WP world is so big that it has its own
| specializations and their subspecializations. You cant
| imagine what kind of complexity is involved in such
| systems and the variety of the problems that are being
| solved.
|
| What WP does is to solve the problem of launching,
| running and maintaining A LOT of things right out of the
| bat, allowing you to build even more complex things.
| There are widely used plugins for many things ranging
| from using replicated databases to launching full fledged
| software/app store websites. The enterprise WP world
| builds on it instead of rejecting what others already
| built and are maintaining.
|
| WP runs 50% of all the websites at the moment. 30% of all
| ecommerce websites. And 'website' means anything ranging
| from the sites of CNN, Reuters to the $5 florist shop
| site a flower shop owner in Oregon just launched without
| knowing anything about programming...
|
| It works. That's whats important.
| nologic01 wrote:
| there is something to be said about the huge installed base
| of WP. one radical new plugin that is not deterred by the
| "blogging" typecasting can change the world.
| JodieBenitez wrote:
| Not gonna bash PHP, but WP... never again.
| spcebar wrote:
| My experience with WordPress has been broadly positive under
| certain use cases. What were the negatives you saw/issues you
| ran into?
| JodieBenitez wrote:
| I've had enough problems with WP installs that I won't ever
| touch it again and I don't even want to list specific
| issues, but it's all about quality. So for a while it has
| been the same story, over and over: - non
| technical someone wants a CMS - I tell them I'll
| build them what they need, then give them a quote -
| non technical someone doesn't like my quote and installs
| Wordpress and a gazillion shiny plugins, because "it's easy
| with the shiny admin panel and I can install it anywhere
| for cheap and all the functionality is already covered in
| plugins" - things break, because plugins are meh
| - things go real bad, security issues, loss of data, shitty
| performance, the whole pinata - non technical
| someone cries over the phone "can you fix my website ???"
| - I won't fix their website because I like to build things,
| not clean up someone else's mess. Feel free to fill that
| business opportunity but I want to do something else.
| JustSomeNobody wrote:
| Okay, but you didn't mention Go at all in the article.
|
| Jeffrey Way _is_ a really good teacher, btw.
| cutler wrote:
| 5 seconds per request isn't anything to shout about in 2023.
| tiku wrote:
| Laravel gets over 2000 requests per second in PHP 8.1
|
| https://kinsta.com/blog/php-benchmarks/
| cutler wrote:
| Unless you specify the hardware and compare with the OP your
| claims are meaningless.
| devmor wrote:
| There's a lot of reasons to both use or not use PHP, but of all
| the ecosystems I've developed in, PHP has the most lovely dev
| tooling.
|
| Every popular piece of dev tooling in the PHP ecosystem feels
| like it was made to solve a problem, do so as simply as possible
| and let you know all the information as cleanly as possible.
|
| There's contemporaries to most of those tools in every other
| major language, and all of them have problems or annoyances that
| I feel simply don't exist in PHP's tools.
| janmo wrote:
| > Your website is automatically protected against XSS, session
| hijacking, CSRF, SQL injection, host header attacks, and other
| vulnerabilities.
|
| That's quite misleading however
| zemnmez wrote:
| I want to second this. The top StackOverflow comment for
| protecting against XSS in PHP still recommends
| htmlspecialchars()
| https://stackoverflow.com/questions/1996122/how-to-prevent-x...
| which is a terrible and ancient approach (context-aware
| templates are the modern approach).
|
| I also Googled to check CSRF protection and all the sites I can
| find just discuss rolling it yourself; the example uses some
| CSPRNG that can potentially return not cryptographically secure
| numbers without erroring. https://www.section.io/engineering-
| education/csrf-protection...
|
| That's one thing that really drove me away from PHP. It
| presents an extremely simple seeming universe, in which web
| apps are very easy to write - but has really naive bones,
| requiring a lot of extra scaffolding to be safe.
| deanc wrote:
| You don't get XSS protection out the box from any language's
| standard library, nor CSRF.
| zelphirkalt wrote:
| Well, of course not from any lang that treats HTML as a
| string, but there are langs, which treat HTML as structured
| data, in their standard libraries. Take a look at SXML
| libraries for example. Whatever script you stored as a
| username for example, it would still get treated as text,
| not tag, when put into lets say a span or p. SXML is aware
| of the boundary between tags, their attributes and their
| content.
| deanc wrote:
| I googled SXML and it appears to be have implementation
| libraries in lots of languages. This is not the core
| language's standard library.
| zelphirkalt wrote:
| What do you put as the distinguishing feature between
| "core language standard library" and "comes with the
| language at installation"?
|
| Some example: https://www.gnu.org/software/guile/manual/h
| tml_node/Reading-... (no installation of anything third
| party required)
| deanc wrote:
| Alright, let's go with widely-used programming languages
| for now - I've been programming for over 20 years and
| never heard of Guile.
|
| I am not against the idea of having native protections
| built into stdlib, we can agree there, but it's
| disingenuous to suggest that this problem is unique to
| PHP as the parent comment suggested. It's the same in all
| of the major programming languages used to spit out HTML
| as far as I can tell.
| zelphirkalt wrote:
| Oh, very much so. I don't doubt it. Most of them are
| doing it wrong, fiddling with strings, instead of
| structured data, which HTML would lend itself really
| nicely to. Especially PHP, with its "output HTML" in-
| built mentality should have gotten it right, but did not.
| Many others did not do any better.
| Flimm wrote:
| You do get XSS protection out of the box in most templating
| languages, though, and PHP is also a templating language.
|
| Take this template: <h1>{{ title }}</h1>
|
| In most templating languages, for a title of
| "<script>alert();</script>", the result will end up being:
| <h1><script>alert();</script></h1>
|
| In PHP, which is a templating language, the equivalent
| seems to be: <h1><?php echo $title; ?></h1>
|
| But this will print the title unescaped, which is a
| security vulnerability, and incorrect. In reality, the
| equivalent is: <h1><?php echo
| htmlspecialchars($title); ?></h1>
|
| Now, you could say, don't use PHP as a templating language!
| But if you're not supposed to use PHP as a templating
| language, why does it behave as one? This is one of PHP's
| footguns to be avoided. Personally, I recommend a linter
| like PHPCS to catch issues like this one.
| deanc wrote:
| Templating languages are abstractions on top of other
| technologies. I don't see how PHP is a templating
| language. I could write that exact same code above in
| NodeJS and I'd need to use mustache to escape the output.
| So you can make the same mistakes in Node, Python.
|
| Nobody writes PHP mixing HTML and PHP anymore, and if you
| do you should run. Shit code is not unique to PHP and
| I've seen more than my life's share in JS and Python
| codebases.
| ptx wrote:
| > _I don 't see how PHP is a templating language [...]
| Nobody writes PHP mixing HTML and PHP anymore_
|
| PHP is designed to be a template language, but it's a
| terrible template language, so nobody (it is claimed)
| uses it as it was originally designed to be used anymore.
|
| So "use PHP" is not good advice if what you mean is "use
| a web framework and a separate third-party template
| language", which works just as well in any language and
| doesn't give PHP any particular advantage.
| notresidenter wrote:
| I think the easier way to do things is mostly always the secure
| way in Laravel, so unless you go out of your way to do
| something weird, you're mostly safe from those attacks once you
| know how it works under the hood (to some extent) and what
| Laravel does and does not do for you.
| o1y32 wrote:
| [flagged]
| nstart wrote:
| Just made the same comment and deleted it seeing that you
| already stated it. Protecting against all of these is hard and
| no tech is going to automatically protect for all of this on
| its own. Such a weird statement to make that takes away from
| the message of the site entirely.
| cutler wrote:
| Rails does a pretty good job.
| Alifatisk wrote:
| I've tried Laravel, it's a beautiful framework. But I see
| no reason to switch from Rails, it's a beast.
| 0xblinq wrote:
| Hi!
|
| I'm looking for advice on how Rails vs Laravel compare
| (as I'll have to pick one of them soon for a project).
| Assuming the same knowledge and familiarity on both of
| them, why would you prefer Rails over Laravel? Thanks!
| Alifatisk wrote:
| The reason why I stuck with Rails is because I am already
| a Ruby user. I like PHP and all but I am way more
| comfortable with Ruby.
|
| I don't think there is anything Rails can do that Laravel
| cannot and wise versa.
|
| It's about taste.
|
| I think Rails + hotwire hit the sweetspot for me!
| 0xblinq wrote:
| Thanks!
| cutler wrote:
| Ruby is a beautifully-designed, concise language. PHP is
| the opposite. If you like Java-style verbosity you may
| like PHP. I don't.
| Alifatisk wrote:
| Yea, I think what makes me enjoy Ruby a lot is the
| ability to meta-program a lot. I can mold the language to
| what I want to express.
|
| Of course, this can be a double edged sword if you aren't
| comfortable in the language yet.
| hk1337 wrote:
| PHP has come a long way and I have since changed my mind
| about Laravel but I love Ruby, and Rails does an awesome
| job. Laravel actually seems to try to mimick Rails in PHP
| jszymborski wrote:
| The code snippet is very Laravel, and it does a lot to stop
| all those attacks with that API.
| janmo wrote:
| I worked for a company and we used the PHP ORM Propel. So in
| theory no SQL injections you would think, WRONG.
|
| We used a function like findOne() (I don't recall exactly).
| It looked like this:
|
| $resetTokens->findOne($GET['password-reset-token']);
|
| The issue was that findOne would accept wildcards, so one
| could use ?password-reset-token=% in the URL and reset the
| password of any random users.
| hk1337 wrote:
| In both Symfony and Laravel these days they have their own
| request objects to help you get information on the request.
| You shouldn't be reaching into the get or post variables
| directly like that.
|
| i.e. $request->query('password-reset-token');
| blindhippo wrote:
| ... why would you pass $GET through to a logical layer with
| access to a data store write without sanitizing it?
|
| This seems like a pretty basic thing to fix, but then I
| only have your snippet to go by.
| oefrha wrote:
| That's a parametrized API that's supposed to be safe
| against injection, at least to anyone who's ever used
| parametrized APIs and hasn't read the documentation of
| this particular library in detail. That it supports
| wildcard makes as much sense as log4j executing code in
| textual messages.
|
| If an ORM/builder casually puts =/IS and LIKE in the same
| method, don't touch it.
| _the_inflator wrote:
| I totally agree with everyone before me here on the issue
| of security.
|
| If an app stands the stress test against say for example
| this comprehensive list(1), it can consider itself somewhat
| safe or at least benchmarked. Otherwise, only vague and
| unsubstantiated claims, which does not help PHP nor any
| other programming language or framework.
|
| [1] https://github.com/payloadbox/xss-payload-list
| creamyhorror wrote:
| I think the webpage is talking specifically about Laravel.
| It ambiguously doesn't mention Laravel till later, but the
| code snippet looks like Laravel code. Laravel's ORM does
| sanitise strings.
|
| The snippet also validates request inputs, so clearly it
| doesn't assume that inputs are safe.
| zerr wrote:
| Isn't it too much "string oriented"?
| mongol wrote:
| > It can handle more than 500,000 orders per month when hosted on
| a $6/month server
|
| Is this a statement from the real world? What business sells
| 500,000 orders in a month from a $6 server? I mean, if you sell
| that much, you would probably want a high-availability solution
| and they don't sell for 6 bucks.
| tpetry wrote:
| The message seems to be targeted at the ,,webscale" folks.
| Something like: Look, one 6$/month server can do more than you
| ever need. You don't need {complicated stack}.
|
| Just use two 6$/month servers.
| timwaagh wrote:
| For me the best platform is one that's easy to debug and the
| debugging story for php is one of the worst. Otherwise it would
| still be quite hard to read. But at least it's cheap to host.
| pas wrote:
| xdebug is pretty okay. PHP is single threaded, the entry point
| well defined, var_dump/die/echo works wonders, debugable by
| curl and simple php -S nowadays.
|
| it has orders of magnitude less complexity than the JVM, or
| even the various Python server runtimes (gunicorn, uwsgi, etc)
|
| at least in my experience. can you elaborate on what you see as
| the debug support deficiencies of PHP?
| graeber_28927 wrote:
| Not sure what exactly you refer to with "debugging", but I'm
| personally much happier with XDebug in VSCode, spamming my
| breakpoints and stepping through the code inside of the editor
| where I edit the code.
|
| I can set breakpoints in my react app too, but it feels weird
| to inspect code in the browser console. And since modern
| frameworks get compiled for the browser, it is all even less
| familiar at a glance.
| [deleted]
| phpisatrash wrote:
| The "Good Luck" at end speaks for itself.
| ynniv wrote:
| PHP has 99 problems, but shipping code ain't one
| jrsj wrote:
| PHP is pretty nice these days but salaries for PHP roles are
| terrible. I can get paid 50% more being half as productive
| writing Go (for no reason bc 90% of people using it don't
| actually need any of it's features or performance)
| alex_lav wrote:
| Use pretty much any language. It mostly doesn't matter.
| mproud wrote:
| We are pretty much at that point. Choose the language that
| works best with the tools or libraries you want to use... and
| if there aren't any specific requirements, use any language you
| want then.
| iamluzhe wrote:
| Replacing PHP/Laveral with JAVA/SpringBoot is not different at
| all.
| cutler wrote:
| Yes because PHP5+ is pseudo-Java.
| sberens wrote:
| As someone more familiar with js/react, is there an equivalently
| mature reactive frontend framework?
| lostdesign wrote:
| Laravel has inertia, livewire or alpine to get reactive/snappy
| frontends if you want to have an SPA. Inertia lets you use your
| react while not needing to write an api. Livewire drops the js
| completely and does the SPA-esque frontend with php, alpine is
| just a smol lib to make parts of the website interactive.
|
| Generally speaking, if you use PHP to build an API, you can use
| react still as is.
| cryptos wrote:
| $request->user()->orders->create($request->validated());
|
| This looks so wrong from an architectural point of view! A
| request has a user (which in the context of HTTP should be more
| or less only an authenticated principal), which has orders, which
| are created from the same request, where the journey started.
| There is no separation of technical and business concerns.
|
| See: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-
| clean-a...
| BafS wrote:
| It's terrible indeed but Laravel pushes for this kind of
| "fluent" apis
| RadixDLT wrote:
| sorry to break it to you, but symfony is much more superior and
| flexible than laravel.
| pdimitar wrote:
| Developer advocacy is such a weird thing, do it right and people
| will line up for you to mentor them and pay you for it, do it
| wrong and you will people scratching their heads asking "so you
| can do with this thing what you could do with Perl + CGI 15-20
| years ago and still not get more performance out of it?".
|
| Sadly this article is the latter.
|
| I'm working on both sides of the fence -- dynamic strongly typed
| language (Elixir) and static strongly typed languages (Golang,
| Rust) -- so I am already sold on the advantages of dynamic
| languages. That page is doing a poor job selling PHP to me
| though, f.ex. it's not clear when you do
| `$request->user->orders`, does that automatically go to the DB?
| Does it first fetch the user and then all their orders, or does
| it do it in one go? Is the whole thing prone to N+1 queries like
| Rails is (was? no clue about it nowadays)?
|
| Posting cute little coding snippets is skipping 99% of the story.
| The code must _remain_ small and simple and understandable and
| easy to dissect / troubleshoot, long-term, and allow for adding
| metrics / telemetry, analytics and such.
|
| So OK, we get it, you're so hyped about PHP that you made a
| website about it. Alright. Now do a cookbook. Next show us a
| 5-year old project and tell us how long does it take to add a
| feature or fix a bug exactly. Tell us of the issue that took you
| the longest to troubleshoot -- and why did it take so long.
|
| Before that this is basically a surface-level marketing page that
| says almost nothing and is not even accentuating the strong sides
| of your loved technology because what I am seeing here I can
| clearly remember 5 other languages I've done it successfully
| with: JS, Golang, Elixir, Rust and Ruby.
| crazydoggers wrote:
| > Is the whole thing prone to N+1 queries like Rails is (was?
| no clue about it nowadays)?
|
| Rails has had the 'include' method which solves n+1 since
| version 3.0 around 2010. Before that it also had preload which
| worked similar.
| scsteps wrote:
| It's cool to see PHP getting its second heyday once again. It's
| currently a perfect storm of two communities starting to notice
| PHP. From the JavaScript side, people are comparing React with
| PHP, and on the bootstrapped start up side, people are talking
| about just using a single index.php file for your entire product
| without dealing with a complex tech stack as inspired by Pieter
| Levels.
| awestroke wrote:
| > It's cool to see PHP getting its second heyday once again.
| It's currently a perfect storm of two communities starting to
| notice PHP.
|
| Really? I see no evidence that this is happening
| diordiderot wrote:
| The Frontend / server less / JS ecosystem craziness and high
| rate of change has left a lot of devs disenchanted.
|
| High profile posts over bundlers, tailwind, and microservices
| set the scene.
|
| A few popular people on Twitter have been talking about
| Laravel which has influenced other devs.
|
| Wind is in Laravel's sails, not php's
| o1y32 wrote:
| awestroke asked for evidence, but your long comment
| provided none
| evilspammer wrote:
| [dead]
| blueflow wrote:
| PHP has never been replaced as the dominant scripting
| language for the web.
| evilspammer wrote:
| Almost every PHP site also uses JavaScript so I'd say not
| sublinear wrote:
| [flagged]
| jasongill wrote:
| I would say that the thing that gives web devs a bad name is an
| attitude like yours.
| sublinear wrote:
| I hope you're nobody's boss. Talent doesn't come from mild
| mannered yes men and doesn't look like plastering over
| decrepit slop.
| chwilson wrote:
| > The fundamental flaw is still with the community preferring
| server-side rendering of pages
|
| Server side rendering is a flaw?
| zapt02 wrote:
| I hope you will mature one day and that you will see that
| whatever bad experience you had with PHP (probably many years
| ago if not decades) is not universal.
| Uptrenda wrote:
| Also: lets not forget one very important and under-rated side-
| effect of PHP -- it lets you write server-side code that can
| leverage a 'public' address. You might think 'well, doesn't
| everything let me do that?' Not quite. On 'free' VPS servers they
| usually have 'ephemeral' IPs or IPs that change. So while you get
| free bandwidth and compute -- it's hard to actually do anything
| useful with it like run a service if you don't have a public
| address. With PHP it's assumed it will be accessed from the web
| so if you run it on free shared hosting you get that
| accessibility built in.
|
| PHP is very good for writing services that cost literally nothing
| because you can run it on free hosts like 000webhost that give
| you everything you need to host complex services (upload,
| database, sub-domains, and more.) It's perfect for budget devs or
| maybe devs that want to make their infrastructure more resilient
| to ah... financial upsets...
| Gigachad wrote:
| Being able to host for free on dodgy free hosting is hardly a
| benefit anyone should care about.
| lostdesign wrote:
| You can throw it into lambda or vercel for that matter too.
| Yes you can use sketchy hosts but still can use legit ones
| too to host for free or very little money.
| Gigachad wrote:
| You can throw basically anything on lambda. That's hardly a
| feature of php
| polyamid23 wrote:
| Might be useful for teenagers / people with no disposable
| income to start trying web related stuff from a public
| library.
| bityard wrote:
| A great many good things that I still use on a daily basis are
| written in php. Roundcube and Nextcloud for starters.
|
| Some of the most fun I ever had writing basic CRUD apps and
| simple interactive websites was in PHP and Codeigniter back in
| the day. I'm pretty much Team Python now just because of the huge
| ecosystem but maybe it's time to give PHP another chance...
| barneygale wrote:
| [flagged]
| pphysch wrote:
| The problem with PHP is not that you can't write great
| maintainable codebases in it -- you certainly can.
|
| The problem is how easy it makes it to write obscenely
| unmaintainable anti-architected code bases in it. _The average
| PHP production code base is deeply offensive_. I 'm knee deep in
| one right now.
|
| You can still have awful code bases in Rails or Django or Go, but
| the opinionated nature of those ecosystems makes the average much
| better than PHP.
|
| If "PHP" were synonymous with "Laravel", that would be different.
| But it's not.
| jrm4 wrote:
| Nice. I needed this today. I teach "Advanced" Web Programming and
| my classes start next week. I've been generally ignorant of most
| of the kazillion fancy Javascript frameworks and have more or
| less kept PHP as the base of the course. This is what more-or-
| less has felt right most of the time.
| vonseel wrote:
| For "Advanced" Web Programming, I don't really feel like you're
| hitting the mark by sticking with PHP. Sure, it works, and will
| probably get the job done for most web projects any of your
| students will ever work on, but if you want to get people
| excited while making them employable, it's important to teach
| new tools and frameworks. Unless the "Advanced" part is more
| about the techniques and patterns and less about the language,
| I think you're doing them a disservice by not branching out.
| And, of course, you can teach patterns and techniques in any
| modern language.
|
| I'd expect to see some discussion of async job processing and
| front-end web frameworks in any advanced web programming
| course, high-school or college level. Honestly, just teaching
| the usual react stack with a typical node backend would
| probably be ideal since JS is approachable, react is still
| "cool", and you still only need to use one language.
| adamnemecek wrote:
| It's one of those posts again. I have no clue what compels people
| to write things like this.
| chasil wrote:
| I was expecting something about Go.
| latchkey wrote:
| That's why I say "golang".
| pier25 wrote:
| Me too. Some kind of weird Frankenstein of Go mixed with PHP.
| eberkund wrote:
| You mean FrankenPHP? The Modern Php App Server, written in
| Go.
|
| https://frankenphp.dev/
| omnimus wrote:
| Also Roadrunner https://roadrunner.dev/
| gabereiser wrote:
| Same, didn't see anything that was remotely Go other than a
| generic http handler written in PHP. The other part about
| handling 500,000 orders a month on a $6/host isn't very
| impressive. You can do orders of magnitude more with just PHP.
| You can do that in a minute with Go.
| asddubs wrote:
| turns out "go" is also a verb.
| paulryanrogers wrote:
| Thus is why I wish titles quoted names, at least where is
| there is any possibility of confusion
| smashed wrote:
| Not sure how quotes would help?
|
| If referring to the go programming language, the title
| should say "golang with PHP"
|
| There is no other way to disambiguate one of the most
| commonly used English verb from the obscure (in relative
| terms) programming language.
| paulryanrogers wrote:
| > Go with "PHP"
|
| And articles referring to Golang could read
|
| > Go with "Go"
| gabereiser wrote:
| Those of us who program in Go are always looking at the
| word "go" in that lens. Our mistake.
| simonhamp wrote:
| If you're looking for a great CMS and were bitten by WordPress
| back in the day, you should take a look at Statamic
| (https://statamic.com)
|
| It's a Laravel package and it's the best CMS I've ever used (from
| a dev perspective). v4 just dropped the other day
| omnimus wrote:
| PHP has a lot of top tier CMSes. IMHO bunch of them are even
| better than Statamic. Craft CMS (https://craftcms.com/) is a
| lot more mature database based CMS. Kirby
| (https://getkirby.com/) is better at flat-file and has a lot
| better admin interface. Twill (https://twillcms.com/) is better
| integrated in Laravel and is fully open-source. Statamic mostly
| feels like it's sitting besides Laravel and they call
| themselves Laravel based for marketing.
| simonhamp wrote:
| You're absolutely right! PHP is blessed (or maybe cursed,
| depeding on your perspective) for that.
|
| I believe Craft and Statamic share a root in
| ExpressionEngine, which I loved also. I've only used Craft a
| little bit, for me the biggest issue is that it is (or was
| when I last looked) built on Yii, which isn't my go-to
| framework in PHP.
|
| This is in no way a showstopper.
|
| I haven't used Kirby, but it looks like a completely stand-
| alone application so I'm going to miss being able to co-
| locate the rest of my application there with the full toolset
| of the framework behind, which for small sites I really
| appreciate about Laravel+Statamic having right out of the
| gate.
|
| I've also not used Twill, but it looks to be similar to
| Statamic (as it's also a package). Not sure how this can be
| more open source than Statamic tho... if you mean free as in
| price, I'm all for paying for great products to make sure the
| teams behind them can keep on churning out great work. I'm
| sure AREA 17 will keep supporting Twill for a long time to
| come, but it doesn't look to be the focus of their business.
|
| I'm also intrigued to know what you mean by "better at flat-
| file".
|
| UX of the admin interfaces is kinda subjective and less of a
| concern from a dev perspective (though it's still an
| important consideration if you're trying to pick the right
| tool for a client or another team!)
|
| > they call themselves Laravel based for marketing
|
| Same goes for Twill :) nothing wrong with hanging onto the
| coattails of a popular piece of tech
|
| AFAIK Statamic wasn't built on Laravel at all in the
| beginning. I believe Jack adopted it because it was clearly a
| great stack to build on top of. I think he made a great
| choice and I'm glad of it.
| omnimus wrote:
| Statamic, Kirby, Craft are all commercial products and not
| free licensed (as in freedom). Twill is only one that's
| Apache License 2.0. I agree this is both blessing and curse
| and for products like this is much safer to get the
| commercial product that has safer future. But for example
| if you wanted to start small CRUD SAAS based around CMS it
| would be feasible to do only with Twill.
|
| I don't think it's a good idea to have your product and
| your presentation website in one app so for me it's not a
| feature. They should really be separate concerns.
|
| I haven't used Statamic 4 yet but last time i've used it
| they didn't seem to use much from the Laravel. It basically
| publishes routes to Laravel from their own system and
| that's it. It even recommended it's own templating language
| Antlers. It just feels they want to really ride the Laravel
| wagon while still being just separate system. Thats OK but
| Twill for example really depends on Laravel and feels more
| deeply integrated with it.
|
| Craft is good simply because it leverages database powers
| well and it's super mature. Things like relations and
| search are a lot harder in flat-file systems. Twill does
| this OK. Flat-file systems generally have ways to use
| database but it's more work. I would pick Craft for sites
| where having DB is more advantageous than flat-file.
|
| Kirby is kinda it's own thing. It's oldest and mature,
| simple, steady but modern. It tries to have as little
| abstraction as possible. Opposite philosophy to all Laravel
| magic. It's kinda edgy and zen because of that. The
| advantage of less code and dependencies - it's super fast
| and easy to read source code. Not that it would matter in a
| CMS. Kirby embraces flat-file as kind of nosql database.
| For example every page has unique identifier that is
| indexed an can be referenced anywhere. I don't know about
| CMS that does that out of the box. And Kirby admin
| interface is also pretty different because it has no preset
| ways. When you install it it's empty - you have to
| completely define it. This can be huge advantage or more
| work for developer depending on what you do. It's more like
| build your own CMS package than CMS.
|
| Statamic has inspired lots of their features/implementation
| on Kirby and for years played catch up. Nowdays they are
| all very feature rich so it's more matter of taste (and
| price). Statamic has one really nice advantage and that's
| GUI blueprint builder. If you hate writing YAML to define
| admin area (which both Kirby and Statamic need) with
| Statamic you don't have to.
| RadixDLT wrote:
| WordPress is not your grandmas CMS anymore, its a full fledged
| framework and very secure.
| bpbp-mango wrote:
| Even if you write modern strongly typed PHP and make sure to
| handle all your exceptions you will still encounter null (and
| other) errors at runtime. The language is ok these days and far
| faster than Python & Ruby etc but still I would not choose a new
| project to use it.
| marcus_holmes wrote:
| > It can handle more than 500,000 orders per month
|
| Hilarious because other languages are capable of that per minute
| not per month
| hakube wrote:
| on a $6/month server. Are we also losing the ability to read
| now because of AI?
| cntrl wrote:
| 500,000 orders per minute on a $6/month server? Which language
| is able to achieve that?
| zer0tonin wrote:
| Go
| 00deadbeef wrote:
| And what about the database?
| cutler wrote:
| If you're going to pull numbers out of a hat at least
| provide some evidence, especially evidence based on a
| comparable workload.
| zer0tonin wrote:
| I actually wrote a whole article about this myself:
| https://alicegg.tech/2023/02/06/4dollar-vps.html
|
| TL;DR: go can handle 1000+ RPS on a ridiculously small
| server
| MarvinYork wrote:
| I think the point was the $6/month server here.
| alexriddle wrote:
| What stack can handle 500,000 orders per minute - 22.3 billion
| a month - on a $6/month server?
| callahad wrote:
| Most of them? 500k per minute is around 8k reqs/sec. $6 will
| get you 2 vCPU, so each CPU only needs to handle 4k requests
| per second.
|
| I'd at least expect that to be possible in Node, and would be
| somewhat surprised if a Go or Rust framework didn't hit that
| mark.
| cutler wrote:
| Maybe with "Hello world" in Node but not orders. Business-
| grade Rust web framework? Give me a break.
| jeroenhd wrote:
| I think 4k requests per second is quite ambitious even for
| native languages or garbage collected languages like Go.
|
| Hello world will work, but once parsing, validation, and
| database queries get involved, you'll need some beefier
| hardware to get those numbers.
|
| I can't get the cloud benchmarks for 2022 to work (a
| dedicated PowerEdge is the standard physical benchmark and
| that's not very realistic here), but according to these
| benchmarks: https://www.techempower.com/benchmarks/#section
| =data-r20&hw=... you're going to need some very optimized
| code to get close to 8k reqs/s.
| azangru wrote:
| > Read the following code as if it were a documentation page:
|
| If I read this as a documentation page, this makes me scared:
|
| `Order::create($validated + ['status' => 'pending']);`
|
| What does it mean to add an array to something?
| BystanderX wrote:
| It would be shorthand for:
|
| `$validated = ['key' => 'value']; $validated['status'] =
| 'pending'; Order::create($validated);`
| simonhamp wrote:
| This could be rewritten as:
|
| Order::create([...$validated, 'status' => 'pending']);
| azangru wrote:
| Ah, makes sense. Thank you.
| Y-bar wrote:
| As someone who likes PHP that stumped me as well, I *really
| enjoy working with PHP 8.1, but I could not really grok the
| code either.
| iLoveOncall wrote:
| Exactly the same as the spread operator in JavaScript or even
| the exact same syntax in Python, but we don't hear you
| complaining about those, do we?
| maleldil wrote:
| > the exact same syntax in Python
|
| No, because the example is showing concatenation of
| associative arrays. In Python, you'd use a dict, and you
| can't do `validated + {'status': 'pending'}`:
|
| ``` >>> validated = {} >>> validated + {'status': 'pending'}
| Traceback (most recent call last): File "<stdin>", line 1, in
| <module> TypeError: unsupported operand type(s) for +: 'dict'
| and 'dict' ```
|
| You can do `validated | {'status': 'pending'}` since 3.9,
| though. I think using union or the * operator (e.g.
| `{*validated, 'status': 'pending'}`) looks less weird, but if
| you're a PHP programmer, you already know what + does here.
| In the end, it becomes bikeshedding.
| azangru wrote:
| No complaints about the spread operator :-) But the plus in
| javascript produces this: [1,2,3] + [1,2,3]
| // '1,2,31,2,3'
|
| (never tried this in js before; so was amused by the result)
| endorphine wrote:
| Coming from Rails, how does Laravel compares? If you know both
| languages, which one would you pick? I've this hunch that there's
| no reason to lick Laravel over Rails, since that latter is the
| bees and knees for web development.
|
| Alternatively: what would you suggest someone getting into web
| development to learn? PHP or Ruby?
| solraph wrote:
| > If you know both languages, which one would you pick?
|
| The one with the best density of good developers in your hiring
| region if the application ends up scaling.
|
| > Alternatively: what would you suggest someone getting into
| web development to learn? PHP or Ruby?
|
| Neither. I would tell them to get into the Javascript ecosystem
| - not because I think it's necessarily good, but because that's
| where most of the work is. I'd also reccomend picking up at
| least one other general purpose language to be a bit more
| rounded such as Golang, Java, C#, Python.
| hit8run wrote:
| Personally Rails. From a business perspective both are fine.
| BilalBudhani wrote:
| I have worked with both Laravel and Rails. I would still pick
| Ruby on Rails for my projects because I feel the Ruby's
| ecosystem is more mature than Laravel's.
|
| Don't get me wrong -- Laravel (the framework) has some polished
| first party packages however, as soon as you step out to third
| party packages the quality drops significantly.
| pkphilip wrote:
| I would use the PHP Yii framework - it has generation of CRUD,
| controllers, models etc.. and excellent customisability.
| 1337shadow wrote:
| Still a lot more to type than with Python and especially Django
| anonymous344 wrote:
| of course php is best, but how do u do in app(web app/browser)
| notification with 6$/month apache & php? for example if there are
| 2000 users who need to push a message to when a queue job
| finishes in php backend?
| 00deadbeef wrote:
| Laravel lets you run tasks in the background. You just queue up
| those notifications and then some other task you wrote will
| come along and start sending them. Apache isn't involved.
| progx wrote:
| Performance is always a good argument, but, be realistic and be
| honest, most applications did not need ultra fast performance and
| most applications did not have hundreds of parallel users.
| simultsop wrote:
| I thought this is a workaround showing off how they use Go lang
| and PHP together, fell for it!
| badrabbit wrote:
| PHP malware on windows is a thing now too lol
| simonhamp wrote:
| And come check out NativePHP[1] where you can build native
| desktop apps using Electron or Tauri + PHP
|
| Starting with Laravel support and launching soon
|
| [1]: https://twitter.com/search?q=nativephp&src=typed_query
| fHr wrote:
| I too was a junior that was plagued by wordpress and php custom
| plugins, never again will I touch this language if I can.
| languagehacker wrote:
| I am an erstwhile PHP apologist. Having come back to PHP after a
| long time away (not really by choice), I can confirm that the
| language has improved significantly since PHP5. PSR was a huge
| success in a lot of ways. However there are still a few things
| that prevent it from being my language of choice.
|
| First off, there is a surprising number of core behaviors you'd
| expect from a modern web application that there isn't a clear go-
| to for in the PHP world. Does anyone know of a well maintained
| library for publishing and consuming AMQP messages
| asynchronously?
|
| PHP is still limited by living inside of the context of the
| request. This has an effect on certain types of application-layer
| caching, and makes for a poor model for backend scripting.
|
| You also still need to interact with multiple layers of
| dependency management -- from os packages to pear packages to
| composer libraries. Configuration can be messy, and many projects
| still aren't containerized.
|
| Finally, while the language has evolved, many of the projects
| that use it have not. The longer lived the PHP project, the more
| likely you are to encounter the exact paradigms that make it so
| hard to work with. Other languages have benefitted from a much
| greater percentage of their lifespan being supported by
| ecosystems that encouraged keeping your dependencies and the
| parts of your code that exercise them up to date.
|
| That being said, it's great to see that there is a path for
| starting new projects with a modern framework. But I would have
| said the same thing about Zend or Symfony, and those seem to have
| fallen off for reasons I don't know.
| mrunkel wrote:
| Async Messaging:
| https://symfony.com/doc/current/messenger.html#transports-as...
|
| Some of your complaints are a little weird. * The OS
| package/pear package thing is highly dependent on what language
| features you want to add to the base language. If you want, you
| can install all those features with pear. It's just easier to
| install with OS packages. * Composer used to add libraries to
| your code base * The fact that "many projects still aren't
| containerized" has nothing to do with PHP. I doubt there are
| many languages where that statement isn't true. * No idea why
| you think Symfony has fallen off. Laravel has large chunks of
| Symfony code inside it and the project is going strong with
| regular releases.
| PrimeMcFly wrote:
| I see no argument at all for using Laravel over Django or Rails.
|
| PHP was always a mess. Why would I want to come back to it now on
| the off chance they don't screw things up again?
| thomasfromcdnjs wrote:
| Exactly.
|
| array_filter and array_map, have different order of arguments.
|
| ($array, $callback) vs ($callback, $array)
|
| A small example of how inconsistent the language is from the
| ground up.
|
| Most people can explain their respective web servers, but I've
| never heard anyone even come close to what PHP/Laravel is
| actually "doing".
|
| Side Complaint: If you are working with Laravel Queue, it is
| such a hassle to reload your code changes when developing.
| ofrzeta wrote:
| So what's the programming language that's 100% consistent?
| For example Python isn't.
| cutler wrote:
| Ruby, Clojure, Go, Kotlin, Rust.
| pdimitar wrote:
| I doubt any language is at 100% but from my work with them
| Elixir, Golang and Rust are predictable and a joy to use. I
| don't remember the last time their API has surprised me.
| xigoi wrote:
| Perfect is the enemy of good. There are many languages much
| more consistent than PHP.
| lostdesign wrote:
| Yeah, but these things exist across languages. Laravel has
| collection methods that fix that and they can be used in any
| php project too.
|
| https://laravel.com/docs/10.x/collections#available-methods
| e12e wrote:
| I think I'll stick with rails if I want cute DSLs and lots of
| magic ("... broadcast an event to update the frontend in real
| time ..."). But sure, it's great that php has come a long way
| since php3.
|
| That aside:
|
| > It can handle more than 500,000 orders per month when hosted on
| a $6/month server.
|
| Surely it can do more than 700 orders per hour, 1 order every 5
| seconds?
|
| > The only additional fees are for a CDN (if you want your assets
| to be served faster) and a domain name
|
| Uh, so no managed database, but you recommend paying for a CDN
| before slapping Varnish in front of your static assets?
|
| I get that php might be eminently usable at this point - but this
| seems like an odd pitch.
| MattyRad wrote:
| I actually think this article undersells PHP, as it doesn't
| mention the incredible additions that PHP 8 introduces, nor does
| it mention excellent static analysis tools like PHPStan.
|
| I recently rewrote a PHP web app in Rust
| (https://soapstone.mradford.com/riir/) and although it was
| interesting, I think it would have been better staying a PHP app.
| As nice as the Rust compiler was, I felt PHPStan would have
| automatically caught a similar number of bugs, all the while
| feeling less combative.
| keyle wrote:
| As a fullstack developer who has worked many, many years in the
| javascript hellhole, I mean ecosystem, as well as the python
| ecosystem and .NET; coming back to PHP the last 2 years, working
| essentially in Laravel and the like - I couldn't approve more of
| this message.
|
| Seriously, PHP is the grand father that will drive you to class
| and you'll never be late, the car will never smell and everything
| will always just be fine.
|
| It's fast, it's typed (now), it's reliable.
|
| Laravel is pretty darn rock solid. I've used a LOT of frameworks.
| Most of them fall on their ass in either the documentation or
| performance scope. Laravel is beasty, reasonably well documented,
| handles hundreds of thousands of users without a scratch. Plays
| well with Redis and MariaDB or anything really.
|
| Just ignore the fugly standard library inconsistencies of (old)
| PHP, every language has their toilet corner...
|
| Oh and it's free. All of it. PHP, Laravel. And its hosting has
| always been the cheapest. You don't need a particular OS or
| certain cloud providers.
|
| When I consider the solutions of flask and microservices I've
| left behind, the many node processes running with pm2, the
| complexity of .NET solutions... PHP just works, and it's easy to
| make reliable... And if it's slow, it's because I'm doing dumb
| stuff, not because of dark corner edge case I happened to be
| tripping into.
|
| It's single threaded first, queue jobs for anything slower. That
| simple facts make it so much easier to reason about things, and
| keeps the fullstack linear, transactional and easy to reason
| about, 2 years into it.
|
| PHP is not the best language in the world. I prefer Swift and
| even Go for many reasons, but it's an easy, simple,
| straightforward language. It's the BMX of the languages.
| safety1st wrote:
| This 100%. It's actually a bit of a red flag to me these days
| if a developer turns up their nose at PHP. The language has
| matured a lot and building stuff with it is simple, cheap,
| straightforward and fast. If someone's still hating on PHP in
| 2023 it makes me wonder if they've been focused on more exotic
| technology because they were looking to pad their resume with
| more expensive skills, build science projects for their own
| amusement vs. what the business needed, etc. etc. Red flag.
| I've had these guys like this on my team and guess what, they
| built fancy over-engineered solutions to problems that no one
| had and then job hopped and left it for us to deal with. I
| can't speak for anyone else but I go into work every day for
| one purpose, and it's to ship shit which users use. I don't
| have room on my team for people who have other priorities. The
| amount of stuff you can get done with basically just PHP and
| Linux is amazing.
| 1123581321 wrote:
| I love PHP, but a red flag?! If they're busy in the
| Ruby/Java/C#/Go worlds (all get-it-done environments) then
| I'd just assume they don't read many Hacker News praises for
| PHP. It's easy to have not encountered it since the bad old
| days unless you work on a team that uses Laravel for some
| things.
|
| I do understand hiring someone who has that tradesman
| programming ethic and is comfortable with Linux, but that's
| more requiring certain positive traits.
| vonseel wrote:
| Exactly how I feel reading this thread, I had no idea PHP
| has changed so much.
| safety1st wrote:
| Yeah, that's fair. Now that you mention it, 90% of these
| guys where I get that red flag instinct I described are
| Javascript devs or wannabe Javascript devs. It's as if the
| JS ecosystem has driven an entire generation of developers
| insane
| 1123581321 wrote:
| I'm in complete agreement there; I've seen a number of
| those. I like to ask simple questions about what they
| like about programming to catch some of those issues and
| look for a certain amount of self-understanding.
| fsociety wrote:
| Ditto for any language. I think it is a good sign for someone
| to recognize the trade-offs a language makes, or even accept
| that they can complain about it while acknowledging they
| don't understand the trade-offs.
|
| But when a dev says X is objectively bad, that is not a good
| sign. Languages are tools, not a way of life.
| dgb23 wrote:
| > If someone's still hating on PHP in 2023 it makes me wonder
| if they've been focused on more exotic technology because
| they were looking to pad their resume with more expensive
| skills, build science projects for their own amusement vs.
| what the business needed, etc. etc. Red flag.
|
| I get that you are arguing from personal experiences, people
| you met and worked with. But this statement lacks context and
| nuance.
|
| There are developers who don't like PHP because of outdated
| reasons and possibly because they are snobs. Sure, that's a
| red flag.
|
| But there are many who have so many battle scars and war
| stories with the language and its ecosystem that they decided
| it's just not worth the pain anymore. Even though PHP has
| evolved (with regular breaking changes...) and tries its best
| to put something useful on top of a shaky foundation: The
| effort required to make PHP work with you, in comparison to
| other languages, becomes too large and painful. I'm not
| talking about superficial things here, nor do I have the
| tendency to overengineer stuff, quite the contrary. I'm
| talking about writing simple, robust and efficient code.
|
| However I would say there are three very good reasons why you
| should use or at least consider the language:
|
| - You want to quickly hack together something useful with
| minimal fuss, AKA its original purpose.
|
| - Buy-in of the OO, code generation, IoC/DI, magic framework
| stuff that Laravel/Symphony provide.
|
| - You have to.
| 0xblinq wrote:
| > But there are many who have so many battle scars and war
| stories with the language and its ecosystem that they
| decided it's just not worth the pain anymore
|
| This applies to absolutely every language or stack. You
| switch to Ruby because the grass is greener, and 5 years
| down the road you feel the same. Then you switch to Kotlin
| or Erlang or JavaScript and you'll end up hating it anyways
| if that's how you roll.
| chrisan wrote:
| This comes across exactly what the previous poster was
| saying as someone who turns their nose up to PHP.
| Especially the "you have to" gibe.
|
| > But there are many who have so many battle scars and war
| stories with the language and its ecosystem that they
| decided it's just not worth the pain anymore.
|
| I could say the same thing about javascript from the early
| days, through Jquery, and beyond. Should I turn my nose up
| to modern javascript because of the past 2+ decades I've
| been working with it? No because they are "outdated
| reasons" as you say
|
| > The effort required to make PHP work with you, in
| comparison to other languages, becomes too large and
| painful. I'm not talking about superficial things here, nor
| do I have the tendency to overengineer stuff, quite the
| contrary. I'm talking about writing simple, robust and
| efficient code.
|
| Do you have an example of this?
| dgb23 wrote:
| I don't turn up my nose though. I don't judge anyone for
| choosing tech, especially if they have good reasons.
|
| I'm also very loyal and pragmatic. I really tried.
|
| I don't want to start a language war here either. What I
| said above was a counterattack on the idea avoiding tech
| that doesn't agree with you is somehow a red flag.
|
| My general point is: consider that there are people who
| have earned their opinion the hard way. Even if you
| disagree.
| gspencley wrote:
| > I could say the same thing about javascript from the
| early days, through Jquery, and beyond. Should I turn my
| nose up to modern javascript because of the past 2+
| decades I've been working with it?
|
| Yes. And I say that as someone who has been developing
| "modern" Typescript web apps full-stack for the last few
| years.
|
| My issue with JavaScript are fundamental to language
| design decisions that can't be removed due to major
| breaking changes. Things like having to deal with
| `undefined` AND `null`. `==` vs `===` (more specifically,
| type coercion), prototypal inheritance in addition to ES
| classes in addition to TypeScript classes. Array.push
| causing mutations. Having `for of` in addition to
| `Array.forEach` etc. etc. etc.
|
| And then you have the fact that it is neither OOP nor
| Functional. So you get people from both backgrounds, and
| ideologues from both backgrounds, trying to squeeze
| JavaScript into their preferred paradigm, within the same
| code-base ... and JavaScript obliges. Because it is
| neither.
|
| Every single JavaScript application looks radically
| different from each other and, worse, in a large
| organization with many teams working on a common code-
| base, consistency becomes damned near impossible to
| enforce.
|
| And so you start adding lint rule after lint rule after
| lint rule until you have an entire team dedicated to
| maintain your custom linting bullshit.
|
| JavaScript is a complete shit show to this day even if it
| does have nice features and even if you can get up and
| running with it quickly.
|
| If it weren't so popular, and if it weren't the "language
| of the browser", I wouldn't recommend it for anything
| other than small teams who can decide on which "version"
| of a JavaScript adventure they want to strictly adhere
| to.
| jusssi wrote:
| > magic framework stuff that Laravel/Symphony provide
|
| The magic in these frameworks is evil, and likely a big
| part in ruining PHP's reputation. Laravel in particular
| hides way too much stuff behind magic, and when it goes
| wrong you find yourself sifting through OOP-obfuscated
| layers of framework and libraries just to find out how
| exactly your controller is called.
| dgb23 wrote:
| I agree with you. But, and this is a big but, it's a
| tradeoff. You also get benefits.
|
| This is why I said "buy-in". If you are comfortable with
| doing things in their way, you get a ton of leverage:
| easily consistent code, a fast and productive "get off
| the ground" experience. The downside is what you
| described.
|
| Personally I'm just not a fan anymore of these things.
| You quickly produce code that _looks_ clean and
| consistent. But it's also bloated and brittle, especially
| if you need to break out of the happy path. A framework
| like that is great if you don't do software design, but
| more of a hindrance if you do. There's no framework that
| can help you do a holistic solution. For that you need
| good tooling, a robust foundation (AKA not PHP and
| probably not JS) and a simple design.
|
| Again: Trade off.
|
| That's why many here in these discussions will tell you
| that X or Y is the best thing since sliced bread -
| because it fits their needs almost perfectly. But you
| also get many (like us) who have at least some
| reservations, because had to bend over backwards to fit a
| square peg into a round hole and ultimately wasted so
| much time that using X or Y wasn't worth it at all.
| karlerss wrote:
| I've been building on Laravel for some years now and I'm
| always delighted how you can just ctrl+click and see the
| internals (and the magic). They're pretty modular and
| extensible/overridable.
| nine_k wrote:
| It's like that with every framework: Laravel, Rails,
| Django, you name it.
|
| If you build a class of thing which the framework
| creators had in mind, and do not have a need to deviate
| from the prescribed ways, it's a force multiplier.
|
| Once you try to build something that does not fit the
| confines of the framework, it's of course possible, but
| the framework stops helping you, and after some time
| becomes more of an impediment instead.
| 0xblinq wrote:
| "...Once you try to build something that does not fit the
| confines of the framework..."
|
| Can you provide an example of that? In my experience
| people think too quikcly they're smarter than the
| community behind the framework and that it doesn't fit
| their use case, and the real cause is just that they
| don't "like" the recommendations and think they can do
| better. Plot twist: They don't, and usually end up
| creating a terrible mess. What would be the alternative?
| Building your own in-house undocumented, untested,
| unproven framework and/or tying together 100s of
| libraries? Are you convinced that's going to lead to a
| better result for all use cases of your application? And
| that once you leave the company, the next developer will
| think "Oh, this custom framework is great... I'm glad
| they didn't use Rails/Django/Laravel"... not my
| experience... at all.
|
| I think that these frameworks are the best choice for
| most project, and if they're not (Like.. you're building
| Google Earth or Figma or something really different) then
| the problem is that you picked the wrong tool from the
| get go.
|
| I don't think that "this one special case" is special
| enough like to not use a batteries included framework and
| go wild with your imagination. Unless you're a FAANG,
| otherwise you're wasting your employers money.
|
| As an anecdote, I once worked for a shop that used
| Django. One of the developers before I was there
| "decided" the Django ORM was bad and promoted bad
| practices, etc, etc... so he wrote his own "better" ORM
| on top of a postgresql library. You can imagine how that
| went, specially after he left and the second gen of devs
| arrived to deal with the monstrosity.
|
| This happens a lot more frequently than you think.
|
| We should stop thinking we're "so special". We must focus
| more on providing business value by writing product code,
| tests and documentation and less rewriting the world
| because it's cool.
| 0xblinq wrote:
| I honestly prefer community supported battle proven
| production ready "magic" than what most product developer
| under a deadline cobble together. In my experience the
| problem you describe happened like... 2 times in my 20
| years career. And I literally spend my entire days
| fighting my own colleagues very explicit smartnesses
| irobeth wrote:
| > when it goes wrong you find yourself sifting through
| OOP-obfuscated layers of framework and libraries just to
| find out how exactly your controller is called.
|
| debug_backtrace() has always been my friend in situations
| like this
| nine_k wrote:
| Indeed so. But there's value in an ability to find out
| such things without running the code, just by looking at
| it.
| okeuro49 wrote:
| > The magic in these frameworks is evil, and likely a big
| part in ruining PHP's reputation.
|
| Have you actually used Symfony?
|
| It's an absolute pleasure in its domain and includes rich
| debugging abilities through its dev toolbar.
| jusssi wrote:
| I have, though I admit it's been about 10 years since and
| my memory may be mixing in (pun intended) things from
| version 1.
| okeuro49 wrote:
| You're really doing a disservice to others with opinions
| that are so out of date.
| jusssi wrote:
| https://symfony.com/doc/current/page_creation.html
|
| Apparently there's now something called annotation
| routes. Which appear to be inferring functionality from
| comments.
|
| You made me look though. I suppose I had it coming.
| Arkounay wrote:
| They are not comments they are php8 attributes
| jusssi wrote:
| PHP8 attributes _are_ comments with a special format.
| hazn wrote:
| They are not. Attributes are metadata that can
| reflected/accessed at runtime:
| https://php.watch/versions/8.0/attributes
| krapp wrote:
| What ruined PHP's reputation is people believing the
| language itself was a sufficient framework and unsafe SQL
| and escaping practices being the norm, due to naive
| developers (which PHP has plenty of) thinking the
| simplest solution (eg concatenating strings and variables
| into SQL queries vs prepared statements) is always the
| most correct.
|
| I mean, with PHP you either use a framework or you
| necessarily end up writing your own ad-hoc, informally
| specified, bug ridden implementation of one. At least
| frameworks like Laravel are battle-tested and should at
| minimum cover the most obvious issues.
| galangalalgol wrote:
| OOP, codegen, vendorlock, and bloat-magic...
|
| Those resonate with me reminding menof some of the worst
| development experiences in my career. Different language,
| different domain, but I recognize it. The simplicity is
| alluring, and even enticed me at first. It just doesn't
| scale for problems that are complicated vs the ones you are
| shown as marketing. The managers and architects like it
| because it hides the confusing or non-elegant details from
| view, but that just makes it hard for the devs to work on
| it.
| Demoloto wrote:
| Just 6 years ago you still were writing type hints in
| comments as suse annotations which was not PHP standard.
|
| So PHP was and might still be a shitty language.
|
| And PHP was my first language I'm fine with scripting with it
| but it was ugly as hell to write big code
| usrusr wrote:
| And don't get me started with all the points where the
| syntax pretends to consume an expression but it's actually
| just the parser looking for a very specific pattern that
| will be read as if it was an expression, but other forms
| won't be accepted.
|
| Sure, it's perfectly possible to grow numb to those pains
| and some will even pat themselves on the back, claiming
| pragmatism over principles, but wow, if you're not used to
| that level of make-believe in computer languages you'll be
| paralyzed by disbelief. An endless series of "this can't be
| true!"
| switch007 wrote:
| These "as a super important hiring manager" brags are quite
| boring to read
| 0xblinq wrote:
| Don't you dare to tell me that my isomorphic Node trpc
| graphql with redux and sagas on top of next.js with SSG and
| SSR and parts in server components with my home grown
| validation and ORM framework and still no translations
| because they don't work together with everything else and
| deployed on serverless docker lambdas to a kubernetes cluster
| is over engineering a landing page with a contact form. So
| fast!
|
| That's a state of the art WebApp. You old PHP developer!
| qbasic_forever wrote:
| Wait you're not using islands architecture!? Hahahaha how
| quaint! Get a load of this site, it's not using islands!!
| iknowstuff wrote:
| You described the marketing website of my previous
| employer.
| 0xblinq wrote:
| And the marketing website of many others. It's not a
| joke. Pure real life.
| creamyhorror wrote:
| You're not using Temporal workflows? So outdated!
|
| Though to be fair, devs lose employability when they don't
| get to use (in their work) technologies that are gaining
| wide popularity. It's a balance to be struck by the
| CTO/architect (assuming the devs want or are able to demand
| that skills development in the first place).
| topicseed wrote:
| Yeh, JS-land is wild. In a way, it's amazing that this
| ecosystem is so lively and fertile, but my gosh it's
| draining.
| bilekas wrote:
| This made me giggle because I've heard stuff like this in
| serious situations.
| 0xblinq wrote:
| Of course, it's based of my personal experience too. I'm
| not claiming I invented this at all.
| rob wrote:
| Don't forget to deploy all that code to the edge. Your $5
| VPS in NY running both nginx and MySQL is going to be a
| huge bottle neck when somebody in Texas tries to view your
| simple website and it takes .10 seconds longer to load.
| You're going to want that contact form code on at least
| 1,000 servers worldwide for maximum benefits and
| conversions.
| edvinbesic wrote:
| Also, now that you are on the edge and your form
| submissions are web scale you likely need to model
| eventually consistency for the processing so you will
| need a highly available queue running somewhere.
| jjeaff wrote:
| Joking aside, as someone who runs their entire saas off a
| single bare metal server in Las Vegas, I have been toying
| with the idea of pushing some stuff to the edge. The
| reason being, sometimes those average load times are not
| giving you the real picture. If my average load time is
| 560ms per request because 90% of requests are 400ms and
| 10% are 2 full seconds, that might be a problem. Fixing
| those 10% requests and bringing them down in line with
| the rest would equate to an average speed up of only
| around 100ms.
|
| However, I'm not yet sure a complicated edge deployment
| would actually fix the 10% problem.
| cutler wrote:
| 10 seconds? Slight exaggeration, surely.
| samuellevy wrote:
| 0.10 seconds
| gumballindie wrote:
| PHP has matured and has been a nice language for a decade
| now. But PHP developers havent. Cargo culting "good practice"
| and lack of creativity plagues the community. Frameworks have
| become so heavy that you spend more time configuring them
| than actually adding value. Oh and some still argue over
| setters and getters.
| notresidenter wrote:
| That hasn't been my experience at all. Although, I do spend
| more time interacting with the Laravel community (a subset
| of the PHP community) than the PHP community itself.
|
| I found the (Laravel) community to be more about object-
| level discussions ("how to do x feature the best way
| possible") rather than meta-level discussions.
| znpy wrote:
| But that's kinda their point... you spend time configuring
| the framework instead of reimplementing from scratch and
| doing the plumbing yourself.
| gumballindie wrote:
| The issue is that there is so much configuration that
| it's basically coding. PHP frameworks are all bloat. It
| would have been much better to abstract things in a way
| that you actually spend time on features not thousands of
| configs.
| liveoneggs wrote:
| Then use lumen, it comes with laravel.
| gumballindie wrote:
| Nah, I'll use python or other proper languages, thanks.
| lelanthran wrote:
| > Nah, I'll use python or other proper languages, thanks.
|
| Python is no more "proper" than PHP as a language.
|
| In fact, they're both identical as far as footguns go.
| systemtest wrote:
| My experience is that if I join a team of PHP developers,
| there is a 40% chance of the team being professionals and
| writing good maintainable code. With Java, .NET and Python
| I would say 80%. C and C++ around 90%.
|
| This also reflects in their salaries.
| gumballindie wrote:
| That is my experience as well. A competent PHP developer
| can earn as much as developers for the languages you
| listed, but they are less frequent.
| stef25 wrote:
| > Oh and some still argue over setters and getters.
|
| Serious question, what does that argument consist of ?
| gumballindie wrote:
| Whether to use them or not. Petty endless debates over
| their benefits and drawbacks. Literarily for as long as i
| worked with php devs in all teams there was someone
| debating this pattern. As php is not strongly typed these
| can help with data type validation, can perform some
| logic when setting values, while others say it's
| inefficient as thats an unnecessary method call, or that
| no logic should be performed in them. Some prefer to use
| magic functions instead of setters and getters others are
| against it because it makes the code difficult to
| maintain, some say they should only be used for data
| entities, others want to use them for every property,
| some prefer them because you can rename properties while
| maintaining external accessors, others against then
| because of consistency, some argue over what naming
| convention is best, some want to persist data in some
| type of storage when making updates, some attach
| observers to them and so on.
|
| Bottom line is that the language being so flexible,
| unassuming, and swamped by needless features almost
| everything can be debated the point of exhaustion.
|
| Python, being more straight to the point and not
| overkilling oop allows for more focus on doing what
| matters: business logic.
| matheusmoreira wrote:
| > PHP has matured and has been a nice language for a decade
| now.
|
| And how did it manage that? Python forced people to deal
| with encodings properly and the result was _a lot_ of pain.
| You 're claiming PHP somehow invisibly fixed the numerous
| problems of the language without anybody noticing? That
| "fractal of bad design" blog post, everything described in
| it has been fixed?
|
| If so I want to learn how they did it. That's some heavy
| duty language evolution work.
| ceejayoz wrote:
| > everything described in it has been fixed?
|
| Everything? No.
|
| Much of it? Absolutely (and the more widely a particular
| point is agreed upon, the more likely it's fixed). The
| article is _eleven years old_.
| gumballindie wrote:
| Encodings are a non issue in PHP and the availability of
| web tools is much wider in php than for python. PHP
| matured in the sense that it from a wordpress type of
| hacky language to an almost decent language. It can be
| used properly if you know what you are doing (ie can
| scale really well for the web, can be secure, allows for
| good oop design, can be fast _for the web_, and has a
| wide range of supported packages, separation of concerns
| and so on).
| usrbinbash wrote:
| > and the availability of web tools is much wider in php
| than for python.
|
| If that was a metric for language quality, then
| Javascript would be undeniably the most perfect language
| ever designed by any intelligent species in the universe,
| judging by the number of frameworks.
|
| > to an almost decent language
|
| And now I would like to hear a good reason why I should
| use an "almost decent language", when I can use a decent
| one instead.
|
| > It can be used properly if you know what you are doing
|
| It doesn't matter what I do, the language still insists
| of having multiple modes of error handling, a massive
| amount of builtins all of which sit in my global
| namespace, it's configuration is still seperated between
| compiler flags, a system wide ini, and local config. The
| base deployment mode is still "dump files into folder and
| let CGI do the rest".
| gumballindie wrote:
| I am not saying that's a metric of the language's
| quality, nor am i saying that python is worse than php.
|
| What i am saying is that the offering of tools has
| matured in php - instead of a basic template engine like
| smarty you now have "advanced" templating engines,
| packages and so on. Python has less packages but that can
| also he because python packages work better and there is
| no need for an overwhelming number of packages.
|
| Regarding error handling that's precisely one of the many
| issues with php. There are so many ways of doing the same
| thing that it becomes exhausting. And what many php devs
| do is they work around these issues either by endless
| hair splitting debates or a dubious amount of made up
| design patterns.
|
| You shouldn't use php, i am totally against it. I think
| it's as bad as it can affect your mental health. Just
| saying that by comparison to it's previous versions it
| has come a long way.
|
| However it does handle character encoding quite well and
| you can scale as much as you want to literally. Probably
| because thats too complex for the average php developer
| and it was left to core language developers which are
| pretty competent and experienced.
| quags wrote:
| There are breaking changes from 4->5->7->(less so)8
|
| This is why so many basic php web hosts continue to offer
| older php versions because the old code will not work and
| why paid projects like cloudlinux hardened php still
| exists. Just in the last 2 years they finally ended
| security support for php4 on the hardened php project.
|
| So to explain how it worked, it wasn't as sudden as
| python, but the problem areas have been depreciated and
| removed as php has evolved.
| bzzzt wrote:
| > It's actually a bit of a red flag to me these days if a
| developer turns up their nose at PHP.
|
| Depends on the reasons. One good reason for preferring
| another language is .NET/Java business app developers can
| earn a lot more here than PHP developers ;)
| cies wrote:
| Oppositely: not being able to articulate the problems with
| PHP/Laravel compared to a stack of say Kotlin/Ktor or
| C#/MVC or Java/SpringBoot is a red flag too in my book.
| lowercased wrote:
| Have worked at a few places where PHP was dumped on
| because "it doesn't have threads". The dumper-folks were
| also noted to be for spending most of their time trying
| to fix threading issues (Java, usually). Saw this in
| person twice, have heard similarly from other colleagues
| over the years.
| cies wrote:
| I agree "it doesn't have threads" is a bullshit reason.
| Especially since it took JS's threadlessness to make
| evented (aka async, aka promise-based, aka callback-
| based, aka eventloop-based) mainstream, and for good
| reasons! It allows many to maximize the compute resources
| better than possible with the threaded approach.
|
| There are good reasons to avoid/switch-away-from PHP...
| Like weak compile time quality guarantees, messy std lib,
| low quality of available libraries, many security issues;
| all WHILE great alternatives exist for free! (e.g.
| Kotlin, Rust, C#, Java)
| KyeRussell wrote:
| To be blunt, you are a terrible hiring manager if your red
| flag is "they haven't got an up-to-date opinion about the
| shitty-history language that I'm personally into".
|
| This just sounds like PHP Stockholm syndrome with extra
| steps.
| ofrzeta wrote:
| I guess it depends on how it's communicated. If someone
| tells me he doesn't like PHP because of this and that
| reason, that's fine. Getting wound up about some specific
| programming language (feature) or any tech still raises a
| red flag for me. But then I might be terrible as well :)
| cjbgkagh wrote:
| I can be pretty confident that if a language is not from
| the ML family I'm not going to like it for all of the
| reasons it's not a ML language.
| cutler wrote:
| Whatever happened to passionate programmers?
| cardanome wrote:
| One of the reasons why I love working on PHP jobs is that
| I get to avoid "passionate" programmers.
|
| It's fine to be excited about programming but those that
| build their whole identity around it are just super
| obnoxious and not fun to work with.
| cutler wrote:
| Thousands at Railsconf or Clojure Conj would disagree,
| I'm sure but these languages are kinda special.
| rvense wrote:
| There's plenty of stacks that I'd say qualify as "simple,
| cheap, straightforward, and fast" (modern Java, for instance
| - huge red flag to me if people still turn up their nose at
| Java), including some that you'd probably consider exotic
| (honourable mention: Elixir+Phoenix).
|
| I personally never liked PHP, so I haven't kept up with how
| it has developed and I don't expect to start, to be honest.
| Of course, if you've got an otherwise interesting project
| that happens to be PHP and want to pay me to help you with
| it, I'll be professional about it, but there are too many
| alternatives that appeal to me more than PHP for anything
| where I have a say.
| keyle wrote:
| I think it's a case that unfortunately many people don't
| understand how simple a solution can be. They've been fed the
| typical books and articles and firmly believe that if it's
| just PHP it just can't be good. Right? I mean going through
| all this pain and requiring that many developers, means that
| this solution has to be much better? Right?
|
| On the one end of the scale you've got the PHP Laravel
| monolith, and on the other you've got the completely
| serverless bits of JS over lambdas, with 12 different
| technologies, buckets up the wazoo, to store 300mb worth of
| data.
|
| Then you're told 'yeah, but this is distributed'! Okay cool,
| so you save 50ms of latency. Super... How long does your
| javascript takes to start returning content? Right, much
| longer. What the hell is even a cold start? How is that a
| thing in 2023?
|
| PHP is unsexy. And people don't like unsexy. I, on the other
| hand, I like my vacations uninterrupted.
| zelphirkalt wrote:
| One does not need PHP for that. Most well known traditional
| web framework with server side template rendering will do.
|
| But yeah, before you jump through the whole ecosystem of JS
| and require 3 different third party services, only to make
| a website, that does not work with JS turned off and cannot
| be build and run any longer 3 month later, due to
| dependency fup, you are much better off with unsexy PHP.
| za3faran wrote:
| What about people who get their stuff done with mature, well
| established, and high performant Java and C# frameworks? The
| benefits of static languages is already established,
| particularly for longer maintained and larger code bases
| where multiple people work on them.
| tialaramex wrote:
| PHP8. You think it's a red flag when people don't believe
| that PHP _8_ finally got their shit together.
|
| What's that George W Bush line, Fool me once, shame
| on...shame on you. Fool me--you can't get fooled again. But
| we're not talking about getting fooled just once, or twice,
| we're talking about _eight times_.
| ceejayoz wrote:
| First off, this comment reveals some ignorance about the
| language. PHP 6 never existed. Trying to infer _anything_
| off version numbers like this is goofy; in a much shorter
| time period Node is up to v20. Does 20 versus 8 mean
| anything? No.
|
| No one got "fooled". The got a useful tool that got better
| over time.
| tialaramex wrote:
| Anybody who believes that _this_ time PHP isn 't awful
| can expect the same disappointment as the last few times.
| I'm an old man, I remember all the pain of _upgrading_ to
| PHP3 and for my sins my current work includes trying to
| cajole somebody 's PHP7.x code into running even though
| it appears their employer disowned the project we know if
| we don't make it work the "replacement" will never
| actually materialise.
|
| This is a language built by people who didn't really know
| any better, so I don't blame them, but it's ludicrous to
| pretend that it's a "red flag" to have noticed that this
| keeps happening and learned from that experience.
| devjab wrote:
| PHP has been a great language for a while, essentially since
| the world of enterprise became web based instead of application
| based. I suspect it's not seeing too much adoption because it
| wasn't always great, partly because a lot of enterprise is
| married to Java (which is frankly also in a decent state) and
| because JavaScript (with types) and Python lets your teams do a
| single language while also doing a react client or a lot of
| BI/ML.
|
| Most mature programming languages are nice to work with these
| days though. At least in my opinion. About the only one I
| dislike is C#, and that is mostly because whenever I need to
| use C# I need to use it with a combination of libraries (Odata,
| Entity Framework, Asp.versioning) as an example which simply
| don't work together unless you overwrite/extend half of them.
| Because for most use cases C# is as excellent as all the rest.
|
| But PHP was essentially build for the modern use case of
| everything being web-based and it's weird to see the reputation
| it still has. Then again, django is also an excellent tool for
| most modern work that doesn't see the adoption it should. I'm
| so sick and tired of having to deal with things like umbraco
| failing at things that have been a fundamental part of django
| for longer than some of the people reading this post have been
| alive. :p
|
| But I guess its all those things that keep me well paid. So
| maybe I shouldn't be too angry about it.
| EGreg wrote:
| For a framework that is radically different but also PHP-native
| (since PHP 5), would you like to spend an hour playing with
| https://github.com/Qbix/Platform ?
|
| If you do, please share your experience in a comment. I'd love
| to hear it. I architected this framework over the last decade
| :)
| dncornholio wrote:
| Quick scan.. I'm going to be 100% honest. Screenshots looks
| like it's a hobby project. While scanning the code I came
| across folders named "files", "classes", "includes" and
| "scripts" are big warning signs.
| pkphilip wrote:
| Very interesting. I am shocked that this is the first time I
| am hearing of your framework. Any chance you can make the app
| setup work using composure instead of cloning from the git
| repo? It may increase visibility to your project.
|
| But in any case, great job with the platform!
| EGreg wrote:
| Will look into it. You likely meant composer?
| KRAKRISMOTT wrote:
| The way your landing page is laid out isn't doing you any
| favors. If you are going to build a rapid application
| development platform, look at Retool for inspiration in terms
| of designs and copywriting. Cut the token stuff, otherwise
| you will lose customers or self select for crypto bros. The
| license you chose will turn off most professional development
| shops and the ones using the platform would be based in
| places like eastern Europe where the license will be ignored
| entirely. Your landing page design is fifteen years out of
| date, this is the sort of design used to bamboozle small
| trades shops and non tech companies in places like the
| midwest and the US south, you will have a hard time
| attracting the sort of web engineers that will help make it
| go viral. Again, it depends what sort of customers you are
| trying to sell to, but if you intend to make a profit, the
| usually advice would be to offer a cloud offering like
| WordPress. Selling web frameworks rarely work out unless your
| product is a specialized database.
|
| Your copywriting gives off strong old school enterprise sales
| vibes with a dash cryptomania. You are not going to get much
| organic product led growth among the US under 40 crowd here.
| I suggest taking a look at https://payloadcms.com/ and study
| their design, execution, and copywriting.
| EGreg wrote:
| You seem to know what you're talking about.
|
| I checked out payloadcms though, that site is pretty
| terrible...
| omnimus wrote:
| I am afraid that if you think that then there is no help.
| EGreg wrote:
| Umm... are you serious? I could believe you perhaps with
| your criticism but then you say this is the future of web
| design?
|
| The site you held up as the example I should emulate
| feels like some kind of terminal from the 80s movie
| "Hackers"... are we "hacking the gibson"?
|
| It features white text on a black background, overlaid on
| animated white text on a black background...
|
| Then you scroll down, and it has TEXT IN A GIANT SIZE
| going slowly across the screen..
|
| Then it turns to white and has a video that doesn't fit
|
| Then it has text of all different sizes, and code
| examples, which is irrelevant to most customers.
|
| I am not making this up. It's literally here, I would
| invite anyone to look at these images and tell me whether
| this is unironically what I should make the Qbix site
| look like: https://imgur.com/a/IMT6pgB
|
| Are you affiliated with that site or project?
| stef25 wrote:
| Could do with some improvements, a template, maybe a CSS
| framework if you're not using one yet
|
| https://i.imgur.com/RYEo7Gv.png
| EGreg wrote:
| I agree about the developer portal. Have you seen the
| other sections of the site? Start at the welcome page
| creamyhorror wrote:
| I mean no disrespect, but imo you need to get a modern UX
| designer involved in rethinking and redesigning your
| site. Message-wise, your site has too many angles, sells
| too many use cases, and has too many general marketing
| statements and not enough concrete examples. This only
| confuses readers.
|
| In terms of design, the site design (1) doesn't promote a
| linear flow of reading, (2) doesn't space out information
| with enough padding, (3) doesn't make good use of text
| sizing to create an information hierarchy, (4) has too
| many disparate and messy screenshots, and (5) has
| distracting cursor animations and alignment shifts when
| hovering over the top navbar. Overall, it makes for a
| messy, cluttered reading experience and imo likely turns
| many people away. Here's the page I'm talking about:
|
| https://qbix.com/platform/welcome
|
| The important thing is to present a very clear "how this
| is used" right away, targeted at a narrow set of use
| cases, in an easy-to-follow, nice design. Not too many
| examples; one key feature at a time. For the audience of
| devs, they need to see how the platform is used at the
| most basic level (the code and UI screenshots on that
| Payload CMS site are good examples). If you find that
| Payload site's layout confusing, you're probably out of
| sync with modern design. In any case, I hope this
| feedback helps.
| EGreg wrote:
| Please see the sister comment. If this is what "modern
| design" looks like -- no wonder things are so bad.
|
| Instead of clear text sizes and simple messaging like in
| https://qbix.com/communities, there are texts of at least
| 5 different sizes jumbled in.
|
| Instead of contrast so you can read text -- there is
| white text on black over white text on black.
|
| There is also text that is gray and low contrast until
| you scroll it into view, but then it gets covered up by
| code examples. Most regular customers are scared by code
| examples.
|
| Instead of one clear button or call to action per
| section, there are 20 on the screen, making the user
| unsure what to click and what the Information
| Architecture / hierarchy is.
|
| And moreover, all the links are black on white or white
| on black -- just like the text. No clear visual
| separation of where to click. It violates like every UX
| guideline I have read in the last 12 years.
|
| It has GIANT TEXT HORIZONTALLY SCROLLING ACROSS THE
| SCREEN the minute you start to scroll down. Then when you
| get past that, it has a GIANT VIDEO THAT DOESN'T FIT and
| doesnt look like a video, more like some more text in
| many font sizes.
|
| I could go on... but why? Do you actually _prefer_ this
| monstrosity to clean design: https://imgur.com/a/IMT6pgB
|
| By contrast, if you land on https://Qbix.com it looks
| empty and clean, and asks you who you are before showing
| you a page: a customer, an investor, a developer, etc.
| Then that page is specifically tailored to what you need.
|
| Text is text. Colors are colors. A large black menu bar
| is unmistakably at the top, organized neatly so you don't
| get lost, not scrolling out of the way.
|
| Unless you think apple.com is old outdated design and
| modern UX is the payloadcms site?
| creamyhorror wrote:
| While some of what you say is correct (e.g. about the
| scrolling text and the messiness in parts of the Payload
| site), overall your criticisms show that your view of
| what's easy to follow is pretty out of sync with
| developers here. What you perceive as "bad" isn't really
| taken as bad by most others here, and I'd guess they're
| more likely to have positive impressions of Payload than
| Qbix.
|
| The Qbix Communities page is definitely cleaner and more
| linear than the Developers/Platform page, no doubt. But
| it still looks very basic and again doesn't give enough
| focus to specific features. Instead it presents two
| videos (which aren't necessarily a good way to get people
| interested, since they may not even click on them). And
| at the bottom, it has two dense columns of smaller text
| packed together, which doesn't really invite people to
| really think about the features. Would be better if the
| text points were spaced out, given larger header text
| sizes, and accompanied by representative icons or even
| screenshots.
|
| I also watched the first video, and the example Yang 2020
| app you demonstrated also looks cluttered and squeezed
| due to the similar text sizing and lack of spacing things
| out. To me it looks like it's from 10+ years ago, before
| flat, material design really took hold of the mainstream
| and became consistent across many web apps and SPA. (Pity
| about Yang 2020!)
|
| Sometimes it's best to question why others are having
| such a contrasting response to you. It does mean
| something. Letting go of your own opinions and
| preferences can be helpful for finding greater success in
| a wider community. Seriously, think about getting
| opinions from a few UX professionals, and give them some
| weight when you evaluate them, even if you disagree with
| them.
| EGreg wrote:
| I do question it. I am happy to have substantive
| conversations, and improve things. You may not realize it
| but the current site(s) other than the Development page
| are the result of years and hundreds of iterations with
| people who expressed criticism just like yours. Including
| professionals. And thus what you say at this point is one
| data point -- but you can't please everyone.
|
| People often point out problems in design aesthetics, and
| imagine that the opposite solution somehow can be
| realized in a consistent way that makes everyone love the
| result and will make the difference in platform usaage,
| but no. That's not how it works at all. It's like the
| people who say "your app doesn't work" to a developer
| (with no details on a solution should be), and imagine
| that somehow this will lead to a much better app with no
| bugs that everyone will use.
|
| At the end of the day, adoption matters far more.
| Facebook is cluttered and ugly compared to many other
| clean beautiful apps, but people are super used to it.
| Discord is totally bewildering, with tiny gifs for flair
| and many controls are extremely hard to discover and
| operate, but people are used to where things are.
| Craigslist is ugly but at least it's straightforward.
| Many more beautiful sites fell by the wayside as they
| tried to take it on (remember kajiji? others?)
|
| As for Yang 2020... your criticisms are fine but you
| should realize the design wasn't ours. It was, in fact,
| following the design guide here since each community
| designs their own portal:
|
| https://cdn.hackaday.io/files/1665227124477248/Yang%20Gan
| g%2...
|
| You see, when you are designing a tool can be reused in
| many different environments with hundreds of variations
| that could go either way, and still has to work, then you
| realize that the design decisions aren't so simple and
| that these may be the least bad after having gone through
| _exactly_ the process you described.
|
| Look, if Payload's GIANT SCROLLING TEXT and white text in
| black over white text on black was the unavoidable result
| of hundreds of iterations, then I'd accept it. I
| personally think there are good reasons for what we have
| done, having tried tons of other variations. But I don't
| think the GIANT SCROLLING TEXT, or making all links look
| exactly like the text, is necessary or the inevitable
| result of iterating. We HAVE been listening to criticism
| and THIS is the result.
| sneek_ wrote:
| Hi, I made the Payload site
|
| Apparently it triggers you. I don't claim that it's
| perfect by any means (actually I think some of what
| you're saying is right).
| EGreg wrote:
| Sorry if my criticism sounded harsh. I was not triggered
| by it, but simply going into depth why I do not think I
| should spend time making my site look like that.
|
| My response was simply a reaction to the scope of
| criticism and the claim that this is the new best
| practices. Because the other site was held up as an
| example of what I should spend days emulating and making
| my site look like, the sheer time investment and "well,
| if you think it isn't good, then you can't be helped"
| made me believe that this is some canonical example of
| best practices and design. So I naturally critiqued it
| and said exactly why I thought the latest design standard
| was crap. That's why it came out like that.
|
| If I knew the author would be reading it, I would have
| been a lot more tactful in my criticism. But I do stand
| behind what I am saying. (For what it's worth, the
| developer section of Qbix also needs a lot of work, but
| the OTHER sections + overall design of the site I think
| are good -- but happy to take specific and constructive
| criticism in the same vein I gave it.)
| sneek_ wrote:
| Don't worry, I've been a designer for 15 years and I know
| intimately that I can't please everyone.
|
| It's hard to get under my skin. That's actually I think
| what your takeaway should be here - - you can't please
| everyone, but you should take all feedback as valid and
| try and deliver something that solves for your problem
| the most widely.
|
| If someone feels something, then they felt it. Including
| your reaction to my site, and the others' reactions to
| your site.
| mschuster91 wrote:
| > Just ignore the fugly standard library inconsistencies of
| (old) PHP, every language has their toilet corner...
|
| Personally, I do like the way the standard library is - almost
| all cases of where people whine about it being inconsistent, it
| is a consequence of the PHP standard library and _many_ of its
| extensions being extremely thin wrappers around libc and C /C++
| libraries in general.
|
| That, in turn, makes it often possible to just take straight C
| library example code, copy it into a PHP file, add a $ in front
| of all variables, and have it magically work.
|
| (IMHO, it's no surprise that the whiners tend to be younger
| programmers who have grown up with Java in their university
| education - us older "neckbeards" are so used to the C world
| that its conventions are second nature for us)
| a_subsystem wrote:
| >> That, in turn, makes it often possible to just take
| straight C library example code, copy it into a PHP file, add
| a $ in front of all variables, and have it magically work.
|
| * head explodes awesome
|
| I know what I'm doing this afternoon!
| mschuster91 wrote:
| Writing PHP bindings is pretty easy as well (once you
| manage to sort out build tooling, but that's a mess
| anywhere in C). Have fun :)
| throwaway2990 wrote:
| > Oh and it's free. All of it. PHP, Laravel. And its hosting
| has always been the cheapest. You don't need a particular OS or
| certain cloud providers.
|
| Unless you're getting shared hosting, then it's true for most
| things now. You don't need a specific OS or cloud provider for
| .NET, Java, Go, Rust... etc
|
| > When I consider the solutions of flask and microservices I've
| left behind, the many node processes running with pm2, the
| complexity of .NET solutions... PHP just works, and it's easy
| to make reliable... And if it's slow, it's because I'm doing
| dumb stuff, not because of dark corner edge case I happened to
| be tripping into.
|
| .NET isn't anymore complex than a PHP app. Unless you write
| many layers of abstractions. And nothing stops you from doing
| the same thing in PHP.
| nstart wrote:
| There's javascript in the back. And there's javascript in the
| front. Curious what you use for application development on the
| frontend and if you have some recommendations for that?
|
| Thanks in advance!
| keyle wrote:
| Most of the stuff we do now we do with "Laravel Livewire".
|
| It's quite brilliant really, even for modals etc. "look ma,
| no javascript!". Of course it does JS for you, you just don't
| see it. That's my favourite kind of Javascript - someone
| else's problem. Livewire is a mid-way between front-end
| backend, it's a progressive back-end with long polling like
| NextJS I suppose. From your end though, it takes care of all
| the security of running your own API, and correctness. You
| basically have dynamic front-end from the backend.
|
| If you want a full SPA or you need an application that is
| very responsive without network requests, I recommend VueJS -
| Livewire recommends AlpineJS, but of course you might be a
| React guy, that's fine, and use Laravel as a regular API.
|
| You can even use GraphQL if you want to die of a young age,
| have some weird kinky thing going or you have something to
| prove... Unless you're Facebook of course you probably don't
| need GraphQL.
| kaba0 wrote:
| > it's a progressive back-end with long polling like NextJS
| I suppose
|
| It's kind of funny that this is the new best thing, when
| this is almost the same model JSF did decades ago.
| [deleted]
| robertlagrant wrote:
| It just had so many other issues with its ergonomics that
| this nice innovation was lost in the weeds a bit.
| kaba0 wrote:
| That I agree with, though I found that for internal admin
| pages with many forms, there was nothing more productive.
| robertlagrant wrote:
| I actually used a product that built on top of it, so my
| experience is probably worse than yours!
| 0xblinq wrote:
| I've always told my coworkers and friends that the programming
| language doesn't matter at all (despite I don't think there's
| anything wrong or worse than alternatives in modern PHP). What
| matters is the frameworks, libraries, ecosystem, editor
| support, available talent, culture around it, etc. And PHP (and
| the Laravel ecosystem) is rock solid in that area, the best by
| far. I'm a frontend dev at a pretty big company, but before
| this I worked on a Laravel + TurboLaravel (Hotwire, etc) and
| it's just incredible how easy and quick it was to build and
| maintain things.
| liendolucas wrote:
| > It's fast, it's typed (now), it's reliable.
|
| Fast, the most overrated feature that we developers endlessly
| look for. How fast? How much are you winning, milliseconds,
| nanoseconds, picoseconds? It's extremely likely that if
| something is slow is because you're doing something wrong
| regardless the language and/or framework.
|
| It's reliable PHP? Well, so are Python, Ruby, Go and other
| friends, right?
|
| > Laravel is pretty darn rock solid.
|
| Again, so are: Rails, Flask, Django and many other matured
| frameworks out there that have been baked for years now. Unless
| you pick some toy framework project written in a weekend I'd
| say there are plenty of rock solid options out there.
|
| > Just ignore the fugly standard library inconsistencies of
| (old) PHP...
|
| I'll just prefer to pick a language that narrows/discards that
| dark side as much as possible. Very long time ago I couldn't
| finish reading a page whose author painstakingly detailed every
| single inconsistent feature of PHP (literally it could have
| taken a whole day to read). After that horrifying testament I
| said myself to ever get my feet wet with PHP. Now in a team
| with PHP you will need to agree which "inconsistencies" should
| be left out either by adding some tool to automatically watch
| for that or educating onboarding members of your team.
|
| > Oh and it's free. All of it. PHP, Laravel.
|
| Aren't the other friends out there also free? All of them?
|
| > When I consider the solutions of flask and microservices...
|
| Flask AND microservices are two completely different things.
| You can have a full fledged monolithic Flask application or go
| with the microservices rabbit hole with ANY technology and/or
| programming language that you want.
|
| So PHP, well... Nah. At least not for me. There are plenty of
| interesting languages and technologies out there to be learnt
| and PHP for me is definitely not one of them.
|
| One question aside out of ignorance. How do people debug in
| PHP? Many many many years ago I worked for an extremely short
| time for a company that were heavily using Laravel. I didn't
| know how to debug a PHP program at a time. People told me to
| simply do "prints" to the rendered template. If I remember
| correctly I also tried to find some tutorial or howto on
| debugging with PHP only to be unsuccessful. I'd be interested
| to know because with Python is just a joke to do that. Install
| ipython and ipdb. Then set `import ipdb;ipdb.set_trace()` and
| you are done, you get the full fledged mighty console where you
| can see everything you need to track down an issue. Up today I
| haven't got the opportunity to testify someone using a similar
| capability with PHP but hey I might be wrong and something of
| the like is out there.
| a_subsystem wrote:
| > How do people debug in PHP?
|
| Mostly xdebug. There is also ZRay on IBM if you use Zend, but
| I've never used it.
| user3939382 wrote:
| Most things wrong with PHP that I really care about are
| currently being resolved in Psalm which undoubtedly will
| eventually (might be 10-15 years who knows) be rolled into the
| language.
| Demoloto wrote:
| Have a look at quarkus.
|
| Thanks to JVM you have really good out of the box debugging
| features including hot code replacement and profiling.
|
| You can use kotlin which is a really really good language in
| comparison to PHP.
|
| There is no need in my opinion to write real applications with
| PHP.
| abujazar wrote:
| In my experience Laravel teams are WAY more productive than
| Quarkus teams though.
| creamyhorror wrote:
| Is C#/.NET overly complex? I'm used to Laravel and have been
| exploring C#/.NET, which while a bit complicated is nice for
| the static typing. I've been hearing that for web apps the
| Laravel ecosystem is still simpler and more batteries-included
| than the equivalent ASP.NET.
|
| IME, Laravel's "easy deployment" story is heavily linked to the
| paid service Forge, and installing dependencies during
| deployment is a bit slow plus takes a /lot/ of memory (we're
| using old Composer and Laravel versions though). What's your
| take?
| z3t4 wrote:
| > It's single threaded
|
| You could make it single threaded. But the standard is multi
| threaded, and if you have more then 100 users will be have to
| deal with locks.
|
| That said, locks/threads are still easier to manage then async
| code.
| acherion wrote:
| > Laravel is [...] reasonably well documented
|
| Hard disagree. Sorry, I don't have a computer science degree,
| why does their documentation make that assumption. I find their
| docs very hard to grok.
|
| PHP.net docs are no-frills no-fuss, straight to the point.
| Other frameworks are documented very well too, CakePHP comes to
| mind (at least, when I was using it last in v2 and v3).
|
| I can't say I've read the absolute latest version of their v10
| docs, but when I was neck deep in 5.8 I found I had to switch
| to older versions of the documentation to read up on some of
| the most basic of Laravel features. eg. What's the syntax of
| using Form in Blade templates? I had to go back to v4.x docs to
| read up on it, Blade templating hardly got a mention in v5.x
| documentation, despite it being critical component in a Laravel
| application.
|
| If there was a bug in a project and I had management breathing
| a fire down at me because it's breaking the site / losing sales
| / stopping monthly reports from going out, I shouldn't need to
| decode computer science terms, or look through previous
| versions of documentation to find the solution.
|
| This is why, in my opinion, Laravel documentation sucks hard.
| bearmode wrote:
| Really? I don't have a comp sci degree either, and yet I find
| the Laravel docs incredibly easy to grok. Do you have any
| specific examples of things you've struggled to understand?
| naiv wrote:
| The documentation for Laravel is still unreadable.
|
| Guess that is why selling Laravel tutorials seems to be a
| fruitful business.
| KyeRussell wrote:
| Laravel tutorials are a fruitful business because PHP still
| quite rightfully carries its legacy of being the noob
| language.
|
| I'm sure that plenty of us used PHP in the day, have been
| doing something else for a while, and see these HN posts
| from the people that stuck by PHP singing its praises.
| Let's not forget that there's probably been a steady stream
| of newbies coming through the system the entire time -
| which makes the language, and by extension Laravel, a prime
| target for bottom feeding 'one step ahead of the audience'
| "educational" content producing scum.
| rob74 wrote:
| The documentation for Laravel _is_ readable, in the sense
| that if you read it from beginning to end, like a book or
| tutorial, you will get a pretty good understanding of what
| Laravel does. But [supreme being of your choice] help you
| if you just want to find out what the possible values for a
| specific parameter of a specific method can be...
| hparadiz wrote:
| Nah. It's pretty bad. They only document like 5% of the
| features. What they do document is good but other than
| that you have to read the source on GitHub or Google for
| code snippets and I say this as an expert that studied
| the docs for help in documenting my own orm. They just
| straight up don't document most of Eloquent's features
| and class methods in the docs at all and it's super
| frustrating to me.
| myspy wrote:
| But why? I'm working with it daily and what I learned is to
| read the docs properly. Usually it's me not reading
| correctly. There is some advanced stuff that's not covered
| in the docs, but not necessary to build an app.
| rob74 wrote:
| That's exactly the point: a documentation should be
| _comprehensive_ , i.e. it for each class and each method
| it should describe exactly what the method does,
| including all parameters etc. The Laravel "documentation"
| is a _tutorial_ , i.e. it describes what you should do
| for the most common use cases in a style designed to be
| read from beginning to end. Which has its uses too, but
| as _documentation_ , it's pretty lacking...
| Double_a_92 wrote:
| Agree. Last time I tried Laravel the documentation was
| lacking a bit. E.g. there are lot of "automagic" things that
| aren't explained. And then you are left wondering with things
| like "Must the names of those 2 things really match for it to
| work?".
| jitl wrote:
| What are the "computer science terms"? I went looking in the
| docs briefly but didn't find anything like that. Maybe the
| v10 docs do better? https://laravel.com/docs/10.x/blade
| whc wrote:
| there are many documentations tells you the detail in their
| code.... even with the most basic usage
| Elte wrote:
| The documentation reads like a tutorial, which is fine the
| first time you read it, and really annoying the next 99 times
| when you're just trying to find something. My biggest gripe
| though is that the majority of classes / methods aren't
| locally documented with comments, or only minimally. If I
| don't understand how a certain parameter behaves (or even
| what a function does), I have to go online and search for
| examples, or look through the docs hoping that it's
| explained. And don't get me started on Facades, which are a
| code discovery dead end...
|
| All that being said, my overall experience of working with
| PHP / Laravel is quite pleasant, probably more so than other
| technologies I've worked with in recent years. Everything has
| its issues I suppose.
| crabmusket wrote:
| Yep, the tutorials/guides are really good, but as you say,
| the details aren't really covered. There are so many
| examples like "relationsToArray(): Get the model's
| relationships in array form."[1] Just an expanded version
| of the method name with no context or detail.
|
| [1]: https://laravel.com/api/10.x/Illuminate/Database/Eloqu
| ent/Mo...
| zelphirkalt wrote:
| The good ol' "you thought docs, but actually generated no
| information gain and no docs, ha tricked you! but look at
| how fancy our docs website looks" kind of documentation
| style.
| sph wrote:
| > The documentation reads like a tutorial, which is fine
| the first time you read it, and really annoying the next 99
| times when you're just trying to find something.
|
| Ah yes, the Ansible approach. I've used it for a decade,
| and I routinely get lost in its utterly terrible by-example
| documentation.
|
| They are the golden standard on how not to write
| documentation.
|
| God, I hate the Ansible docs so much, they are the reason I
| burned 30% of my Kagi search quota this month.
| ayewo wrote:
| I think more documentation teams need to know of the
| concept of Diataxis [1] so they can invest in the 4
| different kinds of documentation developers turn to for
| help when picking up a new technology:
|
| - tutorials;
|
| - how-to guides;
|
| - technical reference and;
|
| - explanation.
|
| 1: https://diataxis.fr
| maw wrote:
| Thanks for this. This is something I kind of knew but
| would have been hard pressed to articulate, especially on
| the spot. Seeing it laid out like this is very useful.
| a_subsystem wrote:
| This looks very nice and is something I have been
| searching for but didn't know existed. Thank you!
| tepitoperrito wrote:
| See also the C4 model "for visualising software
| architecture". https://c4model.com/
| kristofferg wrote:
| For stuff like Ansible (and other lacking software) docs
| i find that ChatGPT can provide the missing pieces.
| mschuster91 wrote:
| What is wrong with the Ansible documentation?! Almost all
| Ansible module documentation pages follow the same
| structure: a one-sentence synopsis, a list of OS packages
| needed to be present on the machine where Ansible runs
| and on the target machine, a table of parameters
| including aliases, default values and other hints, a list
| of attributes exported, some notes, and real-world
| examples.
|
| It doesn't get more clear than that.
| sph wrote:
| Outside of modules documentation, the rest of Ansible
| docs are examples. For instance, there is no page where
| all ways of accessing inventory variables are listed. Or
| supported jinja filters. They are all scattered in a
| myriad of examples, which you have to read, carefully, to
| find what you need.
|
| https://docs.ansible.com/ansible/latest/playbook_guide/pl
| ayb...
|
| On this page there is no quick index of all the functions
| available, their argument and a short summary of how they
| work. You need to synthesize this information yourself by
| reading through ALL the examples, and hoping your niche
| use case is listed.
|
| There are more than one type of documentation, with
| different use cases. There's the tutorial/list of
| examples, which Ansible excels at, and is ideal for a
| first timer reading the docs from cover to cover. Then
| there's the API reference with quick index, for
| intermediate to advanced users, where they know roughly
| what they need, they just need to find it. In this,
| Ansible's docs fail dramatically.
| mdaniel wrote:
| I am certainly not one to defend the new ansible docs,
| but part of the woes that you're describing are due to
| the fact they just doubled down on `ansible-galaxy
| install` based setups, meaning there isn't "an answer" to
| what filters are available in ansible
|
| The authoritative answer to what filters are _currently_
| available in _your_ distribution is by running `ansible-
| doc -t filter --list` which does include a summary line,
| although for some of them it 's "geez, thanks" just like
| any open source collection of disparate modules glued
| together
|
| I used to actually build the ansible docs locally with
| singlehtml because I despised that chopped-up view, but
| now that they're all "galaxy all the things" it's
| practically useless again (although I will also say that
| building it locally and eliding all their tracking
| bullshit makes the pages load like a bazillion times
| faster, so ... still valuable in that way)
| dotancohen wrote:
| What "computer science terms" did you encounter, that you did
| not understand? I also do not have a CS degree, but every
| term that I've encountered in the Laravel docs I found easy
| to search for. Just don't rely on Wikipedia for explanations,
| for CS (and mathematics) subjects Wikipedia seems to be
| useful only to those already versed in the field.
| acherion wrote:
| I struggled with sorting out Contracts vs Facades vs
| Traits. I graduated from university 20 years ago with a
| software engineering degree, where it was drummed into me
| that simpler often is better, and much more robust. Reading
| the Laravel docs however, leaves more questions than I
| started off with.
|
| eg. https://laravel.com/docs/5.8/contracts - talks a lot
| about how Contracts are powerful additions (like all the
| other features of Laravel, the docs are good at telling you
| they're powerful) and the examples show just some barebones
| code that doesn't really do much without a lot more work.
| The examples in the documentation seem to be more on the
| side of being some code snippets that don't convey much
| context.
|
| Additionally, there's lots of "congratulatory" text in the
| documentation ("Laravel has a powerful feature called <x>",
| "in Laravel adding <feature y> is actually really simple",
| "some developers enjoy using <feature z>". You simply don't
| see this in PHP.net's docs, it just tells you what the
| function / feature is, gives you examples that work
| straight out of the box, lets you know of any pitfalls or
| differences in PHP versions to watch out for, and there's a
| whole list of comments contributed by other PHP devs
| spanning years, that are up/downvoted.
|
| Another example of powerful documentation was that I learnt
| what MPTT is, and how to implement it effectively, purely
| from CakePHP docs back in the day (I'm talking v2 here). I
| can't see how anything as remotely useful would be able to
| be taught from Laravel docs alone; for someone who doesn't
| have a computer science degree, there would be a LOT of
| tabs open, full of rabbit holes that need to be explored.
| This is not effective documentation in my eyes.
|
| The difference between these sets of documentation is like
| night and day to me. The Laravel docs needs to stop patting
| itself on the back, and be more like other software
| projects' documentation.
|
| Don't get me wrong, I love working with Laravel, it _is_
| powerful. My issue is with the documentation, which leaves
| a lot to be desired.
| abujazar wrote:
| The 5.8 docs are like from like 7 or 8 years ago. I'd say
| the 10.x docs have improved a lot, but I do share some of
| your opinions on the docs in general. Anyone can
| contribute to them, though.
| https://laravel.com/docs/10.x/contracts
| ofrzeta wrote:
| The project is in a constant state of flux. So for
| example the Contracts you cited are in version 5.8 but
| they are no longer in the current versions.
|
| EDIT: I just noticed that Contracts are still in the
| current version just got moved in the docs, so I your
| point still stands.
| acherion wrote:
| Right, but this is a discussion about their
| documentation, not whether Feature X in a version of
| Laravel is still around in the latest version. I'm not
| attacking the framework, as I said I love using Laravel.
| I just have criticism about their documentation.
| shp0ngle wrote:
| PHP has types now??
| ceejayoz wrote:
| Yes. Since 2015.
| leke wrote:
| For those who are not familiar with the PHP ecosystem, any
| currently maintained framework is also fine. I myself use F3
| for small personal projects.
|
| Totally agree about the single thread thinking is enough for
| most things. It of course depends on what you build. For
| example, I would use some language that runs on Beam for a chat
| platform.
| willio58 wrote:
| I hold a center position on this. I think PHP is great for a
| lot of things (especially these days). I even agree about
| Swift. Love that lang.
|
| But for web, I personally prefer Typescript frontend and
| backend combos. It's amazing to be able to write everything in
| one language. I largely tune out the arguments and new flashy
| frameworks, but I get why people call the JS ecosystem a
| hellhole. There are a lot of options out there. That being
| said, when your team is competent and balances functionality
| with new shiny stuff, it can be a real treat to have access to
| npm for frontend and backend.
| Alifatisk wrote:
| > It's the BMX of the languages.
|
| How should I interpret this? The language is cool? Can perform
| cool tricks?
| deltarholamda wrote:
| If you want to ride a bike, you can ride the bike. If you
| want to do tricks, you can do tricks.
|
| PHP makes simple stuff easy and difficult stuff possible.
| (But you're not going to win the Tour de France on a BMX
| bike.)
|
| Nowadays, a lot of other things also do this, but PHP was the
| first to really "get" this. I understand it's not for
| everybody, and for certain things, other languages are
| certainly better. But there's precious little that you _can
| 't_ do with PHP, since it's been around for so long and has
| been growing with the Web from pretty much the very
| beginning.
| mxuribe wrote:
| And...the language can be taken to a high school prom - like
| any BMX bike can be:
| https://www.youtube.com/watch?v=VPVJzi7Ta9w
|
| Sorry, could not resist! lol :-D
| yazan94 wrote:
| I know NodeJS well but have never used PHP, but I can attest
| that using PM2 is a pain and node_modules deps issues can be a
| hair-pulling event. But the package.json scripts provide a
| simple and built-in way to run basic build tasks. There's
| always an ~~app~~package for that, no matter what "that" is.
| There are also tons of tutorials, examples, and snippets for
| everything you want to do to get up and running quickly. TBH I
| really enjoy working with Typescript, it really brings sanity
| to JS (as long as you are consistent with it) and Express is
| dead simple and just makes sense.
|
| Would you mind sharing your insights into why one should go
| with modern PHP+Laravel instead of NodeJS+Express+Typescript?
| what does the PHP equivalent of pm2 load-balancing look like
| and how does it compare?
| topicseed wrote:
| The NPM/JS/TS hellhole is real. Moved on from it a couple of
| years ago, and today I switch between Go and PHP (WP custom
| stuff).
|
| Obviously Go and PHP are two very different languages but they
| bring me peace in ways JS never did. Especially when reopening
| older projects.
| mattgreenrocks wrote:
| It's goofy to me how many devs think the art of writing
| software necessitates continually updating dependencies to
| have things not break. You're running in place! You could be
| working on something new that generates value, or adding
| features to what you have in that time.
| topicseed wrote:
| To me, dependency management is a part of software
| maintenance and it's not always just 'running in place'.
| Updates bring security patches (sometimes not publicly
| explained or disclosed), performance improvements, and new
| features that could enhance the value generated by the said
| software.
| taskforcegemini wrote:
| you only point out positives, but the negatives are
| usually felt a lot more intensively
| no_wizard wrote:
| Symfony is better for scaling apps, I have found. I know
| Laravel is built on top of Symfony, but Symfony _scales_ out of
| the box much better, Laravel is still the framework of bespoke
| one off projects in my experience (used it for years). It does
| not excel at maintainability of large apps.
|
| API Platform is really good for scaling CRUD endpoints too (its
| a Symfony project, or at least tightly Symfony adjacent)
|
| Of course, this is my experience (albeit over many years)
| however I wanted to just throw out a worthy alternative people
| really should look at.
| jjice wrote:
| I agree that PHP is a fine language these days, if using modern
| features and techniques. I've seen plenty of recently written
| PHP that looks like it was written in 1997.
|
| That said, PHP does have complexity to running like node does
| with pm2, Apache or Nginx in front. Is it as bad, depends on
| the person, but it does suck IMO.
| npsomaratna wrote:
| I've used maybe a couple of dozen programming languages over
| the years (yes, I'm that old). I see programming languages as
| tools--you want to pick the right tool for the right purpose.
| Whether a tool is right depends not just on the language
| itself, but also the ecosystem of libraries.
|
| Thanks to Laravel (along with Livewire and Alpine.js), and an
| ecosystem of libraries enabled by Composer, PHP is a great
| choice for web development. I'd not use it for, say, coding
| machine learning stuff though!
| pkphilip wrote:
| Absolutely. The developer experience with PHP is so far ahead
| of the Javascript "ecosystem" that it is ridiculous!
| [deleted]
| Thorentis wrote:
| All those arguments would apply to Python and Django in my
| opinion.
| makeitdouble wrote:
| > it's typed (now)
|
| To note, you'll need strict mode for type hints to be useful.
| https://www.php.net/manual/en/language.types.declarations.ph...
|
| The fun part is, instead of going for a generic strict mode
| system we would have expected, PHP went pragmatic: as most
| application won't be 100% strict typed, you need to declare it
| file by file, the icing on the cake being that the restriction
| applies on the caller of the functions, not the function
| itself.
|
| It makes for complicated situations, where for instance you can
| make an utility class that is 100% typed and follows strict
| typing, but if the caller of your class isn't, none of it will
| matter and types will be fuzzily coerced anyway.
| muglug wrote:
| > To note, you'll need strict mode for type hints to be
| useful
|
| This is not really true -- those type hints can be read by
| static analysis tools, preventing you from many of the issues
| that would also be caught in strict mode at runtime.
| dgb23 wrote:
| The type system isn't expressive enough for these tools to
| catch anything but the most basic errors.
|
| In PHP, typing is for function signature documentation.
| jwdunne wrote:
| You're right. Psalm has been a god send on the project I'm
| working on.
|
| Unfortunately, it's taking far too long for Laravel to
| catch up so parts of its API are a black hole for types.
|
| Especially things like request input, which returns a union
| of string and array as opposed to using a conditional
| return type.
|
| You end up with assertion soup every time you touch Laravel
| so over time the project uses less and less of it.
|
| A well-typed framework and set of libraries would be very
| nice.
| muglug wrote:
| > Psalm has been a god send on the project I'm working
| on.
|
| Thanks!
| kaba0 wrote:
| Agree, though I would put Java in the same category as well
| (and actually prefer that). Great ecosystem, great frameworks
| for every conceivable business case, excellent performance,
| tooling.
| unsupp0rted wrote:
| The main reason I don't use PHP is because the browser doesn't.
|
| Sooner or later I end up having to write Javascript and lots*
| of it. Therefore I use it across the board.
|
| *where "lots" = logic that needs to exist on both client and
| server side
| thomasfromcdnjs wrote:
| I've been using Laravel for the past year at work, not a hater
| type but still find it meh even with all the improvements.
| JodieBenitez wrote:
| Why do most PHP related posts on HN read like repentance ? If you
| want to promote the language -to the point of buying a domain and
| making a webpage-, please show interesting stuff, not something
| that is equally trivial to solve in gazillions of web frameworks
| written in gazillions of languages.
| rafark wrote:
| I don't get that feeling. And I like that people are doing
| their best to try to improve the reputation of the language.
| The reality is that modern php is very decent, but a lot of
| people that have never used it or have used a very old version
| mock or look down upon it for no apparent reason.
|
| It's important to try to improve the reputation so that it gets
| new developers interested in it in order for the language to
| keep being relevant.
|
| If you want a concrete reason why I think php is great and has
| many things that are very useful compared to its competition:
|
| Extensive native support for classes and types.
|
| Php does class-based OO better than its competition
| (JavaScript, python).
|
| Designing a traditional object oriented system using classes
| and interfaces is better in PHP than in JavaScript and python,
| if we limit ourselves to the native features of the language.
|
| For example, you cannot define a native interface or an
| abstract class in python or JavaScript. JavaScript classes,
| since they're just syntactic sugar, have _a lot_ of unexpected
| behavior.
|
| In python you have to accept the this/self object in every
| method definition.
|
| Here are a couple of links about php classes, interfaces and
| types for anyone interested:
|
| https://www.php.net/manual/en/language.oop5.variance.php
|
| https://www.php.net/manual/en/language.oop5.interfaces.php
| jensneuse wrote:
| From the title, I thought someone implemented PHP in go.
| _facepalm_
| hankchinaski wrote:
| Laravel is probably the top reason why I moved away from PHP to
| Go. I find it frustrating to have to learn custom DSL and custom
| syntax to do basic stuff. Which then of course if you learn is
| going to be useful until the next major version of the framework,
| at which point you will have to re-learn everything over again. I
| like how I can just know the Go standard library go into dozens
| of different projects and still being able to contribute because
| there are no custom frameworks and DSLs.
| kmod wrote:
| I always dislike the "requests per month" metric because it seems
| like a transparent attempt to impress with a larger absolute
| number: 500k requests/month is 5sec per request, which feels
| pretty underwhelming
| asimjalis wrote:
| There is also Phel (Lisp-like language that compiles to PHP).
|
| https://phel-lang.org/
___________________________________________________________________
(page generated 2023-05-11 23:03 UTC)