You don't need a frontend framework 

If anyone wants to check out the source code, it's here: github.com/aschmelyun/no-frontend-framework-experiment 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!

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

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

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.

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

HTMX mention 🚀

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

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.

The simplicity of moving all complexity to the backend

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

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.

Denial, Agreeing, Repent, Hope, Extreme hatred My emotions throughout the video:

Seriously this is the thing. We really need to think about the frontend from the other side of the framework.

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.

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.

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.

Very nice video, definitely gonna give HTMX a try after this! 💯 I usually work with React/Next.js, sometimes with Java backend, and used Laravel/Blade and vanilla JS with Alpine in the past for a smaller personal project, but as I didn't structure the components and JS code properly, it quickly became a mess. This approach looks very clear and minimalistic to me, but also quite powerful!

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.

Thank you so much for these explanations. The multi step form is gold 🙏

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.

Thanks Andrew! I'm completed agree with you. Using any JS framework instead of a simplified HTMLX/JS native script costs some hours for a senior developer to build an app but thousands of dollars for companies to maintain - that the foundation of the almighty JS frameworks myth.

I am currently working on a project for the software engineering course I'm taking. I am using Django for the backend (first time) and can only use vanilla JS for the front. The project needs to be a SPA, and my solution to handle this was very similar to what you presented at the beginning of the video. I had only worked with React once in the past, and I found the vanilla JS solution much more elegant for the simplicity of what I am doing. =)

I agree ...we need "dumb termials" (as the browser) or treat them as such we going back to it ...they worked well like the student kiosk stations at the university back in the no internet days ...

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.

Edit: Darn, I called it in the very beginning! The form submit you mentioned around the 2:15 minutes mark - is made more convenient by HTMX, where you don't even have to make the drop-down forms. Any element can send an HTTP request to the backend and you can get valid HTML, and you can use that to replace the table below according to the parameters.

i don't know how to feel about this. on the one hand this feels a lot simpler than dealing with all the state management of the front-end, but on the other i still need things like conditional rendering and good templating ( with support for slots and complex props). i think i need to build a couple of apps before settling on how i feel about this.

Use what you need to get the job done, but nothing more. That's always been my guiding pricipal in development, so I completely agree with what you are saying here.

This is the only way I’ve ever made a Web app and I’ve always felt like a half rate dev for doing it this way so it’s nice to have someone advocating for this method

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.

Agree, HTML is easy. No "translation layers", that's my philosophy in development "Avoid translation, chase simplicity" I presented HTMX to my company literally last Friday and I think we will end up using it because we build the kind of app that you showed (like 90% of people)

I think this method works well for a solo full stack developer. But for teams that have separate responsibilities between backend and frontend, this is not a good idea. In the end, different tech and frameworks exist for different development purpose. But maybe I'm wrong.

Offtopic but.. you have insanely good and clear voice! About the topic: i totally agree and this video showed me i am not the only one who thinks that you don't need a front-end framework for every application.

Shameless plug, I'm working on a form validation library for HTML-first approach, works great with HTMX too. It's called input-validity. No js, just attributes. Thin wrapper around native HTML validation. It can give you nice SPA-like form error messages and changes dynamically while user types.

Today i was having a similar conversation with a friend, and is a little battle of me asking, why you need to recreate HTML to spit HTML to the browser, thanks to make it and know im not alone in this crazy idea. Regards from Patagonia Argentina PS: I'm gonna have to read more about HTMX

I'm building a SPA admin dashboard using htmx and hyperscript. Quick tip, using template fragments (not to be confused with partials, which are also useful. Actually the terminology is a mess and different languages and engines use these interchangeably, htmx has a good article about fragments) can make you html files more dry and convenient to work with. Also scss > css :p

It’s amazing to me that this is basically the way we all used to it it. We always do come full circle

About 5 years ago, and before I knew about HTMX, I did a rewrite of a pretty complex app and the first thing I did was ask myself what would this look like if I move it all to the server. I made a demo and it was pretty good and I was easily able to expand on this demo by just adding more stuff in the back end. The HTML ended up just being a visual representation of my state that was also server side. I had a kind of special JSON object that is used to pass data/HTML between the front end and the back end. Every action the user could take, like entering text, or every time I needed to update the UI (or just part of the UI), this JSON object would contain what is needed. Example: User click's button to show a modal. JSON object post to server with what the user wants to do. Server uses deserialized object, appends the HTML needed for the modal, and returns it back to the browser. Some vanilla JS then looks at the object and adds the new HTML to the page. The CSS for the modal is such that it shows as soon as the HTML has been added... no js needed to show it. When the modal is closed, some js will just remove the HTML from the page again... "closing" it. Now I only needed to manage state in 1 place, the server. I only needed a little bit of vanilla JS here and there. My entire back end was the application... I could run the entire app without viewing any HTML which was great for testing. I had 100% control over how everything worked... i could make anything in the app work exactly the way I wanted instead of having to play by some framework's rules or finding workarounds. When it comes to integrating with other services or exposing data from our end, that was done using a separate service with it's own security. The UI app was it's own thing... you know... separation of concerns... What I came up with was by no means perfect... it's a V1 of sorts. I've spent some time polishing things up since then, but unfortunately I never got the chance to take things further like I wanted to. I'm at a point now where I don't write any HTML by hand anymore... I define what I want and on the other end of a generator I get HTML. The html generator also ended up being incredibly simple to do. We live in a world where some things are popular because they are popular and as a result very few people stray and try and come up with something new :(

I’ve been building websites for a year, everything with a React and tailwind front end. Currently building my first project with Material UI and it has saved hours of my life. I’m never going back to plain tailwind

Front end was so limiting for me, so I had to shift to back end with Laravel to finish the entire feature, then augment whatever interactivity I need with Vue and CSS framework like Quasar.

The same thought for backend Instead of downloading tons of libraries and dependencies to shortcut a http request and some databases connection we write it Specifically in small scale applications It will be great to know what is happening behind the scenes

You can build apps without a front end framework - I have. But it's usually harder to build, slower to scale, harder to read, less performant, buggy and a waste of time. For a simple todo app, you can do whatever you want - but for much larger apps, it's better to use a framework. I recommend Solid js.

You touched on the reason why it might make sense to have an API return JSON instead; if the API is to be used outside of the browser. An application I re-architected had a separate API and web app. They had different code to do the same thing and had all sorts of inconsistencies. I was able to combine it into one using a REST API. However, the funny thing is this seems to be the exception and not the norm. Most web apps are just web apps and don't need or care about a separate API.

nice, remaind me miss time that i working with laravel. i will back to laravel again with your idea here

Simple pages don't need front-end frameworks complex pages where you have dynamic (user created) things, editors complex styles is a pain in the ass to do without a framework. Every front-end app I worked on for example used google material which is kinda available without a framework but it's not that good. And I don't think our backend guys would have appreciated to code js and I wouldn't want to lurk around complex backend business logics for my pretty animations. So just for separating the teams and codebases it's good too. Also if you support multiple platforms js frameworks are a no-brainer. Also if you're into webdev but you don't want to learn server stuff just handling some json-s are fun. I'm grateful that I almost never have to do backend

People who only know react don't understand how simpler the standard web development can be. Most don't need the extra flexibility that frontend frameworks offer. This is a fact

I guess the biggest thing is if you need your backend to serve multiple different types of clients (mobile, web, smart tv(?), etc.) -- then you wont be as able to get away with just sending HTML

I still find for most things, a hybrid setup is great. I maintain that the bar for grabbing a frontend framework of some kind should be very, very low. But that doesn't mean grab the most complex, sexy thing out there. Often, it means making 90% of a site work off a template engine, and when a page would work better as an SPA, HTMX and Alpine can probably handle it just fine. My favorite thing for getting a project off the ground quickly is the ADHD stack. Alpine, Django, HTMX, and Daisy. If your project requires more complexity than that, it'll tell you.

2:13 THIS, THIS, THIS is genius, GENIUS. I should say it again. This is genius.

You are right, I agree with you 100 percent. I am actually interested what you mean by the 10 percent.... do you EVER need to use a frontend framework?

isn't this the same as returning the jsx in nextjs?? please respond i'm curious

Quick Laravel question for you. At the 11:55 mark, whenever you generate the page for each form step, you are putting a uuid into the session. Does this not overwrite and reassign a new uuid every time a step is loaded?

we knew where he was going just from the title with no context whatsoever. long live htmx.

I so want to do this with Go or Java. Nice video!

so we need to modify the backend code if we want to add a pure styling class for a, for example, blue themed instead of green themed dropdown etc. seems perfectly fine for a tiny project for a tiny userbase. if you want to scale, it can get horribly bad.

Thanks for this video. i hope to see the combination of Laravel and Alipine-Ajax

to be fair, svelte's ssr and actions abstractions are pretty great

I think one of the main reasons of frontend is for calculations that can be rendered frontend, without the need for constant calls to server-side scripts thereby dramatically reducing load time. Easier to do with a frontend framework.

my opinion is of no importance (and completely uncalled) at all, but this is the absolute best video on web development of the last five or maybe more years

The latest version on Next.js and React has addressed this specific issue with “use server” and “use client”.

I feel like that you would run into limitations while building a big application. And it's easier to reason with data, rather than pagr fragments. Also work is often split between frontend and backend, and for this you would need to be a full-stack

FORM SUBMITS? What is this the year 2000? /s

Server components in react/next js essentially do what you’re saying, they return the jsx.

How does hmtx works for the part you pass the link? When changing the select value, it loads the response on the table you passed. But how does it loads the whole page when you copy-paste the link?

I was wondering, how secure is this? I mean if a user would edit the address line or the link in the button.. Where and how would you check for these things?

Remeber when we didnt need state containers in the front end? It was awesome.

Counterargument here, before even watching the video: Security vulnerabilities and number of connections. Meanwhile, yes, it is entirely possible to write backend websites, it's not really recommended to do it without any frontend. The reason being that when a user does something on the front end, it makes their machine be troubled, not the server. For example let's say as an example multithreading, it's a lot worse performance wise if you make the server do everything and not the user. Saying backend is needed only is like saying "You don't need multithreading, just use async!" and meanwhile it is true that async is good, etc. multithreading is better if you really want things seperated. As for an "accurate" depiction of your statement tho, "90% of websites can be written in only backend" is partly true. Because if we get it from word to word, that includes your local dentist who will likely max see a few thousand views on their site anyway, not millions, like a microsoft or other page. After watching video: Bruh, i did that with my final project xDDD, created the frontend in php by making different queries, etc. then made the list just generated. Still could've just used ajax tho. I am curious tho, but how would you handle "visual" websites? like ones with for example vanta.js ? or something similar. let me guess, those are the last 10% lol.

It vould make sense on admin dashboard apps, which are already barebones as can be, but does not make absolutely any sense to do on a landing page or anything similar.

Sending HTML to the browser so the remote computer assembles the interface using resources in that remote computer, it is the same logic. A front end logic. Having a front end release work to the back end so is more efficient for more connections.

0:42 because different clients might need the same data but they render them differently. But often this is web only (like you say), soo...

Splitting the frontend and backend improves scalability, and it's a nice separation of concerns. Maybe it could be considered over engineering in some cases, but it's useful experience to have since it's what everyone in the industry is doing, having experience with templates won't get you anywhere. Plus, building APIs is fun :) But I mean if it's a really lightweight website I would probably just use something like Sinatra or Express and call it a day.

Hey man, can you tell me the VS code theam name, and font name? please. I love the theme and font.

For laravel, there are livewire and filament. But I don’t know when businesses will use them, instead of react or vue

At work we have a web app that uses graphql to communicate with AWS using JSON, including the server pushing updates to the client. I think in this case HTMX doesn't make sense anymore.

goated example of why rendering HTML on the server is the best option.

as a Front-end developer I 100% agree with this!

I just render the html from the backend in Django right now because i still didn't learn much about the front end lol, this looks like something i would use but let's be honest, if this is not what everyone is using we can't just go and do this except if it's a personal project, I don't want to write code that nobody understands just because it isn't the main way people connect their backend to the frontend and near coming days i will also stop rendering the html from backend

Using web standards its so good, thats why i like remix

I think you point of view is great. But as a front-end developer I'm completely drilled of making bad software. Sometimes simple solutions are ok, but you can always raise the bar and I really think we should be making better and better (event though, more complex) to improve the internet as a all.

html with little bit of vanilla js to filter it out and we can keep it simple and have the separation of concern too .

This is how it was done in the olden days, all good for simple UI like this but when front end requirements gets complicated it just gets messy, just think about adding a row in a table with a button to do that you have to write html of tr with tds inside like a string append dynamic values inside string and then append everything togather to dom, i just remember how complicated these things where back in the jQuery days

BACKEND dev is king, API should be used for mobile apps.

I have tried with django and java web applications that use jsp, even overleaf, even thymeleaf, but the performance is very bad. It's simply too slow to reload an entire page for a simple request. Also, returning html is called high coupling, because you depend on how the information is structured instead of being able to structure it yourself. Remember that the frontend and backend are developed by different people.

You don't need a framework, the project needs. For small projects you dont need frameworks like Laravel, Django, Angular, or Vue. However, a backend framework can save a lot of time if the project involves a lot of backend work. Same for a JavaScript framework, it can be very efficient for projects requiring a lot of interactivity and dynamic content

I agree with all your explanation. Thanks

I'm learning how to use javascript in emergency mode as i need only a login page and dashboard for a uni project to show data from an esp32. I can not find a single tutorial without frameworks. I don't need them, I only need a graph with two variables and two gauges.

Yeah, but how do you store state and process real-life updates this way? You’re talking about very static websites, which is definitely not 90% of the cases

But but... my "separation of concern 😭😭😭

This is cool, but im wondering how about if a user filled the first form, but on the second form he leave, this will create unfinished data, won't it? or what if he did a typo on the first form, and want to correct it?

I will defend my opinion that JetBrains PHP Storm or any JetBrains product is better than VS Code

This is gold! Back to the basics. New developers think they need React for everything, but no. They think websites started to be made after 2014. 😂

am working on a project right now using django template and htmx its good

What Theme are you using? it looks very nice

im seeing a comeback on this with next with using "use server" in the component.

I hand coded an exhibition stall contact address database, input taker and mail out system in an hour from scratch while sat on the stall using it. And I made it so that public uses couldn’t accidentally resubmit forms by using back in the browser using …. PHP. Just. PHP. Lol. (HTML/css/mysql sure. But it was so simple and straightforward)

There's so much to balance in the modern web. Personally I feel like the only real way to do it right is to focus hard on minimizing dependencies. The point of something like React is almost the opposite- to build things in top of but it only does so much on its own. And to me, that's part of the problem. The goal of a web page should be to do whatever the job is, not to be easy to make.

Only watched the video to hear HTMX mentioned. I agree with everything presented here except with calling "apps" to web sites :D

This was really cool

Now try to use the same endpoint to create a native app or other services?

my only gripe with htmx is you cant revalidate once valid. @13:18

What font/typography are you using here? I want your typog