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

171–180 of 262 posts

Re: Laravel 9

#171

Post by jonwinstanley »

XCSme wrote: post #71
ehnto wrote: post #52

Earlier quoted context omitted.

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…

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

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.

Re: Laravel 9

#172

Post by tomschlick »

iio7 wrote: post #157

https://phpthewrongway.com

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

Re: Laravel 9

#173

Post by blueside »

tnorthcutt wrote: post #128
chipotle_coyote wrote: post #117

Earlier quoted context omitted.

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

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

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.

Re: Laravel 9

#174

Post by unfocussed_mike »

XCSme wrote: post #168
unfocussed_mike wrote: post #149

Earlier quoted context omitted.

> as almost all of them do the same thing It's the almost that will get you here.

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?

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

Re: Laravel 9

#175

Post by tomschlick »

XCSme wrote: post #147
e12e wrote: post #141

Earlier quoted context omitted.

Sounds reasonable. (how) do you do testing (unit test and integration tests)?

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

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

Re: Laravel 9

#176

Post by sdoering »

riipandi wrote: post #27
defenestration wrote: post #21

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.

Yeah. Maybe what we love from Laravel isn't only great docs and painless upgrade process, but also the great ecosystem.

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.

Re: Laravel 9

#177

Post by mschuster91 »

doublerabbit wrote: post #66
mschuster91 wrote: post #54

Earlier quoted context omitted.

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

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

Re: Laravel 9

#178

Post by XCSme »

jonwinstanley wrote: post #171
XCSme wrote: post #71

Earlier quoted context omitted.

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

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.

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

Re: Laravel 9

#179

Post by munk-a »

stef25 wrote: post #162
munk-a wrote: post #91

Earlier quoted context omitted.

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…

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

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

Re: Laravel 9

#180

Post by XCSme »

tomschlick wrote: post #175
XCSme wrote: post #147

Earlier quoted context omitted.

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

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

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.
Post reply on HN