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.
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" 😂
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.
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.
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.
@@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
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.
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
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.
This is the only way I’ve ever made a Web app and I’ve always felt like a half rate dev for doing it this way so it’s nice to have someone advocating for this method
@@j.j.oliphant9794you’re not; if what you built served your users and the business goals, and it was standards compliant, then you fulfilled your supreme duty. Nothing else matters.
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
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.
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”
sending raw data instead of html and then formatting at client makes sense if raw data is a more efficient format, which it is with binary data, but json is literally the worst serialisation method to ever exist
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)
@@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.
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 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
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.
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. =)
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.
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
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
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.
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.
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.
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
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.
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.
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
I agree ...we need "dumb termials" (as the browser) or treat them as such we going back to it ...they worked well like the student kiosk stations at the university back in the no internet days ...
I'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!
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.
Today i was having a similar conversation with a friend, and is a little battle of me asking, why you need to recreate HTML to spit HTML to the browser, thanks to make it and know im not alone in this crazy idea. Regards from Patagonia Argentina PS: I'm gonna have to read more about HTMX
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.
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
This is good up to a certain point. If you are returning entire applications, you need significant processing power on your server, especially when you get a significant number of users. Offloading the display to the client can cut down on server costs signficsntly.
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.
A backend server should be agnostic of the client consumer. It will provide much more flexibility to only respond with JSON payloads and let the consumer decide what to do with it.
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 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.
Very nice video, definitely gonna give HTMX a try after this! 💯 I usually work with React/Next.js, sometimes with Java backend, and used Laravel/Blade and vanilla JS with Alpine in the past for a smaller personal project, but as I didn't structure the components and JS code properly, it quickly became a mess. This approach looks very clear and minimalistic to me, but also quite powerful!
“Developer”: I love frameworks! They make this job so easy! Me: Tell me you don’t know how to write fast code without telling me you don’t know how to write fast code. Nobody wants to wait 15s for initial page load.
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
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.
my opinion is of no importance (and completely uncalled) at all, but this is the absolute best video on web development of the last five or maybe more years
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.
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.
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.
I can agree with some of your examples but for one reason security holds better in back end with filtering and execute user input with more controls to handle those input and request, while it push server to the limit if applied as you suggested, so UI libraries and front end framework resolve most of server side issues and make it more usable if it all compute and applied at user side not on the server itself also help your application to granted speed from user browser and CPU not your server resources. At the end l totally agree to simplified things when you can but in way that balance your final application results to be smooth and fast as possible in 2024 you can't ignore any tools or technology available to keep speed and balance websites or applications as fast as possible in the way market need not our opinions or ways to apply things just my humble opinion
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
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 don't know. The moment noone is forcing a particular tech stack down my throat, I keep reverting to good old plain vanilla HTML/JavaScript/PHP. Comes more natural and intuitive to me, everything else feels unnecessarily cluttered. While we are heaving frameworks on top of frameworks, what we seem to be overlooking is that it might be time to completely rethink the core languages themselves. Douglas Crockford has a very interesting perspective on that, and he co-authored Javascript back in the 90s.
So you are making a request for server every time you want to sort or filter out table? That looks good only for 0 users pet project. Do you need to reload entire page to switch to a dark mode? Do you need to store the entirety of user data either at server side (poluting the db), or at the url (meh). Idk why people are scared of react. I'm a big js hater myself, but react is essentially a plain wrapper around html. Whenever you need anything slighly more complex and interactive than these stages examples, you will end up with the same signals and states react already provides out of the box. And let's be honest, perfomance is not the issue. Browser on mobile now is more capable than computers were 15 years ago.
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 ...
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.
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.
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
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 think you point of view is great. But as a front-end developer I'm completely drilled of making bad software. Sometimes simple solutions are ok, but you can always raise the bar and I really think we should be making better and better (event though, more complex) to improve the internet as a all.
So do i have to send data + markup + css + scripts everytime the user push a button or typing something......? That sounds like a burden for my backend and nightmare for my bandwidth..... Edit: and fire for my pocket....
CSS + Scripts are cached by the browser, but yes markup and data would be sent together. Which, is exactly how run-of-the-mill http calls work anyway in a traditional web server approach. You'd just be hot-swapping out the components that are re-rendered if you want to do it without a "hard refresh" appearance.
Web Developer of 20 years... couldn't agree more. Feel like these frameworks were designed for something totally different (e.g. React for Facebook Ads Manager) and people lack the experience to know the right tool for the right job.
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.
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
So we are slowly coming full circle back to the basics after years of trying to reinvent the wheel and overcomplicate things. I guess frontend devs were just really bored in the last decade 😂
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
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 use HTMX in building low-code SaaS platform , untill now i don't have any big problems , but in the other side it's very good that even the backend devs can deal with it without over engirneering of the frontend frameworks , the view fiels allw the fron end and full stack dev to work seperately. for me it's just the desire to feel we make an ENGINEERING COMPLIX thing feed the freaworks for front end dev
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.
