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!
Why is that a problem. If it's just a simple todo app then I don't think it's for production anyway so it wouldn't matter what they use. But if it's a big application then they definitely need to keep performance in mind and that's why frameworks are evolving. Vanilla js and big teams aren't a great combination.
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.
You're comment screams to me why JavaScript is the way it is. "Why reinvent the wheel only to do the things I actually need when I can install a while library to do it all" 😂
I think that it's not about framework or ui library, but about reusability. If you do your todo app, surely there is no need to setup a frontend server. But if you write a real project it's better to serialize your data in a convenient format so any other service could use in their ways in the future. Idk what the author was talking about.
Idunno. But then, using ui library, your app looks generic, like thousands of other apps using same ui framework, and winning over audiance is done by standing out. From my limited experience, even when using a minimal framework, as soon as you want to do some custom own twist, you get into a world of pain trying to struggle against that very same framework to even lets say, change the look of your buttons. You get locked in so to speak.
@@aschmelyun Definitely. I hate Apple, but we gotta "give credit where credit is due": Safari was the *1st and only* browser to implement tail-call-optimization for JS. I'm still salty that Chromium didn't implement it despite being part of the ECMAscript spec
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.
React says "global state bad, local state good", and enforces this by making sure that child elements can only access the information that was passed down to them by their immediate parent element. Which means that you'll need to wrap your elements in a bunch of context providers, unless you want to do prop drilling... And eventually you'll think "isn't there a better way?", and learn about Redux, try to read the docs, and not understand a thing besides a reducer being a function that takes a state, an object that defines how to change it, and returns a new state. Then you'll start wondering if you really need React, if handling global state is really that simple...
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.
Mobile app can show HTML as well as desktop or TV which is the whole point of HTML. You have a universal rendering app, the browser, and keep consistent experience across platforms without needing recompiling for different devices.
@@jan.tichavsky coupling backend and frontend code in one repo? Very convenient, Id love to see how frontenders would love it and how you gonna expose your api to third party apps with that, write microservices.
@@jan.tichavsky Are you implying every app should be a website or that every app should utilize WebView? Because there's so many reasons to not do either of those things in so many cases
In my projects I create a api backend and render it with jinj2 on flask using the apis, so I get the simplicity of render html direct from back and have one backend with endpoints for all apps
Well, you do end-up replicating almost all backend on the frontend otherwise... so writing it once, instead of again in another language is more simple.
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'm both using a framework, AND did, in fact, create it (although it does use a few dozen libraries, on both front and back, and the front ones include Vue, which itself is a framework).
well... yes. but that's bcs none of the mainstream libraries do it the way you like. Otherwise, you would use an existing one, won't you? :P The thing we want to optimize is how much code is being executed on the client. Cause.. the browser literally does most of everything already. All these js frameworks as backends... gosh it's like flushing 30+ years of development down the drain, bcs sm1 discovered he can run the javascript vm outside the browser.
I've used jQuery ajax for years. For smaller applications like a CMS or just a frontend application loading content I've developed a slim formula to use just one ajax function to load all the backend generated html content for all the pages. I've even used ajax to pull one html content and then break it using class names and plugging it in different places in the page. To me it couldn't get easier than that. Using htmx or alpine does the exact same thing. We don't need to over engineer simple tasks
The benefit of creating you own framework is that you can cater it to your own needs. A lot of problems are most elegantly solved by just adding new features to the framework, and that's something you can't really do with third party solutions without a hard fork or huge maintenance cost
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.
For web dev I'm just a hobbyist (even though I do software for a living). I made the first version of my hobby project with pure Flask but at a certain point it just didn't cut it any more. It was too hard to improve usability or add interactivity. I was also left wondering how do you do user authentication with pure html? Where do you store the credentials? In a cookie? Doing that stuff by hand is just a pain.
@@markopoutiainen7108 There are ways to do user authentication with pure HTML but it’s not great. You can of course use “modern” features such as XMLHttpRequest and Bearer Auth Tokens with LocalStorage without a framework, and I do. Again that’s not the part I want to outsource, mostly just DOM state changes. Anyway I can turn highly procedural, mutative code into declarative code I will.
@@markopoutiainen7108 You have multiple ways to store data on the user's machine, making it very secure and very easy to manage. There are general in-memory datastores offered by every browser, as well as databases. You should look into browser APIs, there is everything you need.
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.
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.
@@peterszarvas94 But why would I when I can use that time actually work on things people haven’t done before. There’s no point in hundreds of people coding the same thing that’s already been done before
@@crugg idk, maybe sveltkit is not so bloated like react, but some of us just hate using js. you dont need a framework, you can choose to use it, but you are fine without one
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.
Sure, but the point is that not many webapps productively use or even /need/ the features that you mention and actually are just CRUD style apps. Nobody (in their right mind) is claiming that you can or should go write Google Maps or Excel using just the hypermedia approach. Rather, people have grown absolutely sick of being fed the idea that you /need/ an extremely complex fronted / backend approach to write /any/ sort of "modern" web application. The best thing is, you are free to mix and match, combine different approaches for different parts of the application where needed.
YES! couldn't agree more, use javascript for animations etc, you know.. for scripting the browser!? Not for plumming data, agregates, computations and building the entire UI client-side... like bro common.. And PWAs? you can do that easily with a RESTful Webservice or some websockets... there's your "native" feeling webapp for you... Regarding offline anything in the browser.... why? just why? If you need your app to be offline... why did you build a webapp instead of u know.. an app?
Oh I couldn't agree more, which is something that I specifically mentioned in the video. What I said applies _only_ if the application you're building is fairly straightforward in its features and it doesn't require that an external API be available to other clients. Frontend frameworks are invaluable and I use Vue and React on an almost daily basis for a variety of other projects. I just worry that a lot of hype (especially with meta-frameworks like Next or Nuxt) can have people over-engineering projects that could be a lot simpler.
@@MrSofazocker One app that runs on Android, iOS, MacOS, Windows, Linux, and also offers the same experience as a user can get on the web page. Or you can just idk, make the web page vOv
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.
Good point, but it doesn't really work with large data where you'd end up with pagination, still have to request it from the server every time with React
@@maxim_mazurok In general, doing everything on the backend prevents you from having frontend state that isn't rendered, and you have to make another request every time you want to change what's rendered. Sure, if your unrendered data is very large, then that way can be better. But very often it's not, and the extra loading time is an inconvenience to users.
_"With react you can fetch once then filter the data"_ This is the main problem with modern devs lol. You make it sound as if plain old JS / or even a thin library like Alpine JS can't achieve this.
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.
Saying REST and json in the same sentence makes me curl up and wanna die. REST and SOAP was ought to be a standard way to communicate for WebServices, a "special" sort of API by convention that provides a common interface and restricts the return type and uses HTTP as protocol and returns XML. (normally) Like... you have a backend.. that's fine and dandy, and it has an API for other apps to communicate with it.. that's not going away. Buut, what everyone started doing was, "Well since we have an api, why don't we just call that to get the data the frontend needs, and let the frontend render it... oh and while we are writing the client-side in javascript, and make requests validation there, why don't we write the whole backend in javascript as well to share code?" And shit sandwich was made. What you ought to do is, if you want to serve to web, is make a WebService. That response to HTTP requests and spits out HTML to whoever requested it, utilizing the API of your backend. (restricting your backend to REST is also limiting, there are better ways to access and communicate with a backend, like RPCs) Why, and where you need state, or the frontend to handle anything is beyond me. You still have your frontend, you still have all your animations, view-transitions in javascript, client-side....
@@MrSofazocker, you have some really fair points, and yeah, Protocol Buffers are pretty dope. But to be fair, you always end up reinventing the wheel because sooner or later, you end up needing client state to handle different interactions. Not only to display data but, for example, if the user clicks or interacts with (x) button, it needs to show (y) information after (z) time. And while HTMX could handle it to an extent, you might as well have reusable components to deal with it.
Exactly, the point I was trying to make is that there's a whole group of applications which never connect to other clients (mobile apps, libraries, etc). The data flows just from server to frontend, so it makes less sense to build out a full-fledged JSON API for those particular ones.
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”
I have never even been tempted to use front-end frameworks. Doing so would introduce technical debt. And my programming/developing career has spawned 30 years to date, so the statement does not come from a place as naivete and has proven its benefit many times.
I also don't use any front-end frameworks. Plain old javascript fetching and posting data (not HTML) from a server-side REST API seems to work great, as far as I can tell. I find it much simpler to keep all my "look-and-feel" stuff in static html/js/css files, and my server-side just passes data back and forth from the database (or other data source) with security. If I want to make a change in the way things look, i can just edit my static front-end files, and my server-side doesn't need to know or care.
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.
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.
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.
So instead of adding an api call returning the JSON you propose to add an api call to return the HTML. Yes adding the 'x-refresh' can be seen as adding an api call as it is an additional path in your code. If your connection to the server is slow your performance of the app will be affected. You're proposal will also increase the bandwidth usage because you can't cache the answers and sending html is more data then sending the values. The actual problem is the behemoth frameworks, not front-end rendering. IMHO the reason why server-side rendering is promoted by AWS, Google and MicroSoft is primarily for the increase in number of requests and increased payload because that is where they make their money on.
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.
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
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
But that point doesn't apply to a framework like SvelteKit because it feels just like writing normal HTML (because you can). Everything else is optional.
3 місяці тому
Like the good old days as devs use jquery for only $() ... They cant wrote a querySelector.
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.
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
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 ...
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'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.
You can also use a JavaScript graphing library without a framework. Chart.js is perfect for this, and has been around long enough that you can ask ChatGPT or Copilot for some helpful examples!
Front end developers used to just handle the UI but now they have to managae state, make API requests and basically also do the backend's job. The responsibility of the front end engineer becomes too much at some point. It's a bad experience for the developer and unnecessarily complicated design for many websites.
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
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
He addressed that near the beginning of the video. At around 1:41 he says the app will live solely in the browser. Ofc if you need a mobile / desktop / IoT client, then that's a whole other story.
well... lets take Discord for example. their main app is a webapp, works totally fine, their desktop app is an electron chrome browser, works totally fine, their android app? same, IOS, yep, html! So what did you say?
@@FelipeV3444 just bundle a browser with your app lol. Electron hello? Everyone does it, and pretty much the only reason everyone's googling "how to download more RAM." :;D
frontend from backend is awesome, I really want to use it, it simplifies a lot frontend development, but there are some important limitations. 1 - reuse components - there is no one starndard way to reuse components, using template engine is NOT the the elegant way we have in frontend frameworks 2 - reactivity on the client - sometimes we need reactivity on the client, if you push this responsivility to backend, it means that you need one router for each client action, is this can become a mess? if you use some js lib such as alpinejs or vue from CDN, it works too, what do you think? 3 - PWA - even it's possible, but you would have to change the way your frontend is generated from backend 4 - if you have API, you start to negligence your API, because you don't consume your API like external client does, using vue, react etc
@@aschmelyun More like Google found it expensive to crawl Client Rendered Websites. So, the move to full circle was triggered by SEO requirements. With Meta-frameworks like NextJS, Nuxt, Sveltekit, enable SSR. I usually work on apps with multiple touchpoints. So, I can't avoid making APIs.
Nobody's coming full circle. It's just a dumb new fad that will die after a bunch more videos on YT will saturate the influencer bro market. Server-side is limiting, not actually simpler (you're not the one writing the framework, remember), costs more to host.
Oh definitely, I haven't done much in Svelte but the little I've worked with it, it's a great frontend framework. Especially for smaller, tighter applications.
You forget that the reason all UI code is handled on the frontend these days is because: if you remember, you'll inevitably end up with 1, 2, ... 20 Backend developers who "know frontend" and will absolutely rot the project for everyone and blame the frontend developers for not being good enough to work with their utter heinous monstrosity. Frontend devs FINALLY won that ridiculous war after, when they had a task requiring a sturdy handle on the data, telling the backend dev "just make the response JSONP so we can go home". That said, modern CSS is so good now that you might be able to do more without that sturdy handle now. But if it's just you for a prototype product or something than this is great as long as it's more than a static content/flyer site. I could see myself using this approach for certain projects.
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
1:29 Because you want to handle the data as a separate entity from the HTML Basically, take your initial logic: if what you want is HTML, then you should get HTML. So if I'm parsing data out of the HTML that I just downloaded, we've gone full circle. As always, it depends on the application.
The main reason to separate front-end from back-end is speed; your data rendering can be untied from data fetching. The benefit of something like Laravel is security; you have zero chance of an MITM if it's all requests sent to the server and the fully rendered page returned from the server. Just keep in mind that even Laravel (with or without Breeze) is moving to using Vue or React as basis for the UI, separating the two, and the default Breeze implementation even uses the implicit password grant flow for authentication which is pretty bad. If I need to quickly build something there are two approaches; data-first, or functionality-first. If it's the former, I go with Vue and a simple API that returns the data I need. If it's the latter, I would probably go with Laravel, and I may even use Nova to kickstart my application.
But I believe that laravel ecosystem is moving towards livewire, not Vue or React. Even the official livewire documentation is hosted at the subdomain of laravel site itself. I'm betting on this meta framework approach that laravel and next are implementing. This approach will grow at least for a few years until a new cool thing emerges
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.
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.
0:44 - i get it...but in real life you arent really always going to be simply making a table with your entire web app. Youll need to do way more complex things like SPA's, in which case the table example is a very small part of it. I am with you on this example, but when that table is a part of a much bigger responsive app that needs javascript and reaction, imo its way better to use vue, which justifies doing a single file component for that table. I think there's a complexity line in the sand that when crossed, makes more sense to bust out some kind of a framework
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.
no way in hell I am going back 10+ years to a time I was writing php to handle my HTML templates... this sounds OK when you have a single easy page... but unless you are hafing like a landing page dispalying data from CMS... we all know "sprinkle" some JS mantra is going down the shitter... which is in most of the cases. So funny how things are going full circle... like when JS with ajax was starting taking over the BE world... and the "OGs" were like... no, that's laughable, for JS (a joke language) to control our apps... we will never consider this to be anthing but a fad ... and now is happening the same, just backwards. But, I think I was one of the OGs, that never thought that, JS and ajax is a bad idea... jQuery and after SPAs just made the web a beautiful place... that over the years just got consolidated. I think separation of concerns is super important. and I think html templates are part of the DOM and front end stack and has no place being on the backend... But I get it... I mean in Balkan, people say "100 ljudi - 100 cudi" which mean 100 people have different views. To each their own would be the expression... but with all these new frameworks and ways of thinking... it feels like we are getting more divided and we are pulling all in different directions instead of one... (or couple) ... is quite tyring ...
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.
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.
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.
@@username7763 because you can scale each part independently, for example if you're experiencing a heavier load on your backend you can scale that independently. You can also split your backend into microservices and implement load balancing.
@@noided7071 That heavy load will result in more network communication which slows down the system with scale. The more pieces you break things up into, the more network-dependent you will be. This only makes sense in very high cpu-demanding applications which is generally not the case with web apps. They are typically network-bound already. Scalability is incredibly tricky.
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.
The solution is Astro with islands. You built a static page and you can do SSR only in those island components that are built in the static pages without needing to change anything else
Great video, I love htmx The problem with the htmx multi-step form is when the user has a slow connection. Instead of just validating the data on the frontend and then submit on the last step you are always asking for more data making the user with a slow connection having to wait on each step. And the problem is not htmx but the way things are being handled. Still with that I would prefer the htmx way on my personal projects, the developer experience is very good. There is a way to check for slow connections using Javascript Web API Navigator, but I don't know how it behaves nor I know how to use it to make the better of both worlds
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 :(
Congratulations, you've reinvented a front-end framework using vanilla custom JS. I remembering doing similar things back in the day, I have no idea why people pretend now that it wasn't awful. It never scales. You always eventually end up with some corner case that cannot be implemented with "just a little bit of JS here and there". Even the cognitive workload of having to explain your custom JS framework to the next programmer is not worth it. You set yourself up for failure in the future. If the app ends up being insignificant, then who cares how it's written. If it turns out to be important and will be actively developed - it better be written in something that more than one person can understand.
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.
I use an HTMX-like library that is smaller that I created and use it to create offline-first web applications (PWAs). It's worked out pretty well for me and is pretty fast and straight forward to get apps going.
The biggest time save is not needing to implement the same endpoints(s) twice. One for your page and one for your general use api. Among all the other reasons that people have given.
I like the idea of HATEOAS but I believe json back and forth is the best idea, good abstraction one backend to rule them all. The idea of having directives that give html the ability to make calls and hydrate parts of the UI is nice and worth exploring.
What about if I want to change my cart icon's count when I add/remove items? Well, you can do this but that's where the frontend frameworks like react/vue comes into the play.
Keep in mind you need to know a bit about servers and backend. For example in AWS there is an easy way to create a static website or single page application using S3. This alternative requires to create an EC2 or another alternative. And that requires backend knowledge that sadly too many frontend devs doesn't have.
Excellent. 👍. I tried to do something similar with alpine.js but ended up with a lot of JavaScript functions as I had selection dependent drop downs. I concluded that there’s not really a halfway house as I ended up watching for change, sending fetch requests, receiving json, there was not much left in terms of the traditional html method. I’m very interested in what you’re doing here and htmx now after watching this video. It looks legit.
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.
When you mix HTML with dynamic data on a server, your HTML is not cacheable via headers. This is why I like to separate dynamic JSON, and static HTML that can be cached. And then I use EHTML to map JSON response with HTML data and that's it.
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
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?
No, because the endpoint being hit by the form pages is through a different route. It's only the initial load at the /form endpoint does that uuid session get set. This was so I could easily have an 'identifier' and attach all of the page responses to the same data in the database.
@@aschmelyun Yeah, That is normally how i assign multi page forms as well. Was just confused because I thought it was re setting the uuid each time the page route ran. Thanks for the response!
Whaaaat? Where would you have to re-validate something you already sent? Changing anything on the client-side then and there wouldn't change anything on the server!?
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
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
The big benefit with client side code is that your server side business logic is completely decoupled from your UI. I am bias toward JSON and REST APIs at this point. Not because it's"trendy" either. You don't even need a front-end framework for this either. For simple apps, just design an ORM that makes sense, spit the JSON out, consume, and build DOM with jQuery. From here, client has what it needs so no unnecessary requests to the server afterwards
For those debating the necessity of frontend frameworks, it's worth considering the significant advantages offered by meta-frameworks like Nuxt 3 for Vue or Next.js for React. These tools streamline development and, once you grasp the component-based architecture of the frontend, enable the creation of sophisticated applications with ease. If your project doesn't require extensive complexity, Vue and React offer plenty of straightforward solutions. Complex state management, for instance, is unnecessary unless your application truly demands it. Ultimately, the best technology is the one that fits your specific needs. If you prefer to master a single framework, ensure you learn it thoroughly to handle a variety of scenarios effectively.
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
I hate the fact that this needs to be explained and is presented as the "modern" way of doing things when it was the og way of doing things. SPAs have their place, for example a backend for the owners of the website to manage content. For everything showned to a visitor just do it server side
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.
Client-side framework bloat is an issue, but dude, for the data I already loaded to be sorted or filtered I don't need or want to download it again. Making an offline frameworkless sorting and filtering table is somewhere around lesson 2 of JS course though.
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.
I think the issue with this design is the responsiveness -- I'm a backend dev too but if i was in kansas and the server was in virginia, having to do a whole network hop to filter the cars by color could take seconds -- much better in that case to have a longer initial loading time for better responsiveness once the slug is loaded
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.
I use this pattern for proof of concepts when working with customer ideas. Some Go + PocketBase + Templ + HTMX for SSR. PicoCSS or Tailwind for styling. Gets me pretty far for presentation and light usage from a couple hundred users. Let’s be honest, why build an app for 10000 plus concurrent users from the get-go when most apps are glorified ToDo CRUDs.
Build fast and launch fast, I respect it. I've seen a lot of people using the Go + HTMX stack for smaller, one-off applications, and I have to say I'm eager to check it out and see what it's like.
I might be getting it entirely wrong, but the argument is that instead of using frontend frameworks we use backend frameworks that streamline the process of creating the frontend? Hot take, I've been working on many medium/large projects and maintainability of the structure of the project is not an easy thing to keep up, and the fact that the backend and frontend is separated is what makes it more manageable, if I wanted to create a crud application I'd likely wouldn't use a framework and just do it in what I currently like using the most, but anything more complex its just a bad idea to not use the tools available for you, I'm sorry that I say this but things gain popularity and more usage because they work, and they're better than other solution for one reason or another, its that simple, you can certainly say that everyone is stupid and you aren't because you feel this way, but apart from a small app I'd never do this route you mentioned, because it becomes a mess really quickly, or at least that is my experience as a fullstack dev, its not that maintainable, and I wish I never have to work on a project that does this, its trash to work with and the neighbours grass is in fact greener unfortunately.
I don't like to use abstractions over abstractions either but I have been able to develop at quicker speeds with frontend UI frameworks. Having frontend and backend separated also allows people to become specialized. Let's be honest, there are way too many tools coming out now. The amount of time it took you learn developing will be 10x bulkier for a fresh developer.
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!
Hi Andrew, it would be very interesting to see this combination from you as there is no longer video on YT about Laravel + HTMX
i would love to see that.
Yes please elaborate on more complex pagination with numbers instead of only prev and next buttons
Yes, please!
Please do the laravel + HTMX tutorial
Javascript devs on their way to install 2.61 gigabytes of dependencies for todo app
it makes even more funnier that you write gigabyte instead of gb
@@eraysonatbh I don’t think they know the difference between GB and gigabyte 😭
@@AnimeZone247where is the difference ?
@@eyriusbacterius one is an acronym, the other isn’t
Why is that a problem. If it's just a simple todo app then I don't think it's for production anyway so it wouldn't matter what they use. But if it's a big application then they definitely need to keep performance in mind and that's why frameworks are evolving. Vanilla js and big teams aren't a great combination.
This is great. Is there a React wrapper for this?
Yes, NextJS
lmao
Lol
😂😂😂
Astro
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.
only 39 likes wtf?
It is also so simple with SPA and capacitorjs build android and ios app in no time
Exactly. HTML templating is a great way to couple your frontend and backend and make your project a horror to scale.
he literally says "if you're project lives only in the browser".
Some webpages really shouldn't be SPAs. For example SQL query results. Or the news website. Or cinema booking tickets website.
Halfway through watching the video:
You've just reinvented HTMX
What's wrong with that? If it can be done with less library overhead...
@@BrianTakita he never said he was wrong tho?
I mean, HTMX is just a wrapper for working with server-side responses through html attributes, so... yeah, I guess I did!
You're comment screams to me why JavaScript is the way it is.
"Why reinvent the wheel only to do the things I actually need when I can install a while library to do it all" 😂
Halfway through the video, I knew that it was a buildup to introduce HTMX.
It’s not about a framework but about a UI library that saves time.
make your own ui library i guess
@@peterszarvas94 and when would that be useful?
@@paulholsters7932for fun :^)
I think that it's not about framework or ui library, but about reusability. If you do your todo app, surely there is no need to setup a frontend server. But if you write a real project it's better to serialize your data in a convenient format so any other service could use in their ways in the future. Idk what the author was talking about.
Idunno. But then, using ui library, your app looks generic, like thousands of other apps using same ui framework, and winning over audiance is done by standing out. From my limited experience, even when using a minimal framework, as soon as you want to do some custom own twist, you get into a world of pain trying to struggle against that very same framework to even lets say, change the look of your buttons. You get locked in so to speak.
And with the upcoming view transitions as a native feature in browsers, we will have nice animations between views without a lot of code.
Yes! I'm so excited about view transitions. Been seeing a lot of devs showcasing their experiments with them lately, and it's pure magic.
Yes, and we need to wait 8 years, until all browsers support it
@@Garkolym Safari's become the new IE :(
@@aschmelyun Definitely. I hate Apple, but we gotta "give credit where credit is due": Safari was the *1st and only* browser to implement tail-call-optimization for JS. I'm still salty that Chromium didn't implement it despite being part of the ECMAscript spec
@@RudxainGoogle, Mozilla and Apple should really unite and make cool features together.
Many features are available only in one browser
HTMX mention 🚀
I came here just to comment that, lolololol
Same, the moment he starts making partial hydrations of the UI I thought htmx!
Yeah if HTMX team more serious and focus on their project, they can defeat react
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.
React says "global state bad, local state good", and enforces this by making sure that child elements can only access the information that was passed down to them by their immediate parent element.
Which means that you'll need to wrap your elements in a bunch of context providers, unless you want to do prop drilling...
And eventually you'll think "isn't there a better way?", and learn about Redux, try to read the docs, and not understand a thing besides a reducer being a function that takes a state, an object that defines how to change it, and returns a new state.
Then you'll start wondering if you really need React, if handling global state is really that simple...
KISS
@@pierrotlasticot5848 always KISS your homies (good software design practices say so)
Spot on. Don't write things because you can, write them because the data states you need to. Write based on the data, not based on opinions.
why not save money and render everything on the client browser 😏
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.
...and never had the opportunity to change backend, but hey, it's possible
Mobile app can show HTML as well as desktop or TV which is the whole point of HTML. You have a universal rendering app, the browser, and keep consistent experience across platforms without needing recompiling for different devices.
@@jan.tichavsky coupling backend and frontend code in one repo? Very convenient, Id love to see how frontenders would love it and how you gonna expose your api to third party apps with that, write microservices.
@@jan.tichavsky Are you implying every app should be a website or that every app should utilize WebView? Because there's so many reasons to not do either of those things in so many cases
In my projects I create a api backend and render it with jinj2 on flask using the apis, so I get the simplicity of render html direct from back and have one backend with endpoints for all apps
The simplicity of moving all complexity to the backend
It's awesome!
You don't move complexity to the backend, you avoid it completely.
Yes, instead of duplicating it on both the front and backend. And most backend frameworks and languages handles complexity better than JS imo.
Well, you do end-up replicating almost all backend on the frontend otherwise... so writing it once, instead of again in another language is more simple.
@@CristianKirkkinda. You still have to now manage all the frontend in the backend...
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.
Agreed 100%. Once you start putting these "abstractions" all over the place, just reach for a framework (or at least a library like Alpine!)
I'm both using a framework, AND did, in fact, create it (although it does use a few dozen libraries, on both front and back, and the front ones include Vue, which itself is a framework).
well... yes. but that's bcs none of the mainstream libraries do it the way you like. Otherwise, you would use an existing one, won't you? :P
The thing we want to optimize is how much code is being executed on the client.
Cause.. the browser literally does most of everything already.
All these js frameworks as backends... gosh it's like flushing 30+ years of development down the drain, bcs sm1 discovered he can run the javascript vm outside the browser.
I've used jQuery ajax for years. For smaller applications like a CMS or just a frontend application loading content I've developed a slim formula to use just one ajax function to load all the backend generated html content for all the pages. I've even used ajax to pull one html content and then break it using class names and plugging it in different places in the page. To me it couldn't get easier than that. Using htmx or alpine does the exact same thing. We don't need to over engineer simple tasks
The benefit of creating you own framework is that you can cater it to your own needs. A lot of problems are most elegantly solved by just adding new features to the framework, and that's something you can't really do with third party solutions without a hard fork or huge maintenance cost
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.
For web dev I'm just a hobbyist (even though I do software for a living). I made the first version of my hobby project with pure Flask but at a certain point it just didn't cut it any more. It was too hard to improve usability or add interactivity.
I was also left wondering how do you do user authentication with pure html? Where do you store the credentials? In a cookie? Doing that stuff by hand is just a pain.
@@markopoutiainen7108 There are ways to do user authentication with pure HTML but it’s not great. You can of course use “modern” features such as XMLHttpRequest and Bearer Auth Tokens with LocalStorage without a framework, and I do. Again that’s not the part I want to outsource, mostly just DOM state changes. Anyway I can turn highly procedural, mutative code into declarative code I will.
yes, a secure cookie is generally the best place to store credentials regardless of js implementation
@@markopoutiainen7108 you store in the same way you gonna store with some framework
@@markopoutiainen7108 You have multiple ways to store data on the user's machine, making it very secure and very easy to manage. There are general in-memory datastores offered by every browser, as well as databases. You should look into browser APIs, there is everything you need.
Denial, Agreeing, Repent, Hope, Extreme hatred
My emotions throughout the video:
What's the extreme hatred for?
Javascript failed us
What the extrem hatred for ? React or HTMX ? tell me. :v
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.
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.
Nice ad
@@ivanh1821 Ad?
you can code any of that behaviour by yourself
@@peterszarvas94 But why would I when I can use that time actually work on things people haven’t done before. There’s no point in hundreds of people coding the same thing that’s already been done before
@@crugg idk, maybe sveltkit is not so bloated like react, but some of us just hate using js. you dont need a framework, you can choose to use it, but you are fine without one
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.
This. It Just depends on the projects needs. Roasting all JS Frameworks ist literally just another trend all the tech influencers are hopping on...
Sure, but the point is that not many webapps productively use or even /need/ the features that you mention and actually are just CRUD style apps. Nobody (in their right mind) is claiming that you can or should go write Google Maps or Excel using just the hypermedia approach. Rather, people have grown absolutely sick of being fed the idea that you /need/ an extremely complex fronted / backend approach to write /any/ sort of "modern" web application. The best thing is, you are free to mix and match, combine different approaches for different parts of the application where needed.
YES! couldn't agree more, use javascript for animations etc, you know.. for scripting the browser!?
Not for plumming data, agregates, computations and building the entire UI client-side... like bro common..
And PWAs? you can do that easily with a RESTful Webservice or some websockets... there's your "native" feeling webapp for you...
Regarding offline anything in the browser.... why? just why?
If you need your app to be offline... why did you build a webapp instead of u know.. an app?
Oh I couldn't agree more, which is something that I specifically mentioned in the video. What I said applies _only_ if the application you're building is fairly straightforward in its features and it doesn't require that an external API be available to other clients.
Frontend frameworks are invaluable and I use Vue and React on an almost daily basis for a variety of other projects. I just worry that a lot of hype (especially with meta-frameworks like Next or Nuxt) can have people over-engineering projects that could be a lot simpler.
@@MrSofazocker One app that runs on Android, iOS, MacOS, Windows, Linux, and also offers the same experience as a user can get on the web page. Or you can just idk, make the web page vOv
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.
Good point, but it doesn't really work with large data where you'd end up with pagination, still have to request it from the server every time with React
doesn't HTMX solve this "request everytime" problem?
@@Rudxain no htmx is the same thing with syntax sugar
@@maxim_mazurok In general, doing everything on the backend prevents you from having frontend state that isn't rendered, and you have to make another request every time you want to change what's rendered. Sure, if your unrendered data is very large, then that way can be better. But very often it's not, and the extra loading time is an inconvenience to users.
_"With react you can fetch once then filter the data"_
This is the main problem with modern devs lol. You make it sound as if plain old JS / or even a thin library like Alpine JS can't achieve this.
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.
That said this video really does a good job at pointing out how powerful a server can be
Saying REST and json in the same sentence makes me curl up and wanna die.
REST and SOAP was ought to be a standard way to communicate for WebServices, a "special" sort of API by convention that provides a common interface and restricts the return type and uses HTTP as protocol and returns XML. (normally)
Like... you have a backend.. that's fine and dandy, and it has an API for other apps to communicate with it.. that's not going away.
Buut, what everyone started doing was,
"Well since we have an api, why don't we just call that to get the data the frontend needs, and let the frontend render it... oh and while we are writing the client-side in javascript, and make requests validation there, why don't we write the whole backend in javascript as well to share code?"
And shit sandwich was made.
What you ought to do is, if you want to serve to web, is make a WebService.
That response to HTTP requests and spits out HTML to whoever requested it, utilizing the API of your backend. (restricting your backend to REST is also limiting, there are better ways to access and communicate with a backend, like RPCs)
Why, and where you need state, or the frontend to handle anything is beyond me.
You still have your frontend, you still have all your animations, view-transitions in javascript, client-side....
@@MrSofazocker, you have some really fair points, and yeah, Protocol Buffers are pretty dope. But to be fair, you always end up reinventing the wheel because sooner or later, you end up needing client state to handle different interactions. Not only to display data but, for example, if the user clicks or interacts with (x) button, it needs to show (y) information after (z) time. And while HTMX could handle it to an extent, you might as well have reusable components to deal with it.
@@MrSofazocker Also why do double the work when the API clearly fits the needs and the user barelly notices the drawbacks?
Exactly, the point I was trying to make is that there's a whole group of applications which never connect to other clients (mobile apps, libraries, etc). The data flows just from server to frontend, so it makes less sense to build out a full-fledged JSON API for those particular ones.
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”
I have never even been tempted to use front-end frameworks. Doing so would introduce technical debt. And my programming/developing career has spawned 30 years to date, so the statement does not come from a place as naivete and has proven its benefit many times.
I also don't use any front-end frameworks. Plain old javascript fetching and posting data (not HTML) from a server-side REST API seems to work great, as far as I can tell. I find it much simpler to keep all my "look-and-feel" stuff in static html/js/css files, and my server-side just passes data back and forth from the database (or other data source) with security. If I want to make a change in the way things look, i can just edit my static front-end files, and my server-side doesn't need to know or care.
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.
As an olde webmaster who stopped paying attention after the LAMP days: you guys *haven't* been doing this??
Ah, the good ol' LAMP days, when web development was simpler
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.
Link It
then put the link here you madman
Please link it dude I am dying
Is it on gitlab or GitHub?
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.
Exactly.
You're not wrong.
Seriously this is the thing.
We really need to think about the frontend from the other side of the framework.
No we don't
So instead of adding an api call returning the JSON you propose to add an api call to return the HTML. Yes adding the 'x-refresh' can be seen as adding an api call as it is an additional path in your code. If your connection to the server is slow your performance of the app will be affected. You're proposal will also increase the bandwidth usage because you can't cache the answers and sending html is more data then sending the values.
The actual problem is the behemoth frameworks, not front-end rendering. IMHO the reason why server-side rendering is promoted by AWS, Google and MicroSoft is primarily for the increase in number of requests and increased payload because that is where they make their money on.
Interesting take, and well said.. I haven't worked on FE..wish to hear some more opinions on this.
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.
true
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
now imagine wanting a website that dynamically loads instead of waiting for the backend to generate the whole thing
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
But that point doesn't apply to a framework like SvelteKit because it feels just like writing normal HTML (because you can). Everything else is optional.
Like the good old days as devs use jquery for only $() ... They cant wrote a querySelector.
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.
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
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. =)
React sucks. Just because it’s popular it still doesn’t make it good.
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 ...
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'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.
My goto for this kinda things are SVGs. Specifically when I need some simple, non-interactive graph.
You can also use a JavaScript graphing library without a framework. Chart.js is perfect for this, and has been around long enough that you can ask ChatGPT or Copilot for some helpful examples!
Front end developers used to just handle the UI but now they have to managae state, make API requests and basically also do the backend's job. The responsibility of the front end engineer becomes too much at some point. It's a bad experience for the developer and unnecessarily complicated design for many websites.
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
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
He addressed that near the beginning of the video. At around 1:41 he says the app will live solely in the browser. Ofc if you need a mobile / desktop / IoT client, then that's a whole other story.
@@FelipeV3444 Oh yeah good point. I definitely heard that but I guess for some reason it didn't register.
well... lets take Discord for example. their main app is a webapp, works totally fine, their desktop app is an electron chrome browser, works totally fine, their android app? same, IOS, yep, html!
So what did you say?
@@FelipeV3444 just bundle a browser with your app lol. Electron hello? Everyone does it, and pretty much the only reason everyone's googling "how to download more RAM." :;D
@@MrSofazocker their iOS and Android apps are using React Native, so no, not HTML.
I am so happy I never left this methodology. I never bought into the complex frontend hype.
frontend from backend is awesome, I really want to use it, it simplifies a lot frontend development, but there are some important limitations.
1 - reuse components - there is no one starndard way to reuse components, using template engine is NOT the the elegant way we have in frontend frameworks
2 - reactivity on the client - sometimes we need reactivity on the client, if you push this responsivility to backend, it means that you need one router for each client action, is this can become a mess? if you use some js lib such as alpinejs or vue from CDN, it works too, what do you think?
3 - PWA - even it's possible, but you would have to change the way your frontend is generated from backend
4 - if you have API, you start to negligence your API, because you don't consume your API like external client does, using vue, react etc
It’s amazing to me that this is basically the way we all used to it it. We always do come full circle
History repeats itself and all that :D
But we don't have HTMX back then? So not a circle but more like a spiral?
@@aschmelyun More like Google found it expensive to crawl Client Rendered Websites. So, the move to full circle was triggered by SEO requirements.
With Meta-frameworks like NextJS, Nuxt, Sveltekit, enable SSR.
I usually work on apps with multiple touchpoints. So, I can't avoid making APIs.
Nobody's coming full circle. It's just a dumb new fad that will die after a bunch more videos on YT will saturate the influencer bro market. Server-side is limiting, not actually simpler (you're not the one writing the framework, remember), costs more to host.
to be fair, svelte's ssr and actions abstractions are pretty great
Oh definitely, I haven't done much in Svelte but the little I've worked with it, it's a great frontend framework. Especially for smaller, tighter applications.
You forget that the reason all UI code is handled on the frontend these days is because: if you remember, you'll inevitably end up with 1, 2, ... 20 Backend developers who "know frontend" and will absolutely rot the project for everyone and blame the frontend developers for not being good enough to work with their utter heinous monstrosity. Frontend devs FINALLY won that ridiculous war after, when they had a task requiring a sturdy handle on the data, telling the backend dev "just make the response JSONP so we can go home". That said, modern CSS is so good now that you might be able to do more without that sturdy handle now.
But if it's just you for a prototype product or something than this is great as long as it's more than a static content/flyer site. I could see myself using this approach for certain projects.
@@BenoitMas maybe you're really slow at using them. Are you really slow at using them? Cause it sounds like you're really slow at using them.
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
1:29 Because you want to handle the data as a separate entity from the HTML
Basically, take your initial logic: if what you want is HTML, then you should get HTML. So if I'm parsing data out of the HTML that I just downloaded, we've gone full circle.
As always, it depends on the application.
2:13 THIS, THIS, THIS is genius, GENIUS. I should say it again. This is genius.
The main reason to separate front-end from back-end is speed; your data rendering can be untied from data fetching. The benefit of something like Laravel is security; you have zero chance of an MITM if it's all requests sent to the server and the fully rendered page returned from the server. Just keep in mind that even Laravel (with or without Breeze) is moving to using Vue or React as basis for the UI, separating the two, and the default Breeze implementation even uses the implicit password grant flow for authentication which is pretty bad.
If I need to quickly build something there are two approaches; data-first, or functionality-first. If it's the former, I go with Vue and a simple API that returns the data I need. If it's the latter, I would probably go with Laravel, and I may even use Nova to kickstart my application.
But I believe that laravel ecosystem is moving towards livewire, not Vue or React. Even the official livewire documentation is hosted at the subdomain of laravel site itself. I'm betting on this meta framework approach that laravel and next are implementing. This approach will grow at least for a few years until a new cool thing emerges
@@arashshahabi853 livewire is slow AF
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.
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.
How do you like Quasar? I've been wanting to play around with one of those "frontend for mobile" frameworks like Capacitor or Quasar, but haven't yet.
0:44 - i get it...but in real life you arent really always going to be simply making a table with your entire web app. Youll need to do way more complex things like SPA's, in which case the table example is a very small part of it. I am with you on this example, but when that table is a part of a much bigger responsive app that needs javascript and reaction, imo its way better to use vue, which justifies doing a single file component for that table. I think there's a complexity line in the sand that when crossed, makes more sense to bust out some kind of a framework
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.
What about the advantages of reactive programming when working with user interfaces?
no way in hell I am going back 10+ years to a time I was writing php to handle my HTML templates... this sounds OK when you have a single easy page... but unless you are hafing like a landing page dispalying data from CMS... we all know "sprinkle" some JS mantra is going down the shitter... which is in most of the cases.
So funny how things are going full circle... like when JS with ajax was starting taking over the BE world... and the "OGs" were like... no, that's laughable, for JS (a joke language) to control our apps... we will never consider this to be anthing but a fad ...
and now is happening the same, just backwards.
But, I think I was one of the OGs, that never thought that, JS and ajax is a bad idea... jQuery and after SPAs just made the web a beautiful place... that over the years just got consolidated.
I think separation of concerns is super important. and I think html templates are part of the DOM and front end stack and has no place being on the backend...
But I get it... I mean in Balkan, people say "100 ljudi - 100 cudi" which mean 100 people have different views. To each their own would be the expression... but with all these new frameworks and ways of thinking... it feels like we are getting more divided and we are pulling all in different directions instead of one... (or couple) ... is quite tyring ...
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.
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.
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.
Don't tell anyone, but I also love building frontends (Vue!) and definitely agree on the separation of concerns part :)
When does one know a website is lightweight or not? if it weren't lightweight? What would you use or what would you change?
How does this improve scalability? Scalability gets harder the more communicating parts there are.
@@username7763 because you can scale each part independently, for example if you're experiencing a heavier load on your backend you can scale that independently. You can also split your backend into microservices and implement load balancing.
@@noided7071 That heavy load will result in more network communication which slows down the system with scale. The more pieces you break things up into, the more network-dependent you will be. This only makes sense in very high cpu-demanding applications which is generally not the case with web apps. They are typically network-bound already. Scalability is incredibly tricky.
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...
JS is so good, i just need to learn 100000 libraries and frameworks that's 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.
The solution is Astro with islands. You built a static page and you can do SSR only in those island components that are built in the static pages without needing to change anything else
I will defend my opinion that JetBrains PHP Storm or any JetBrains product is better than VS Code
Rare instance of me not using PHPStorm
neovim or hx , with zellij (if you dont have any money)
otherwise jet.
@devstuff2576That's obvious
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. 😂
Great video, I love htmx
The problem with the htmx multi-step form is when the user has a slow connection. Instead of just validating the data on the frontend and then submit on the last step you are always asking for more data making the user with a slow connection having to wait on each step. And the problem is not htmx but the way things are being handled.
Still with that I would prefer the htmx way on my personal projects, the developer experience is very good. There is a way to check for slow connections using Javascript Web API Navigator, but I don't know how it behaves nor I know how to use it to make the better of both worlds
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 :(
Congratulations, you've reinvented a front-end framework using vanilla custom JS. I remembering doing similar things back in the day, I have no idea why people pretend now that it wasn't awful. It never scales. You always eventually end up with some corner case that cannot be implemented with "just a little bit of JS here and there". Even the cognitive workload of having to explain your custom JS framework to the next programmer is not worth it. You set yourself up for failure in the future. If the app ends up being insignificant, then who cares how it's written. If it turns out to be important and will be actively developed - it better be written in something that more than one person can understand.
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.
Thank you so much for these explanations. The multi step form is gold 🙏
I use an HTMX-like library that is smaller that I created and use it to create offline-first web applications (PWAs). It's worked out pretty well for me and is pretty fast and straight forward to get apps going.
The biggest time save is not needing to implement the same endpoints(s) twice. One for your page and one for your general use api. Among all the other reasons that people have given.
I like the idea of HATEOAS but I believe json back and forth is the best idea, good abstraction one backend to rule them all. The idea of having directives that give html the ability to make calls and hydrate parts of the UI is nice and worth exploring.
What about if I want to change my cart icon's count when I add/remove items? Well, you can do this but that's where the frontend frameworks like react/vue comes into the play.
Keep in mind you need to know a bit about servers and backend. For example in AWS there is an easy way to create a static website or single page application using S3. This alternative requires to create an EC2 or another alternative. And that requires backend knowledge that sadly too many frontend devs doesn't have.
Excellent. 👍. I tried to do something similar with alpine.js but ended up with a lot of JavaScript functions as I had selection dependent drop downs. I concluded that there’s not really a halfway house as I ended up watching for change, sending fetch requests, receiving json, there was not much left in terms of the traditional html method. I’m very interested in what you’re doing here and htmx now after watching this video. It looks legit.
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.
When you mix HTML with dynamic data on a server, your HTML is not cacheable via headers. This is why I like to separate dynamic JSON, and static HTML that can be cached. And then I use EHTML to map JSON response with HTML data and that's it.
I rarely comment, but your content is amazing
So you don't need a framework, you need a library...
lol
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
Server components in react/next js essentially do what you’re saying, they return the jsx.
html with little bit of vanilla js to filter it out and we can keep it simple and have the separation of concern too .
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?
No, because the endpoint being hit by the form pages is through a different route. It's only the initial load at the /form endpoint does that uuid session get set. This was so I could easily have an 'identifier' and attach all of the page responses to the same data in the database.
@@aschmelyun Yeah, That is normally how i assign multi page forms as well. Was just confused because I thought it was re setting the uuid each time the page route ran. Thanks for the response!
The latest version on Next.js and React has addressed this specific issue with “use server” and “use client”.
my only gripe with htmx is you cant revalidate once valid. @13:18
Whaaaat? Where would you have to re-validate something you already sent? Changing anything on the client-side then and there wouldn't change anything on the server!?
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
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
The big benefit with client side code is that your server side business logic is completely decoupled from your UI. I am bias toward JSON and REST APIs at this point. Not because it's"trendy" either. You don't even need a front-end framework for this either. For simple apps, just design an ORM that makes sense, spit the JSON out, consume, and build DOM with jQuery. From here, client has what it needs so no unnecessary requests to the server afterwards
For those debating the necessity of frontend frameworks, it's worth considering the significant advantages offered by meta-frameworks like Nuxt 3 for Vue or Next.js for React. These tools streamline development and, once you grasp the component-based architecture of the frontend, enable the creation of sophisticated applications with ease.
If your project doesn't require extensive complexity, Vue and React offer plenty of straightforward solutions. Complex state management, for instance, is unnecessary unless your application truly demands it.
Ultimately, the best technology is the one that fits your specific needs. If you prefer to master a single framework, ensure you learn it thoroughly to handle a variety of scenarios effectively.
“With ease”… yeah about that,
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
I hate the fact that this needs to be explained and is presented as the "modern" way of doing things when it was the og way of doing things. SPAs have their place, for example a backend for the owners of the website to manage content. For everything showned to a visitor just do it server side
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.
Client-side framework bloat is an issue, but dude, for the data I already loaded to be sorted or filtered I don't need or want to download it again. Making an offline frameworkless sorting and filtering table is somewhere around lesson 2 of JS course though.
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.
I think the issue with this design is the responsiveness -- I'm a backend dev too but if i was in kansas and the server was in virginia, having to do a whole network hop to filter the cars by color could take seconds -- much better in that case to have a longer initial loading time for better responsiveness once the slug is loaded
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.
I use this pattern for proof of concepts when working with customer ideas. Some Go + PocketBase + Templ + HTMX for SSR. PicoCSS or Tailwind for styling. Gets me pretty far for presentation and light usage from a couple hundred users.
Let’s be honest, why build an app for 10000 plus concurrent users from the get-go when most apps are glorified ToDo CRUDs.
Build fast and launch fast, I respect it. I've seen a lot of people using the Go + HTMX stack for smaller, one-off applications, and I have to say I'm eager to check it out and see what it's like.
I might be getting it entirely wrong, but the argument is that instead of using frontend frameworks we use backend frameworks that streamline the process of creating the frontend?
Hot take, I've been working on many medium/large projects and maintainability of the structure of the project is not an easy thing to keep up, and the fact that the backend and frontend is separated is what makes it more manageable, if I wanted to create a crud application I'd likely wouldn't use a framework and just do it in what I currently like using the most, but anything more complex its just a bad idea to not use the tools available for you, I'm sorry that I say this but things gain popularity and more usage because they work, and they're better than other solution for one reason or another, its that simple, you can certainly say that everyone is stupid and you aren't because you feel this way, but apart from a small app I'd never do this route you mentioned, because it becomes a mess really quickly, or at least that is my experience as a fullstack dev, its not that maintainable, and I wish I never have to work on a project that does this, its trash to work with and the neighbours grass is in fact greener unfortunately.
I don't like to use abstractions over abstractions either but I have been able to develop at quicker speeds with frontend UI frameworks. Having frontend and backend separated also allows people to become specialized. Let's be honest, there are way too many tools coming out now. The amount of time it took you learn developing will be 10x bulkier for a fresh developer.