I Really Miss Laravel | Hacker News Reader

I Really Miss Laravel

old.reddit.com

34 pointsbehnamoh14 comments

Serverless, OOP, functional programming, domain driven design, monoliths, microservices, server side rendering, etc... .

All have their different upsides and downsides. But the past 10 years as a software developer has taught me one thing above all; I'm sick and tired of every paradigm shift being sold as a silver bullet.

There. Are. NO. Silver. Bullets.

If you look up ideas or methodologies and they never present both upsides and downsides they tend to either posses limited knowledge on the subject matter or they're trying to sell you their idea.

I still remember a meeting with all senior devs at a large client about pitching microservices deployed on kubernetes. I was the only one to state that we'd be shifting complexity and not eliminating it. My remark was voted to be removed from the report, because it sounded too negative.

Years later, and hearing how terrible it turned out, I'm still shaking my head.

Fashion driven industry.

The best technical skill any senior can have, is to get a feeling when to ignore fashion, and when to actually pay attention to fashion that stays around.

It's true that sometimes fashionable skills stick around. I think of all my past coworkers that dismissed: git, CI, repository branches, unit and integration tests, code review, local development databases, automated deployment, automated migrations, separating display logic from business logic, putting comments in git commits instead of in code comments, and removing secrets from code.

Almost two decades later most is these are taken for granted in mature teams.

On the other hand, some tools and techniques are on a continuum: microservices/monoliths, thick/thin UI clients, schema/schemaless databases, SQL/ORMs, strong+static/weak+dynamic types. A team needs to carefully consider their project to determine what fits best (and it might change over time). None of these are "always the right choice." We have very little science about how to accurately determine the needs of a project, so we get a lot of hearsay and fashion.

To quote from the post:

> The Correct Way [(tm)]

To many people today believe that their way is the only way. But sometimes the boring technology is way better than the latest stuff. Bot to say that boring tech is always better, but asking the question "Wouldn't ... be enough?" is a valid question - and the answer "no" is also valid to it.

As someone who benefits greatly from serverless at a company I started I have to agree on the whole.

I love JS/TS, I really do. I love the syntax, I love almost everything about it. Packaging and commonJS vs ESM are the worst. It feels like black magic and problems take me a long time to fix. In the end I’m not always clear on why there was a problem in the first place.

I use raw PHP at my $dayJob (and have for almost a decade, well I used CakePHP and Laravel at other jobs) and I’ve got to say PHP can be pretty great. Most my annoyance with it comes from specific historical decisions the company (or I) made and not the language itself. Laravel provides a very nice layer on top of the crufty parts of PHP and while it sometimes over-complicates or over-abstracts things I do really like Laravel.

There just are less things in PHP that are “show stoppers”. I hope that things like Deno make wiring the language I love, TS, easier and less of a pain in the long run but today PHP is easier.

Sharing code with the front/backend is really nice in TS and only thinking in 1 language is great. Also serverless, for all it’a downsides, has one major upside: I don’t have to think about scaling almost at all. I know that’s not 100% correct but it gives me a massive peace of mind. My business is very spikey/bursty and so this matters a lot to me. Cold starts suck but once you get going it’s great. Also using Lambdas as “glue” for queue or just little self contained bits of logic does feel like magic. We use it at my $dayJob for things that we need to scale at a moments notice and it works like a charm.

I know you can run Laravel on Lambda but I do feel strongly that it’s not the right move to force a monolith into a Lambda (see also Express). I think serverless requires a custom/no framework because it’s just very different from normal deployments.

Serverless is immediately suspicious just as a name: ofc there s a server, running a piece of code, it s just way less efficient when you need good latency but a lot more when you need giant throughput.

You can do the same with a dump server and a few scripts, and for cheaper. Im sure these people would be shocked to how aws or other cloud vendors implemented it

They probably just use the same Perl scripts like the old share hosters from the late 90s early 00s, but with a complete state of the art JS frontend. ;)

There's a kernel of a brilliant idea to it, but when it's really just marketing speak for spinning up a VM or container on demand, it's kind of a joke.

I completely understand where the author is coming from. I tried to go serverless but the drawbacks are so big that it was a lot easier to scale up my Laravel stack. There are bottlenecks everywhere in tech but bottleneck during development are the worst of them all.

Totally agree but this is improving. SST makes life super easy compared to the Serverless Framework but managing it on your own really sucks.

That said, even with SST it’s hard to beat PHP (or other languages) for DX.

I miss Laravel too. It was the first framework I worked professionally. I feel I was much more productive in PHP compared to TS/Node, and also feel I was more confident in doing complex projects even though I had less experience. It’s like the current stack just changes under your feet. All the SSR going on nowadays appears too complex. I do think bug tech companies influenced downstream players too much. It’s just funny to see modern frameworks stitching code within HTML, it has come full circle.

It’s plaintext and it’s totally ok to put it on a serverless server as long as that is connected to the interwebs.

Serverless means:

- No access to native cron

- Remote database (latency)

- Cold starts

- Function timeouts

- Memory constraints

- Limited runtime

Using Laravel in a serverless environment would introduce the same restrictions.

I hated working in php… the exception to that was Laravel, which was really delightful and sensible.

Reply on news.ycombinator.com