Separate the backend from the frontend

[soufiene-slimi]

Hi all,
So I was thinking about separating the backend from the frontend, and this can have many good benefits, especially speeding up the evolution of Backpack.
This will be a really nightmare for maintainers, and will take a huge effort to accomplish, but we will gain a larger community members especially if a popular choice like ReactJS is chosen, so what do you think @tabacitu?

[tabacitu]

@soufiene-slimi this is a very good question, and it's something I've been thinking about FOR YEARS. It has a few components and I'm going to break down my opinion about each one below. Please feel free to contradict me on them or tell me your opinion if it's different in any way - I've been wrong before 😂

Separating the front-end from the back-end (call the PHP routes using AJAX)

I like the idea in principle, but I think it costs A LOT more than it's worth, and it's not a future-proof decision. It would be a HUGE refactoring effort, with extra maintenance burden. And it would only attract new users if (and only if) we also provide front-ends for other technologies (ex: Vue, React, Svelte). Otherwise... we'd get 0 benefits.

More than that, we'd lose all the benefits of using Blade - which I really like. I enjoy coding in Blade much more than I do in Vue.

Refactoring all our front-end using one front-end framework

I think choosing one particular framework, or ALL frameworks, would NOT be a smart idea:

• Choosing one framework would further niche Backpack; It would then only appeal to those who like the combination of Laravel + Bootstrap + React; With a market that small I'm pretty sure Backpack would die; And I don't want that;
• The benefits will be limited to first-party Operations, Fields, Columns, etc. As soon as you use a third-party Backpack addon that needs jQuery, you'll also have jQuery on page. Or Vue. Or React. Or Svelte;

Providing multiple front-ends, one for each front-end framework (Vue/React/Svelte)

Obviously:

• Building front-ends for every popular front-end framework would be a nightmare;
• Keeping feature parity between all front-ends would be HELL;
• Even just a simple thing as keeping each one of them up-to-date would be super-difficult, at the speed at which the JS ecosystem moves and breaks stuff;

So this is a definite no-go.

---

And I think all my positions above have one root cause. I just don't think that's the way people should build admin panels, most of the time. Since most of the time admin panels DO NOT provide end-user functionality, it's super-important that the dev:

• builds them super fast
• never needs to rewrite them (for years and years)
• when they need to jump in and make changes years later, they won't dread doing it

This is more apparent when building apps for clients. Example:

---

You build an e-commerce store for a client. You build it using React because that's what you like now. For 4 years you just make small changes and maintenance. Nothing fancy, no new features, they're focused on selling, you're focused on other projects.

Then after 4 years they come back with new ideas and want to add new features, make changes. But... you no longer like working with React. In fact for the past 2 years you've worked exclusively with Svelte. Going back to using React will seem old and unproductive now.

How difficult would it be to convince your client to pay for rewriting the admin panel from React to Svelte, because now you no longer like working with it? Super freakin difficult, because it adds NOTHING to their business. So what you did by choosing React in day one was pigeonhole your futureself to always working with React on this project. Even if you no longer like it.

---

This is a real-world scenario that happens more often than we like to admit. And it's taught me to NOT chase the next potentially greatest framework. When I choose a stack for a client, choose it for the long run.

Of course, I'm not saying Vue/React/Svelte don't have their place:

• In a fast-paced startup environment with a few developers, all proficient in that framework - excellent match.
• When building a side-project, where you're the sole decision maker, go wild.
• When building a microsite or something that will only live for a few months maybe a year, choose whatever tech you want.

I'm just saying admin panels are not their place, most of the time. When you potentially work 2 months now and 2 more months only after 4 years... you gotta be extra freakin' careful that your decisions today do not make your life difficult in 4 years. You gotta choose a stack you're going to be happy with in 4 years... 5 years... maybe more. This is probably a conservative or personal way to look at it, but judging by my JS preferences in the past:

Do I know that in 4 years I'll still prefer using Laravel? Yes, I'm pretty sure.
Do I know that in 4 years I'll still prefer using Vue? Not really, no...

(it'd be super-interesting to how others would answer the two questions above; I'm guessing similar but I don't know that)

To sum it up - I don't think it's smart to choose a particular front-end framework for your entire admin panel. Just like I don't think it's smart to make your admin panel a SPA. They have their place, but the 90% use case that Backpack tries to cover... that's not a good place for them. Backpack should keep a minimal stack, add stuff on top if you want to, but don't make decisions for the developer that we ourselves aren't sure we'll agree with in 4 years.

I think this is what makes us different from other admin panels. We don't try to be a niche solution. We try to be a general solution. A solution for the 90% use case. A solution for those that build apps (and admin panels) for clients. And in those use cases... I don't think you should pigeonhole yourself with a JS framework.

---

That's why the plan for the next version of Backpack is to have reusable components, with as little JS as possible. And the JS we do provide to be vanilla JS. Framework-agnostic. That way:

• if a dev wants to put Vue on top of it to make his custom code Vue, go at it; (just like now)
• if a 3rd party addon wants to use Vue/React for a custom field, go ahead; (just like now)
• if you choose to write custom React components now, in 4 years when you will no longer prefer React... then you'll just have to rewrite your custom components; you don't have to choose a different admin panel; or rewrite the entire admin panel;

I think our job as Backpack maintainers is to make admin panels quick & fun to build - but also quick & fun to maintain. And I think choosing a particular framework goes against that.

That's why we don't plan to do it. I'd be interesting what you think though, since you're the one who raised this question 😀 And what other Backpack devs think, of course.

[jcastroa87]

Hi.

Due to not activity on many years i will close this discussion, if there is needed feel free to reopen or create a new one.

Cheers.