Learn PHP the Right Way(github.com)
github.com
Learn PHP the Right Way
https://github.com/ggelashvili/learnphptherightway-outline
72 comments
Passively watching YouTube is probably not the right way to learn any progamming language.
Anecdotal at best, but that is essentially the way I learned English, and definitely the reason I think I don't have a distracting accent when talking in English.
PHP in 2024 is really nice. It's come a long way but is still very rock steady.
I like PHP, and guess what? I also like PowerShell for web apps. I don't really care what anybody says—I can build fast in PowerShell. My clients are happy, it's simple to debug, and I can tap into .NET classes when necessary. PowerShell + HTML + Alpine = productivity. I'm not building the next Netflix or Amazon and the end-user isn't going to notice or care that I haven't selected Node and React.
I just can't get behind the complexity of build steps and compiling, all just to get a website online. It's crazy. The simplicity that PowerShell (and PHP) bring to this process can't be overlooked... so I like to beat on this drum whenever I get the chance.
Choose the tool that is right for the job, and PHP can be that tool in a surprising number of cases.
I just can't get behind the complexity of build steps and compiling, all just to get a website online. It's crazy. The simplicity that PowerShell (and PHP) bring to this process can't be overlooked... so I like to beat on this drum whenever I get the chance.
Choose the tool that is right for the job, and PHP can be that tool in a surprising number of cases.
I really learned to appreciate what Powershell is after listening to @adamgordonbell CoRecursive episode with Jeffrey Snover (https://corecursive.com/building-powershell-with-jeffrey-sno...).
I really loved PHP, but now with go+templ (https://templ.guide) I personally don't have a use-case for PHP anymore, but that doesn't mean it's irrelevant for the world.
I really loved PHP, but now with go+templ (https://templ.guide) I personally don't have a use-case for PHP anymore, but that doesn't mean it's irrelevant for the world.
> I really loved PHP, but now with go+templ (https://templ.guide) I personally don't have a use-case for PHP anymore, but that doesn't mean it's irrelevant for the world.
This is the first time I've heard of Templ. It looks cool and it was really easy to set up. Apparently there are IDE extensions to enable syntax highlighting and HTML auto-completion, but is there a way to type check the templates? One of the things I love about JSX as a templating language is that errors in your markup get reported as type errors [1]. If I write `<a herf="/foo">` instead of `<a href="/foo">` and run `tsc --noEmit --watch`, TypeScript will complain until I fix the issue. You can even extend the types to support your own HTML custom elements. JSX is a first class citizen in TS (and by extension any editor or IDE with support for TS).
[1] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...
This is the first time I've heard of Templ. It looks cool and it was really easy to set up. Apparently there are IDE extensions to enable syntax highlighting and HTML auto-completion, but is there a way to type check the templates? One of the things I love about JSX as a templating language is that errors in your markup get reported as type errors [1]. If I write `<a herf="/foo">` instead of `<a href="/foo">` and run `tsc --noEmit --watch`, TypeScript will complain until I fix the issue. You can even extend the types to support your own HTML custom elements. JSX is a first class citizen in TS (and by extension any editor or IDE with support for TS).
[1] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...
It's disappointing that PHP still gets hate in 2024. PHP of 2024 isn't the PHP of 2004. As someone with a bunch of experience in Java, C, C++, Python, PHP, Hack, Javascript and a handful of others, PHP is (IMHO) almost a perfect language for serving HTTP requests because of these characteristics:
1. Essentially an HTML document is a valid PHP program. This is an excellent starting point for beginners;
2. PHP has a stateless API that means there's basically zero start up cost, unlike, say, loading libraries like you do in Java or even Python;
3. There's no threading within the context of a request. This is what you want 99.99% of the time. Hack extended this with cooperative async/await;
4. Because of (3) everything you allocate/use within a request context just gets thrown away. There's no persistent state (eg like Java's servlet model). Again, this is almost ideal;
5. Because of all the above, PHP hosting is incredibly cheap and accessible.
The two things I'd probably add to PHP come from Hack: a modern type system with nullable support and the collections (vec, map, set).
1. Essentially an HTML document is a valid PHP program. This is an excellent starting point for beginners;
2. PHP has a stateless API that means there's basically zero start up cost, unlike, say, loading libraries like you do in Java or even Python;
3. There's no threading within the context of a request. This is what you want 99.99% of the time. Hack extended this with cooperative async/await;
4. Because of (3) everything you allocate/use within a request context just gets thrown away. There's no persistent state (eg like Java's servlet model). Again, this is almost ideal;
5. Because of all the above, PHP hosting is incredibly cheap and accessible.
The two things I'd probably add to PHP come from Hack: a modern type system with nullable support and the collections (vec, map, set).
IMHO most of hate is just because it is fashionable to hate some languages including PHP and Perl. But there is some criticism which looks valid to me e. g. [1]
Regarding embedded into HTML PHP code - it's a easy for beginners but in a large application it leads to hard to maintain mix of app logic and presentation - AFAIK this feature is rarely used outside toy project for many years.
[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ (very old and some issues may be were addressed but it's hard to fix all of this without creating an incompatible language)
Regarding embedded into HTML PHP code - it's a easy for beginners but in a large application it leads to hard to maintain mix of app logic and presentation - AFAIK this feature is rarely used outside toy project for many years.
[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ (very old and some issues may be were addressed but it's hard to fix all of this without creating an incompatible language)
Embedding PHP in HTML is often treated as a kind of dirty legacy we don’t talk about, even though is actually an amazing prototyping feature. As long as you use it like you would use Jupyter notebooks, you’re golden.
Honestly speaking, the main thing that always made me dislike PHP was lots of things related to the syntax. Call it petty, but it's the truth.
I've always felt that PHP could greatly benefit from a Kotlin-esque interop language with a more modern syntax and QoL upgrades, but I'm not sure if the juice is really worth the squeeze.
I've always felt that PHP could greatly benefit from a Kotlin-esque interop language with a more modern syntax and QoL upgrades, but I'm not sure if the juice is really worth the squeeze.
...why take a title that's already quite famous in the industry?
https://phptherightway.com/
https://phptherightway.com/
Take me back to the LAMP stack days, good times
lbj(2)
The only reason to learn PHP in 2024 is if you are specifically targeting PHP jobs. Learning PHP is like learning Perl: suboptimal.
Edit: Jesu X. Chris, I didn’t mean to start a language war. Learn PHP if you want, I won’t stop you lol
Edit: Jesu X. Chris, I didn’t mean to start a language war. Learn PHP if you want, I won’t stop you lol
Both have their uses.
I am not saying they don’t. I am just saying there are (except in a few rare cases) better uses of your time.
After learning HTML, CSS and Javascript, PHP is a good next choice on the path to self-learning web development in 2024. The whole idea is to achieve "world is your oyster" with the minimal number of steps. Don't agree? That's fine. Web development isn't meant to be dictated to others.
Please give me some examples!
Learn a functional language like Elixir. That’ll prove both useful and mind expanding!
Using Perl for sysadmin work and living life in Regex for a while has its perks too. ;)
How can I use Elixir for the web, microcontrollers or making games?
How can Elixir make the development of those things easier/better?
How can Elixir make the development of those things easier/better?
Elixir looks great. It reminds me of the functional and pseudofunctional programming languages I used at uni and their environments like Poplog.
I agree it's mind-expanding.
But I don't think most web development work is mind-expanding or a realistic application for it.
I also don't think using it to criticise PHP is really the right target. If you want to use a functional programming language/environment as a critique of modern web development... maybe start by targeting server-side JS.
I agree it's mind-expanding.
But I don't think most web development work is mind-expanding or a realistic application for it.
I also don't think using it to criticise PHP is really the right target. If you want to use a functional programming language/environment as a critique of modern web development... maybe start by targeting server-side JS.
> if you are specifically targeting PHP jobs
Lot of those around[0].
[0] https://w3techs.com/technologies/history_overview/programmin...
Lot of those around[0].
[0] https://w3techs.com/technologies/history_overview/programmin...
There's certainly a ton of use cases where php is a few minute job and anything else is 10x more or even longer just like is true with shell scripts and perl
Snobbery is like saying you're intellectually superior to using a specific screwdriver or kitchen knife.
Snobbery is like saying you're intellectually superior to using a specific screwdriver or kitchen knife.
Or they're simply committed to using the wrong tools for the job out of some misguided ideology someone else handed them when they were too new to know better.
PHP is so much nicer to use on a webserver vs Python or JS. It’s almost like PHP was built for the web and fits it like a tailored suit!
Would I use PHP to make games? No! I wouldn’t use JS or Python for that either.
I try to use the best language for the job without letting any cargo cult biases get in the way.
Front end stuff? JS!
Backend stuff? PHP!
AI stuff? Python!
Games and microcontrollers? C/C++!
Would I use PHP to make games? No! I wouldn’t use JS or Python for that either.
I try to use the best language for the job without letting any cargo cult biases get in the way.
Front end stuff? JS!
Backend stuff? PHP!
AI stuff? Python!
Games and microcontrollers? C/C++!
Is it really that good for backend?
1. You will still need to learn JS, and now it may even be embedded in PHP depending on the type of app you are working with!
2. It still has horrible conventions, arrays being sorted maps has to be one of the worst design decisions, IMO its worse than having null and undefined as types. Mutlibyte strings are still an afterthought in the core of PHP. Inconsistent function naming. It's new typing system is plain worse than TS in every way. Async programming is still terrible. Needle Haystack swapparoos throughout the language.
3. It was built for the web as it stood 20 years ago, HTML embedded in code, single server sessions, cgi servers, and minimal latency server to server communication. It cannot feel more out of place today.
I will give it: Laravel is a robust framework that helps hide some of this, but its hard to hide most of it.
1. You will still need to learn JS, and now it may even be embedded in PHP depending on the type of app you are working with!
2. It still has horrible conventions, arrays being sorted maps has to be one of the worst design decisions, IMO its worse than having null and undefined as types. Mutlibyte strings are still an afterthought in the core of PHP. Inconsistent function naming. It's new typing system is plain worse than TS in every way. Async programming is still terrible. Needle Haystack swapparoos throughout the language.
3. It was built for the web as it stood 20 years ago, HTML embedded in code, single server sessions, cgi servers, and minimal latency server to server communication. It cannot feel more out of place today.
I will give it: Laravel is a robust framework that helps hide some of this, but its hard to hide most of it.
1. I am already very good with JavaScript, I like having the language separation between frontend and backend.
2. I much prefer using PHP arrays than JS arrays. All the other stuff you mentioned have never been a issue for me in the past 10 years. I don’t care about types (I don’t even remember when I had a real type bug).
3. The modern web is an over engineered mess, all the modern js frameworks have made the user experience objectively worse. Oh wow your shitty website that has some text and a few pictures is taking 900mbs of ram and 70% of my cpu? Wow very modern! What progress we have made!
2. I much prefer using PHP arrays than JS arrays. All the other stuff you mentioned have never been a issue for me in the past 10 years. I don’t care about types (I don’t even remember when I had a real type bug).
3. The modern web is an over engineered mess, all the modern js frameworks have made the user experience objectively worse. Oh wow your shitty website that has some text and a few pictures is taking 900mbs of ram and 70% of my cpu? Wow very modern! What progress we have made!
1) Okay, but in terms of getting shit done how is it helpful to people to learn two languages?
2) They aren't even arrays? How can you say that lol. If you haven't tripped over what I have listed I just cannot imagine how you have been using PHP. I ran into a multibyte encoding issue with Mongodb and Laravel last week for example. Just a few weeks ago the lovely json_encode a map was sometimes an array vs an object. Granted these are older laravel apps... I don't think a framework can fix these issues.
3) Great straw man! I am sure all PHP apps are beautiful things and their interactivity experience with the end user are perfect :)
Also speaking of over engineered, how is having to run a standalone web server along with PHP, and then having to have an entire JS stack as well not over engineered?
2) They aren't even arrays? How can you say that lol. If you haven't tripped over what I have listed I just cannot imagine how you have been using PHP. I ran into a multibyte encoding issue with Mongodb and Laravel last week for example. Just a few weeks ago the lovely json_encode a map was sometimes an array vs an object. Granted these are older laravel apps... I don't think a framework can fix these issues.
3) Great straw man! I am sure all PHP apps are beautiful things and their interactivity experience with the end user are perfect :)
Also speaking of over engineered, how is having to run a standalone web server along with PHP, and then having to have an entire JS stack as well not over engineered?
> 1) Okay, but in terms of getting shit done (one of your points) how is it helpful to people to learn two languages?
It's actually pretty clarifying. Two different perspectives on one single problem domain is almost always good for your brain. Like being bilingual.
Also I would dispute that there are not, fundamentally, two different environments in the browser and Node backend even now. One of those environments is a GUI which is naturally a good application for async. The other is not. Backend web development is still largely input -> process -> output. Node is just shoehorning JS in, and pretending that JavaScript's weaknesses are strengths.
> Also speaking of over engineered, how is having to run a standalone web server along with PHP, and then having to have an entire JS stack as well not over engineered?
Not sure what you mean. There are a bunch of ways to run PHP -- one is with a process manager (php-fpm, not unlike things like PM2). Another is to run Apache as a backend to something like Caddy or nginx or some other cacher; this is actually a highly robust way to do things, because Apache can be tuned in so many different ways. And yet another is to use FrankenPHP, which is Caddy with a PHP process manager.
I personally treat JS at the front end (Vue/Nuxt) as a client application development environment, and PHP as a backend development environment, as clean separate things defined by an interface. I don't believe that blurring the boundary between code running in the client and code running in the server has ever been a good idea, nor will it ever be. It just leads to edge cases where the code has to ask, and developer traps where developers don't realise they need to know.
It's actually pretty clarifying. Two different perspectives on one single problem domain is almost always good for your brain. Like being bilingual.
Also I would dispute that there are not, fundamentally, two different environments in the browser and Node backend even now. One of those environments is a GUI which is naturally a good application for async. The other is not. Backend web development is still largely input -> process -> output. Node is just shoehorning JS in, and pretending that JavaScript's weaknesses are strengths.
> Also speaking of over engineered, how is having to run a standalone web server along with PHP, and then having to have an entire JS stack as well not over engineered?
Not sure what you mean. There are a bunch of ways to run PHP -- one is with a process manager (php-fpm, not unlike things like PM2). Another is to run Apache as a backend to something like Caddy or nginx or some other cacher; this is actually a highly robust way to do things, because Apache can be tuned in so many different ways. And yet another is to use FrankenPHP, which is Caddy with a PHP process manager.
I personally treat JS at the front end (Vue/Nuxt) as a client application development environment, and PHP as a backend development environment, as clean separate things defined by an interface. I don't believe that blurring the boundary between code running in the client and code running in the server has ever been a good idea, nor will it ever be. It just leads to edge cases where the code has to ask, and developer traps where developers don't realise they need to know.
> One of those environments is a GUI which is naturally a good application for async. The other is not. Backend web development is still largely input -> process -> output. Node is just shoehorning JS in, and pretending that JavaScript's weaknesses are strengths.
Until you need to perform two or more IO operations at the same time (e.g. more than one of: database query, Redis query, HTTP request, file operation, etc). Then it becomes:
input -> Promise.all (or Promise.race, or Promise.allSettled, or Promise.any) -> output.
If you watch Ryan Dahl's original presentation introducing Node, you'll see that JS was explicitly chosen because of its asynchronous nature — it wasn't shoehorned in: https://youtu.be/EeYvFl7li9E?t=795&si=FG0yxaGoCgz1rqOX
> Not sure what you mean. There are a bunch of ways to run PHP
Node doesn't require an upstream CGI server at all. There's a server built-in to the Node binary: https://nodejs.org/docs/latest-v22.x/api/http.html#class-htt...
Until you need to perform two or more IO operations at the same time (e.g. more than one of: database query, Redis query, HTTP request, file operation, etc). Then it becomes:
input -> Promise.all (or Promise.race, or Promise.allSettled, or Promise.any) -> output.
If you watch Ryan Dahl's original presentation introducing Node, you'll see that JS was explicitly chosen because of its asynchronous nature — it wasn't shoehorned in: https://youtu.be/EeYvFl7li9E?t=795&si=FG0yxaGoCgz1rqOX
> Not sure what you mean. There are a bunch of ways to run PHP
Node doesn't require an upstream CGI server at all. There's a server built-in to the Node binary: https://nodejs.org/docs/latest-v22.x/api/http.html#class-htt...
> Node doesn't require an upstream CGI server at all. There's a server built-in to the Node binary
Though you'll still want a process manager for this to make sure it stays up. Which it won't, over the long term.
PHP also has a built-in webserver, which you shouldn't use.
FrankenPHP is the better way to do this with PHP: you get a full Caddy build, with all that offers, with a built-in PHP engine.
Though you'll still want a process manager for this to make sure it stays up. Which it won't, over the long term.
PHP also has a built-in webserver, which you shouldn't use.
FrankenPHP is the better way to do this with PHP: you get a full Caddy build, with all that offers, with a built-in PHP engine.
The FrankenPHP binary also needs a daemon to manage it, which is why the docs recommend using Docker. So you end up with Docker (or SystemD or whatever you prefer), managing Caddy, which is in turn managing PHP. This is because the server which ships with PHP is documented with a big red warning that says something to the effect of "don't actually use this in production, this is just a dev server" [1]. Node's built-in web server is production ready, so you can safely cut out the reverse proxy middleman. I don't actually have any major qualms about the FrankenPHP stack, I was just trying to intuit what the original commenter meant when they said "standalone server".
[1] https://www.php.net/manual/en/features.commandline.webserver...
[1] https://www.php.net/manual/en/features.commandline.webserver...
FrankenPHP doesn't proxy to the PHP dev server. It is a PHP SAPI process manager itself.
You should be able to run FrankenPHP as the front end server just fine -- Caddy is excellent and it's my production front-end almost everywhere anyway (the Let's Encrypt support alone is worth it).
Though depending on the deployment I sometimes use Apache and mod_php still for the backend; this is still modestly less painful if you want to use WordPress in the same environment.
There is absolutely no way I would put node at the front of any server; I'd reverse proxy to it as a matter of principle, with very locked-down routing. The security situation with node package dependencies is hilariously bad, and some other server should be managing HTTPS.
Personally I consider the NPM ecosystem to be a horrific side-road in web development, and I think by contrast PHP is at least honest about what it is and what it is not. The amount of cargo-culting advice around package management in NPM is frightening.
You should be able to run FrankenPHP as the front end server just fine -- Caddy is excellent and it's my production front-end almost everywhere anyway (the Let's Encrypt support alone is worth it).
Though depending on the deployment I sometimes use Apache and mod_php still for the backend; this is still modestly less painful if you want to use WordPress in the same environment.
There is absolutely no way I would put node at the front of any server; I'd reverse proxy to it as a matter of principle, with very locked-down routing. The security situation with node package dependencies is hilariously bad, and some other server should be managing HTTPS.
Personally I consider the NPM ecosystem to be a horrific side-road in web development, and I think by contrast PHP is at least honest about what it is and what it is not. The amount of cargo-culting advice around package management in NPM is frightening.
> FrankenPHP doesn't proxy to the PHP dev server.
I didn't say FrankenPHP proxies to the PHP dev server. I'm saying FrankenPHP is a Frankenstein amalgamation of the Caddy reverse proxy server and PHP, which is necessitated by the lack of a production server built in to PHP. Some languages/runtimes like Go (which Caddy is written in) and Node have production ready servers built in to their standard libraries.
> I'd reverse proxy to it as a matter of principle [...] some other server should be managing HTTPS.
I've used Caddy and it's great, but if I have Cloudflare or some other service terminating SSL and serving static assets, then I don't necessarily need Apache, Nginx, or Caddy acting as a middleman.
> The security situation with node package dependencies is hilariously bad
Most of the security issues involving NPM are related to client side JS, not server side JS. PHP doesn't run client side at all, so it's a bit of an apples to oranges comparison. If you're just doing traditional server side templating then there are plenty of rock solid frameworks. Hapi has zero third party dependencies and was designed by one of the authors of the OAuth spec for example.
I didn't say FrankenPHP proxies to the PHP dev server. I'm saying FrankenPHP is a Frankenstein amalgamation of the Caddy reverse proxy server and PHP, which is necessitated by the lack of a production server built in to PHP. Some languages/runtimes like Go (which Caddy is written in) and Node have production ready servers built in to their standard libraries.
> I'd reverse proxy to it as a matter of principle [...] some other server should be managing HTTPS.
I've used Caddy and it's great, but if I have Cloudflare or some other service terminating SSL and serving static assets, then I don't necessarily need Apache, Nginx, or Caddy acting as a middleman.
> The security situation with node package dependencies is hilariously bad
Most of the security issues involving NPM are related to client side JS, not server side JS. PHP doesn't run client side at all, so it's a bit of an apples to oranges comparison. If you're just doing traditional server side templating then there are plenty of rock solid frameworks. Hapi has zero third party dependencies and was designed by one of the authors of the OAuth spec for example.
1) learning two languages is not hard or a problem. The fundamentals are the same.
2) I have no idea what you are doing but I have never had those issues. I don’t use Laravel or Mongodb though so maybe it’s that? json_encode should give you a string not an array or object?
3) stating a fact is not a strawman and calling it a strawman is not an argument. PHP is as good or as bad as you want it to be. It boils down to the skill of the developer. Bad developers will have a bad time, but that applies to most languages.
I’m not serving an entire JS “stack” either, I write fast, efficient tailored JS without dependencies or frameworks.
Sending html and having JS just for interactivity is surprisingly fast.
2) I have no idea what you are doing but I have never had those issues. I don’t use Laravel or Mongodb though so maybe it’s that? json_encode should give you a string not an array or object?
3) stating a fact is not a strawman and calling it a strawman is not an argument. PHP is as good or as bad as you want it to be. It boils down to the skill of the developer. Bad developers will have a bad time, but that applies to most languages.
I’m not serving an entire JS “stack” either, I write fast, efficient tailored JS without dependencies or frameworks.
Sending html and having JS just for interactivity is surprisingly fast.
> 1. You will still need to learn JS, and now it may even be embedded in PHP depending on the type of app you are working with!
Yes, you will. But to me this is an irrelevance: JS has IMO very little business near the back end. I have absolutely no patience for the JS-everywhere thing.
(It is never necessary to directly embed JS in PHP; there are always choices. Sure, you might sometimes need to briefly template your JS, but that's true of all web environments; it's fundamental to the problem)
> 2. It still has horrible conventions
It does. But for example JavaScript is still riddled with bad conventions. Look at the mess that inconsistent array/object duality, inconsistent property enumeration, has wrought across the language for a whole generation of programmers
> 3. It was built for the web as it stood 20 years ago, HTML embedded in code, single server sessions, cgi servers, and minimal latency server to server communication.
So was JavaScript.
Laravel is, I think, the most sensibly-designed web framework that has ever existed. Every single other framework I have used has disappeared too far into the developers' own biases towards tier after tier of NIH decisions. Laravel doesn't have pretensions.
(I used to love Ruby on Rails but even I remember when the people who were the talk of the developer world with their brand new easy to use developer framework did not know that GETs should be idempotent)
Yes, you will. But to me this is an irrelevance: JS has IMO very little business near the back end. I have absolutely no patience for the JS-everywhere thing.
(It is never necessary to directly embed JS in PHP; there are always choices. Sure, you might sometimes need to briefly template your JS, but that's true of all web environments; it's fundamental to the problem)
> 2. It still has horrible conventions
It does. But for example JavaScript is still riddled with bad conventions. Look at the mess that inconsistent array/object duality, inconsistent property enumeration, has wrought across the language for a whole generation of programmers
> 3. It was built for the web as it stood 20 years ago, HTML embedded in code, single server sessions, cgi servers, and minimal latency server to server communication.
So was JavaScript.
Laravel is, I think, the most sensibly-designed web framework that has ever existed. Every single other framework I have used has disappeared too far into the developers' own biases towards tier after tier of NIH decisions. Laravel doesn't have pretensions.
(I used to love Ruby on Rails but even I remember when the people who were the talk of the developer world with their brand new easy to use developer framework did not know that GETs should be idempotent)
PHP may have been built for the web (backend) as it was 20 years ago, but JS wasn't built for backend at all, so, if I had only the choice between PHP and Node (or one of the many Node alternatives), I would still pick PHP. Pretending that "you only need to learn JS, and hey, with Node you can also be a backend developer" has led to too many flaky backends already.
Exactly right. I would not call myself a PHP "proponent" because at fifty I have too little time in my life left to tell people what they should or should not choose, but I do think it is rich to see this criticism from the JS side. Everything bad about Node is bad because JS is also a "fractal of bad design".
If it wasn't that good for a backend it wouldn't have maintained complete domination of that market for decades, which it has. Incidentally the number of web development projects that have any objective use of async programming or fussy types is a rounding error. Perhaps your interests are pointing in another direction?
I remember someone trying to recruit me for a London-based startup whose developers were obsessed with async and Meteor. They struggled to ship (it was a silly idea anyway) and I don't think they survived their pivot. But the tools choice was a good part of the problem: it wasn't ready and they were imagining it had harnessable pixie dust.
I can see applications for async work within the wider backend all over the place.
But the objective justification for the async stuff being involved in the rendering of page content is thin.
And since the other applications are for sort of "high level systems" programming -- that boundary between the app and the OS -- I personally prefer Go for all of that.
Node is a significant devOps/package management pain that belongs in as few places as possible.
I can see applications for async work within the wider backend all over the place.
But the objective justification for the async stuff being involved in the rendering of page content is thin.
And since the other applications are for sort of "high level systems" programming -- that boundary between the app and the OS -- I personally prefer Go for all of that.
Node is a significant devOps/package management pain that belongs in as few places as possible.
JavaScript is a terrible language and it still dominates front end :)
There are two types of developers that consistently bitch about languages: junior developers with delusions of grandeur and senior development that drank the coolaid and are yoked to a project using the wrong stack.
> arrays being sorted maps has to be one of the worst design decisions.
I'm curious, why is that so bad? It tends to be a useful property of PHP arrays.
Also for webdevelopment, I/O is often the bottleneck. This code creates an array with 1 million items, each being 'a' and then loops over each value, changing them to 'b':
How often do you need to create and change each element of a million item array? A roundtrip TCP/IP call to PostgreSQL is bound to be slower than that for most web servers.
I'm curious, why is that so bad? It tends to be a useful property of PHP arrays.
Also for webdevelopment, I/O is often the bottleneck. This code creates an array with 1 million items, each being 'a' and then loops over each value, changing them to 'b':
$array = array_fill(0, 1000000, 'a');
foreach ($array as $key => $value) {
$array[$key] = 'b';
}
How often do you need to create and change each element of a million item array? A roundtrip TCP/IP call to PostgreSQL is bound to be slower than that for most web servers.
It is also funny to see a JS developer criticise the architecture of PHP arrays specifically.
It does hint that perhaps bearjaws is (lucky for them!) too young to remember the mess that incomplete implementation of array/object duality got the JS world into.
It does hint that perhaps bearjaws is (lucky for them!) too young to remember the mess that incomplete implementation of array/object duality got the JS world into.
Been programming both languages since 2008.
Right. Then you are too young (as a developer at least!) to remember. Except that Object.entries() is there to remind you. And two different for() enumeration syntaxes (for...in and for...of).
JS has an enormous amount of bad-design scar tissue.
I find it interesting that JS developers will forgive it all (global variables, iterables confusion, broken this handling, insane implicit number and int conversions, not to mention simple stuff like semicolon handling) and think PHP developers doing the same for theirs are inferior.
It's a classic example of fundamental attribution error.
JS has an enormous amount of bad-design scar tissue.
I find it interesting that JS developers will forgive it all (global variables, iterables confusion, broken this handling, insane implicit number and int conversions, not to mention simple stuff like semicolon handling) and think PHP developers doing the same for theirs are inferior.
It's a classic example of fundamental attribution error.
> PHP is so much nicer to use on a webserver vs Python or JS.
How?
How?
One thing that I think is under-appreciated from the perspective of "getting shit done" is that the default model of PHP makes it really hard to have memory leaks that eventually crashes your app/server, as your PHP script has a defined "start" and "end" that are all within the request lifecycle.
So even if you leak horribly, thanks to Apache/Nginx/Caddy/whatever only launching your script and then your script stops running, it basically doesn't affect you at all.
Granted, this is more like a bandage, but it works out great for beginners who just want to create their own personal dynamic homepages, something PHP does great :)
Compared to Python or JS where the standard practice is creating a server that runs constantly, and if you leak memory somewhere, your application eventually crashes as you run out of memory.
So even if you leak horribly, thanks to Apache/Nginx/Caddy/whatever only launching your script and then your script stops running, it basically doesn't affect you at all.
Granted, this is more like a bandage, but it works out great for beginners who just want to create their own personal dynamic homepages, something PHP does great :)
Compared to Python or JS where the standard practice is creating a server that runs constantly, and if you leak memory somewhere, your application eventually crashes as you run out of memory.
Basically, PHP was using arenas before arenas were cool :)
A lot of the vanilla inbuilt functions are very web oriented and if you like C, it feels very similar but much easier.
Disagree. Laravel is a great productive framework and there are actually a lot of high paying PHO jobs
PHP is usually the only option for running server-side code on shared/managed hosting. (Either that, or a version of Ruby from 2004. Do you want to use Ruby from 2004?)
I think for probably more than half of all websites out there, something like LAMP is either the optimal, or very close to the optimal solution. It's absolutely bonkers to me what kinds of tech stacks people use to render what essentially amounts to a bunch of forms.
At least half of all websites would probably be better of if their creators realised they needed something closer to a 'blog' than a 'web app'. It's especially true when it comes to the media industry, who seem to love creating the most over engineered SPAs possible for functionality that's barely changed since the 90s.
I'd say swap out MySQL but yeah, a CMS is 99% of what you need.
After spending many years on Objective-C/Swift, I had a couple of opportunities to work with Django (Python), and then Laravel (PHP).
I'd take Laravel with Livewire (and some Alpine.js) over Django any-day. Plus my gut feeling says, that React would be as pleasant as Laravel and co.
I'd take Laravel with Livewire (and some Alpine.js) over Django any-day. Plus my gut feeling says, that React would be as pleasant as Laravel and co.
Not if you're trying to make money and learn Web development. PHP is king.
I'd rather get paid $1,000 to build something that takes < 1 day and $50-150/month to maintain something on a $20 VPS using a tried and true Web technology with tons of developer support and a stable ecosystem.
I can start a new Laravel project and with a starter kit have 50% of the site done. Auth's already done out of the box. The ecosystem is amazing. The tooling is amazing. WordPress is amazing and its ability to extend itself and build almost anything you want is amazing.
I'm moving on to the next client while someone is crying about WordPress' arcane database structure or code and they're still sitting at a text editor with some Haskell code.
All I have to do is worry about my project, not create OCD for 2 weeks on the best way to set something up out of 10 different ways.
I'm not worrying about which flavor of JavaScript framework is in popularity this week - I'm not worrying about how to deploy my Python app and setting up Kubernetes. I'm not worried about compiling my Elixir project to WASM and deploying to Fly.io to support my 1 visitor a month.
I'd rather get paid $1,000 to build something that takes < 1 day and $50-150/month to maintain something on a $20 VPS using a tried and true Web technology with tons of developer support and a stable ecosystem.
I can start a new Laravel project and with a starter kit have 50% of the site done. Auth's already done out of the box. The ecosystem is amazing. The tooling is amazing. WordPress is amazing and its ability to extend itself and build almost anything you want is amazing.
I'm moving on to the next client while someone is crying about WordPress' arcane database structure or code and they're still sitting at a text editor with some Haskell code.
All I have to do is worry about my project, not create OCD for 2 weeks on the best way to set something up out of 10 different ways.
I'm not worrying about which flavor of JavaScript framework is in popularity this week - I'm not worrying about how to deploy my Python app and setting up Kubernetes. I'm not worried about compiling my Elixir project to WASM and deploying to Fly.io to support my 1 visitor a month.
> I didn’t mean to start a language war.
Lot of that going around; especially in venues like this, which has a lot of "Ooh! Shiny!" going on. I tend to be a bit more conservative than many; but not to any kind of extreme degree. I like new stuff, but I also like shipping, which doesn't come from the bleeding edge.
Personally, I use PHP on my backend work, mostly because it's a known quantity, and is an industrial-strength, massively-supported system, that is not going anywhere but up.
And I don't feel like learning a whole new language and API, just for some relatively minor-scale server work (I spend most of my time, writing native Swift frontends).
If it's good enough for PornHub, it's good enough for me.
That said, if PHP were, as is often falsely claimed, going away, I'd probably learn something new. I doubt it would be the tip of The Shiny Spear, but it would be a more modern system; maybe Python. I've never actually liked working with PHP, but the same could be said for most languages I've used. I like Swift.
As it is, I would still want to learn Laravel, before moving away from PHP. From what I understand, it's a fantastic framework, that makes PHP a much more effective server system.
Lot of that going around; especially in venues like this, which has a lot of "Ooh! Shiny!" going on. I tend to be a bit more conservative than many; but not to any kind of extreme degree. I like new stuff, but I also like shipping, which doesn't come from the bleeding edge.
Personally, I use PHP on my backend work, mostly because it's a known quantity, and is an industrial-strength, massively-supported system, that is not going anywhere but up.
And I don't feel like learning a whole new language and API, just for some relatively minor-scale server work (I spend most of my time, writing native Swift frontends).
If it's good enough for PornHub, it's good enough for me.
That said, if PHP were, as is often falsely claimed, going away, I'd probably learn something new. I doubt it would be the tip of The Shiny Spear, but it would be a more modern system; maybe Python. I've never actually liked working with PHP, but the same could be said for most languages I've used. I like Swift.
As it is, I would still want to learn Laravel, before moving away from PHP. From what I understand, it's a fantastic framework, that makes PHP a much more effective server system.
I watched it myself and learned a thing or two despite also working with PHP professionally for years.
Highly recommend to also stop after each video and try to implement a quick example of what it is teaching.