3 ms·

I tried out PHP recently for a project because I have fond memories of it, but didn't end up going with it. I want server side rendering for the SEO benefits, b

I tried out PHP recently for a project because I have fond memories of it, but didn't end up going with it. I want server side rendering for the SEO benefits, but I also want some good 'app like' interactivity on the page. Doing the app like stuff with PHP is possible, but you kind of have to have mirror routines, one to load the data, and other api calls to update the data using whatever binding library you choose. The good client side rendered js frameworks, react/svelte/vue have SSR solutions, but they also have their own servers for enabling SSR - next.js and sveltekit. So if you need SSR, SEO, good client side interactivity - you might as well as used those pre-packaged servers. You also have the added benefit of working in a single language across the stack. Laravel's front end recommendations aren't great - https://laravel.com/docs/9.x/frontend https://laravel.com/docs/9.x/frontend I do like how react packages html/css/js as components and that you get static typing across the typescript to html bindings which makes the code more maintainable. Also react has a pretty good front end component library with MUI. You kind of have to 'kitchen sink' the front end libraries with PHP as there's no compiler to weed out the ones you're not using - plus you need to use a CSS library, and 'bring your own javascript' to utilize them with where MUI includes everything wrapped as components already. Interested in others thoughts on this.

0xblinq 4y ago
You can add any interactivity you want to PHP (or any other server rendered html) using Alpine.js, Unpoly, HTMX, or any other kind of modern approach to frontend JavaScript. It is not anymore a dichotomy between ugly jQuery spaghetti or full SPA Next.js thing.
- bottlepalm 4y ago
  I did consider Alpine, the pro is that it is very light. The con is that the components don’t seem as complete as MUI and not free either. Also the repo activity of next/react/MUI is much higher than PHP/alpine. One thing you want to do is try to choose a stack with the best chance of not leaving you stranded in few years. Also a good set of components so I’m not stitching together random packages that may or may not be under active development. I like next because I don’t want to build a SPA, I want multiple pages that are rendered server side - for the SEO benefits.
  - 0xblinq 4y ago
    > The con is that the components don’t seem as complete as MUI and not free either. I think you're mixing different things here. Not liking Alpine because you don't like the components is like not liking React because you don't like some component library for it. Alpine per se is a perfectly standalone library. I use it for my projects and I do not use their components library. Same I use React and don't use MUI either on some projects. > Also the repo activity of next/react/MUI is much higher than PHP/alpine. If the project is well maintained, widely used, documented and has no evident unsolved/ignored bugs... isn't this a feature? Why do we need things to constantly change? > One thing you want to do is try to choose a stack with the best chance of not leaving you stranded in few years. Also a good set of components so I’m not stitching together random packages that may or may not be under active development. I've worked for companies that, even using popular tools, ended up stranded. One of then with a Vue 2 project which they already "declared" they'd never move to Vue 3 because of all the third party dependencies and own code they had. Same at another job with Python 2/3. So choosing popular libraries, while safer, it's not always safe. On the other hand, when you choose React (or any other "SPA" heavy tool) you will also need to decide on 10s of other libraries. From state management, to routing, maybe a meta-framework, a validation library, an ORM or data access library, some other for doing maybe background jobs, another for translations, another for graphql or your rest API, etc, etc, etc. Any of those can go unmaintained and cause big headaches. I highly doubt anything such as Rails, Laravel or Django will go unmaintained and leave you stranded. Alpine.js doesn't look like it is going away any time soon as it is already pretty popular. Would love to say the same thing about Adonis, but I don't know many people using it yet, although I have big hopes for it. Unpoly, HTMX, etc... are more valuable by their ideas and ideology that by their implementation imho. They're small enough like to maintain it yourself or write your own implementation in a worst case scenario.
    - bottlepalm 4y ago
      I need well fleshed out components, and because of the size of the project and the lifetime of it - something that won’t have to be rewritten because the tech went stale next year. Same with ORM and state management - sequelize and redux seem to be the most active and compatible with next. I had the same experience being stranded with AngularJS. You never know what will be abandoned next, you can only make choices to help minimize that chance.

0xblinq 4y ago

You can add any interactivity you want to PHP (or any other server rendered html) using Alpine.js, Unpoly, HTMX, or any other kind of modern approach to frontend JavaScript. It is not anymore a dichotomy between ugly jQuery spaghetti or full SPA Next.js thing.

bottlepalm 4y ago
I did consider Alpine, the pro is that it is very light. The con is that the components don’t seem as complete as MUI and not free either. Also the repo activity of next/react/MUI is much higher than PHP/alpine. One thing you want to do is try to choose a stack with the best chance of not leaving you stranded in few years. Also a good set of components so I’m not stitching together random packages that may or may not be under active development. I like next because I don’t want to build a SPA, I want multiple pages that are rendered server side - for the SEO benefits.
- 0xblinq 4y ago
  > The con is that the components don’t seem as complete as MUI and not free either. I think you're mixing different things here. Not liking Alpine because you don't like the components is like not liking React because you don't like some component library for it. Alpine per se is a perfectly standalone library. I use it for my projects and I do not use their components library. Same I use React and don't use MUI either on some projects. > Also the repo activity of next/react/MUI is much higher than PHP/alpine. If the project is well maintained, widely used, documented and has no evident unsolved/ignored bugs... isn't this a feature? Why do we need things to constantly change? > One thing you want to do is try to choose a stack with the best chance of not leaving you stranded in few years. Also a good set of components so I’m not stitching together random packages that may or may not be under active development. I've worked for companies that, even using popular tools, ended up stranded. One of then with a Vue 2 project which they already "declared" they'd never move to Vue 3 because of all the third party dependencies and own code they had. Same at another job with Python 2/3. So choosing popular libraries, while safer, it's not always safe. On the other hand, when you choose React (or any other "SPA" heavy tool) you will also need to decide on 10s of other libraries. From state management, to routing, maybe a meta-framework, a validation library, an ORM or data access library, some other for doing maybe background jobs, another for translations, another for graphql or your rest API, etc, etc, etc. Any of those can go unmaintained and cause big headaches. I highly doubt anything such as Rails, Laravel or Django will go unmaintained and leave you stranded. Alpine.js doesn't look like it is going away any time soon as it is already pretty popular. Would love to say the same thing about Adonis, but I don't know many people using it yet, although I have big hopes for it. Unpoly, HTMX, etc... are more valuable by their ideas and ideology that by their implementation imho. They're small enough like to maintain it yourself or write your own implementation in a worst case scenario.
  - bottlepalm 4y ago
    I need well fleshed out components, and because of the size of the project and the lifetime of it - something that won’t have to be rewritten because the tech went stale next year. Same with ORM and state management - sequelize and redux seem to be the most active and compatible with next. I had the same experience being stranded with AngularJS. You never know what will be abandoned next, you can only make choices to help minimize that chance.