Live data from Hacker News

Lumen – A micro-framework by Laravel

laravel-news.com

71–80 of 116 posts

Re: Lumen – A micro-framework by Laravel

#71

What Rails is to Laravel, Sinatra is to lumen. Nothing more than another copycat idea from the ruby/rails world.

This attitude, the illusion that RoR is year zero in software development is the #1 reason why Rails has become toxic for many companies.

Hordes of hipster RoR developers making the same mistakes all over again because they refuse to learn from mistakes already made by others. Turning project after project into an unmanageable mess with a marginal life expectancy because they believe their superior elegant language and one-size-fits-all opinionated framework means they don't have to think about architecture and design.

In all my years I've never seen a developer movement piss away its initial success so rapidly as the Rails community.

Re: Lumen – A micro-framework by Laravel

#72
post #8

Looks nice, I really like Slim Framework, this looks a lot like Slim from what I could tell. Gonna be interesting to see how (if at all) this will effect some performance focus from the Slim developers.

I completely agree. I've used Slim in lieu of Laravel for a number of small API projects. I'm excited about porting them over to Lumen.

Have you ever tried Flight, http://flightphp.com? It has a smaller footprint than Slim but still has the ability to drop in PHP components. Disclaimer, I'm the author of Flight.

Re: Lumen – A micro-framework by Laravel

#73
post #64

As someone who develops/maintains many high-IO requirement PHP microservices (as part of a service-oriented architecture, or, SOA), I'm torn on this one. Laravel is one of my favorite frameworks, especially since 5.0 given its noble attempt to adhere to contract-first/interfaced development and many best practices that in some ways prevent the "worst" kinds of code from being written. It's not static typing, but it's…

I guess if the micro service is using a bunch of shared code from a Laravel project (maybe just interfacing with the database) or if your team is large and already using Laravel, then the first step of optimizing a service into a 'micro service' is to use Lumen. Then step two (if Lumen isn't going fast enough) is to go raw PHP as you described. But if your service is getting that popular, memory leaks are going to be…

Yes! Haha I realized that when I'm working double the hours without noticing, because the challenges are finally unique enough to be interesting :)

I think you hit the nail on the head again too, since frameworks as a philosophy don't intrinsically value shared-nothing (SN) principles which is the other 'dimension' to scalable concurrency--from a devops perspective, anyway.

And while there's never complete isolation, minimizing that interdependence makes your builds that much more environment-agnostic, and easy to provision dynamically.

Honestly what I'd love to see is a kernel-up PHP environment/container that doesn't focus on runtime in isolation, but the entire TCP stack from syscntl to the webserver (h2o?) and maybe even with some experimental support to extract frequent commands to compiled modules with C headers.

But by that point you'd probably just be using Go or Haskell because that's what compiled, statically-typed languages are for ;)

Re: Lumen – A micro-framework by Laravel

#74
post #64

As someone who develops/maintains many high-IO requirement PHP microservices (as part of a service-oriented architecture, or, SOA), I'm torn on this one. Laravel is one of my favorite frameworks, especially since 5.0 given its noble attempt to adhere to contract-first/interfaced development and many best practices that in some ways prevent the "worst" kinds of code from being written. It's not static typing, but it's…

I'm a php dev (amongst others) and I use it everyday at work but if I'm getting to the point where lumen or something like it is the bottleneck I'd just dump PHP altogether and go to a compiled language.

There is a niche I think for faster than laravel but not incredibly optimised, its another tool not the tool.

Re: Lumen – A micro-framework by Laravel

#75
post #64

As someone who develops/maintains many high-IO requirement PHP microservices (as part of a service-oriented architecture, or, SOA), I'm torn on this one. Laravel is one of my favorite frameworks, especially since 5.0 given its noble attempt to adhere to contract-first/interfaced development and many best practices that in some ways prevent the "worst" kinds of code from being written. It's not static typing, but it's…

I'm a php dev (amongst others) and I use it everyday at work but if I'm getting to the point where lumen or something like it is the bottleneck I'd just dump PHP altogether and go to a compiled language. There is a niche I think for faster than laravel but not incredibly optimised, its another tool not the tool.

Bingo.

At that point you've hit on the essential purpose/elegance of static types and a compiler :)

Re: Lumen – A micro-framework by Laravel

#76
post #28

Earlier quoted context omitted.

Yes, and even more so with https://envoyer.io/ - according to the website a Laravel product.

How is this different from Laravel Forge? https://forge.laravel.com/

Taylor Otwell have replied to a similar question here before: https://laracasts.com/discuss/channels/general-discussion/en...

> They really aren't similar at all. Forge manages sub-domains, Nginx, Cron jobs, SSL certificates, queue daemons, recipes, etc. Envoyer does none of those things. Envoyer is solely focused on deploying PHP applications to multiple servers with zero downtime.

Re: Lumen – A micro-framework by Laravel

#77
post #37

Earlier quoted context omitted.

The same holds true for Silex[1], the Symfony Components-based micro framework. Silex and Lumen look very similar (not only because Laraval/Lumen use Sf Components as well), not only because both use (just as Laravel) Sf Components. Slim 3 seems to move in the same direction of modern PHP frameworks, where you return a response from your controller, instead of setting up some global state (the main thing I don't like…

I've done some projects with Silex and it's not bad but I've found myself losing quit a bit of time because you can never really use most components exactly like in the Symfony standard distribution but the docs mostly show you that way. Also you have to be careful with dependencies version or you're quickly in Composer hell (because Symfony moves forward so fast). Always wanted to compare it with Slim but didn't tak…

>you can never really use most components exactly like in the Symfony standard distribution

I'm glad its not just me. The documentation gave me problems. I started wondering why I didn't just use symfony in the first place.

Re: Lumen – A micro-framework by Laravel

#78
post #14

Earlier quoted context omitted.

Saying "it's the wrong tool for the job" and hating on it are two different things.

And you said anyone using PHP in 2015 is doing it wrong, which given that you don't know what "the job" someone might be using it for, seems to head over to the "hating on it" territory. PHP in 2015 means great frameworks like Symfony/Laravel, high performance with HHVM (and soon PHP7), good package management with Composer, etc. It has made great strides.

It's playing catch-up, and it's severely hampered by its refusal to break backwards compatibility for anything. I did a PHP contract last year after not having done PHP in years. I had genuinely high hopes for it because of having seen sentiments like yours. And Symfony is a pretty okay framework (but not great), Composer is decent, and HHVM is a pretty fast VM. But the language itself has fundamentally not changed at all -- it's still flawed in deep ways, while the developers seem mainly preoccupied with adding as many features from Java as they can. In 2015, I see someone defending PHP and I think they simply don't know any other language.

Re: Lumen – A micro-framework by Laravel

#79

Earlier quoted context omitted.

Nobody uses FTP for deployment anymore, but the idea is still the same: just get the file to the server.

You mean that you think it's not hip to use FTP? Because people definitely still do this.

No, I mean that using FTP is the wrong/insecure/slow way to do it. SFTP at a minimum, please.

Re: Lumen – A micro-framework by Laravel

#80

Earlier quoted context omitted.

I'm a PHP developer that works for a major media company. We do large scale deployments, and I'd like to say that PHP is a terrible language that gets a bad rap. It's getting better, and it's already 1000000x better than the PHP4 days, but it's still not a nice language. It's not a nice runtime. The only thing nice about it is that a zillion people and their dogs all know it and it's relatively easy to deploy.

Do you use an off the shelf framework or CMS?

We use Drupal.
Post reply on HN