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

181–190 of 262 posts

Re: Laravel 9

#181

Post by XCSme »

unfocussed_mike wrote: post #174
XCSme wrote: post #168

Earlier quoted context omitted.

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

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?

Re: Laravel 9

#182

Post by munk-a »

XCSme wrote: post #65
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…

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 'dbcon…

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

Re: Laravel 9

#183

Post by philo23 »

jonwinstanley wrote: post #166
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…

I doubt the routes are evaluated with regular expressions on every request, more likely it’s matched based on an explode of /

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

Re: Laravel 9

#184

Post by jstummbillig »

e12e wrote: post #137
jstummbillig wrote: post #132

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?

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.

What requirements does Laravel meet that Rails does not?

Re: Laravel 9

#185

Post by pooya72 »

_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 Django, although those have been with small projects.

I always find these technical decisions to be difficult to gauge when you're starting off.

Re: Laravel 9

#186

Post by munk-a »

hhda wrote: post #135
munk-a wrote: post #116

Earlier quoted context omitted.

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

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…

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

Re: Laravel 9

#187

Post by XCSme »

munk-a wrote: post #182
XCSme wrote: post #65

Earlier quoted context omitted.

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 'dbcon…

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…

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

Re: Laravel 9

#188

Post by fendy3002 »

chipotle_coyote wrote: post #70

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…

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

Re: Laravel 9

#189

Post by rahkiin »

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…

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.

Re: Laravel 9

#190

Post by ceejayoz »

ceejayoz wrote: post #118
sibit wrote: post #31

Anyone know if/when they'll push these changes to their micro-framework Lumen ( https://lumen.laravel.com/ )?

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#authentication-q... .

Update: Yep, straight from the horse's mouth. https://twitter.com/taylorotwell/status/1441101127496323080
Post reply on HN