[HN Gopher] Laravel 9
___________________________________________________________________
Laravel 9
Author : riipandi
Score : 233 points
Date : 2022-02-08 17:00 UTC (6 hours ago)
(HTM) web link (laravel-news.com)
(TXT) w3m dump (laravel-news.com)
| XCSme wrote:
| I like using plain PHP + PDO MySQL. I structure it so almost all
| files contain a single function/MySQL query, with very little
| dependencies. I already know how to implement core
| functionalities when needed (e.g. CSRF, user permissions). Why
| should I consider Laravel if plain PHP seems to work excellent in
| my case (been able to maintain the same codebase for over 9 years
| without issues, can quickly create a new app if needed, can reuse
| code from one project to another, understanding what the code
| does requires zero-framework knowledge, performance is as good as
| it can be, as every file executes only what's needed and doesn't
| create unnecessary abstractions, etc.)?
| gnarcoregrizz wrote:
| For me, its about the higher level things included. I don't
| want to write a queue, event system, or cache layer again.
| XCSme wrote:
| That makes sense, there are probably some more complex use-
| cases, but for those I would personally not use PHP (e.g. if
| real-time communication is required or linking together many
| microservices and having to do operations that involve more
| than a database and file system).
| momenti wrote:
| Though for a small-ish site (say <150 users), such techniques
| are typically not necessary.
| XCSme wrote:
| The PHP apps that I have created handle millions of monthly
| users without issues, so I would say that probably specific
| techniques are needed more to implement a given
| functionality instead of to achieve a better performance.
| ehnto wrote:
| Frameworks are useful for working in teams, and on long term
| projects. This is because they provide a set of idioms,
| patterns and decisions that everyone can learn and know,
| without having to invent them all yourself. It doesn't have to
| be the perfect way, it just has to be a way, so that you can
| focus on your domain specfic problems.
|
| Likewise, when a new developer arrives, they know exactly where
| to find everything because it has a place that it belongs, and
| they can reference the docs if they are having trouble.
|
| It's less about the code and more about treating the project as
| a whole ecosystem.
| XCSme wrote:
| But what if the app is a simple monolith that exposes some
| API routes and processes/reads/stores data in a database?
|
| Is something like this really harder to understand for a new
| developer than a Laravel project? .htaccess
| dbconfig.php /api /users
| create.php get.php getAll.php
| delete.php /products create.php
| get.php delete.php
|
| And where each file does something like (simplified)
| // /api/users/getAll.php include 'dbconfig.php';
| checkPermissions(ROLE_ADMIN); $res =
| $db->exec("SELECT * from users"); echo
| json_encode($res);
| munk-a wrote:
| Those files might work and your project might stay on that
| small scale - but you'd find it impossible to add automated
| tests to that. If your project grew to be serious enough to
| warrant automated testing then you're going to want to
| seriously refactor it and using a framework's dependency
| management is just going to make your life easier. You can
| make things a lot safer with just a little bit of
| separation and that will help protect you against bugs and
| security issues.
|
| This is all said by someone who is working right now with a
| codebase with a checkPermissions function that they added
| to shift things off of direct $_SESSION access and which
| has since been almost entirely supplanted by route based
| authentication. I delight in working to modernize and
| secure legacy systems which is why I heavily favor Laminas
| over Laravel due to the add-it-as-you-need-it approach,
| when I first worked to convert our codebase to a framework
| we did it page by page and component by component with
| everything working fine for both legacy and framework
| fulfilled requests and we've slowly added more components
| as they've become necessary (and removed ones that are no
| longer of use).
| XCSme wrote:
| It might be hard to do, but do you measure any KPIs
| (performance, codebase size, time needed to write a new
| feature, security) for before/after converting the
| platform to a different framework?
|
| I did switch the front-end side from no-framework (jQuery
| spaghetti) to a framework (React + MUI + TypeScript), but
| the main reason was that I needed:
|
| 1) Component reusability
|
| 2) Premade components (UI elements)
|
| 3) Data typing (thus TypeScript, to get autocompletion
| features)
|
| On the back-end side, the default PHP language already
| supports most of those things, plus the reusability part
| is very little for an API (it's mostly having some basic
| functions such as auth/db connection and writing
| different queries), for which a framework wouldn't
| necessarily make things easier, just provide a different
| way of writing those queries (i.e. ORM vs direct DB
| query). I agree, it's nice that with an ORM you get
| autocompletion for the fields you want to select, but the
| databases that I usually use only have a few (intuitively
| named) columns, so if you take a look at the table it
| immediately makes sense (but the queries are still prone
| to typos, so you might get an error the first time you
| type it).
| munk-a wrote:
| We don't specifically numerically measure them but we
| have seen our defect rate go down noticeably. The changes
| are also quite minimal with very little developer
| overhead being required - using a service architecture
| requires writing a factory and class definition once...
| using a query repository is about the same.
|
| The biggest advantage we've seen though is in onboarding
| time. The more purpose driven and modular our code gets
| the quicker it is people pick up on each individual
| module types structure and new devs can start
| experimental coding quite quickly.
|
| For me, personally, the ultimate attribute I value over
| everything else in a codebase is minimized maintenance
| costs - we have a few corners of our codebase that have
| extremely brittle automated tests that require hours of
| labour to execute the simplest of changes in and they're
| on our fix list. But the stuff we need to change
| frequently can be changed quickly and safely so our bug
| fix turn around is relatively minor. I'm actually in the
| middle of upgrading us from ZF2 to Laminas and this work
| is probably going to last about three weeks (with a bunch
| of the most annoying fixes coming out of Doctrine and
| their fanatical devotion to `final`ing every class under
| the sun - thanks guys) which honestly seems extremely
| reasonable to me for bumping two framework versions.
|
| I'm also really not personally a fan of ORMs because the
| query building tends to make DB performance harder to
| tune and I loathe the performance implications of
| ActiveRecord approaches - but they're components I've
| built into our infrastructure to support other devs and I
| can comprehend their appeal.
| jonwinstanley wrote:
| If your project is as simple as this then yes, a framework
| would be overkill for you.
|
| The people that benefit from Laravel use a lot of its
| features and aren't willing to waste time rewriting them
| for themselves.
|
| In the businesses I have worked at, if we had spent the
| whole time building the stuff that Laravel already does for
| us then we'd have gone broke really quickly.
| blowski wrote:
| Nearly every time I see PHP projects like this, I find
| massive security vulnerabilities combined with extremely
| brittle functionality.
|
| Sure, this describes many Laravel and Symfony projects as
| well, and not every vanilla PHP project is bad. But there
| is definitely a pattern.
| XCSme wrote:
| I agree, one big reason to use frameworks is that they at
| least make it harder to make insecure things, but as you
| said, if the developer is inexperienced they can still
| introduce vulnerabilities in any codebase.
|
| I would say, in this regard, that Laravel is better than
| plain PHP when working with inexperienced devs that are
| likely to make mistakes or write bad code.
| blowski wrote:
| So what happens if you want to hire a second dev to help
| you? Or you want to sell the codebase?
| XCSme wrote:
| A new dev can start writing code immediately by looking
| at any existing file, as almost all of them do the same
| thing: include a shared header, get some input from the
| user, do one or more MySQL queries, return the result.
|
| The backend is completely separated from the frontend (so
| the PHP application just exposes an API to work with), so
| any code written there does exactly what you expect with
| no side effects on the client-side.
| unfocussed_mike wrote:
| > as almost all of them do the same thing
|
| It's the _almost_ that will get you here.
| XCSme wrote:
| The difference is mostly the user input, MySQL query and
| DB table and output. This is indeed prone to typos and
| "brain-farts" when selecting the wrong data.
|
| Does Laravel provide any protection in making sure you
| don't SELECT from the wrong table?
| unfocussed_mike wrote:
| Generally I use the model builder methods for this
| anyway, because I'm using the ORM and the models
| represent tables, so I barely ever build my own select
| statements at all.
|
| https://laravel.com/docs/8.x/eloquent
| XCSme wrote:
| Even with an ORM, isn't there the risk of typing
| Flight::select('name') instead of
| Passenger::select('name'), if both values return the same
| data type (string)?
|
| Is that harder to do than accidentally typing `SELECT
| name FROM flights` instead of `SELECT name FROM
| passengers`?
|
| Aren't most of those issues found as soon as you first
| test the feature?
| unfocussed_mike wrote:
| I don't understand the point you're getting at here.
| Isn't this kind of typo more or less universally
| possible? Which code library or generator can protect you
| from errors like this (and divine your intent?)
|
| You _can_ be protected from SQL injection and you can
| have various other query operations, and you can gain
| refactoring support (e.g. by telling the models the new
| table name), or you can add custom scopes that
| encapsulate transformations on the query.
|
| Laravel also allows you to express model relationships,
| so Flight might have: public function
| passengers(): BelongsTo { return
| $this->hasMany(Passenger::class); }
|
| and then you can do things like:
| $flight->passengers->where('name', 'like', 'XCSme%');
|
| > Aren't most of those issues found as soon as you first
| test the feature?
|
| I don't know.
|
| The thing is, an ORM brings you other stuff (like a query
| builder integration) that allows you to construct queries
| without having to glue SQL strings together (and chain
| and pass query objects).
|
| And Laravel separately also brings you a migration tool
| that allows you to encapsulate upgrades to your database
| as code snippets (so you can put code live without
| manually fiddling with SQL at all).
|
| In my experience even really small apps benefit from this
| at some level. The discipline of using regular patterns
| like this is really useful.
|
| (The Lighthouse GraphQL binding is where this stuff gets
| really interesting)
|
| At any rate, we're unlikely to agree.
|
| [edit: removed a tired-brain word choice mistake!]
| ehnto wrote:
| If I am working alone, I sometimes do similar stuff. But if
| I am working with others, I don't really want to deliberate
| over every new architectural decision if a project grows. I
| want to be able to say, "Hey, can you make a new
| storelocator page" and then they can get it done using the
| docs. They know where models, controllers, views live, they
| know how to make migrations for the new tables, they can
| even google "store locator laravel" and probably get 90% of
| the way there in a day or less. Once they are done, I
| already know how this new feature should work before I even
| read their code.
| unfocussed_mike wrote:
| I took over an enormous system that a third party
| developer built in Laravel.
|
| Not good code, particularly, and not particularly good
| database design.
|
| Also no documentation really.
|
| But the implementation was pretty clearly pure Laravel,
| and the migrations ran without issue. So that was
| immediately a huge weight off my mind, because I knew I
| would be able to maintain the live, stage and dev boxes
| sanely.
|
| The two biggest problems with this app were
|
| 1) the number of places they diverged from using the
| query builder for no really good reason when scopes could
| have made everything so much more readable
|
| 2) a false assumption they made about subquery ordering
| in MySQL (implicit ordering that worked for them in 4.x
| but would not work in 5.x, something along those lines
| anyway)
|
| Because of 1), 2) was _incredibly_ painful to fix. Dozens
| of bits of arbitrary SQL that could have been handled by
| the query builder.
|
| And I'm sure the only reason it's like that is because
| that's the way they started out and they had time
| pressure that stopped them ever changing course.
|
| Expedience kills software.
| unfocussed_mike wrote:
| There is no doubt that getting in and out of a Laravel
| project is a bit more difficult than the example you
| suggest. But the example you suggest absolutely encourages
| bad practice.
| XCSme wrote:
| > absolutely encourages bad practice
|
| Bad practice, as in security-wise, performance-wise,
| readability-wise, or something else?
|
| If you trust the developer to implement things properly
| (use PDO prepared statements when storing data in DB,
| properly check for permissions, write efficient queries,
| etc.), shouldn't that automatically exclude common bad
| practices?
|
| If the developer is inexperienced, can't they still
| implement something in a bad way in Laravel (e.g. save a
| user-submitted file on the disk without checking for
| permissions)?
| unfocussed_mike wrote:
| > If you trust the developer to implement things properly
| (use PDO prepared statements when storing data in DB,
| properly check for permissions, write efficient queries,
| etc.), shouldn't that automatically exclude common bad
| practices?
|
| That depends. How tired is the developer? How under
| pressure? How over deadline? ;-)
|
| I do get your point and I understand where you're coming
| from.
|
| But this model of PHP (where every URL entry point is its
| own script) is the thing that most encourages expedient
| development rather than good development, because you can
| just hack on that one thing without affecting anything
| else.
|
| It also (traditionally) encourages somewhat riskier
| hosting configurations, because any PHP file the web
| server can route may need to be executable, and because a
| failure of web server configuration can expose PHP files
| as readable. Whereas with a single point of entry
| (index.php router), you can locate your codebase outside
| the document root, refuse to directly execute anything
| but your endpoint script, etc.
|
| These are partly old-fashioned concerns, admittedly, but
| it's surprising how often the approach you're outlining
| is still the source of malicious PHP exploits where a
| script file gets buried in a hacked release, or where
| some server vulnerability can be inveigled into executing
| PHP code by some image file upload mechanism that didn't
| do adequate checking.
| XCSme wrote:
| I agree that writing secure PHP code is hard, but using a
| framework like Laravel, even if it has a single point of
| entry, makes it a lot more likely to introduce more
| security issues. When a framework is popular and open-
| source, people will spend a lot more resources trying to
| find and exploit vulnerabilities than in a custom private
| codebase:
| https://snyk.io/vuln/composer:laravel%2Fframework
| unfocussed_mike wrote:
| I can see your point.
|
| But at the same time, I have never seen a project built
| along the lines you discussed that has not collapsed
| under the pressure for expedience, and it's just as
| vulnerable to issues in libraries (which any project of
| any complexity will use).
| XCSme wrote:
| I think the biggest question to ask is how big the
| project is.
|
| Wikipedia, Facebook, Etsy and other huge platform are
| written in PHP, but I doubt they use a framework like
| Laravel and not some in-house built platform.
|
| Very tiny projects probably need no framework.
|
| That leaves medium-sized projects, but again, it's hard
| to define what "size" means. I think a project is bigger
| if it implements various functionalities instead of
| having hundreds of different files that do a similar
| thing.
|
| I can see Laravel being used more by out-sourcing
| companies. Custom frameworks or no framework being used
| more by companies building their own product.
| tomcam wrote:
| Non-PHP, non-Laravel person here just trying to learn.
| That looks pretty good to me. What bad practices does it
| encourage?
| XCSme wrote:
| I wrote that example, which is simplified, but here are
| some security things to keep in mind when dealing with
| PHP/MySQL: - Always use PDO prepared
| statements to avoid SQL injections - Should
| probably implement a CSRF token check - You
| shouldn't output values directly from the user/database
| and that can lead to XSS attacks (either sanitize
| the stored data, or when outputting it make sure the page
| is always interpreted as plain text) - You
| might forget to check for permissions in a specific route
| (code enforce this via some linting/IDE rules, by using
| some automated tests or by checking in an included shared
| script that permissions were indeed verified)
| ipaddr wrote:
| Always use PDO prepared statements to avoid SQL
| injections?
|
| Sanitize your data and use whatever driver you want.
| Prepare statements are like sending xml instead of json.
| If you are populating a database with known data why add
| the overhead?
| XCSme wrote:
| > on long term projects
|
| Aren't frameworks harder to use in a long-term project if the
| codebase is not constantly updated to match the new framework
| standards?
|
| For example, a code-base written in React (pre-hooks) is
| probably pretty hard to understand for a developer that has
| only learned React recently and uses hooks for everything.
| ehnto wrote:
| There is often ongoing maintenance for sure, but if that is
| a concern a framework probably doesn't fit your project for
| other reasons already.
|
| Frameworks are heavier, but in the same way a company gets
| heavier as it gets more professional and more complex.
|
| I think your use case doesn't require a framework, so don't
| think my angle is to convince you that you do. Just that
| there is definitely a time and place for them.
| jonwinstanley wrote:
| There's definitely an overhead in updating your codebase to
| work with new versions of the framework but the time saved
| by not having to write all the features yourself makes it
| worth it.
| XCSme wrote:
| Can you give example of some features that you have to
| write that don't exist in a plain PHP application nor an
| external library (i.e. features that have to be tightly
| integrated in the core of the product)?
| jonwinstanley wrote:
| To be honest, I'm sure all the features of Laravel I use
| could also be done with external libraries, but
| researching and finding something suitable, hooking it
| together, configuring, integrating it into my project is
| something I am unwilling to spend time on.
|
| I write code to solve problems for my company, so
| building a framework is very low on my priorities. I'd
| rather just use something that is ready on day one.
|
| Maybe it's not to everyone's taste but I like the fact I
| can just get on with trying to build my product.
| castis wrote:
| > Why should I consider Laravel
|
| If you work on all those projects alone, and you're happy doing
| this, you probably wouldn't. You aren't the target market for a
| framework like this.
|
| Laravel (and any good framework, really) is for people who want
| a consistent dev experience _with good documentation_.
| XCSme wrote:
| Yes, I do work alone on those projects, but I do use
| frameworks on the frontend-side as I find them to help in the
| long term, not hinder the projects as PHP frameworks do (a
| lot of boilerplate).
|
| It makes sense that if Laravel is strongly-opinionated to
| result in a consistent dev experience, but is a consistently
| bloated dev experience better than an inconsistent lean one?
| colecut wrote:
| Bloat can be mostly ignored, inconsistencies can not.
| unfocussed_mike wrote:
| > You aren't the target market for a framework like this.
|
| I don't know about this. But then I am of an age where I
| consider myself to be a team of programmers separated by
| time.
|
| There are the younger, less easily tired versions of myself
| who thought this was a great idea for a career and lived on
| takeaway curries, there's me, and there are the four or five
| older versions of myself who will hate me for trying to be
| clever and not trying to be consistent.
|
| Laravel helps me take on projects that allow me to hand off
| pieces of work among my team ;-)
| munk-a wrote:
| I wouldn't consider Laravel for this use case - I might
| consider either Laminas or Symfony though since those two
| frameworks allow you to pick and choose which features you
| actually want to roll into your project. If you'd like to
| simplify your routing files but otherwise leave everything else
| the same - Laminas and Symfony can do that trivially. If you
| find yourself forced into an ORM due to needing to support
| multiple SQL dialects, Laminas and Symfony can also do that
| trivially.
|
| Laravel is a sort of all-in option that tends to perform worst
| when integrated into a legacy project - it isn't completely
| overbearing (it won't creep into absolutely every file you're
| using) but it will end up requiring changes to a lot more files
| than is reasonable.
| e12e wrote:
| Sounds reasonable. (how) do you do testing (unit test and
| integration tests)?
| XCSme wrote:
| I don't do unit tests (tried it, it was slowing down
| development too much).
|
| I did have integration testing for a while for the core
| functionality, but in the end that was not helping much
| either, and after releasing a new version of the app I
| deleted the tests and (after 2 years) still haven't written
| new ones, without any bad consequences so far.
|
| I deploy a new version to a beta branch, test it myself for a
| few hours/days (as I do use the app myself daily), then
| publish it live. Customers gradually upgrade to the new
| version and if anyone encounters an issue they let me know,
| and I fix it ASAP, but it almost never happens.
|
| Also, the app is pretty complex, so writing tests for every
| use-case and environment is impossible.
|
| I am not a big fan of writing tests when working in a small
| team (<5 developers). I did work on some pretty big projects
| that turned out great and very robust, without having written
| any tests.
|
| That being said, if I ever have the time and am bored enough,
| I will write some integration tests, but mostly for the
| installation part of the application, not for the usage part.
| tomschlick wrote:
| > Also, the app is pretty complex, so writing tests for
| every use-case and environment is impossible.
|
| No, you're just using the most expensive / error prone
| testing methods: doing it manually.
| XCSme wrote:
| Maybe my comment was not clear, I do not specifically
| test the app and all its functionalities. I use the app
| myself on a daily basis anyway, which acts like a sort-of
| continuous integration testing program. I use the new
| version myself for a few days before publishing it, or
| provide it to some chosen beta testers that use the
| product anyway.
| tomschlick wrote:
| How in the world is that better than automated testing?
| Rather than being sure that a feature didn't break,
| you're taking the chance that you or a beta user is going
| to hit the bug and report it back correctly.
| bluedino wrote:
| Self-made frameworks are great as long as: They
| work. If they are full of bugs they are a pain They
| are complete. If they are missing parts because they weren't
| needed yet, they are a pain They are documented.
| Documented well is a bonus There isn't a self-made
| framework for every project at the company The
| person who made the framework is still around The
| person who made the framework didn't also make v2 and v3,
| mixing them in the same project
| XCSme wrote:
| My point was more that PHP is more of a framework-less
| language, as most of the functionality needed for a basic web
| application is built-in (file-based routing, secure PDO
| database access, external libraries for specific
| functionalities like PHPMailer for sending emails).
|
| I think that if you need something a lot more complex than
| this (realtime communication, processing data in separate
| threads, linking microservices), then PHP is not a good
| choice.
| dabernathy89 wrote:
| There are lots of reasons someone like you might benefit from a
| framework, but this one jumps out immediately:
|
| > I already know how to implement core functionalities when
| needed (e.g. CSRF, user permissions)
|
| Even if you know "how", this is still wasted time on your part.
| These are solved problems.
|
| Particularly when it comes to security features like CSRF,
| relying on yourself to implement it sounds like a major footgun
| opportunity. When you use a framework that has this built in,
| you have to try really hard to bypass these security features.
| You barely even have to think about how to implement it.
| daveaiello wrote:
| Could somebody say, if you are planning to embark on a new
| Laravel project and you have no experience, how to begin?
|
| I bought a subscription to Laracasts, and there is a "What's New
| in Laravel 9" series. But "Laravel from Scratch" is still on 8.
| devNoise wrote:
| Go with the "Laravel from Scratch" on v8 to learn the basics.
| Then follow up with the "What's new in Laravel 9". I'll be
| updating to v9 this spring. Laravel has been pretty stable
| since they changed to semver for versioning (ie v6). The
| framework is fairly stable. They held off the v9 release so it
| could have the new Symphony components. A lot of features that
| would have been released with v9 were added to the v8
| framework. v9 may have some breaking changes, but I'd have to
| really dig through the release notes to find what would affect
| my app.
|
| I'm more concerned with updating PHP from 7.4.x to 8.x then the
| framework update. Our test env had issue with one of our blade
| templates when running under 8.x.
| unfocussed_mike wrote:
| Yep -- I am more worried about the PHP side because there you
| run into the question of whether other PHP devs whose
| packages you use are as good as the Laravel guys.
| wilsonfiifi wrote:
| Also take a look at Code Course [0]. Good stuff and reasonable
| pricing.
|
| [0] https://codecourse.com/
| munk-a wrote:
| Don't be afraid to investigate the other frameworks as well.
| Both symfony and laminas have a lot to offer and tend to be
| less all-encompassing. Laravel is the right choice to get
| something simple from 0 to 60 quickly, but if you need to do
| complex things or integrate legacy systems it can be a lot more
| punishing.
| durpleDrank wrote:
| You could try LUMEN which is a lite version of Laravel. Took me
| around a day or two to fully get what was happening. I'm at the
| point now where I want to switch a big project I've been
| working on over to Laravel but it's a bit of a PITA.
|
| Anyway, for hello world stuff or a small api project try
| beginning with LUMEN.
|
| https://lumen.laravel.com/docs/8.x
| tomschlick wrote:
| Lumen is mainly feature complete and its mostly recommended
| to just use Laravel and unload the service providers you dont
| need.
| KerryJones wrote:
| The Laravel from Scratch will still largely be applicable, the
| changes in 9 won't be breaking enough for you to be missing out
| a lot. The upgrades tend to be painless with a few small tweaks
| you might have to make (and those are usually described on the
| upgrade page).
|
| If I were you, I'd start with Laravel 8.0 as you go through the
| Laracasts, and when done, go to the upgrade page of Laravel 9.0
| and checkout the changes.
| yurishimo wrote:
| I've onboarded plenty of people in the past couple of years to
| Laravel.
|
| The changes from v5 -> v6 were the larger than most of the
| changes from v6 to now. Even then, those 5->6 changes weren't
| that bad.
|
| You can follow along with Laracasts on v8 and upgrade to 9 when
| you're ready. It will be an easy transition.
| geenat wrote:
| Laravel and Drupal 7+ frankly ruined PHP for me.
|
| PHP as a platform is KISS and elegant, and I still admire some of
| its features such as built in templating, filesystem based
| routing, etc.
|
| But whenever I look back at Laravel, I remember how dangerous
| overly complex fluff with a nice logo is to a platform.
| pan69 wrote:
| > Laravel and Drupal 7+ frankly ruined PHP for me.
|
| You don't have to use either. It's like saying something like
| "Britney Spears ruined music for me".
|
| Just go with Symfony and be done with it.
| geenat wrote:
| Management routinely influences stack choice based on hype
| level.
| pan69 wrote:
| To be fair, developers seems to be very good at doing this
| themselves as well.
| bdcravens wrote:
| Any app without a framework ends up creating a framework of its
| own. Complexity isn't something to hand-wave away, but neither
| is the mess of include's and SQL injection risks that many
| "vanilla" apps become.
| cutler wrote:
| Not true of Node.js.
| unfocussed_mike wrote:
| Node.js is only fine if you have the personal energy to
| keep up with all of JS tooling all the time. It strikes me
| as insanely unprofessional most of the time.
|
| Laravel always seems to be the work of grownups; it's not
| cutting edge but it is solid and self-contained.
| skinkestek wrote:
| True, and just like with the Gradle build system on JVM,
| every project is its own unique snowflake.
|
| That's what you meant, right ;-)
|
| Or is it just everything I inherit?
| doublerabbit wrote:
| Same applies for frameworks. Your hoping that the framework
| and ecosystem is clean as to get everyone to update the
| framework isn't an easy task espcially when a vulnerability
| arises from within.
|
| It's moot. Take Wordpress for example.
| mschuster91 wrote:
| > However your then hoping that there are not any
| vulnerabilities within the framework.
|
| The likelihood of me introducing an injection,
| authentication/authorization bypass or RCE vulnerability in
| homegrown stuff is orders of magnitude larger than in an
| application where at least the sensitive core parts are
| handled by something that's battle tested in millions of
| deployments and regularly audited.
| doublerabbit wrote:
| If the framework is promoted to be enhanced by a
| ecosystem of plugins, widgets, your still introducing the
| same exploitable ground as of developing your own. If not
| more dangerous because your operating already on core
| infrastructure and with a wider audience. How often does
| the developer get bored and start to neglect the plugin?
|
| I do agree that a single home-hobbyist programmer should
| not be coding a bank and that sql injections and the rest
| are all lethal to the internet. However you end up with
| stagnation and lack of innovation if you pressure users
| to use a framework because there's a fear of some sort of
| exploit.
|
| It's like riding a bike and forcing the rider not to ride
| without stabilisers because they may fall sideways.
| mschuster91 wrote:
| >How often does the developer get bored and start to
| neglect the plugin?
|
| For the most popular frameworks (e.g. Drupal, Symfony,
| PHPunit), the core ecosystem is (co-)maintained by the
| framework authors, who are funded through various means -
| usually consulting/webdev agencies. The "usual" FOSS
| burnout problem doesn't apply for them.
|
| > However you end up with stagnation and lack of
| innovation if you pressure users to use a framework
| because there's a fear of some sort of exploit.
|
| A framework is just that: a framework. You can develop
| all you want with that framework - I've seen Symfony
| being used for tiny microservices to the code for a
| bank's website. You can develop faster and better code
| because you don't have to re-invent wheels or do tedious
| interoperability tests for basic stuff allll the time,
| and whatever problem _you_ encounter, _someone else_ will
| have also encountered and posted a solution on
| Stackoverflow.
|
| > It's like riding a bike and forcing the rider not to
| ride without stabilisers because they may fall sideways.
|
| No. Symfony, Laravel and others are the vendors for the
| basic bike... you can always bolt on custom parts
| according to your need and for the PSR-standardized stuff
| like loggers, you can even choose between multiple
| different part vendors.
| ivanhoe wrote:
| IMHO Laravel and Symfony are the best things that happened to
| PHP community since php5. PHP was an ugly mess of bad
| practices, fragmented into many outdated apps/frameworks and it
| was just exhausting to use. Symphony was a great improvement,
| but a bit too rigid and too enterprise-level for my taste. For
| me Laravel was honestly a breath of fresh air - finally I had
| something significantly more powerful than my custom framework
| and still highly flexible and light-weight.
| TimWolla wrote:
| Laravel definitely is everything, but light-weight. It's the
| slowest of the large names in PHP.
|
| see http://www.phpbenchmarks.com/en/comparator/framework or h
| ttps://www.techempower.com/benchmarks/#section=data-r20&hw=..
| .
| davejitsu wrote:
| You're posting benchmarks for versions that are now more
| than 7 years old
| coder543 wrote:
| TechEmpower appears[0] to be using Laravel 8.70, which
| was released about 3 months ago. Much less than 7 years
| ago.
|
| The numbers there don't paint an encouraging picture
| either, but I'm happy to concede that performance isn't
| _everything_... it just doesn 't matter for some
| applications. But, numbers like these are pretty
| appalling to me. (And yes, I feel the same way about
| Rails.)
|
| [0]: https://github.com/TechEmpower/FrameworkBenchmarks/b
| lob/mast...
| BareNakedCoder wrote:
| Agreed! Framework == good doesn't mean any/all frameworks
| == good. Many of PHP's frameworks seem to have ignored
| PHP's unique run-time characteristics and adopted Java
| idioms (with Java, you pay once at compile time; with PHP,
| you pay with every single request). Ubiquity, near/at the
| top of the PHP benchmarks, seems to accept PHP's unique
| run-time characteristics (so performs well) and yet still
| provides all the benefits of a framework (consistency,
| etc). Ubiquity should see much more love than
| Laravel/Symfony/etc but doesn't :(
| dgb23 wrote:
| You can use Laravel just for the basic wiring, integrated
| tooling, SQL query builder, auth, sessions, and HTTP routing.
| It really gets out of the way if you need to avoid features you
| don't like. All of the stuff I listed above are a PITA in plain
| PHP.
| ThatMedicIsASpy wrote:
| Symfony components would be the better choice? Did they
| change Laravel to only include what you want like Symfony?
| unfocussed_mike wrote:
| Yep -- Laravel has always been the work of grownups in this
| regard.
|
| It's a really very good platform for headless PHP. The job
| queuing stuff is so neat it actually makes me write queueable
| jobs.
|
| Combined with Lighthouse, Spatie's Stripe Webhooks library,
| Spatie's MediaLibrary, I've actually had _fun_ with Laravel.
|
| I see no reason for hate now.
| cmg wrote:
| I went kind of in another direction a few years ago -
| CodeIgniter's routing/sessions/etc base was plenty for most
| of my projects, but I wanted a real ORM. So I integrated
| Eloquent from Laravel and ignored the built-in CI database
| layer. A bunch of these sites are still running smoothly on
| modern PHP.
| PZ81JUXJE7uJ wrote:
| Funny, all I remember is the hot mess everyone was producing
| before Laravel.
| agumonkey wrote:
| beside legacy cobol, wordpress plugins were the most
| horrendous code i've ever seen. dead code I should say since
| quite often half of it was left commented in the official
| running source.
| unfocussed_mike wrote:
| Right.
|
| Laravel 7 and 8 have been excellent. It's a good product with
| beautiful documentation.
| pak9rabid wrote:
| Having worked in both environments (framework vs no framework),
| for anything other than very trivial apps, you want the
| framework to force everyone into a common way of doing things.
| Otherwise the project turns into a a massive clusterfuck of
| everyone doing their own thing, often with many instances of
| "reinventing the wheel" going on.
| defenestration wrote:
| We have been using Laravel for over 8 years. Nothing but praise.
| It's a framework we could rely on. No painful upgrades and clear
| documentation. For us it's a pleasure to work with. I also
| recommend Laracasts from Jeffrey Way.
| KerryJones wrote:
| Seconded this in its entirety. Been to Laracon multiple times,
| use it for all my side projects (as well as startup). Has
| performed remarkably well and more consistently than any other
| experiences I've used
| riipandi wrote:
| Yeah. Maybe what we love from Laravel isn't only great docs and
| painless upgrade process, but also the great ecosystem.
| sdoering wrote:
| I wanted to try it. I wanted to see if it could help me solve
| a business problem.
|
| Sadly I just wasn't able to understand the first steps to get
| something out there.
|
| I really still want to like it. But currently I have no idea
| how to practically start.
| unfocussed_mike wrote:
| It's the fact that it has a culture of grown-ups. Where by
| "grown-ups" I mean there is an avoidance of cute hacks for
| the sake of things, there is an approach where nobody assumes
| anyone is the same kind of expert, and takes care to
| contextualise.
|
| There is a stronger emphasis on being able to _write_, to
| explain, etc.
|
| I love really cute hacks and neat minilanguages and
| metaprogramming and all that when I am doing things for fun.
| But when I am working, I want documentation, not five-line
| git READMEs that presume I am up-to-date.
| withinboredom wrote:
| Doctrine + graphqlite. It's all you really need for a sane API,
| you don't even need a router unless you just want one.
| jstummbillig wrote:
| All else being equal, how do we feel about Rails 7 vs Laravel 9
| in 2022? Giving the breadth of both frameworks I am pretty
| certain there has to be one objectively better choice. Which one
| is it? Why?
| e12e wrote:
| I don't think either is _objectivly_ better - if for no other
| reason than ruby and php being quite different languages.
|
| Personally I _much_ prefer ruby - but I could perhaps see
| myself reaching for Laravel for a project depending on
| requirements.
| jmcharnes wrote:
| As a Ruby developer I resonate with this. I love a LOT about
| the Laravel ecosystem, but I also still really love Ruby and
| Rails.
| jstummbillig wrote:
| What requirements does Laravel meet that Rails does not?
| yurishimo wrote:
| Marginally cheaper/easier to deploy. Very robust queue
| system built in. Where you'd pay for Sidekiq in Rails,
| that's included in Laravel. Auth is also more streamlined
| since Laravel takes a stance on what the default is unlike
| Rails (though I admit most people just use Devise).
|
| I think PHP is still faster as a language? There are also
| tools available now to run Laravel apps on serverless
| infrastructure if that's something you don't want to mess
| with.
|
| I'll admit I'm biased and haven't spent much time with
| Rails outside of a hello world and various podcasts.
| jackconsidine wrote:
| Exactly 45 minutes ago I went on Laravel docs and saw the "you're
| on an old version of Laravel" message on the Laravel 8.x docs.
| Wow, I thought, Laravel quietly dropped a major release and I
| didn't even see press for it.
| riipandi wrote:
| Don't forget to watch Laracon Online, tomorrow on Youtube.
| unfocussed_mike wrote:
| Ooh thanks for this.
| exceptione wrote:
| Can someone contrast Laravel with Symfony? Why would you pick one
| over the other when?
| ipaddr wrote:
| What does everyone recommend for learning testing with Laravel?
| tomschlick wrote:
| https://testing-laravel.com/
|
| https://laracasts.com/series/build-a-laravel-app-with-tdd
|
| https://course.testdrivenlaravel.com/
| ricardonunez wrote:
| The documentation is pretty straight forward. Just follow it
| and you can get it running in a few minutes.
| neals wrote:
| I've used Laravel on and off. But I always run into uncertainties
| when doing large refactorings. How are you doing large
| refactorings?
| deergomoo wrote:
| As with any dynamically typed language, good test coverage is
| important.
| hparadiz wrote:
| I'm just now learning (week 2) Laravel after coming from using
| other custom frameworks for years. For the record I have my own
| framework with a fully featured ORM of it's own and 99% unit test
| coverage for said ORM which is a fork of one my friend started 15
| years ago and I have contributed to for several years. We started
| it before Laravel existed and in many ways it's exactly like
| Laravel. [https://github.com/Divergence/framework]
|
| But anyway.....
|
| So far what I like:
|
| - Migrations
|
| - The ORM is pretty good
|
| - Query writer is aight
|
| - Blade
|
| - Mixx
|
| - built in CLI
|
| So far what I don't like:
|
| - All routes defined in one single file instead of procedurally
| in each controller (performance wise this is terrible cause
| you're running a bunch of regular expressions on each and every
| request. augh)
|
| - File structure doesn't adhere to PHP league standard
| [https://github.com/thephpleague/skeleton] All PHP code should be
| in src directory or tests directory.
|
| - [php artisan] - each project should have a file in bin folder
| with a PHP shebang [#!/bin/env php] with +x on the file and
| linked globally so instead of writing php artisan you would write
| $projectName instead. Link it globally even.
|
| - .env file - just use PHP files for configs which opens many
| possibilities like inheritable config setups. Instead of just dev
| or staging or prod you would instead have main, dev, production
| where main is env variables that don't change between
| environments.
|
| - Docs aren't great. Eloquent needs a PHP.net -like page where I
| can see every single member function but instead I google and get
| the getting started docs which gloss over the best features. I
| have to manually sit down and read the source code.
| yurishimo wrote:
| I'll admit I'm not an expert, but using `php artisan
| route:cache` does provide some performance boost. About 5x in
| real world scenarios when dealing with very large route files.
|
| Article with more info: https://voltagead.com/laravel-route-
| caching-for-improved-per...
| fendy3002 wrote:
| > - .env file - just use PHP files for configs which opens many
| possibilities like inheritable config setups. Instead of just
| dev or staging or prod you would instead have main, dev,
| production where main is env variables that don't change
| between environments.
|
| Uh what, .env is standard practices for many languages even in
| docker. And Laravel doesn't prohibit you to extend the config
| folder with your custom settings. You can easily do both.
|
| And for anyone who don't know yet, don't commit your
| configuration to the repo.
| jonwinstanley wrote:
| I doubt the routes are evaluated with regular expressions on
| every request, more likely it's matched based on an explode of
| /
| philo23 wrote:
| I think quite a lot of the PHP routers are based on regexes,
| for better or for worse. One of the most famous is FastRoute
| by nikic that (from memory) merges all your routes into one
| big regex and then tells you which route to dispatch based on
| some index that comes back in the match. I don't know how
| widely that specific library is still being used though or if
| it's since been replaced by something better.
|
| https://github.com/nikic/FastRoute
| lowercased wrote:
| > "All routes defined in one single file instead of
| procedurally in each controller (performance wise this is
| terrible cause you're running a bunch of regular expressions on
| each and every request. augh)"
|
| Have you timed it? And do you have a flexible alternative
| measurably faster that can drop in/ Are you taking in to
| account route caching?
|
| Not everything has to be in one file. RouteServiceProvider
| gives you a place where you can programmatically determine
| which route files, if any, you want to process.
|
| > File structure doesn't adhere to PHP league standard
|
| So what? And... "all php code should in in src or tests..."
| That doesn't even seem to be documented anywhere. PHP code
| could live in /config (like... you seem to want above?) - but
| 'config' isn't /src or /tests.
| [deleted]
| Darmody wrote:
| I've been programming in PHP for around 5 years. I've used
| vanilla PHP, full featured MVC frameworks, micro frameworks and
| I've been working with Laravel for around 2 weeks. Worst
| experience ever. The more I dig into it the more I hate it.
| folkhack wrote:
| I've been programming PHP since around 2003 and although I
| don't find Laravel to be perfect, I find it to be a _very_
| solid framework to build general web solutions with. I have
| successfully launched everything from complex OAUTH solutions
| handling insane amounts of traffic, to dumb startup ideas, to
| just simple CRUD apps I use in my own personal life.
|
| I find it to be fully featured, incredibly well documented, and
| easy to use/learn. I find it to be my favorite "RAD" tool for
| generic API development. Also, the community is pretty solid
| too - specifically the IRC channel. I'll go far enough to say
| that Laravel has positively motivated my development as a
| software engineer - it's opinionated but I find it to be
| opinionated in a good way. Example: Laravel is heavy on
| testing/tooling which I think is outstanding.
|
| I am really curious as to what specifically you're finding
| problematic?
| e12e wrote:
| Please tell us why?
| celestialcheese wrote:
| Honestly surprised by this. It's an opinionated framework, but
| it's consistent and the ecosystem is rich with options. I've
| been very happy working inside the laravel ecosystem for the
| last couple of years.
| chipotle_coyote wrote:
| A problem with any "opinionated" framework is that people may
| disagree with the opinions. :)
| ziggus wrote:
| Do you have any actual complaints?
| sequoia wrote:
| Downvoting because you're not adding any info besides 'laravel
| bad.' I am interested in your experiences, but "I hate it"
| isn't useful by itself.
| TimWolla wrote:
| This is my experience with Laravel as well. Laravel looks great
| on the surface for a simple CRUD application, but once you need
| to do something non-trivial with it, you need to start fighting
| the framework. Also I dislike the large amount of magic
| happening within the framework. I want to understand what the
| code is doing, so that I can properly debug it in an emergency.
|
| As a specific example I needed to override half of the classes
| of Laravel Passport within the DI container to fix issues
| upstream wouldn't acknowledge at the time / doesn't
| acknowledge. Some of them are fixed by now (e.g. they _finally_
| support non auto increment Client IDs OOTB), some of them are
| not when I last checked.
|
| I wouldn't choose Laravel again.
| henry700 wrote:
| Exactly this for the exact same reasons, only more specific
| to the Eloquent ORM instead. God forbid you need to do
| nested-nested-nested relationships or something relatively
| complex. Laravel works VERY well for the simple cases, but
| all the weak typing, reflection and runtime searches that it
| uses just makes every runtime framework problem a pain in the
| ass to debug. I'll stick to Spring Boot or ASP.NET Core any
| day.
| porker wrote:
| It sounds like Doctrine https://www.doctrine-project.org/
| is what you need if you want an ORM to handle relatively
| complex stuff. It's the default in Symfony projects and I
| don't know if there's a Laravel integration.
|
| ASP.NET Core is nice mind; if you have the choice... :)
| fendy3002 wrote:
| I don't know if many share the same sentiment, but mine is
| to keep ORM use to the simplest of query. Anymore complex
| than that is better to be developed with raw queries, which
| also usually supported by the ORM.
| unfocussed_mike wrote:
| Passport is the only bit that makes me nervous, because of
| one over-broad exception that it raises that I don't really
| like. I accept that the action from that exception is the
| same in each case but I'd rather it broke it up into more
| than one.
|
| The rest of Laravel I have no complaints over; compared to
| Rails it is a model of pragmatism.
| ceejayoz wrote:
| This doesn't match my experience at all, and given Laravel's
| popularity... this comment would be a lot more valuable with a
| _why_.
|
| I will say I opt out of the starter packs and Laravel Sail
| (their Docker-for-dummies basic setup) in favor of a more
| bespoke setup, but my Laravel experience has been great
| otherwise.
| rob74 wrote:
| Not the OP, but one thing that stands out for me is the (lack
| of) quality of the documentation. It reads more like a book
| (that tries to explain how to do things) than a reference (an
| exhaustive list of all classes, methods, parameters etc.).
| Ok, it's nice to have the former, but the latter would be far
| more important!
| dabernathy89 wrote:
| It's actually not unreasonable to expect something that
| exists between the main documentation and the automated API
| documentation. Sounds like a great idea for someone to
| build and contribute back to the community!
| raziel2p wrote:
| If you think so, it's available here:
| https://laravel.com/api/master/
| vanviegen wrote:
| That _does_ seem very, uhh, minimalistic, if that 's
| supposed to be the reference documentation. Just one very
| short sentence per method. Most arguments are
| unexplained. No examples that I could find.
| yurishimo wrote:
| I'm not sure what you're trying to find. The main Laravel
| docs are fine for 90% of what you would want to do. If
| you're digging into the core of some internal class
| trying to decide if you can re-use something elsewhere,
| that seems edge-case-y.
|
| The ORM, relationship model, templating, and routing are
| all thoroughly documented in the main docs. If you want
| to find out what obscure methods might be available for
| your custom package, you're probably competent enough to
| parse the auto-generated code docs or read the source
| directly (which is also very clear and well organized).
| bdcravens wrote:
| Does Laravel have anything akin to the Rails Guides? (ie,
| higher level based on what you want to do, rather than
| API-level documentation)
| ceejayoz wrote:
| https://laracasts.com/
| masterof0 wrote:
| Checkout Laracasts, Jeffrey Way is pretty good explaining
| things. I don't use Laravel (or PHP at all),but I do like his
| video tutorials a lot. I say this, because maybe is you the
| docs, or you cant find a way of doing something, etc...
| munk-a wrote:
| When learning cool bird facts I really enjoy listening to
| people talk - but when trying to debug or learn a new
| framework I absolutely insist on written documentation. I
| need to be able to re-read paragraphs or segue to other
| topics briefly and then return which is incompatible with
| anything audio-visual. The existence of Laracasts was
| actually a strong disincentive for me to go with Laravel and
| I've been quite happy over in Zend/Laminas land.
| ricardonunez wrote:
| I think I know where you are coming from. The first time I
| touched laravel was somewhere 2016-2017. I loved the way you
| got started and using valet got your app up and running a few
| minutes. Recently I wanted to do a quick project and noticed it
| is getting bloated. You have multiple paths you can follow
| instead of being straight forward. It adds to the learning
| curve. It is ironic because some of this new things were
| supposed to make it easier to create an MVP, but what happens
| is that it makes it harder to learn how the framework operates
| and integrates with all the new features.
| PZ81JUXJE7uJ wrote:
| Given the success of the framework, you just might need sone
| more time before it clicks
| KerryJones wrote:
| I've been programming in PHP since ~2000, I've created giant
| systems with vanilla PHP, Kohana, Code Igniter, WordPress, and
| for the last ~8 years, Laravel. It's been a dream to work with.
|
| I, like others, am curious about what your actual complaints
| are more than "I hate it".
|
| As others have said, its opinionated, but its opinions tend to
| be strong ones with good data. It is also extremely
| customizable, with a smaller learning curve than most other
| frameworks and a richer community and documentation that the
| vast majority of frameworks.
|
| If I were to hazard a guess, you're running into your opinion
| being counter theirs?
| mattl wrote:
| I'm curious what you don't like about it. I work with a team of
| people who love it.
| porker wrote:
| Facades is the one that comes up every time I ask this
| question.
| ceejayoz wrote:
| Which is a little silly, as you can avoid them entirely if
| you don't like them, and use the dependency injection or
| helpers instead.
| hackandtrip wrote:
| What would you suggest as idiomatic server code which is not
| Laravel, in PHP?
|
| I had the "pleasure" to work a bit with a PHP legacy server
| written in Laravel, and I thought that the framework was
| alright - the problem was in the PHP code written with it
| (specifically its typing). I think laravel is opinionated and
| can help to have a consistent codebase... curious to know why
| you had such a bad experience, and where you were happier :D
| dabernathy89 wrote:
| This is a wildly unhelpful comment without additional
| explanation. My guess is you're doing it wrong.
| phplovesong wrote:
| I thought Laravel was dead. Well looks like some people still
| like to use these slow and bloated frameworks. I cant say i miss
| the PHP ecosystem of bloat.
| FinalBriefing wrote:
| I'll take the bait.
|
| Laravel is far from dead; it's more popular than ever. The
| older versions that you might be familiar with have seen a lot
| of improvements over the last couple of years. They're fairly
| aggressive with deprecating older versions of PHP, while still
| supporting LTS versions.
|
| Its ecosystem is really flexible, and generally has great
| solutions for anything web-related with easy configuration. I
| haven't found Laravel to be slow when building websites, but we
| always put a CDN in front of it, so it doesn't really matter
| how fast or slow the framework is.
|
| If you want a lighter-weight core to start with, there's Lumen,
| which is designed to be an API-only version of Laravel. Forget
| templates, just return JSON (or whatever).
|
| Laravel is a great solution for a lot of websites and
| applications. Maybe not some applications you have in mind, and
| that's ok. Pick the right tool for the job. As someone who used
| to hate PHP, modern Laravel would be my go-to if I need a
| backend and can't simply get by with a static site generator.
| igammarays wrote:
| As a solo bootstrapped SaaS founder that literally relies on my
| app to pay my rent and food, I owe my sanity to Laravel. I've
| been doing web development for 10+ years. Nothing else
| understands the needs of a business owner AND solo programmer
| like Laravel does.
|
| I worked with Python (Flask/Django) for (4+ years) longer than I
| worked with Laravel (only 1 year), and yet I'm already 10x more
| productive in Laravel than I have ever been in Python.
|
| Software projects follow Conway's Law, i.e. [1] the software
| architecture reflects the team structure. Laravel reflects the
| needs of business owners and one-man-companies because it is
| built by a business owner and has an ecosystem supported by one-
| man-companies who build high quality products for profit. I want
| beautiful high level abstractions AND a theoretically sound
| framework that is battle-tested in production. Laravel gives me
| both.
|
| The number of headaches that Laravel just solves for me, out of
| the box:
|
| 0. Background Jobs/Queues/Rate Limiting/Retry logic handled by
| the excellent queueing framework
|
| 1. Rock solid server deployments/DevOps handled by Laravel Forge
|
| 2. Seamless version upgrades handled automatically by Laravel
| Shift
|
| 3. Backend-agnostic full-text search built into the framework
| with Scout
|
| 4. ORM which seamlessly enables caching, lazy loading, advanced
| subqueries, dynamic scoping, or just mixing in raw SQL when you
| need it
|
| 5. And there's just so much more. I live and breathe Laravel.
|
| [1] https://en.wikipedia.org/wiki/Conway's_law
| pooya72 wrote:
| I love hearing about developer experiences by solo devs. As a
| potential solo dev, I was actually looking to go the Spring
| Boot route. I think Java has gone in a better direction the
| past few years, and I prefer it over PHP due to static typing,
| functional programming (to a point), and the tooling. Spring
| Boot seems to provide a lot of the same development
| productivity. My only other experience is with Rails and
| Django, although those have been with small projects.
|
| I always find these technical decisions to be difficult to
| gauge when you're starting off.
| rahkiin wrote:
| I also find these decisions very hard. I switched from NodeJS
| to Spring Boot some 5 years ago when I found that the JS
| community moved faster than my clients could pay me to keep
| up to date. It has been great to make apps in Java with
| Thymeleaf, until I wanted to add dynamic frontends (a lot of
| advantages vanished) or when I tried to put Java on my CV. I
| am now considering switching to .NET and Angular.
|
| I would be happy to have a talk on this topic: what
| directions to take as solo-dev. I find that a whole different
| set of requirements apply.
| pooya72 wrote:
| Hey that's fantastic. I'd love to hear more! You went 5
| years in the direct direction I want to go (Spring Boot +
| Thymeleaf). I'm a bit confused why you were having
| difficulty finding work with Java. Seems like there's a lot
| of Java work out there.
| rahkiin wrote:
| What I found, and I may have been wrong, is that there is
| a lot of Java work but if you look deeper it is hardcore
| Java EE with all thise 200 levels of Java that a lot of
| folks fear. And so do I. Even jobs that had Spring Boot
| asked for the JavaEE experience.
|
| Could be just me though.
| mgkimsal wrote:
| I don't think it's just you. I came off a java gig about
| couple years back - typical enterprise... stuff. Lots of
| legacy stuff from 10-15 years ago that few people knew
| anything about, mixed docs, some tests, but not useful to
| learn from. Even pre-covid, far too few people for the
| size of the codebase and where they were trying to go. I
| started in October, I was given a ticket in November that
| someone else - who had left months earlier - estimated at
| '40 hours' in May of that year. This was my first 'task'
| at the company, and ... it took way more than 40 hours.
| It took 40 calendar hours to get a meeting with the PM to
| actually walk me through how to set up the bug the ticket
| was about. Some bigwig threw up to my manager that I was
| 'over budget' and 'threatened their client relationship'
| because I was taking so long (on a ticket that had been
| sitting around 5 months before it was estimated, then
| another 6 months before someone started working on it).
| They routinely rejected requests for info on the issue,
| or access to servers/data/etc. So... I went part time
| then, and moved in to something else pretty quickly. I
| know not all Java shops are like that, but it was like
| living in an enterprise cliche.
| jw1224 wrote:
| > As a solo bootstrapped SaaS founder that literally relies on
| my app to pay my rent and food, I owe my sanity to Laravel
|
| I'm in the same boat as you, and I couldn't agree more. Your
| comment absolutely nails it.
|
| Laravel is a pleasure to work with. It takes care of 95% of
| everything I could ever need from a framework. And that last 5%
| is guaranteed to be covered by a high-quality community
| package. (Just look at Spatie, this is all just from one
| maintainer! https://spatie.be/open-source )
|
| Some commenters in this thread seem to take issue with
| Laravel's "artisan" approach... and yeah, sure. Maybe it's a
| bit pretentious. But, whatever. They've earned it. Laravel, its
| ecosystem and community takes pride in being polished and
| professional -- and rightly so.
| unfocussed_mike wrote:
| Medialibrary and the Stripe Webhooks library made me happy.
| iio7 wrote:
| https://phpthewrongway.com
| tomschlick wrote:
| Ah yes, the world of everyone using a bespoke framework that
| almost always gets rewritten once the original programmer
| leaves a company is obviously the way forward!
|
| /s
| jackconsidine wrote:
| For those here wondering why you'd use Laravel over vanilla PHP +
| MySQL + PDO, a few of my clients had this opinion so I've had
| experience. The Laravel "fluff" saves you from rewriting tons of
| code, helps you write test cases, and makes logic easy to follow.
|
| One of my clients was very anti "needless vendor packages"
| (definitely some truth to this sentiment), but we ended up with
| 14 extra php files reinventing the wheel. I'd opt for the former
| any day.
| dragosmocrii wrote:
| yes, that's basically what a framework is for. but you have to
| follow the framework's way of doing things. most of the time
| that works well. few times, you may be fighting the framework
| to achieve some special cases.
|
| you call libraries. framework calls you.
| jackconsidine wrote:
| Yeah you're right this is kind of the archetypical "framework
| vs not" or "framework vs library" debate.
|
| And I agree there's nuance to that conversation.
|
| IMO, PHP codebases _most_ err on the side of "reinventing
| the wheel" because PHP has since its inception just sort of
| worked, i.e. mirroring directory structure, spitting out HTML
| verbatim etc. So the framework luddites tend to be over-
| represented with PHP projects. Hence my opinion here.
| munk-a wrote:
| I would say that if you're considering frameworkless I might
| suggest Laminas (the Zend successor) as an alternative since it
| allows you to pull in tools in a more piecemeal style.
| Integrating roll-your-own components into Laravel can be
| difficult due to have tightly knit and off the beaten path
| their internal style can be.
|
| I think there are a few quite good choices of frameworks right
| now in PHP and I hope the space remains healthy and varied
| since the different options do cater well to different use
| cases.
| PetahNZ wrote:
| 14 files on the scale of a large app, is nothing?
| jackconsidine wrote:
| Yeah, not a large app. I should have mentioned that it had
| like 12 endpoints total
| pluc wrote:
| The concept of frameworks in PHP predates its package manager
| and its PSR standards. Nowadays you can easily slap a
| collection of libraries together to create your own micro-
| framework that fulfills your precise needs. That is often a
| better decision than to go with a monster like Laravel or
| Symfony which by design aims to be good at all the things,
| instead of good at the things you need. Those frameworks
| themselves usually have individual components that can be used
| independently of the rest of the framework for exactly this
| purpose
| n42 wrote:
| hello, I am in a growth phase startup and have been here
| since the early days. I am speaking from experience about a
| specific type of company and codebase.
|
| if you're planning to scale a team and a company, do not do
| this. stick to Laravel. let your new hires read the docs and
| move on to shipping features.
|
| if I were going to build a solo project, yes, I would
| consider bolting the libraries I want into a high comfort
| codebase that allowed me to move quickly.
|
| there is a massive Laravel talent pool and straying from the
| standard approach just makes onboarding and maintenance more
| difficult. focus on your company's problems and don't be
| bespoke. if Laravel is even in consideration for you and your
| company and your problem space, there's absolutely no problem
| that is worth reinventing the wheel on here
| jonwinstanley wrote:
| If you're pulling libraries instead of using a framework,
| you're basically just writing your own framework. One that's
| simpler but also it's unique so you lose the ability to bring
| in a seasoned Laravel dev that can get going right away. You
| have introduced a learning curve for all new devs that didn't
| need to be there.
| mechanical_bear wrote:
| There is a micro symfony build just for this purpose, as
| barebones as possible, pull in only what you need.
| tomschlick wrote:
| The biggest benifit to something like Laravel is that a new
| developer to your team can step in and know where everything
| should be and how it should generally work without asking.
| There is good documentation so you dont have to write that
| for your foundational code, just your business logic.
|
| A bunch of bespoke packages strung together with no logic
| does not provide that. You can surely look up how one package
| works but its a lot harder to figure out how it all ties
| together.
| munk-a wrote:
| I think this is a benefit from using a framework in general
| and there are some good alternatives in the PHP space.
| yurishimo wrote:
| One of the nice things about Laravel, is that in a lot of
| ways it extends the functionality of Symfony and uses
| many of it's packages under the hood.
| pluc wrote:
| I can see how it's seen as a benefit, but the flipside is
| that you're teaching your developers Laravel, not PHP. They
| assume whatever they do, they do in a good way because it's
| Laravel that does it which is great, but it abstracts
| actual knowledge. It's like if a developer uses SQL
| exclusively through an ORM and DBAL, how much can they be
| expected to know about the workings of SQL performance,
| indexes, etc.
|
| I also find it very interesting that there's no stigma
| associated with "Laravel developers" that focus exclusively
| on that framework and its syntax and way of doing things
| and you have "WordPress developers" who do the exact same
| but are seen as incompetent.
|
| I understand though that there are scenarios in which what
| you want is a guy that knows a framework really well, but
| if we're talking about skills of a developer, I'll pick the
| guy that knows vanilla PHP over a framework specialist 80%
| of the time
| tomschlick wrote:
| Being Laravel focused and knowing what is happening
| underneath the hood are not mutually exclusive. A mature
| developer knows when to stray from the framework when its
| absolutely needed, not when it just seems like a fun
| thing to do. 99% of the time the frameworks predetermined
| path is the right way as its the simplest to maintain.
| sibit wrote:
| Anyone know if/when they'll push these changes to their micro-
| framework Lumen (https://lumen.laravel.com/)?
| ceejayoz wrote:
| My sense is Lumen's eventually going to go away, with the
| heavier built-in stuff moved into optional packages like the
| starter kits at https://laravel.com/docs/9.x/authentication#aut
| hentication-q....
| ceejayoz wrote:
| Update: Yep, straight from the horse's mouth.
| https://twitter.com/taylorotwell/status/1441101127496323080
| unfocussed_mike wrote:
| I really, really need to look at Breeze and Jetstream.
| unfocussed_mike wrote:
| Excellent.
|
| The LTS nature of this release is good news (because presumably
| it involves the Laravel team committing to supporting the version
| of Symfony they use for some components).
| chipotle_coyote wrote:
| Personally, I liked Laravel when I was first investigating it
| years ago, but was always a touch put off by the pervasive "I am
| beautiful, adore me" undercurrent throughout its design,
| documentation, and even comments. I'll be the first to admit
| that's not a rational critique.
|
| Having said that, though, Laravel is relatively unusual among
| major frameworks in that it doesn't seem to have been developed
| in tandem with a real-world project like Rails and Django were
| (e.g., BaseCamp and the Lawrence World Journal's internal CMS),
| but rather developed just to be "a better framework." Each
| successive release of Laravel seems to push even harder at tying
| you up with other Laravel add-ons, some of which are paid
| services. Rails and Django are open-source projects, but Laravel
| is an open-source _product._ Again, not necessarily bad, but
| there 's an increasing feeling that the Laravel commercialization
| model is "give us sufficient money and you'll barely have to
| write any code."
|
| My other nitpick with Laravel is that learning to develop with it
| is often learning to develop _specifically for Laravel_ rather
| than learning to develop for PHP. This is a charge leveled
| against Rails and Django, too, but Python and (perhaps
| especially) Ruby are just better languages for developing DSLs
| in. Laravel has to jump through a _lot_ of hoops behind the
| scenes to do what it does, leaving you with a framework that isn
| 't particularly nimble and design patterns that often aren't
| particularly applicable to the rest of the PHP world.
|
| If you're willing to hop fully on board with the Laravel train,
| none of this may be an issue for you. But at this point I'm not
| convinced that smaller PHP projects, at least, might not be
| better off without frameworks at all. Use Composer to pull in
| specific packages that you really need, and ask "if I can get the
| functionality I need from this package with an afternoon's work,
| is the package bringing anything to the table that I still want"
| before adding them. (Sometimes the answer is "yes," but not
| always, and I tend to be wary of packages that primarily just
| wrap other packages.)
| unfocussed_mike wrote:
| > but was always a touch put off by the pervasive "I am
| beautiful, adore me" undercurrent throughout its design,
| documentation, and even comments. I'll be the first to admit
| that's not a rational critique.
|
| I should add, separately, that after a long career in web-
| development, this kind of reflexive emotional response strikes
| me as practically a survival instinct, so I am not judging you
| for it at all.
| unfocussed_mike wrote:
| FWIW I have never once interacted with Laravel's commercial
| model, or felt that I am being engineered into it. I just don't
| give it another thought.
| chipotle_coyote wrote:
| I haven't interacted with it, either. "Engineered into it"
| would be too strong a phrasing, but it's hard not to get the
| impression Laravel's creator(s) _really, really_ want you to
| use their other services. I mean, compare the menu bars of
| rubyonrails.org, djangoproject.com, and laravel.com: Rails 's
| first links are "blogs" and "guides"; Django's first links
| are "overview" and "download"; Laravel's first links are
| "Forge" (their commercial provisioning service) and "Vapor"
| (their "serverless" deployment platform).
| unfocussed_mike wrote:
| I take your point and I understand that you could get that
| impression looking at the website; they have stuff to sell.
|
| There's also more of a market for some of that stuff, and
| the reason is the huge proliferation of different PHP
| execution environments. PHP runs in more places and there
| are more opportunities to help correct for the limitations
| of those environments (with log monitoring tools and the
| like).
|
| _(Also -- contrarywise as they say -- PHP does _not_ run
| first-class in some serverless environments; you need a
| custom execution environment for PHP in Lambda. So there 's
| an opportunity there.)_
|
| But as a developer experience it is really not
| commercialised at all. I do not look at or think of any of
| those things, and I've not encountered any significant
| upselling. I'd forgotten all about Forge until you
| mentioned it! (And will now revisit it)
| tnorthcutt wrote:
| Just for some context, here's how the items under "Ecosystem"
| on laravel.com break down on free vs. paid:
|
| Free:
|
| - Breeze
|
| - Cashier
|
| - Dusk
|
| - Echo
|
| - Horizon
|
| - Jetstream
|
| - Mix
|
| - Octane
|
| - Sail
|
| - Sanctum
|
| - Scout
|
| - Socialite
|
| - Telescope
|
| - Valet
|
| Paid:
|
| - Envoyer
|
| - Forge
|
| - Nova
|
| - Spark
|
| - Vapor
| chipotle_coyote wrote:
| You left out Nova, which is also paid.
|
| I don't want to come across as "nobody should give Laravel
| money," to be clear. I'm just observing that Laravel is
| essentially a commercial open-source enterprise in a way that
| Rails and Django aren't. Models like this seem to be a bit
| more common in the PHP world. (e.g., Sensio Labs makes their
| money by teaching and consulting on Symfony, Laravel LLC
| makes money from Laravel add-on services, but Basecamp makes
| money from the SaaS applications they're building on top of
| Rails and is not trying to monetize Rails itself.)
| unfocussed_mike wrote:
| Rails very much was a commercial open source enterprise
| when it started out.
|
| It's just that the enterprise was Basecamp and the other 37
| Signals apps. They benefited enormously from the extra
| eyeballs on their framework, not least during the infamous
| _" hey, we built this massive web framework in part around
| the incorrect assumption that GET requests don't need to be
| idempotent and then encouraged everyone to use it"_ time.
|
| They had no services to sell but they had a keen commercial
| imperative.
| porker wrote:
| > not least during the infamous "hey, we built this
| massive web framework in part around the incorrect
| assumption that GET requests don't need to be idempotent
| and then encouraged everyone to use it" time.
|
| Tell me more. I remember when Rails was first released
| but missed that entire saga.
| unfocussed_mike wrote:
| It is so long ago now that I can't even find stuff about
| it on Google -- 2006 I think?
|
| Basically, well after they'd released the framework they
| had to change the Rails scaffolding (and I think their
| own apps) because parts of the scaffolding (CRUD deletes)
| would use GET to do the action that should only be done
| as POST. They discovered it about the time link-
| prefetching was invented ;-)
|
| Basically, browsers were pre-fetching all the clever
| scaffolded delete URLs and destroying records, seemingly
| at random.
|
| I was really impressed with Rails at the time but stayed
| well away from the scaffolded code in production, and I
| was gobsmacked by the idea that people talking about a
| clever, opinionated framework that did the right thing
| and produced magical, clean, elegant code to rescue you
| from terrible alternatives did not understand that GET
| requests should be idempotent.
|
| Edit: here is one bit about it:
|
| https://dhh.dk/arc/000455.html
|
| The unearned high-mindedness of this still makes me
| chuckle.
| [deleted]
| tnorthcutt wrote:
| You're right, thanks! Edited to add Nova (which I think is
| a fantastic product, and is worth far more than the $199 it
| costs).
| blueside wrote:
| for $199, you'd think Nova would be mobile friendly.
| Maybe this has changed? When we tried it last year, we
| were quite shocked it had no responsive design support.
| unfocussed_mike wrote:
| I've just realised that a) I've used precisely none of them,
| and b) Passport isn't even on the list!
|
| I really do need to look at all of this stuff again, because
| I'm very open to not running my own VMs/services for a couple
| of apps.
| aprdm wrote:
| This gives absolutely no context as I have no idea what these
| funny names are :)
| jw1224 wrote:
| Free:
|
| - Breeze: authentication starter kit
|
| - Cashier: payment processing through Stripe or Paddle
|
| - Dusk: automated browser testing
|
| - Echo: real-time broadcasting
|
| - Horizon: queue handler
|
| - Jetstream: application scaffolding
|
| - Mix: frontend asset compilation
|
| - Octane: serverless Laravel
|
| - Sail: Laravel Docker environment
|
| - Sanctum: SPA authentication
|
| - Scout: search engine
|
| - Socialite: OAuth provider authentication
|
| - Telescope: application monitoring
|
| - Valet: macOS developer environment
|
| Paid:
|
| - Envoyer: zero-downtime deployment service
|
| - Forge: Laravel hosting via AWS, DigitalOcean, and more
|
| - Spark: application scaffolding kit
|
| - Vapor: serverless Laravel hosting via AWS
| jonwinstanley wrote:
| Disagree mostly. I've never paid for any of the paid modules
| and continue to use Laravel on a daily basis.
|
| I do feel the docs are a little minimal at times, maybe to make
| them prettier? Could definitely benefit from a little more
| explanation in places.
| [deleted]
| dabernathy89 wrote:
| > Laravel... doesn't seem to have been developed in tandem with
| a real-world project
|
| > other Laravel add-ons, some of which are paid services
|
| These other services are what you're looking for - that's how
| Taylor and the team dog-foods Laravel.
|
| While I don't object at all to the claim that small PHP
| projects can easily be done w/out a major framework, it's worth
| noting that both many components of these frameworks (including
| Laravel) can be incorporated into a smaller project ad hoc.
| igammarays wrote:
| > Laravel has to jump through a lot of hoops behind the scenes
| to do what it does, leaving you with a framework that isn't
| particularly nimble and design patterns that often aren't
| particularly applicable to the rest of the PHP world.
|
| And tell me, do you use React? Talk about jumping through hoops
| just to print HTMl.
|
| Personally I'm very glad Laravel was written in PHP, because:
|
| 1) you can still use raw PHP in the templates if you wish.
|
| 2) PHP Traits allow a very interesting form of polymorphism and
| code-reuse which is especially suited to the kind of business
| logic you find in web apps.
|
| 3) PHP is very much a C-inspired language that was built ONLY
| for the web, so you get access to a lot of low-level constructs
| and a "baremetal" paradigm (passthroughs like system() for bash
| scripts with seamless handling of STDIN/STDOUT) plus a solid
| standard library for the web. The PHP standard lib supports
| everything you need to write HTTP servers: curl_setopt,
| parse_url, FFI for calling C functions for performance-
| sensitive code, date/time/number/currency formatting, global
| variables for cookies and sessions, etc. all out of the box.
|
| For web apps, I'll take PHP over NodeJS/Ruby/Python any day of
| the week.
| munk-a wrote:
| If you want to talk about potentially irrational reasons to be
| put off Laravel: when picking a framework I ended up going with
| Zend over Laravel mostly due to the modularity of the former...
| but also because the wide prevalence of Laracasts made me
| concerned that written documentation would be difficult to use
| and the documentation space of the framework would slowly
| migrate to being half-out-of-date video and audio snippets that
| slowly became more and more misleading and inapplicable without
| being updated due to a lack of motivation.
| tnorthcutt wrote:
| FWIW that hasn't been my experience at all. The documentation
| is great and well maintained. The repo is public and you can
| see all changes here: https://github.com/laravel/docs
| munk-a wrote:
| I made this decision about four years ago and while the
| documentation was well maintained at the time I was
| concerned that the Laracasts would be unmaintained and
| become a source of confusion that talked about no longer
| present features. I was mostly afraid about the primary
| problem with over-documentation: you're introducing a
| maintenance cost which, if you ever stop paying, ends up
| quickly causing more harm than never having had the
| documentation in the first place.
|
| Here[1], for instance, is someone in this very response
| thread talking about how the core getting started Laracasts
| are out of date and they're confused which documentation
| they should reference. This will probably be addressed
| pretty soon (see the comment) but I think this is a very
| real danger with promising to deliver non-text based
| documentation.
|
| 1. https://news.ycombinator.com/item?id=30261801
| hhda wrote:
| Laravel 9 was released today (hence this thread) -
| Laravel 8 is the major version that came out directly
| before Laravel 9. Further, Laravel 9 is essentially
| Laravel 8 with a bump to the dependencies, with most
| higher impact changes coming as a result of those
| dependencies being updated[1]. The Laravel 8 From Scratch
| series has videos as recently as August[2], with the
| What's New in Laravel 9 series already having 11
| videos[3], with the most recent posted yesterday. The
| Laracasts video series are still very much actively
| updated (with Jeffrey, who runs it adding new teachers in
| the last year).
|
| And Laracasts is a 3rd party learning resource anyway,
| with the first party docs all being well maintained.
|
| 1. https://laravel.com/docs/9.x/upgrade
|
| 2. https://laracasts.com/series/laravel-8-from-
| scratch/episodes...
|
| 3. https://laracasts.com/series/whats-new-in-laravel-9
| munk-a wrote:
| I think it's safe to view Laracasts as being "sold" as
| part of the documentation officially accessible - and
| documentation should be ready before a release is pushed
| into public release. I absolutely sympathize if I've got
| the wrong impression of Laracasts (though maybe they
| should be less frequently promoted by Laravel itself if
| that's the case) and I completely understand that it
| takes time to record updated audio-visual tutorials...
| but that's exactly the sort of thing I'm talking about -
| those prominent audio-visual tutorials existing and being
| pretty officially associated with Laravel means that new
| users trying to learn the system have windows where the
| documentation is confusing and out of date.
|
| It seems like an unnecessary risk to have adopted given
| that it's not at all standard in the industry - sometimes
| language designers will give a version specific tutorial
| but they're understood to be unmaintained with the docos
| being the official source... Laracasts are a very
| different thing which appear to be mostly working, but
| seem really likely to dramatically and suddenly become
| more of a danger than a benefit.
|
| One parallel I would draw on is the community effort,
| when PHP 5.3 or 5.4 came out, to purge all the terrible
| advice from StackOverflow. PHP had an issue, its
| documentation on php.net was fine and followed best
| practices, but the StackOverflow answers were often
| _terrible_ like - this will cause a big gaping hole in
| your security instantly terrible. It took a significant
| amount of effort to delete or properly answer these
| sources and since that happened the reputation of PHP has
| hugely improved. Bad documentation existing is worse than
| no documentation existing (but please don't take this as
| an excuse to not comment your code, just be conservative
| in your comments and keep it to a level you can actually
| afford to maintain).
| stef25 wrote:
| Are there any decent docs for Zend at all? I struggled with
| it for years. Simple "how do I ..." questions would just
| bring up nothing. Not from the docs, nor anywhere else on the
| web. Any solution I'd find wouldn't work in my case because
| other parts of my app were built in some incompatible way.
|
| The Laravel docs on the other hand are the best I've ever
| seen and there's a huge amount of community driven guides
| that are mostly decent too.
| munk-a wrote:
| Zend has had some issues in that Zend1 and Zend2 were
| essentially different frameworks since Zend1 was built
| before namespacing was implemented. Whenever googling I'll
| include zf1, zf2, zf3 or laminas in the query to make sure
| I'm looking at the right version. The official
| documentation[1] itself is pretty good and has been since
| zf2 though, since laminas/zend has always been extremely
| modular, there aren't a lot of assumptions around what
| other components you're using, so most of the component
| documentation is pretty self contained. There are also
| resources like the skeleton application[2] that can be good
| places to begin if you're starting fresh.
|
| 1. https://docs.laminas.dev/
|
| 2. https://docs.laminas.dev/tutorials/getting-
| started/skeleton-...
| chipotle_coyote wrote:
| That's not super irrational. :) Laravel does seem to be
| keeping up with their written documentation, although it's
| also occasionally an example of their "See how great Laravel
| is? See? See?" style.
| fendy3002 wrote:
| > I'm not convinced that smaller PHP projects, at least, might
| not be better off without frameworks at all
|
| Uh having experienced the old pre-codeigniter php, I don't
| really recommended it. Without proper controller separation
| (using twig as rendering engine for example) it poses the risk
| for the business logic to be tangled with view.
|
| Not to mention that it's hard to do routing with native php,
| except the simple [folder-path]/[php-filename].php and remove
| the extension requirement with .htaccess.
|
| At that point I recommend to just use a framework instead,
| though arguably Laravel may be too big for some. I don't know
| if PHP has similar framework like expressJs though that just
| handle the minimum requirements.
| jordanmorgan10 wrote:
| I met Taylor a few years ago at a conference we were both
| speaking at. Coming from the iOS world, I had no idea who he was.
|
| "So, what do you work with?"
|
| "PHP mainly", he said.
|
| I replied "That sucks, sorry man."
|
| -\\_(tsu)_/-
| 0des wrote:
| What was his response?
| aarondf wrote:
| That's kind of a mean thing to say. Maybe that's what your
| shrug meant?
| dabernathy89 wrote:
| We're used to it . You're wrong, though!
| jonwinstanley wrote:
| To be fair, the guy is doing alright. His business is booming.
| He probably gets the PHP pity all the time and has learnt to
| deal with it.
| progre wrote:
| _
| danielhlockard wrote:
| I fail to see how this is related at all to laravel.
___________________________________________________________________
(page generated 2022-02-08 23:01 UTC)