It stores plugins as strings in the database, then pulls those strings back and evals them as PHP on requests.

"Better coded" is very much a subjective assessment.

There are pretty much two usage patterns that come up all the time:

1- automatically add bearer tokens to requests rather than manually specifying them every single time

2- automatically dispatch some event or function when a 401 response is returned to clear the stale user session and return them to a login page.

There's no reason to repeat this logic in every single place you make an API call.

Likewise, every response I get is JSON. There's no reason to manually unwrap the response into JSON every time.

Finally, there's some nice mocking utilities for axios for unit testing different responses and error codes.

You're either going to copy/paste code everywhere, or you will write your own helper functions and never touch fetch directly. Axios... just works. No need to reinvent anything, and there's a ton of other handy features the GP mentioned as well you may or may not find yourself needing.

This is pretty much what I meant. Even if the browser is what comes up, the fact is the user isn't interacting with the browser as a browser. They're interacting with their phone through an app (voice => search). They don't understand website URLs, or what search engines are doing. That makes it harder for them to return (engagement metrics!) than tapping the icon on their phone that opens up directly to the app.

It's also why so many websites try to offer push notifications or, back when it seemed like Apple wouldn't cripple it, the "add to home screen" or whatever CTA was that would set the website as an icon. Anything that gives the user a fast path back to engaging without having to deal with interacting with the browser itself is what PMs and marketing want.

> And from a product standpoint, there's really only one reason to ship a native app

I have worked on several applications where the product managers wanted to make our web app something that could be installed through the app store, because that's how users expect to get apps.

I know people who don't even type search queries or URLs into a browser, they just tell the phone what they want to find and open whatever shows up in a search result.

I've tried pushing back against the native app argument and won once because customers actually reported liking that we had a website instead of an app, and other times because deploying an app through the stores was more work than anyone had time to take on. Otherwise, we would've been deploying through app stores for sure.

Marketing gets plenty of data from google analytics or whatever platform they're using anyway, so neither they nor product managers actually care about the data from native APIs.

I honestly think the single file thing is best reserved for C, given how bad the language support for modularity is.

I've had the inverse experience dealing with a many thousand line "core.php" file way back in the day helping debug an expressionengine site (back in the php 5.2ish days) and it was awful.

Unless you have an editor which can create short links in a hierarchical tree from semantic comments to let you organize your thoughts, digging through thousands of lines of code all in the same scope can be exceptionally painful.