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

Laravel 9

laravel-news.com

Post reply on HN
Print view View original

221–230 of 262 posts

Re: Laravel 9

#221

Post by cutler »

TimWolla wrote: post #53
ivanhoe wrote: post #41

Earlier quoted context omitted.

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…

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 https://www.techempower.com/benchmarks/#section=data-r20&hw=...

As soon as you throw an MVC framework into the mix with an ORM the much-touted speed gains of PHP in recents years vanish into thin air. That's because with heavy frameworks PHP's shared nothing architecture works against you.

Re: Laravel 9

#222

Post by hparadiz »

laristine wrote: post #216
hparadiz wrote: post #161

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

> 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. The PHP League Skeleton is only for packages . On the other hand, you use Laravel to create full applications so it's not applicable. Even if somehow the Skeleton is so good its structure might be used for applications, we're under no obligation to follow PHP…

It's totally a preference thing which I admit. Personally however I think that all namespaced PHP code should go into src/$namespace. Config and tests directory not withstanding.

Re: Laravel 9

#223

Post by cutler »

porker wrote: post #133
henry700 wrote: post #55

Earlier quoted context omitted.

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.

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

ASP.Net Core runs perfectly well on Linux so cheap VMs are an option now.

Re: Laravel 9

#224

Post by hparadiz »

lowercased wrote: post #206
hparadiz wrote: post #161

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

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

This article has and it's pretty bad

https://voltagead.com/laravel-route-caching-for-improved-per...

A good routing framework would not need to use a cache at all. Mine doesn't and I've built huge platforms with it. I say platforms cause my last big one was a website, 3rd party api, and mobile app back-end all integrated into one thing.

Re: Laravel 9

#225

Post by hparadiz »

fendy3002 wrote: post #205
hparadiz wrote: post #161

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

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

That's actually kind of why I don't like it. Combining a Laravel project with docker makes you end up with multiple env files and it gets a little confusing.

Re: Laravel 9

#226

Post by doublerabbit »

mschuster91 wrote: post #177
doublerabbit wrote: post #66

Earlier quoted context omitted.

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…

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

You have valid points, I disagree on personal preference and so I'll agree to disagree.

I guess what i'm saying is building from scratch makes different happen. I can see the purpose of frameworks but when it comes to a new start-up project, it just feels like it should be built from scratch otherwise you have a project which is pre-made and not really yours. Thats what puts me off from using a framework.

Myself was script-kiddie in the older-generation of the internet era, 15/16. I'm talking 2003. when extensions have .php3 and uploading scripts over 56k took hours. If you wanted a forum, same for a CMS either use a pre-existing platform and used the functionality it provided or built it yourself. PHPNuke, e107, PHPBB all come to mind. However the internet was young, compared to now where technology has evolved and time is less, so I can see where frameworks come in.

Re: Laravel 9

#227

Post by fendy3002 »

hparadiz wrote: post #225
fendy3002 wrote: post #205

Earlier quoted context omitted.

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

That's actually kind of why I don't like it. Combining a Laravel project with docker makes you end up with multiple env files and it gets a little confusing.

You're getting it wrong. PHP's (and Laravel) getenv is getting the system's environment variable. .env is a helper that overrides them. It just helping you setup different env var for each project in same system.

If you're using docker, it's fine to just use docker's env_file or environment value, or use Laravel's .env only if you prefer it.

Re: Laravel 9

#228

Post by lnxg33k1 »

pooya72 wrote: post #185
_xnmw wrote: post #155

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…

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

If your points are with static typing functional and tooling i would give another look to PHP 8/ symfony|Laravel

Re: Laravel 9

#229

Post by benreesman »

0des wrote: post #136
jordanmorgan10 wrote: post #73

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." ¯\_(ツ)_/¯

What was his response?

Making money in PHP is better than making none at all!

Re: Laravel 9

#230

Post by XCSme »

tomschlick wrote: post #204
XCSme wrote: post #180

Earlier quoted context omitted.

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.

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.

Rather than spending hours on writing and maintaining tests that are very unlikely to catch any of the future breaking changes, it is indeed better for me than automated testing.
Post reply on HN