Hacker News Reader

Comment by stunt | Hacker News Reader

Most of the comments against PHP are from developers that wrote PHP<5.4 long time ago as their first or second language. PHP had a bad ecosystem with lots of bad practices being a norm.

There are still some issues but considering the current state of language, frameworks, libraries, and the ecosystem, it's very practical and productive environment to build any project.

I've been doing Typescript, Scala, and recently also Go in last few years. Scala and Go have decent language design and I'm a fan of both of them. But, when it comes to productivity and ecosystem they don't come anywhere close to PHP. If I was about to build my own web startup, I'd definitely build it with PHP because I'm sure I could launch it 10 times faster with Laravel.

View on HN

I think there is a huge difference between web sites and web applications. Most large applications today uses SPA and an api. The api can be done in any backend language and there is not many obvious benfits of using php but some clear drawbacks.

If you just want to create a web site quickly then php works fine but on the other hand you can do it quickly with js, c# or Typescript also.

> Most large applications today uses SPA and an api.

[citation needed]

> Most large applications today uses SPA and an api.

I’ve been thinking a lot about this over the last year+. Is this true? Because the deployment model is 1000x more straightforward for CRA vs NextJS (nuxtjs, etc.).

CRA?

Create React App: https://create-react-app.dev/

If you used laravel you get things like queuing (tooling around). You can go async. There are some advantages.

PHP 4 was the last time I wrote any PHP; I hated it. You are right, though. PHP now is not the PHP I knew.

One of the great things about PHP is the development has always taken backward compatibility into mind.. so while true it's not the PHP you know, it still pretty much knows the PHP you knew.

> If I was about to build my own web startup, I'd definitely build it with PHP because I'm sure I could launch it 10 times faster with Laravel.

Fair enough, and same applies to Ruby on Rails.

Let's not conflate "easy and quick to launch an MVP" with "sustainable for long-term development" however. There are many stories on the net how people started with something as basic as WordPress or Rails but had to rewrite in Phoenix or one of Python's frameworks down the line because the maintenance burden of the MVP-grade technology was too heavy.

True, but I still haven't heard of anyone having to rewrite Symfony or Laravel project because of the frameworks themselves, usually it's poor design choices that could have happened in Django or RoR or Express as well (and that happens all the time, I've seen a lot of node projects that sucked because of lack of planning and we had to practically rewrite them from a scratch). No framework can save you from being careless (nor it should IMHO). In the end, unless you're building something really super popular it really doesn't matter which framework one chooses as long you learn how to properly use it and you don;t suck at programming... it's just vim vs. emacs type of problem, it's simply a personal preference, both are great, just use what you enjoy the most...

> it's just vim vs. emacs type of problem, it's simply a personal preference, both are great, just use what you enjoy the most...

To a large degree, but not completely.

Some frameworks (actually the runtimes of the languages) allow for much easier and quicker scaling and/or deployment compared to others. But businesses usually prefer to burn money for that as opposed to making an informed choice early on.

And also majority of businesses will never need more scaling up than perhaps upgrading to a slightly more expensive VPS or adding 2 more GBs of RAM.

It's amusing to me to see all the hate for PHP, especially when the original lazy gripe was that people hated when faced with code that was mixed with templates. So completely different than the dominant modern front-end frameworks.

At least one of those front-end frameworks doesn't "mix code with templates", it represents HTML as code.

(It's for that reason that JSX is the first way-to-splat-HTML-out that hasn't made my skin crawl in...pretty much ever.)

JSX just reverses the story, it's js with islands of html tags thrown in it instead of being html with code in it... in the end when you look at an average presentation component it's still like 90% html tags and some js mixed all together...

JSX is not, and I mean this emphatically not, "HTML tags". They're a tree of objects. That they sometimes represent HTML is orthogonal to why it's fantastic.

To elide all of the power and powerformance that JSX provides in the situations where it's appropriate as just "HTML tags" fundamentally misunderstands what they are and why they are powerful.

Data structures are more than text. This is a good thing.

JSX is data after compilation which means it's not as transparent or accessible programmatically in the same way hiccup is

That said I'm not sure it'd be as easy to do hiccup in pure JS because names aren't a first class data type there

GP could've easily been talking about the many other libraries/frameworks that DO use templating, though: Template Syntax in Angular/Vue, Glimmer in Ember, etc.

It's even more amusing how gross a generalisation you are making. I for one dislike PHP for all its little nasty surprises like implicit type conversion. Even 15 years ago I had zero problems with code and templates mixed in a file.

Reply on news.ycombinator.com