You don't need a frontend framework

Sometimes I feel that web development has gotten pretty complicated. Fairly straightforward applications are split apart with their frontends powered by behemoth frameworks like React, Next, or Nuxt. But, it doesn't have to be that way.

In this video, I show how a basic backend framework (in this case, Laravel) with its templating language, can have full-stack applications built around the engine of hypermedia, the actual HTML in a browser.

It's a strange way of looking at development, but has the potential to remove a lot of headaches, letting the modern standards present in HTML handle the workload, being enhanced at times with a sprinkling of vanilla JavaScript.

The result is an accessible frontend that's fast and scalable, with your data and state built-in. What do you think?

Some helpful links:

- 0:00 Intro
- 0:55 An HTML-First Approach
- 2:04 Refactoring Out The Frontend
- 3:52 Seamless New Data
- 6:40 Introducing HTMX
- 11:05 Multi-Step Form with HTMX
- 15:02 Wrapping Up

[aschmelyun]

Also, let me know if you'd like to see a longer video where I'll actually build a full-stack practical application with Laravel + HTMX!

[dukeofnorfolk]

Javascript devs on their way to install 2.61 gigabytes of dependencies for todo app

[MTLSTCCLTH]

This is great. Is there a React wrapper for this?

[SylvainPOLLETVILLARD]

In the end, it always depends on the app, but the main reason i'm defending client-side rendering is offline capabilities. We shouldn't take internet connectivity for granted, and we can make web apps more resilient to network issues, allow users to continue browsing and interacting with the app after they lose connection for one reason or another. You indeed end up with a more complicated stack, but also reduce the computing power needed server-side, make it easier to implement an effective caching strategy, and the API layer you create for your app in the process could end up being reused by another project: a mobile app, a business intelligence tool, a new front-end for special customers... It happened too many times in my carreer to not talk about it. Be careful about what you claim you don't need, because you might regret it a few years later.

[paulholsters]

It’s not about a framework but about a UI library that saves time.

[razvanfilea]

Halfway through watching the video:
You've just reinvented HTMX

[nonlinearsound-]

And with the upcoming view transitions as a native feature in browsers, we will have nice animations between views without a lot of code.

[MarkVrankovich]

My philosophy has always been to do everything on the server, delivering only rendered html. That is, unless you can prove a certain page needs a lot of frontend rendering, in which case you'd be amazed at how much you can get done with plain Javascript. Keep it as simple as you can, and only move up the complexity ladder if you prove you have a need.

[edhahaz]

The simplicity of moving all complexity to the backend

[_skyyskater]

As someone who did a ton of this before all of the frontend frameworks came out, I can say your estimation of 90% is overstated. Sure, there are cases where backend-rendered templates is the best solution, but for complex web apps, it is not. There is a reason why so many frontend frameworks exist and are so popular. You don't want to go back to the old days of manipulating DOM elements by hand all the time for basic things, nor can you re-render the entire dom for every change. That's where modern frontend frameworks come into play -- they manage the DOM for you. All you have to do is provide a declarative definition for the view and the state. Very similar to how PostgeSQL, MySQL, etc. work.

[ivagov]

If the back and front exchange data using something universal, say JSON, the back becomes client-agnostic, it doesn’t matter which client it exchanges data with. We can use such a backend for both web pages and mobile applications, and even to create chat bots. For all this we will have ONE backend. If we strictly tie the backend specifically to HTML and the web, then we will have to create our own backend for each potential client.

It was not for nothing that we abandoned this approach.

[neociber]

I always say: If you are not using a framework you are just creating your own.

For most simple cases is just simple JS, but when you start creating abstractions over that logic it's just other framework at least more slim than just importing React or Vue.

[CrazyWinner]

Now you fetch data from server everytime you change the filter. With react you can fetch once than filter that data without fetching. Not only this method makes backend more complex, it increases the load.

[krtirtho]

Denial, Agreeing, Repent, Hope, Extreme hatred

My emotions throughout the video:

[crugg]

Some of the upsides of frontend frameworks is how fluent the page switches feel + the ability to maintain state (and especially elements, such as audio players) across page switches.
But returning HTML is great too for a variety of reasons. But this is why I love SvelteKit.
For each route, you have the HTML markup, and the server-side code. The initial request is traditionally rendered server-side, and further page switches are rendered client-side. Also comes with things like pre-fetching on link hover which you don't have without frontend frameworks.

[rrraewr]

I mean, for an online crud app sure, but the main focus of frontend frameworks to me, which backend people kinda miss, is more like offline capabilities, stylistic changes with animations and transitions, generating stats and charts with client side data you can edit, mix and match. You can't serverside an offline pwa. There's a lot of use cases for client side js. There's more to frontend than sending a material themed hello world todo app.

[galower]

It is true that this can be accomplished with the backend just serving plain HTML, which is far more performant than using JavaScript to parse JSON and then render it. However, let's not forget the reason we use APIs: to provide an accessible entry point to the data for other clients, not just your frontend client. These clients could be a mobile app or an external library. Making REST JSON APIs allows us to have this architecture which is already accessible from any client not only the browser.

[abdulmlaikalomayri]

I find this really interesting, sometime we should stop diving into technology just because it's trending or has a fancy name and start asking what the problem that we are trying to solve in a simple way, without needed to add another complixty layer which make the project overwhelmed.

[burdenedbyhope]

this kind of title draws attention, that’s what content creators need. The correct title should be much less appealing: “for a very simple webapp, you can still you html and vanilla javascript”

[manonthedollar]

As an olde webmaster who stopped paying attention after the LAMP days: you guys *haven't* been doing this??