Hacker News Reader

Comment by owenwil | Hacker News Reader

I've actually been really impressed with Laravel after switching back to PHP for a few projects. Not only is the developer tooling experience some of the best I've experienced, it's just really the only framework I've ever experienced with a high quality ecosystem of tools—from Forge[1], which makes it dead-simple to deploy a Laravel app into production to things like Horizon, for managing Redis queues.

A great example of this in action is Laravel Spark[3], a first party base for building paid SaaS apps. I built and launched a writing tool, Write Together[2], to the world in under three weeks, payment systems and all, and got 150 paying customers in a matter of a few weeks. One hell of a great way to MVP an idea and build something useful, in a low amount of time.

I'm basically developing two Laravel apps full-time at the moment, and it's the most fun I've had in years...compared to the hellscape of NPM dependencies and other complexities I'm usually bogged down with. Composer, the package distribution system, really needs work and is incredibly slow, but other than that—I'm really happy.

[1] https://forge.laravel.com

[2] http://writetogether.space

[3] https://spark.laravel.com

View on HN

Agreed, Laravel provides the best dev experience in the PHP world.

The funny thing is that Laravel basically took the Ruby on Rails philosophy and applied it to PHP. Just looking at their site it's clear they have a very similar vision: simple, fast and fun. One can always find differences but the basic principles are the same.

IMO this is great kudos to the Laravel guys, whatever language I use I always look for the tooling that follows the KISS principle. In PHP you have Laravel, in Java/SCala you have PLay, etc.

I need to add that, because of the job, I did a lot of PHP, Ruby, Java, Javascript with many different frameworks and I can say that Rails is still the best for me when it comes to dev experience if you need to move fast. Laravel has come a long way but it's still not at the same level of maturity in terms of tooling and ecosystem. As a bonus with Rails you use Ruby which is designed for programmer productivity and fun.

Anyway, whatever language/framework you use just keep it simple, that's the most important decision you can make for the health of your project.

It's funny, I remember when I started working on my first PHP framework, I knew about Drupal, CodeIgniter, Kohana, Symfony and Ruby on Rails. Back then, Symfony was the Ruby on Rails applied to PHP. And I wanted to have a more "php-like" approach to everything. That's when I made phponpie.com (the early attempt).

Fast forward to now. After 10 years there is https://qbix.com/platform . If you're reading this and know PHP / LAMP, I would encourage people here to try it and give me feedback. I've never really spent time growing the community or popularizing it like Laravel. But at every turn, it's made decisions that are as close to PHP and standards as possible.

In particular, the Db module may be better than Doctrine, for example.

> I knew about Drupal, CodeIgniter, Kohana, Symfony and Ruby on Rails.

I was a huge fan of PyroCMS which was based on Code Igniter. I stopped using it when the all of the JS frameworks exploded. I went back last year to check on them and found out they moved to Laravel.

https://pyrocms.com/

The community since then has grown by leaps and bounds. Good to see the Pyro team still out there making a great CMS.

I used both Laravel and Symfony but I ended up with the second. I didn’t like the way Laravel’s ORM has its models structured plus the Symfony PHPStorm plugin is a miracle. Your mileage may vary and this is just me but I never quite understood why people ended up loving Laravel so much vs. Symfony.

I used Silex (the symphony micro framework which was merged back into Symfony), which means I'm now using Symfony. I too prefer it to Laravel. I thinks less opinionated maybe?

honestly its ok to have a different opinion, different people prefer different things.

I feel Laravel is fantastic for Junior and medior programmers, while Symfony appeals more to seniors.

I’m a senior programmer and love Laravel. But maybe I’m a junior at heart ;)

All the worst projects I've inherited and rescued were Symfony. Developed by senior devs that overengineered. I'm sure newer Symfony is better and there's some good stuff out there but as a decade+ senior engineer I like Symfony components but not the framework. Love Laravel and Lumen and also some of the other microframeworks for some things. Enjoying Laravel Nova right now too.

Perfectly encompasses my experience with it as well. The community of Laravel-focused developers is extremely proactive in sharing best practices and very much encourages simplicity.

Yep. Laravel is basically PHP on Rails. They do a great job with it too.

I dunno... Their home page looks like something out of the Panera Bread playbook looking at the homepage. 'Web artisans'? Why is it 'clean' because it has an absurd amount of whitespace and comments of platitudes for the code example?

"Clever" "marketing" language like this is not unique to Laravel, most frameworks use language like it for tag-lines on their homepage. Pyramid, a framework for Python, even goes with the same "artisan" language. They're just trying to be fun, inspiring, etc

From the home page of a few other frameworks:

Django: "The web framework for perfectionists with deadlines."

Flask: "Web development, one drop at a time"

Express: "Fast, unopinionated, minimalist web framework for Node.js"

Pyramid: "You need a Python web framework that supports your decisions, by artisans for artisans."

Why is it clean? Build an application with Laravel and you'll find out. :) The documentation and community are excellent. I've used many frameworks across many different languages, and (imo) it really is very nice to work in.

It's funny how the most negativity comes from people with very little experience, or at least recent experience, in the thing that they don't like.

It’s not funny. People who have bought in something have (1) to rationalize their choice and (2) cheer so the project remains alive and a major contender.

That's not my experience at all. Most developers I know have worked with technologies before and come out saying, "I would rather use something else next time."

They should have used "Laravel: The Framework Thomas Kinkade Would Have Created."

Glad I'm not the only one who thinks "modern PHP" struggles to fit more than a couple of lines of real code on a screen surrounded, as it is, by space-wasting nonsense such as block comments, blank lines and K&R brace style. No wonder people prefer Ruby. Around the time of PHP5 the language ditched its own identity and sought to become the scripting version of Java. Give me back my procedural PHP4.

Lol, I agree their packaging looks a bit different but the contents of the package are basically the same.

Working with both Laravel and Rails will make it clearer that they try to follow the same principles of convention over configuration and programmer happiness :).

PHP frameworks crack me up. They so often claim they're "powerful." What does that mean exactly, who is that language aimed at?

Then there is Laravel, why "artisans?" The word generally means pre-industrial. In my mind, that evokes devs doing edits on live code. Also, "Laravel" sounds like something to do with larvae.

Then there's Drupal, which for the longest time was "community plumbing," which did match the experience of having to call someone in for mysterious specialist emergencies.

The command line tool for Laravel is named 'artisan'. You use it to do everything in Laravel, from setting up controllers/views to seeding databases.

I guess "Laravel - The PHP Framework For Web Scaffolders" wasn't catchy enough.

(Can't edit. I meant the word "powerful," not the language PHP).

I don't like their code and architecture though. The code is ugly because it is built around static methods instead of proper OOP, and uses magic methods a lot. It is not easy to read.

Also, they love to invent their own names for existing things. For example, they named a folder with interfaces as "Contracts", although there are only interfaces.

You are using "Ruby on Rails" as some sign of quality, but if it uses magic and static methods like Laravel, I would consider it ugly too. Also, I remember reading somewhere that they were hotpatching imported modules. Luckily in PHP you cannot do it.

> it is built around static methods instead of proper OOP

The fake case against Laravel that never dies . The truth is found in the docs: https://laravel.com/docs/5.8/facades

> Facades provide a "static" interface to classes that are available in the application's service container. Laravel ships with many facades which provide access to almost all of Laravel's features. Laravel facades serve as "static proxies" to underlying classes in the service container, providing the benefit of a terse, expressive syntax while maintaining more testability and flexibility than traditional static methods.

What isn't fake is that Laravel uses magic methods everywhere, especially in the ORM layer.

There are way too many magic things happening under the hood for my taste.

Magic methods in PHP are very commonly used to help reduce code verbosity - having come from working mostly in C++ I appreciate being able to express things succinctly.

Much more important for code, especially library code is readability

Laravel is moving away from magic methods to using facades, FWIW.

The static methods you are seeing are by and large facades -- convenience methods -- but Laravel is still absolutely "proper OOP."

https://laravel.com/docs/5.8/facades

"Contract" is not a term they invented; it's a term from "design by contract programming," and Laravel enforces the "contracts" through interfaces.

https://en.wikipedia.org/wiki/Design_by_contract

(And, no, they did not invent the term "facade," either.)

If you think Rails is ugly you're going to have to frame this with what you think is beautiful so we know where you're coming from.

Rails does take a lot of established concepts like MVC and mangles them pretty badly, but the Rails version of MVC works well in practice if you're willing to overlook how unconventional it is. The beauty is not in the adherence to dogma, but the day-to-day experience of using it when you know how it works.

It takes surprisingly little code to do some complex things in Rails. I'm working with GraphQL now and it's stupid easy to build out an API with Rails.

Laravel might seem all sorts of "wrong" to someone who has expectations of "how things should be", but the Laravel way, when accepted for what it is, works. It provides structure and cohesion which in the PHP world is in extremely short supply.

There are comparable things with other frameworks too.

For example I wrote a course on building a SAAS app with Flask. It's available at: https://buildasaasappwithflask.com/

It covers everything about user registration, profiles, subscription billing, 1 time billing, invoicing, and about 50 other things you would likely want to do in a SAAS app or any application really.

The course comes with the source code along with 15+ hours of video explaining every line of code in stages, life time free updates and life time support for close to half the price of what Spark charges just for the source code for 1 site license (with the Flask course you can use the code in however many projects you want).

Spark's business model seems interesting though. I don't use it personally but do you just get the source code and nothing else? How do they limit you to 1 site if you end up with a local copy of the scaffolding / code base?

Nice! It looks very nice and complete. I've found this other one in Go lang https://buildsaasappingo.com (I'm not affiliated nor tested it) I think it is a good idea to turn something that you need for yourself into a side income, I've though about doing this same thing myself in a different language.

What can you tell about your experience building this course, is it worth it ? rewarding ? Did you find difficult to promote it ? what are the main channels to adquiere customers ?

And if you don't mind sharing some numbers, how many people purchased it so far?

I'd like to get an idea on how profitable (or not) and personally rewarding are type of courses, to motivate myself and write one of these one day.

thank you!

edit: I'm thinking maybe that was too many questions, sorry if so, you could create a "meta-course" on explaining all these things and I'd buy it! :)))

That's how the course came into existence.

I built a number of SAAS apps (and apps that had similar functionality) for a few freelance clients. Then I eventually thought "hmm, lots of repeated patterns here, maybe I can make this into a course", so then I made the course.

As for the process. Funny you mention it. The changelog just had me on as a guest for their "backstage" podcast last week where we talked about content creation and the process of recording courses. That's at: http://changelog.com/backstage/4

It covers most of your questions but it doesn't cover nitty gritty details on sales figures and revenue. Thousands of people have signed up for the course but I still do quite a bit of freelancing. Freelancing and course creation is my full time job.

I find it really rewarding at a personal level. I just like creating things, but it is a lot of work. It's not just hitting record and being done in 2 days. Expect it to take 3-6 months of full time work to make a course. Then there's having to keep it updated (because tech changes so fast) and ongoing 24/7 support.

Couple people have asked me to make a course on making courses. Maybe one day but at the moment there's still a bunch of technical courses I still want to make, a million blog posts to write (I have 85 draft posts that are unpublished) and some side projects in the works.

wow, serendipity I guess :)

Definitively I'll check the podcast, thanks a lot!

No problem. If you still have questions after the podcast shoot me an email and I'll do my best to answer everything.

Hey thanks for mentioning my book. Like nickjj after building 2 SaaS in Go, I noticed that there were lots of pieces that could be extracted into a library.

I'm currently building another with that library.

Every time I try out Flask, Aiohttp or even Express.js I appreciate more the stuff Django normally does for me.

Django abstracts away a bit too much, if you ask me. For a simple REST API it's complete overkill. I prefer Flask or Falcon[0], in which you don't just get better performance[1] but also a lower level of control.

[0] https://falconframework.org/

[1] https://klen.github.io/py-frameworks-bench/ or https://github.com/the-benchmarker/web-frameworks

Why exactly do you want a lower level of control?

You want the complete opposite; have as many problems solved for you already with battle-tested ways to break out of the happy path when you need to.

Every sufficiently large Flask app becomes a half-assed reinvention of half of Django, except without the hundreds of thousands of eyeballs and man-centuries of bug fixing.

I agree with your parent. When I started with (Python) webdev some years ago I picked Flask, but nowadays I use Django, as it has superb documentation and useful things built-in. In particular I miss the user-management, authentication and authorization in Flask.

Personally I consider Django without any additional apps less complex than Flask with apps (or "plugins" in Flask jargon) to handle basic stuff like auth.

If performance is a concern, both of them are insufficient and I would rather pick another language like Rust, Go or even Java.

I started with Flask, moved to Django, and now at work am back on Flask. It all depends on what you are building; if you are going to need some ORM, standard auth, etc, Django is a no brainer. However if you are going to be building out much of your own idiosyncratic architecture, Flask gets out of your way and avoids including lots of things you don't need.

For performance, we are building some parts of our system with Clojure. It feels extremely well suited, albeit with some initial learning curve.

How are you implementing REST using Faclon if I might ask ? fully custom ? or is there anything like DRF hanging around ?

Dito.

Really well done site for the course. The flow of the single page to the sign up is compelling.

Seem's like it'd have to be the "honor system". They could certainly add somethings to detect the software being used on multiple domain, but you could ultimately remove that if you were motivated to.

Tokens are issued from within the Spark customer dashboard and the token is required in order to pull the repo during install. It’s basically the honor system.

Thanks.

I noticed they have a public repo with a tool that manages a way to download the spark code base.

I'm guessing without a token you can't access whatever code that public tool pulls down, meaning you need an active token to get future updates of the code base? Pretty cool system if that's the case (there's motivation to keep your purchase to receive updates).

I'm not asking to try and rip him off. I was just curious about the mechanism of protecting the download. Sounds like the only real difference here is the download is done over a command line tool instead of a web interface. Other than that, it's no different than serving a protected file?

I believe so. Updates are handled through composer package manager and the process is no different than updating a normal Laravel installation. I've never seen any info about how Spark is protected, so I'm just going off of my personal experience using it.

I cut my teeth as a developer on PHP, back in the 4.3 days before they'd really placed their bets on OOP, and we were dealing with mysql_real_escape_string, needles and haystacks, and haystacks and needles. No PDO, XSS and SQL injections up the wazoo.

I can't say I enjoyed working on any of those projects compared to the kind of stuff I do now (and how much I've learned since), but I've been remarkably surprised by some more recent codebases, despite the architecture sometimes feeling a little over-engineered (Symfony 2, for an outdated example).

It's not the style of code I enjoy writing at all but I've seen some incredibly clean stuff that would put a lot of Rails apps to shame. And I'd take that PHP over a badly maintained Rails app any day.

I wouldn't use PHP by choice still, but I no longer care to be snobbish about it. People are doing some good stuff in it, just the same as has happened with JS.

Modern PHP is light years ahead of 4.3. Not just the ecosystem, but the language itself, the performance. It's really not bad.

> Composer, the package distribution system, really needs work and is incredibly slow, but other than that—I'm really happy.

It's also use abysmal amounts for RAM for some reason. I managed to use Chrome headless for my app with only 512MB, but not Composer.

How long ago was that? There were some issues if you had xdebug enabled, but AFAIK that has been fixed.

Just few months and I did not use xdebug on that server. To clarify it's was just CRUD app on Laravel with few small dependencies on top of it. Composer used like 700MB RAM to install it for whatever reason.

Just today, I had to resize the swap on a raspberry pi so composer could update the dependencies.

I've had fun issues recently where Composer crashed after hoovering up 1.5 GB of memory. (Composer sets that limit by itself on startup, I didn't arbitrarily choose that number.) XDebug was off. I fixed it by telling Composer to use unlimited memory.

I had to raise Composer’s RAM limit last week for a fairly simple Symfony project with less than 10 extra dependencies. I had to up it from 2 to 4 gigs. PHP 7.2.8. without xdebug.

To speed up Composer you can install Prestissimo [1] globally, it speeds things up considerably.

[1] https://github.com/hirak/prestissimo

> Composer, the package distribution system

a package distribution system.

Composer suffers some of the same issues NPM does, IMO: it encourages stuff like 'install dependencies at deployment' and "why write it when you can blindly trust someone else's code".

Not everyone who uses PHP uses Composer.

The vast majority of people using a package manager in the PHP ecosystem are using composer. It makes sense to call it "the" package manager.

I’d argue that the only “the” is one that’s distributed with it, which is PEAR. I’m not saying PEAR is used more or that it’s better, just that it’s the only one close to “default” with the language distributions.

PEAR hasn't been distributed with PHP in well over a decade, and the last commit to the PEAR "modernization" project was in 2011.

PEAR is an abandoned tool used by no one. Arguing for it to be considered "the" package manager is a really weird fight to pick.

I don't like that PEAR by default needs administrator privileges and installs packages into system directories. That's inconvenient because you might have many PHP applications, and each needs different versions of dependencies. What did PEAR developers think? That I will be working on a single app for whole life?

Installing libraries globally is inconvenient for developers. Sadly, most Linux package managers have same problem and do not allow you to install several versions of PHP or Node.

PEAR installation will be disabled by default in PHP 7.4, see https://externals.io/message/103977. It was a good tool, once, but the community has moved on.

pear/pecl are more for installing extensions TO php in my experience, where composer is for installing packages built IN php, so composer is more the defacto community package manager, pear/pecl are useful though when you need to install gmp, gdi, intl, etc on your local dev environment. I don't know anyone who uses pear to install carbon or guzzle, or any other php package though.

I literally know no one who uses PEAR.

I do. I was using it back in 2003... pear/DB. I still have some code from that era that uses it.

Would you use a pear dependency in a new project if you weren't pulling bits in from an older one?

Personally, I wouldn't... I worked with pear and pecl and composer is just far more pleasant to interact with.

I agree... No, I would not. That code is old enough to drive at this point...

actively maintained pear packages can be installed also with composer

Which is literally irrelevant to my point.

Last time I used composer (about 3 years ago) it had a nasty memory leak that eventually meant I had to run the build on a higher specced instance than the actual application. This was mainly due to the ridiculous dependancies of the application, but it was almost a show stopper. Has this improved?

Composer is very useful in penetration testing. Lot's of good information in the composer.json files people keep forgetting to block..

A Laravel or Symfony app operates out of the public/ directory, so composer.json shouldn’t need any blocking typically - it’d be outside the web root.

Yeah I remember the problems with composer. It's good now.

It is not a leak, it just loads too much data into memory so you need about 1 Gb of RAM to run composer update.

Yeah, that's not a thing anymore.

I hear you on composer being slow. One thing I found that works extremely well to speed up composer installs:

https://packagist.org/packages/hirak/prestissimo

Give this package a try, it really worked for me to speed up package management with composer.

In my opinion the framework matters more than programming language. One typically doesn't need the "odd" or "fancy" features of a programming language if the framework is well designed and/or a good fit for the shop's conventions or needs.

No doubt its great, but does anyone know how does it compare to django for saas apps?

Honestly I don't see what's all the fuss about Laravel, especially when you compare it to Django. I mean, you have an admin ready out-of-the-box, and database migrations are automatically generated. Correct me if I'm wrong but, Laravel you need to do those things manually...!

Laravel was fantastic. The first month I followed the tutorial, I was bitter about the complexity, but when it came time to building my back end, it took only a few weeks.

I would recommend.

Laravel is interesting for greenfield stuff. I'm working on a legacy project and we've had a bunch of good times with zend as it allows you to transition to it more naturally piece-by-piece.

kudos to laravel team (and symfony, since IIRC, laravel is built on top of sf bundles)

Reply on news.ycombinator.com