Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go with PHP

gowithphp.com

Post reply on HN
Print view View original

391–400 of 532 posts

Re: Go with PHP

#391

Post by yazan94 »

keyle wrote: post #17

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 f…

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?

Re: Go with PHP

#392

Post by no_wizard »

keyle wrote: post #17

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 f…

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.

Re: Go with PHP

#393

Post by jrsj »

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)

Re: Go with PHP

#394

Post by gspencley »

chrisan wrote: post #359
dgb23 wrote: post #253

Earlier quoted context omitted.

> 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…

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…

> 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.

Re: Go with PHP

#395

Post by konart »

heywhatupboys wrote: post #119
konart wrote: post #63

Earlier quoted context omitted.

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…

> >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…

>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).

Re: Go with PHP

#396

Post by 0xblinq »

nine_k wrote: post #361
dgb23 wrote: post #303

Earlier quoted context omitted.

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 consi…

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 impedim…

"...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.

Re: Go with PHP

#397

Post by openthc »

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?

Re: Go with PHP

#398

Post by qbasic_forever »

0xblinq wrote: post #93
safety1st wrote: post #44

Earlier quoted context omitted.

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 th…

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 st…

Wait you're not using islands architecture!? Hahahaha how quaint! Get a load of this site, it's not using islands!!

Re: Go with PHP

#399

Post by 0xblinq »

dgb23 wrote: post #253
safety1st wrote: post #44

Earlier quoted context omitted.

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 th…

> 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…

> 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.

Re: Go with PHP

#400

Post by a_subsystem »

mschuster91 wrote: post #170
keyle wrote: post #17

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 f…

> 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 poss…

>> 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!

Post reply on HN