[HN Gopher] PHP is the new JavaScript?
___________________________________________________________________
PHP is the new JavaScript?
Author : davekiss
Score : 65 points
Date : 2024-09-06 19:33 UTC (3 hours ago)
(HTM) web link (www.mux.com)
(TXT) w3m dump (www.mux.com)
| dubcanada wrote:
| I find it funny the author choose Symfony as a framework to
| "shudder" about. Considering the base of Laravel is Symfony.
|
| The rest of the article seems to be more about AI code editing
| and MUX video players then PHP.
|
| So I am not really sure what I am supposed to take from this
| post.
| tasuki wrote:
| Back in the day we used Symfony at work. I have a vague feeling
| that some of my coworkers looked down on Laravel. Less
| dependency injection, more weird magic.
| TOGoS wrote:
| Count me as one of those disgusted by weird magic people.
| Unfortunately for us, the majority seem to love it. The more
| coding resembles throwing spaghetti at the wall and seeing
| what sticks, the happier they are. "What do you mean this
| could have been 10 lines and no frameworks; that can't
| possibly be complex enough [for some ETL thingy]."
| kgeist wrote:
| Laravel follows dubious practices: god objects (like a parent
| class which has hundreds of functions), static functions etc.
| The kind of practices our product is actively moving away
| from (originally based on Symfony 1 which had all the
| architectural issues Laravel has now), because it didn't
| scale beyond CRUD (makes it easy to write hard to support
| spaghetti code etc.). So it feels like a step backward...
| Especially when you learn they base it on top of Symfony
| which is already great and nicely designed.
| bakugo wrote:
| > I have a vague feeling that some of my coworkers looked
| down on Laravel. Less dependency injection, more weird magic.
|
| Well, you can rest easy knowing it probably wasn't just a
| vague feeling, because I'm pretty sure every moderately
| experienced programmer who has tried both and went with
| Symfony feels that way.
|
| Laravel was clearly written from the ground up with one goal
| above all else: to make it was easy as possible for beginners
| to write babby's first website as fast as humanly possible.
| Every other essential aspect of such a framework
| (maintainability, modularity, code clarity, ease of debugging
| complex issues, etc) was thrown to the wayside in favor of
| that one main goal, which is why there's so much "magic"
| everywhere. You're expected to just blindly trust the magic
| and never look behind the curtain. Unfortunately, beginner
| programmers that have no intention of ever evolving past
| their beginner phase are a huge audience nowadays, so you end
| up with many people who have never had to write or maintain a
| complex codebase hailing Laravel as the next coming of
| Christ.
|
| This is all heavily reflected in this article: the author
| picks one of the most extremely simple use cases to
| implement, a 99% static page with a single dynamic variable
| that doesn't even seem to use a database. And despite the
| code being extremely simple, he still has to ask AI to write
| 90% of it for him because he isn't interested in learning how
| anything works, he isn't interested in expanding it or
| maintaining it in the future, he just wants to pump out the
| minimum viable product as fast as possible.
| ainiriand wrote:
| Laravel is really not great for some use cases, while with
| Symfony you have the flexibility of doing the things the way
| you want.
|
| For example, in Laravel you have the dependencies sprinkled all
| around the app and with Eloquent you kind of need to use
| active-record.
|
| I am not a big fan of Laravel but I think it is a great tool to
| build websites, not sure about data heavy backends.
| steve_adams_86 wrote:
| Ha, this reminds me of a time I was proposing our team use
| Symfony rather than Laravel for a new project. It was such a
| battle.
|
| Eventually I wrote up a document (I must have spent 20 hours
| on that thing) showing the pros and cons according to our
| needs and what each options offered. The gist of it was that
| Laravel was a nice wrapper over Symfony components at the
| time (though it did offer more as well, too - it just wasn't
| the more we needed), and since we were kind of like power
| users (data heavy backend with tens of thousands of users,
| rapidly growing), we should go direct to the source and use
| the Symfony components without any abstraction.
|
| I mean, we shouldn't have been using PHP at all at the time,
| but what can you do.
|
| Literally no one arguing for Laravel knew it was based around
| the Symfony components. Once the CTO saw that and heard me
| out, we didn't actually end up reviewing the Laravel option
| at all. I was so relieved.
|
| Those were weird times. I'm not sure how much Laravel has
| changed since then. At the time it was kind of like an easy
| way to build simple stuff fast, but it didn't strike me as a
| great tool for our use case. We needed to make the most
| performant php-based booking system possible, and some basic
| benchmarking showed that Laravel introduced some incredible
| performance penalties that didn't make any sense for us.
|
| Sometimes I miss that product. It had massive potential. I
| still stumble across it while booking stuff. The UI has
| barely changed. I suspect they haven't made many changes or
| made much progress since I left 7 years ago. I really wanted
| to build it into something better.
|
| Long story short: Laravel wasn't the right choice for that
| kind of application, no one who wanted to use Laravel had any
| idea about its architecture but argued with me about it for
| weeks, haha. Write detailed documents to support your case,
| it works wonders.
| alecsm wrote:
| Laravel hasn't changed much. I mean, it did, PHP also
| changed a lot in the last years but the whole idea behind
| the framework is the same. Full of features, easy to set
| up, many tools built around Laravel to deploy your app, to
| build your own SaaS, etc but it's highly opinionated, you
| have to do it their way.
|
| Symfony on the other hand takes more work but it's more
| flexible. One of internal apps is made with Symfony and
| after working on it for a couple years, if I had to set up
| the whole thing again I wouldn't know how.
| drivingmenuts wrote:
| Since I no longer work on big projects, I actually prefer
| Codeigniter. It's just simpler and yes, it doesn't do nearly
| as much as Laravel and I'm OK with that.
| pjmlp wrote:
| While I use PHP on my private site, I am in no hurry to use it
| beyond that.
| roschdal wrote:
| Good old PHP is infinitively more easy to understand than React
| js soup.
| cies wrote:
| With server-side only you need only one place to keep state.
| Then you have a stateless webserver that needs to persist all
| to a db. Those constraints make software easier.
|
| React is just the view part in the browser. You still needs
| state management in the browser, which is NOT stateless like
| most web server apps. On top of that all browser apps still
| need a backend: so you manage state twice.
| technojunkie wrote:
| PHP 8.x == TypeScript
| 0x073 wrote:
| Phpstan == TypeScript
| vundercind wrote:
| Backwards. "Serverless" JavaScript is the new PHP. Minus the high
| performance.
| zelphirkalt wrote:
| I mean, in some ways JS truly is the new PHP. That is when you
| output some jsx template string, which conditionally has pseudo
| HTML elements (more components, but with HTML syntax) inside
| it, mixed with normal HTML tags, which in turn contain snippets
| of JS, which can have side effects ...
|
| All of course preferred by the daily JS coder, instead of
| separating it out as one used to do with traditional template
| engines. PHP is the one that probably started this
| intermingling of everything, treating HTML as a mere string,
| instead of structured data, one of the biggest sins, leading to
| countless vulnerabilities over decades of web development. JS
| now carries on that torch of treating HTML wrong, only that the
| frameworks have apparently built in parsers or processing steps
| for their jsx, so that they find the web components and can
| separate them out from the surrounding HTML string, to evaluate
| them and output the HTML of those components into the
| surrounding HTML string.
|
| JS also got the hallmarks of attracting a lot of beginners,
| just like PHP used to do, due to all the hype around JS
| frameworks. It is very tempting. You can quickly see the
| browser do something. With some backend language it will take
| much more, to see anything graphical. Seeing things move or
| change how something is displayed is a strong feedback and
| motivator for the beginner.
| CuriouslyC wrote:
| PHP definitely is not the new JavaScript, but for people who want
| a server side solution for content delivery that's separated from
| the client, I'm sure it's much better than the mess it was 10+
| years ago. That's still just a transition from meme level tech to
| valid option though.
| TOGoS wrote:
| > What happened? Well. Laravel happened (and has been happening).
|
| Funny, because Laravel was one of the things driving me _away_
| from PHP, in the same way that Rails drove me away from Ruby. PHP
| was becoming a salvageable language with some of the 7.0 changes,
| but if you don 't dump 1000 pounds of gunk on top to make the
| easy things hard and there hard things dang near impossible, then
| you're not a "web artisan", I guess.
|
| Laravel needs its own 'fractal of bad design' article. My
| experience was being told to use it for a work project by a
| koolaid-driven manager, and finding that it made our CRUD apps
| about 1000 times harder to write[1] and 100 times slower to
| execute. It seriously took Laravel 100 times longer (0.3s to 30s)
| just to bootstrap itself than it took our Phrebar app to handle a
| request including a bunch of database accesses and permission
| checks.
|
| [1] Or maybe infinitely, even with code generation, because the
| ORM didn't support composite keys. In that way we were forced to
| bypass the whole thing regardless of my feelings about it.
| chamomeal wrote:
| Hearing these negative laravel opinions is super interesting.
| As someone who absolutely dreads working with php, I've always
| been curious about laravel cause people seem to love it so
| much.
| TOGoS wrote:
| All I can figure is that a lot of people, especially those
| willing to put up with PHP's warts in the first place, look
| at a giant crusty knot and can only be impressed with its
| size and seek to emulate its design. If, upon seeing the huge
| crusty knot, you puke in your mouth a little and say "are you
| sure you needed a knot at all" they briefly look at you funny
| before carrying on to make bigger and bigger knot composition
| frameworks to blather about on their blogs where they have a
| picture of their head in a little circle, because that was
| trendy among the so-called artisans for a time.
| SoftTalker wrote:
| Nothing to fear about it. It's just a scripting language. It
| has some bad history but not so much because of the language
| but how it was used. The same messes could have been (and
| were) created with VBscript (ASP) and Perl back in the day.
| wvenable wrote:
| As someone who has worked in a lot of languages and a lot of
| frameworks, I never understood the hype around Laravel. It's
| very opinionated as to how you structure your application but
| it gives you very little for forcing all that structure. I
| thought it would be and should be more batteries included.
| And the active-record style ORM is also not my cup of tea.
| SoftTalker wrote:
| "the ORM didn't support composite keys"
|
| Well composite keys are a bad idea, so maybe it had a reason
| for that.
| wvenable wrote:
| Composite keys are fine as long as all the key columns are
| surrogate keys.
| TOGoS wrote:
| If an ORM can't be used to access a valid database, then that
| ORM sucks. (ORMs often suck for additional reasons, but that
| one's pretty hard to ignore if you have an existing database
| that you need to interact with.)
|
| There are perfectly valid uses for composite keys. In a table
| that indicates a relationship between multiple other objects,
| for example.
| victortroz wrote:
| I get where you're coming from but recent versions are quite
| different. Specially with the new one which requires also PHP
| >8.2 afaik.
|
| But having 30s requests in general should be a red flag into
| other systems, laravel surely won't take that much to
| bootstrap.
| TOGoS wrote:
| Granted, this was on some virtual machine on a computer from
| 2007. But I did pare it down and down until all that was left
| was Laravel itself, doing "nothing".
|
| I don't find it all that surprising. Overly-complex startup
| times are the convention for web frameworks that want to be
| taken seriously [by koolaid-driven managers]. These days I'm
| forced to work with Spring Boot, and it also takes for-eh-ver
| to get to the point where it can run my code. According to
| the logs, it's a lot of walking the classpath to find every
| different class and figure out how to assemble them into an
| application. Because heaven forbid someone call a constructor
| to make the object they want.
| cies wrote:
| ORMs only make easy things slightly easier. Complex queries are
| not expressable in ORMs, so you need SQL queries (usually as
| strings, in external files or generated with a tool like
| jOOQ/LINQ).
|
| I think just doing all with SQL is easier to understand and
| maintain.
|
| I see no benefit of ORM considering the small benefits vs cost
| of learning.
|
| And your code become hugely dependent on them.
| jf wrote:
| Why choose between PHP and JavaScript when you can write code in
| CASSIS, a language that runs in the syntactical intersection of
| both languages?
|
| For example: if (js()) { /* javascript */
| } else { /* PHP */ }
|
| https://github.com/tantek/cassis
| stackghost wrote:
| That looks so... _unholy_...
| nine_k wrote:
| The Dunwich horror, but with languages.
| namanyayg wrote:
| https://tantek.com/cassis.js
|
| I don't know what to say, just that I wish I hadn't read this
| code
| pyinstallwoes wrote:
| function sxg_to_num($s) is a beauty.
| selimthegrim wrote:
| The HyperTalk support is touching
| danaris wrote:
| As someone whose primary languages right now are PHP and JS...
|
| ...that looks incredibly cursed.
| ainiriand wrote:
| This is why we can't have nice things.
| keb_ wrote:
| Hahaha I love this comment and love that this is a thing.
| hu3 wrote:
| Related: Laravel, the PHP framework mentioned by the article,
| just received a $57 million investment from Accel, the same folks
| that invested in Sentry and Vercel.
|
| https://laravel-news.com/laravel-raises-57-million-series-a
| pkstn wrote:
| https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
| ljm wrote:
| I don't understand this post; the author is just shilling
| Laravel; the entire post is an advert for Laravel with a
| clickbait title.
|
| The content of the article is describing the concept of a full
| stack framework, as if Laravel is the novel solution to it.
|
| How in god's name is this tripe upvoted on HN?
| Aldipower wrote:
| Yes, the title does not make any sense, after reading this
| advert for Laravel.
| akagusu wrote:
| Money really changes people's perception.
|
| For more than 1 decade Silicon Valley bros considered PHP a
| bad,irrelevant, legacy programming language.
|
| Now, with a PHP framework receiving millions in funding, PHP is
| cool again.
| cies wrote:
| Just VC money buying good press. PHP still shit. Not valley
| bros, just engineers that have worked many hours with several
| wildly different languages simply know what works well.
| conradfr wrote:
| I don't really get the hype for Laravel over Symfony, or the joy
| of writing prompt instead of actually coding.
| Diti wrote:
| Wait until that person learns about FrankenPHP!
| https://frankenphp.dev/
| davekiss wrote:
| oooohhhhh wow
| VeejayRampay wrote:
| everytime I see PHP and python, it reminds that the best of the
| three main languages in the "slow / overly dynamic" lane (Ruby)
| got the short end of the stick for some reason, it's terrible
| wvenable wrote:
| Python is pretty magical in places. PHP is slightly magical in
| places. But Ruby is magical everywhere.
| Pesthuf wrote:
| JS has done the impossible: It made me kinda appreciate PHP. I
| still despise PHP for its many design (it wasn't actually
| designed, it just happened) failures, but I've yet to see an
| application running on a single server with PHP, Apache and
| MariaDB run slower than "modern" JS slop that needs half a
| cluster to run the dozens of random object DBs and caches JS devs
| insist on using prematurely where the application takes 20
| seconds to load a simple page because the fully decoupled
| frontend needs to load and execute 500MB of JavaScript and that
| JavaScript then loads the data in 50 sequential XHRs because the
| API dev found a "loadAll" endpoint to be premature optimization.
|
| ...I envy TypeScript, though. I wish PHPDoc was more powerful...
| I just want ADTs.
| duskwuff wrote:
| > ...I envy TypeScript, though. I wish PHPDoc was more
| powerful... I just want ADTs.
|
| You can get a lot of the way there with static analyzers like
| Psalm (psalm.dev). Annotate your functions/classes with
| detailed types in PHPDoc, and it'll verify that your code
| behaves consistently with those types.
| game_the0ry wrote:
| I thought react was the new PHP.
| davekiss wrote:
| keep up!
| andirk wrote:
| Laravel + Vue is a popular and straight forward framework
| pairing. With all the shade in these comments, there's almost no
| suggestion for alternatives.
| cies wrote:
| Ktor + jOOQ + Elm + OpenAPIv3 generators for generating a type-
| safe Elm client and Kotlin DTOs for the serverside.
|
| IHP (Haskell) w/ HTMX.
|
| Elm + Lamdera; for small games (super low boilerplate).
|
| Hasura (Postgres + authorization exposed as GraphQL w/
| generated schema) + Elm + GraphQL generator for generating a
| type-safe Elm client.
|
| Rust + Yew w/ Actix or Axum on the backend.
|
| Rust + Dioxus.
|
| The thing I propose is: use something that makes it hard (near
| impossible) to express runtime errors. Life's to short for
| fixing bugs, and in many cases business is too fast to write
| 95% test cov. You need safety baked into your langs/tools.
| oddevan wrote:
| To play on how every engineer is different, OP is excited about
| PHP because of a framework, while I'm having more fun than I've
| ever had explicitly _not_ using a framework!
|
| (I am using the PSR standard interfaces[1], which means I can sub
| in any number of different libraries for different pieces of
| infrastructure. Including Laravel's. :D)
|
| [1] https://www.php-fig.org/psr/
| tredre3 wrote:
| Bit worrying that the first code example given in the blog isn't
| valid PHP.
|
| Strings are concatenated with the . operator, not +.
|
| https://3v4l.org/v9tFN
|
| Or in older PHP versions it would output a number (because it
| would cast the strings to 0).
| pavel_lishin wrote:
| But that's an example of something crappy someone would throw
| together in 1998 and FTP up to their provider of choice.
| davekiss wrote:
| Shows how long it has been since I've written PHP
| tengbretson wrote:
| Just use Next.js and _only_ use server components. Bang! you 're
| basically using PHP but with a better type system.
| pavel_lishin wrote:
| Forget the framework, forget the AI assistant. What are PHP
| developers like these days?
|
| Awhile back, we wrote an MVP, a proof of concept, using
| Wordpress. I dug around some of the plugins and themes we used,
| and _my god_ , it's still garbage. Things being shipped with huge
| swaths of code just commented out, spaces & tabs intermixed for
| indentation, TODOs littering the codebase. Things that were just
| _flat out broken_.
|
| I used to be a PHP developer, and the habits that I learned
| probably stunted my professional career by a good decade. And
| from what I've seen - granted, in a very limited exposure - tells
| me that _most_ PHP developers still write garbage code. Weirdly,
| I 've even seen examples at work where developers write perfectly
| cromulent Elixir and Javascript/Typescript, but somehow revert
| back to the fecal firehose when it comes to writing PHP code.
|
| I don't care how good Symfony or Laravel is. I care about what
| happens when my employer hires someone who can't write good code,
| and in my experience, the odds of that increase hugely when we
| talk about PHP.
| bakugo wrote:
| > using Wordpress
|
| Wordpress should be avoided like the plague if you care about
| code quality at all. It actively encourages bad code and this
| will never change.
|
| PHP programmers being conditioned to write low quality code due
| to their experience with things like Wordpress or other legacy
| bespoke codebases that aren't built on top of good programming
| practices is a real problem, and using a modern framework alone
| won't solve that problem, but I think Symfony in particular
| deserves credit for generally trying to steer people in the
| right direction. If you're just starting out writing complex
| applications in PHP, by using Symfony with PHPStorm (and
| possibly other code quality tools like PHPStan and php-cs-
| fixer, though PHPStorm already has decent static analysis and
| formatting built-in), watching the SymfonyCasts tutorials and
| being open to learning new ideas, you will likely end up
| writing at least moderately decent code because almost all of
| your programming environment will be pushing you in that
| direction.
|
| Of course, if you just hired a straight up incompetent
| developer, they will likely end up writing unmaintainable
| spaghetti no matter how much they're pushed in the right
| direction, and there's definitely a high risk of that when
| hiring PHP developers, but I feel like there's an equally high
| risk for any popular high level language nowadays. Especially
| Javascript, there seem to be tons of self-proclaimed "front-end
| developers" out there who literally only know how to copy-paste
| React code and don't actually know much Javascript or CSS at
| all.
| calibas wrote:
| There's been enormous improvements to PHP's performance and to
| the language itself over the past couple decades. It's something
| worthy of praise.
|
| That being said, it's not the "new Javascript". Javascript isn't
| dominant because of Node.js or anything like that, but because it
| runs in every major web browser. Whether you like it or not,
| Javascript is essentially part of the web itself.
| mintone wrote:
| The comments on this thread are interesting. I use Laravel
| extensively. For big applications, serving lots of users. It
| works when the application is relatively complex, and the
| ecosystem is second to none. Need to just throw it up on a
| server? There's Forge[1]. A better CI/CD process? Envoyer[2].
| Want serverless? Not for me, but Fathom[3] use it to deal with
| >100Ms of hits a day; there's Vapor[4]. All three of those are
| Laravel developed and maintained solutions.
|
| If I'm throwing something small together then sure, I'll maybe
| use Flask or something lightweight[5]. But Laravel is very good
| for nearly every use-case where you intend to actually build
| something.
|
| Then there's the bigger question: if you're building to meet a
| business use case, or well, to make money, then why wouldn't you
| use the most complete scaffold possible? I'd say Laravel is that.
| If it's too much of a pain to do something in PHP I can just
| stick in a call to a python file or really whatever language I
| want. But for the basics? A db? Auth? and lots of other stuff
| that I never want to personally build again? Yeah, give me
| Laravel everyday.
|
| [1] https://forge.laravel.com/ [2] https://envoyer.io/ [3]
| https://usefathom.com/ [4] https://vapor.laravel.com/ [5] To
| prove I'm not a shill, this is from literally last night:
| https://github.com/simonminton/consensus-article
| layer8 wrote:
| From the title I wasn't sure whether it means PHP is improving or
| is going south.
| bschmidt1 wrote:
| Always thought React (specifically JSX) made JavaScript "the new
| PHP" in that there is markup all mixed in with functions and the
| syntax is so similar to old school PHP.
|
| "New school PHP" frameworks like Laravel are nearly exactly like
| Ruby-on-Rails: The same MVC style, database and ORM built-in,
| Laravel is so similar to Rails in many ways.
|
| I would say:
|
| "Laravel is the new Rails"
|
| and
|
| "New PHP is the old Python/Ruby"
|
| The original dev use case for Wordpress where you can easily put
| up a basic CRUD app with user logins and roles/permissions was
| largely displaced by Django, which is just a little bit more
| mature of a project for such tasks than Wordpress could ever be.
| WP never wanted devs anyway, they wanted bloggers - so a lot of
| people stopped writing PHP simply because WP lost popularity as a
| web framework.
|
| PHP lost a ton of up-and-coming developers to Python (esp. in
| academia) and JavaScript (esp. to Node), in the same way
| Flash/AS3 lost developers to iOS/Android. Unlike Flash, PHP never
| really died - just kept hanging around.
|
| It's not a bad language, brings back fond memories at least. But
| there's nothing about its performance or usability that stands
| out, and there's no core platform need for it the way there was
| with Wordpress. JavaScript has the browser DOM and Node, Python
| has AI/ML libraries and best practices that aren't available in
| other languages, and in terms of another PHP use case - all the
| dynamic languages can quickly start an http server on localhost
| now. There's just no use case for PHP.
|
| I went through a PHP mini-phase in 2022 where I checked out
| Laravel (and Lumen, trying to do less monolithic things with it).
| I wanted to use PHP serverless with Vercel, it was a fun
| experiment. When I would ask (complain) about things in PHP to a
| PHP dev - just like a lowlife Angular dev they blame the version:
| _broo you 're on PHP 5 which is utter dogsh!t you have to be on
| 7_ (don't ask why there's no PHP 6. They just didn't bother).
| There's still a small community surprisingly. Like Basque - the
| only surviving Paleo-scripting language still used by modern man.
| wkyleg wrote:
| What ever happened to Hack (https://hacklang.org) the language
| Meta built as a superset of PHP?
|
| Why not take an approach more similar to TypeScript?
|
| I sometimes do wonder if many of the server side rendering
| approaches (or alternative Node runtimes) would be better off
| trying to emulate some aspects of PHP
| conradfr wrote:
| What would you want from typescript?
| durbinn wrote:
| How is this better than rails?
___________________________________________________________________
(page generated 2024-09-06 23:02 UTC)