Earlier quoted context omitted.
I wouldn't recommend PHP to anyone who isn't already invested/emerged in the language. Wordpress for blogs or websites on a shared host with automatic updates and a few select plugins? Yes. Laravel or Symphony for applications? Ok. But just PHP has way too many footguns and doesn't provide nearly enough affordances to make them worth it IMO. Plus it's a language that breaks backwards compatibility way too often, stop…
Gotta disagree with you here. Modern PHP is quite great, especially when paired with Laravel or Symphony. They had to introduce breaking changes to move the language forward, but I don't recall anything huge after 7.0 or so. There's a huge ecosystem of packages to do just about anything web-related, and the documentation and community resources are way better than anything I've seen with say, Java/Spring. Laravel is…
Four ways to build web apps
81–90 of 181 posts
Re: Four ways to build web apps
#82Earlier quoted context omitted.
I wouldn't recommend PHP to anyone who isn't already invested/emerged in the language. Wordpress for blogs or websites on a shared host with automatic updates and a few select plugins? Yes. Laravel or Symphony for applications? Ok. But just PHP has way too many footguns and doesn't provide nearly enough affordances to make them worth it IMO. Plus it's a language that breaks backwards compatibility way too often, stop…
I'm sorry but this is a really ill informed comment, and nothing said here is actually true. You're going to need to spend some substantial time to back up what you've said.
Re: Four ways to build web apps
#83Learning dozens specific cloud services and shelling out money everywhere I go is way less appealing to me than buying a cheap dedicated server and firing up exactly what I need. It'll take me far longer to figure out what FarGate and Cloudflare Pages and all these are and infinitely longer to keep up with the latest and greatest because it keeps changing constantly. And even once I get it, I'll have very limited con…
I use it for a few reasons. I like that it’s free and the hosting of the static content is at the edge. They also take care of some things automatically, like compressing the assets once at build time and serving them with the right headers.
I don’t think this is unique. I believe netlify and others have similar offerings. These providers are excellent for the use case of serving static content at low latency and low cost.
Re: Four ways to build web apps
#84Learning dozens specific cloud services and shelling out money everywhere I go is way less appealing to me than buying a cheap dedicated server and firing up exactly what I need. It'll take me far longer to figure out what FarGate and Cloudflare Pages and all these are and infinitely longer to keep up with the latest and greatest because it keeps changing constantly. And even once I get it, I'll have very limited con…
Re: Four ways to build web apps
#85Learning dozens specific cloud services and shelling out money everywhere I go is way less appealing to me than buying a cheap dedicated server and firing up exactly what I need. It'll take me far longer to figure out what FarGate and Cloudflare Pages and all these are and infinitely longer to keep up with the latest and greatest because it keeps changing constantly. And even once I get it, I'll have very limited con…
2) These technologies are stable and usually not that complicated. You are missing out on a lot of productivity by not looking into them.
Understanding the "real underlying technologies" is a myth. The "underlying technologies" are constantly changing, unless you are using an extremely outdated stack: https://www.youtube.com/live/hWjT_OOBdOc?feature=share.
Re: Four ways to build web apps
#86Learning dozens specific cloud services and shelling out money everywhere I go is way less appealing to me than buying a cheap dedicated server and firing up exactly what I need. It'll take me far longer to figure out what FarGate and Cloudflare Pages and all these are and infinitely longer to keep up with the latest and greatest because it keeps changing constantly. And even once I get it, I'll have very limited con…
1) Almost all of these services have generous free tiers. Even if you're running a relatively high traffic site your bill will be practically $0. 2) These technologies are stable and usually not that complicated. You are missing out on a lot of productivity by not looking into them. Understanding the "real underlying technologies" is a myth. The "underlying technologies" are constantly changing, unless you are using…
So will also constantly change their behaviour in the edge cases. Thank you for giving me another reason for not using that crap. I'll stick with my extremely outdated stack.
Re: Four ways to build web apps
#87Earlier quoted context omitted.
> Plus it's a language that breaks backwards compatibility way too often Do you have examples of such compatibility breakages? I noticed Nextcloud and WordPress both seem to lag behind the last version of PHP a bit. But on the other hand I also see such thing in the Java World where people are stuck on Java 8 or 11, when backward compatibility is one of the strength of the language. I also have PHP scripts I wrote fo…
> Do you have examples of such compatibility breakages? The wordpress integration test suite broke with PHP 8.0. They seem to be lagging behind for 8.1 and 8.2 as well. Remember new keywords were introduced and code just breaks in weird ways since these versions if you have conflicting names or depend on any library that has conflicting names. There was a somewhat recent article that talked about changes for a string…
Wordpress was since it creation a bad coded software and as a result they have issues with keeping up with the php release cycle.
> In the near future you won't be able to assign new properties on instantiated objects anymore.
Wrong, the stdClass that json_decode uses still works and will work, if you need dynamic properties without define it in your class add the attribute for this class #[AllowDynamicProperties] .
> There was a somewhat recent article that talked about changes for a string template literals cleanup for the next major version that will break a whole bunch of code as well.
Next major version comes in several years until then you get deprecate warnings, if you can't fix problems that will occur in 2-3 years you should think about your software development skills.
> But what about many projects? What about transitive dependencies?
If you have many projects but no manpower to maintain it thats a bigger problem for the projects itself, e.g. security. And you can use phpunit combined with rector for many projects.
> PHP is moving fast and makes no excuses. It's simply not a language that prioritizes stability.
PHP is stable if you write good code and on the same level as nodejs or python.
> There are so many little gotchas and weird behaviors. Thats the reason for the upcoming breaking things, if php would stick at php 5 it would be dead.
Re: Four ways to build web apps
#88Earlier quoted context omitted.
1) Almost all of these services have generous free tiers. Even if you're running a relatively high traffic site your bill will be practically $0. 2) These technologies are stable and usually not that complicated. You are missing out on a lot of productivity by not looking into them. Understanding the "real underlying technologies" is a myth. The "underlying technologies" are constantly changing, unless you are using…
> The "underlying technologies" are constantly changing, unless you are using an extremely outdated stack So will also constantly change their behaviour in the edge cases. Thank you for giving me another reason for not using that crap. I'll stick with my extremely outdated stack.
Cloud and serverless platforms are similarly modern tech, except for deployment and hosting. Do you really think that e.g. AWS and Cloudflare "constantly change their behaviour in the edge cases"?
Re: Four ways to build web apps
#89Re: Four ways to build web apps
#90This approach works pretty well when you have a pre-existing API and need to, say, minimize # of round trips to fetch data without wanting to couple your frontend(s)backend too tightly.