I am a senior software developer and architect, with a methodical and philosophical approach to decision making. On this channel I talk about various concepts in software development and design.
Can we use Django + React + Nextjs for building a KMS with bi-directional linking + advanced searches at the front end while saving data at the backend?
Well after the release of bun and hono this suggestion and video is completely useless. Sorry but appreciate your talent to find this problem back at that time.
Hono and Nest are not really the same Nest has a much bigger scope than just a "web" framework. It's much more of a modular framework with web as one of the possible entry points. If you think Hono is a full replacement for Nest I recommend looking into Nest a bit more closely
@@devagrI was talking about this video not nest js please don't misunderstand me the things you have said in this video all of those things can be done greatly by hono Nest js capabilities are way larger than the use cases you described in this video and to build such a simple application Hono can easily do the work without getting into more complexity like Nest js will require.
I just got carried away, watched the entire video and this is the first time I'm commenting on RU-vid. Pure perfection, throughout the video! hats off senor 🧢
I saw the Theo vid on Next and tried it out, the idea of being able to just await fetch inside my components sounded nice since I was new to React and was working to convert my node js CLI project to have a proper UI. Then I learned what stateless actually means when I spent a few hours debugging why a bunch of Classes that get instantiated in Request 1 are undefined when running Request 2.... I just feel like if your requests are anything beyond basic crud operations with a high need for static generation then next will be more trouble than its worth
This, is FANTASTIC. That model of web project structure is spot on and so versatile, and you seem so sincere/authentic/honest with all your statements. So satisfying to watch
@@joel9909 Yhhhh. Cause blindly following trendy stuff is what makes you a "principal" dev. People like you couldn't design maintainable systems to save their life.
@@forevernoob97why are you being so rude? I thought tech/dev people weren’t toxic like that? Are you one of the bad apples I’ve been warned about? I’m a beginner (going the college route for comp sci). I like to read the comments because some people have great insight. If you were to explain why both concepts are terrible maybe that person you’re being rude to could learn something, and also I could learn something as well. I hope you’re having a better day today forevernoob.
Nextjs is just pain. Unless I can use ssg, nextjs is absolutely useless. Anyone who is really developing and not not just make some 5min tutorial on RU-vid will agree. With every release it takes away more of the simplicity it should provide and adds more bugs.
3:19 oh trust, React Query is still going to have a place in some corners of the JavaScript/TypeScript ecosystem for quite some time. Big example: a mobile app made with a JavaScript/TypeScript-based cross-platform framework like React Native, Expo, or Ionic (any flavor of Ionic). Mobile apps have to be offline-capable and making even a large plurality of a mobile-app server-rendered would be very very ill-advised. Mobile apps will still need solutions like React Query to cache and de-dup API requests. If I were Tanner Linsley I would definitely plan to continue developing and maintaining React Query and its respective Solid/Vue/Svelte counterparts for the foreseeable future, but it is certainly also good that he has branched out into other directions (routers, UI components, etc.)
Here's a very simplified overview of server vs. client components that may help people understand - Server Components - basically JavaScript-powered HTML templates that are run and rendered on the server only, then the finished/filled-out template is sent to the client (browser) as *only* HTML, not to be run again unless another request to the server is made* - since server components are only run once and sent over as static HTML, interactivity (state, immediate dynamic feedback etc.) is not possible with them. The advantage of server components is that since they are rendered on the server, less JavaScript is sent to the client, and also server-side environment variables can be used within server components, therefore secrets such as backend keys and database passwords can be stored securely, and databases can be directly accessed securely within server components * Also, the default behavior of frameworks like NextJS 14 is to cache the result of a server component being run and send the cached result on subsequent requests instead of running the server component (in other words, the template machine) again unless you explicitly tell it not to do this. For dynamic server components that render according to , for example, changing URL parameters (like search filters, for example), caching the result of a server component being run is not what you want and you want the component to run every time. For a static component that doesn't change, caching the result of the component being run is ok. Client Components - basically what we used to call "server-side rendered" components, components that are run on the server to produce a non-interactive HTML "shell" of the component, then that shell is sent to the client (browser) bundled with the JavaScript that the browser will use to "bring it to life" and make it interactive on the client/browser (this is what's called "hydration" in a nutshell). Client components can use state, be interactive, show immediate dynamic feedback, and everything else we were doing with React components before, however they, like the pre-RSC client components before them, are not safe places to store secrets and their use results in more JavaScript being sent to the client (browser). In my and many other people's opinion, "client component" is kind of a misnomer since the component is run on the server AND the client. "Interactive component" would probably have been a better name. It is ok to use client components when it is necessary for interactivity of any sort, but they should be used sparingly. Aim to make as many of your components into server components as possible.
for me, the server your right for a web application is part of frontend. I would say next is a fullstack WEB framework. backend is something else that goes beyond web
