> One thing I have observed is that in each silo, there are certain programmers who assume they are the only sane group in the industry. They aren't interested in what problems the other siloes are solving and they assume any solution "over there" they don't understand is bad / decadent / crazy

A lot of coders have realized there's social credit in trashing other programmers. I regularly see comments from people claiming to have a singular custodial spirit for their craft, unrivaled by their peers. There's obviously advantages to telling people that everyone else is holding it wrong.

Then their advice is

- Some niche trick that's completely irrelevant to most situations

- Something that sounds obvious and uncontroversial, but is so broad and vague that it's not even worth arguing about.

And I realize the irony of me making this comment. But I wish we'd get over this phase where everyone thinks they're an expert, and that every bad codebase or slow app was the result of someone who didn't care. I have yet to work with someone who didn't care about their code.

It’s connected with the questions around occupational licensing of programmers, unions, and similar structures which would not be so much about getting paid more but about getting quality up, squashing bullshit, and getting our quality of life up.

Without a cohesive community, mutual respect, and recognition of a shared body of knowledge, we don’t have the solidarity to make it happen.

As for Laravel, I’d say people were making complex applications (Ebay, Amazon, Yahoo) in 1999 —- Google Maps were better than Mapquest, which drew each image with a cgi-bin, but many SPA applications are form handling applications that could have been implemented with the IBM 360 and 3270 terminal.

The OG web was missing a few things. Forms were usually written on one HTML page and received by a separate cgi-script. To redraw the form in case of errors you need one script that draws the form and draws the response and a router that choose which one to draw. You need two handfuls of helper functions, for instance

   <? draw_select($options,$selected_options,$attributes) ?>

As for performance, web sites today really are bloated, it’s not just the ads and trackers, it’s shocking how big the <head/> of documents get when you are including three copies of the metadata. If you are just drawing a form and nothing else, it’s amazing how fast you can redraw the whole page —- if you are able to delete the junk, old school apps can be as fast as desktop apps on the LAN and still be snappy over mobile.

> Laravel is fine. It's not amazing. Like most "Modern PHP" it exhibits a Java fetish and when used carelessly can degrade into an upside-down impression of Enterprise J2EE patterns (but with an almost non-existent type system).

As opposed to Javascript, the pinnacle of tight standards and high quality performative code...

The same arguments that can be made against PHP/Laravel absolutely apply to Javascript equaly, if not more so due to the pretty well know shiny object syndrome issues that many JS devs get caught up in.

Ya this is nonsense. The web is what it is.

You could maybe say "every framework is a hack to workaround protocols primarily designed in the 90's before we really understood the full application of the web"

What 'other' templating thing? I'm assuming you're likely talking about either Intertia or Livewire. Inertia's more geared towards SPAs than Livewire though. Most Laravel devs tend to use JS sparingly - not everything needs JS.

Theres next to no reason why the vast majority of sites on the web would ever need to be heavily reliant on JS. Rendered HTML/CSS with JS being used sparingly for page functionality is a far better user experience. I'll never understand the obsession with JS for the sake of JS.

> Maybe the sheer amount of SPAs out there shows us what we really want from the web.

A distribution and installation system that works on almost any device?

> all mainstream GUI frameworks, including desktop, represent their UIs with a DOM.

If you call every hierarchy of visual items with some kind of layout manager(s) a DOM, then yes. Notably, the D doesn't really apply because GUIs aren't documents, and that's exactly why HTML is kind of awkward for GUI programming: it was initially designed for documents.

Edit: Sibling comment makes the good point that the main difference is that GUIs have mutable state while documents don't. I would add that GUIs also have controls to change that mutable state, which is a more superficial difference, but well, web-based GUIs are still extremely varied in their interaction styles, which not necessarily good.

Not the person you're replying to. I agree with a lot of what you are saying but:

> The most basic reasons are performance (and perceived performance), not only because the require less data to be moved around the internet but also every flow doesn't require full page reloads.

I can't keep a straight face at this one. If there's one thing the web isn't anymore, it's "fast." Presumably what you are getting at is server performance, because it's pushing all the work to the client.

Anyway there's a good talk on this - https://veryinteractive.net/pdfs/ceglowski-thewebsiteobesity...

> > Every web framework is _literally_ a hack to make the web something it isn’t.

> You are clearly talking about things you have no understanding over. It matters nothing if you specify a DOM with a static file or procedural

Don't be so dismissive. This is like the old anecdote about one fish saying to the other, "how's the water." The "something it isn't" is stateful. The web was not designed to be stateful, and every web framework is indeed a hack to work around that.

Thanks for dissecting all this nonsense. Although in all honesty, we may as well be dealing with comedy here: green account, recommending PHP and Rails in 2025 as if that's supposed to solve anything... we're being trolled.