Yesterday, I created a fresh nextjs 13 app for the sole purpose of back end stuff. It's actually going to be a REST API and I'm probably going to cry a lot, but it's just because I have to deliver this to someone who doesn't deserve a good backend. Sad to hear it's actually a backend framework now.
Thanks, working on my first next.js app and I was going to try and use it it with rails as a backend. But it seems like it meets the criteria for just going serverless! So excited to test this out.
At what point should I ditch the "old school pattern" of having a separate backend (nodejs express app that provides json API routes) and a frontend (react with create-react-app or nextjs) in favour of "joining" these two in a single application (nextjs with API routes) This might be a dumb question, but isn't this approach mixing the concerns instead of separating them? Before you had an application that only worries about backend stuff and an application that only worries about frontend stuff, and now you have these two things that used to be completely separate mixed in a single code base. This seems counter productive?
I think the idea is that before, front end and back end were so different in their duties and syntax that it didn't make sense to mix them. Now it becomes simpler to just have 1 code base where everything is there since there's no "bridge" to manage between them.
You are right in the feeling that we as programmers should be separating concerns. The question now is: What do we separate? The natural and historical answer has been "Lets separate the back-end and the front-end", but should we? What if we started to think of the web as what it is: Just another IO device. I think that tools like Next And tRPC and others that blur the line between the front-end and back-end are demonstrating that there is value in moving towards this mentality about the web. This frees us to think of better ways of separating the concerns in our systems.
I agree. It seems like React/nextjs is going back to those "old schools"(SSR is nothing new than what rails has been doing) for those "SEO" or some "performance" issues. But to me, it looks like React is losing its original purpose - client side rendering for SOC. Everybody says Next.js is kinda revolution but for me it sounds like just a repetition of rails or django. Could anyone tell me what point I am missing here...
@@sungjuyea4627 The point you are missing is that Rails and Django are not single-page application frameworks. They are multi-page application frameworks.
It is a backend framework, but for something like hackathon or small workshop or proof-of-concept applications. This is exciting! However, for anything remotely serious, who are we kidding?
I get your point, but not all production-ready or "serious" applications are complex enough to justify going for a different solution. Sometimes the requirements can be properly satisfied with a simple stack.
Can we have different requests based on method in the same path now? For example GET /books and POST/books doing different things Last time I was learning next this was not possible without doing some ugly stuff like "if method === GET then". Is there a more pretty solution to this problem today?
I would only consider this for smaller solutions to be honest. In most business contexts, APIs are made to stay and have sufficient complexity to warrant their own system components. For smaller projects or hobby Projects, or as a general BFF I agree.
Is it correct to understand , that react/nextjs is now also backend frameworks, that they're now doing stuffs what rails or django(or maybe spring) has been doing over the past decades? But then, I wonder, why do we need to use React rather than rails or django? I think there would be tons of issues - like db security, db configs, ORM, managing session/cookie, etc., which are relatively easy to be "ignored" on the frontend side.
No it never was and probably never will be, you still need additional backend layer just api can live next to "next.js". It's nowhere near orms, configs, automation, security, db configs, auth, etc at least yet - there are some stuff here but still u need to do a lot.
You would do this if you're primarily interested in using React as your frontend and just need whatever backend to support it, instead of going for a backend web framework (Rails, Django, etc) that you can slap some frontend on. It all depends on what's more important to you or what your main skills are.
@@angelurena You can use Django and Rails to provide an API consumable by next, it's more a matter of wanting to stay in a JS environment and decrease complexity by not decoupling
@@heroe1486 If you're exposing an API built with Rails or Django, the simplest way to consume it would be to call those endpoints directly from the frontend. Unless you have some other constraints or a desire to add decoupling by using NextJS as a middle man, then you wouldn't actually be using it as your backend, would you?
Front end has always been a somewhat ambiguous term. Thanks in particular for that bit. It can mean the browser client/local storage, cookies etc. as well as the code/files set apart to communicate with it. This is clearer to those I'm training after having watched the "create react app - why its bad" video. While technically on the server-side, it isn't meant for all the other backend stuff that node comes with. Helps to understand some of the contracts or boundaries between each piece. The browser's "contract" to not share too much of the end user's OS and also the server's need to protect its own OS by keeping isolated from its high value assets like data and secured files. BTW, I am not sure exactly what "the edge" is or how to explain that. Seems like a new term for something else I know / could easily figure out but still a very overloaded newish term.
What I'm understand by the Edge: It means the closest server to the users, yeah, CDN have servers and networks everywhere around the world, so when a user interacts with your site, not only the frontend but also the "backend" or functions will execute it's code in the closest server to the user. In traditional apps the code will always execute in your server, like the VPS on digital ocean or ovh server and so on. Pretty good isn't it?
@@carlosescobar5995i agree with everything except the bash of the digital ocean VPS. I have a question, on what do you think the CDN servers run? Themselves? There is also a solution for long running server instances, it’s called geo-aware DNS and because of this you can have solutions like ‘the edge’
Can somebody tell me the BGM being played at the beginning . I was legit vibing to that . By the way i've always seen that people using react slowly shift to nextjs in the long run . Quite evident now
but compile it to run via localdb like nodejs or ttanslate it to web assembly, straight to cpu via web, with security in mind and then do drafting and page design separately and you dont need an app.
Assuming this is not a troll & you aren't familiar with Theo's thoughts on unit testing, it's pretty simple really. Each API endpoint is just a *.tsx file containing a serverless function. Serverless functions are pure functions. All the data you need is either in the request object or your database. Either mock out your data fetch or have a test database and just make requests to the dev server. I recommend using Jest and Supertest. You can also use Mocha and Chai. Arange the test database, make your request, and assert the response. It's not true unit testing if you factor in middleware, but that's good. You should test the API the way you will use it, and that is by making requests.
Nice and distinguished explanation, but the same person was talking about Deno and Fresh and said that they are much faster, and yet he was saying that they are not good and he wants to create his own framework, so how can I believe the comparisons now?
Hello guys, c++ guy here. I am using web for fun not for main job. Its very hard for me to understand why db, business logic and rendering are in the same function??? Seperating real backend (db + business logic) and front end (rendering) is so much better. Easier to develop, scale, etc. What of a want to optimize business logic and rewrite the code in some other language and so on. I think this "full stack" works only for small projects.
@@bishenpatel1676 LOL. So basically, Nuxt, which is a framework that does nearly the same thing as Next but for Vue, is not a backend framework, but Next is a backend framework? You front engineers have some wild logic.
Django is in the same category as Ruby on Rails. Flask is more lightweight, batteries not included. As for separation of concerns, that's a tradeoff. Which concerns do you want to separate? Is separation more important to you than simplicity? You won't get a perfect solution across the board with any tool. You have to choose what you're optimizing for.
7:40 is this true that the serverless function will die after responding? Doesn't it have to wait for the function to return? Why wouldn't you be able to execute code after returning a response?
Usually what happens in serverless is that once the runtime has received a response from your application, after some tiny delay, the runtime pauses giving CPU time to your application instance, and it's basically frozen. It may be unfrozen at a later time (e.g. when another request is received. In which case your code continues running after a long pause.), or the frozen instance may be thrown away (to be replaced with a new one on the next request. In this case the code after sending a response may not be run at all).
I currently know react and am planning to become a fullstack dev. Will nextJS + react be called fullstack? How does next handle db? Can anyone explain me I'm dumb
Next.js is definitely a frontend framework with a sprinkle of backend, namely serverless functions which are not optimal for communicating with a database (they make a new connection for every request). Claiming anything else is pretty disingenuous.
6:38 the NextJS middleware, of course, runs ON your servers (not the edge and definitely not before your servers)… people abuse the term “edge”. It will typically mean an appliance/cloud service that requests pass through BEFORE sending to your app… your app cannot (should not) operate at the edge. This is not what “middleware” is in an isolated server process like your NextJS bundle. You can rate limit, IP block, defend DDoS, terminate SSL, etc. at the edge, you cannot (should not try to) do these things in your bundled middleware. Middleware is app-global preprocessing if requests to limit code/logic repetition across your project(s). That’s it.
I'm pretty sure they do run on the edge. Hosting providers like Vercel run middleware on an edge function, which uses a Cloudflare worker under the hood iirc
This is incorrect. On vercel the middleware runs on cloudflare edgeworkers and not in the AWS lambdas that the rest of code is executed in. Although Vercel are moving away from lambdas to run everything on the edge network. Middleware does however run on your local dev environment.
Theo Browne: "Next.js is a backend framework!" Also Theo Browne: "Okay Next.js is just React + Express...if you want to do the things that a real backend framework does, just use 3rd party solutions!" So dishonest...do better!
Theo is a great presenter and knowledgeable around the react ecosystem. The only issue is that he likes to encourage folks to use a ton of third-party services for trivial stuff that can be easily be done by any competent dev
Well, if you're willing to pay a dev to create & maintain services that those third-party services provides with way less cheaper price than the dev's salary. You can go for it - but I'd rather go with the third party services so I have tons of less bugs in the backlog
This is typical for content creators. They are incentiviced to continuously pump out new content; not to give good advice. Furthermore, if you're recording videos instead of working as a programmer, you're not going to learn the skills that are necessary to give advice in the first place.
@@uziboozy4540 Good luck expecting people to stop using a tool that they enjoy using to solve real problems for what I assume is nothing more than your personal preference. I'm guessing that you consider yourself above React plebs because your favorite tool is better at everything, right?
@@Chris-zt4ol yes but we cant leverage that behavior of react in nextjs since nextjs uses its own router not the react router and the app somewhat reloads on navigating to different link/url.
Working with file uploads on the server side with next js sucks. You have to use a third party library just to process the uploaded file data. Not mature yet.
The reason you probably reference to is his smugness. While his "character" does not really resonate with me, he is indeed quote knowledgeable to I still Listen.
@@_thehunter_more like for tinkering inside of a browser at 20fps to edit code without formating/autocompletion/vim commands or having to to rewrite the thing from scratch (or move if it's not FOSS) if your use case isn't handled. Those tools are good for non devs or if you have half a day to accomplish the task
@@perc-ai that is so far from truth you have no idea. Big companies want specialists not generalists. Even if that happens I'll be retired by then probably
@@froggy3496 theres not that many big companies lol... theres far more mid to small cap companies that LOVE generalists. Frontend devs are quickly taking over backend developers jobs, unless your domain knowledge is really specific your safe. But if your just building CRUD API's rip
No, sorry. The fact that you can build backends in NextJs does not make it a backend framework. Rendering components on the backend does not count, sorry. I would welcome NextJS to go in this direction though (like BlitzJS tried / are trying to, like RedwoodJS aspires to).
Vercel, please don't promote this guy. He's a troll working every angle he can for his attention addiction. The guy is a child who will attack anyone who disagrees with some very immature and malformed takes. We don't need people like this.
Every frontend framework is a backend framework as long as your boss is greedy enough to avoid hiring people who actually knows backend. I am very tired and scared of that trend when people who supposed to be centering a div inside another div starting to get responsible for handling proper authorization, predicting SQL-injections and so forth.
"display:flex;justify-content:center;align-items:center;" done centering, now i can focus on my favourite activity: forwarding user inputs directly into my sql statements its actually not trivial since im using a orm but fortunatly prisma has the $queryRaw und $executeRaw function 💪💪💪
The presenter is pretty good at this kind of stuff. He should start streaming.
He should work for twitch!
Maybe better if he had a newsletter that he faxed out every week or so
Maybe he could start a TH-cam channel as well!
He has a yt channel
@@frankyb702 he was work for twitch, and also he is a streamer.
NextJS was just described to me the other day as a “Fullstack” framework
I love how he explains things.
It's hard to argue against this with the full implementation of server components.
"Any application that can be written in JavaScript, will eventually be written in JavaScript.” Jeff Atwood
@@sicario55 No it will be rewritten in javascript, just different javascript framework :)
Yesterday, I created a fresh nextjs 13 app for the sole purpose of back end stuff. It's actually going to be a REST API and I'm probably going to cry a lot, but it's just because I have to deliver this to someone who doesn't deserve a good backend. Sad to hear it's actually a backend framework now.
You nicely summed up in, "... to someone who doesn't deserve a good backend ..." :D
Using presigned url does might be dangerous if a malicious user will spam your bucket with many large files, as you cant validate the file size
Haven't watched Theo's videos in awhile. Glad to see his face! Will have to get back into binging his streams
Thanks, working on my first next.js app and I was going to try and use it it with rails as a backend. But it seems like it meets the criteria for just going serverless! So excited to test this out.
At what point should I ditch the "old school pattern" of having a separate backend (nodejs express app that provides json API routes) and a frontend (react with create-react-app or nextjs) in favour of "joining" these two in a single application (nextjs with API routes)
This might be a dumb question, but isn't this approach mixing the concerns instead of separating them? Before you had an application that only worries about backend stuff and an application that only worries about frontend stuff, and now you have these two things that used to be completely separate mixed in a single code base. This seems counter productive?
I think the idea is that before, front end and back end were so different in their duties and syntax that it didn't make sense to mix them. Now it becomes simpler to just have 1 code base where everything is there since there's no "bridge" to manage between them.
@@QazJer yeah, I guess that makes sense. I wonder if at some point having all the code in a single codebase makes it harder to work on
You are right in the feeling that we as programmers should be separating concerns. The question now is: What do we separate? The natural and historical answer has been "Lets separate the back-end and the front-end", but should we? What if we started to think of the web as what it is: Just another IO device. I think that tools like Next And tRPC and others that blur the line between the front-end and back-end are demonstrating that there is value in moving towards this mentality about the web. This frees us to think of better ways of separating the concerns in our systems.
I agree. It seems like React/nextjs is going back to those "old schools"(SSR is nothing new than what rails has been doing) for those "SEO" or some "performance" issues. But to me, it looks like React is losing its original purpose - client side rendering for SOC. Everybody says Next.js is kinda revolution but for me it sounds like just a repetition of rails or django. Could anyone tell me what point I am missing here...
@@sungjuyea4627 The point you are missing is that Rails and Django are not single-page application frameworks. They are multi-page application frameworks.
It is a backend framework, but for something like hackathon or small workshop or proof-of-concept applications. This is exciting!
However, for anything remotely serious, who are we kidding?
I get your point, but not all production-ready or "serious" applications are complex enough to justify going for a different solution. Sometimes the requirements can be properly satisfied with a simple stack.
Can we have different requests based on method in the same path now?
For example GET /books and POST/books doing different things
Last time I was learning next this was not possible without doing some ugly stuff like "if method === GET then".
Is there a more pretty solution to this problem today?
nop
Not in Next.js natively but tRPC solves this problem and many more, cutting down on boilerplate drastically
@@Chris-zt4ol interesting, I'll look into it. Thanks a lot!
Wait, Next can't do this? This is a fundamental part of a backend...
@@Anbaraen A backend doesn't always need to be a RESTful API.
7:06 this tweet makes no sense, the guy has no idea what he is talking about
None at all
I'd ponder this TH-camr might find success on Twitch doing live coding stuff and hot takes
I would only consider this for smaller solutions to be honest.
In most business contexts, APIs are made to stay and have sufficient complexity to warrant their own system components.
For smaller projects or hobby Projects, or as a general BFF I agree.
Cool video. Learned some interesting points about where Next can be tricky. I look forward to explore your suggestions!
Is it correct to understand , that react/nextjs is now also backend frameworks, that they're now doing stuffs what rails or django(or maybe spring) has been doing over the past decades? But then, I wonder, why do we need to use React rather than rails or django? I think there would be tons of issues - like db security, db configs, ORM, managing session/cookie, etc., which are relatively easy to be "ignored" on the frontend side.
No it never was and probably never will be, you still need additional backend layer just api can live next to "next.js". It's nowhere near orms, configs, automation, security, db configs, auth, etc at least yet - there are some stuff here but still u need to do a lot.
You would do this if you're primarily interested in using React as your frontend and just need whatever backend to support it, instead of going for a backend web framework (Rails, Django, etc) that you can slap some frontend on. It all depends on what's more important to you or what your main skills are.
@@angelurena You can use Django and Rails to provide an API consumable by next, it's more a matter of wanting to stay in a JS environment and decrease complexity by not decoupling
@@heroe1486 If you're exposing an API built with Rails or Django, the simplest way to consume it would be to call those endpoints directly from the frontend. Unless you have some other constraints or a desire to add decoupling by using NextJS as a middle man, then you wouldn't actually be using it as your backend, would you?
It took me so long to realize this. I wish this video was uploaded like a year ago
Thank you theo. The explanation is pretty great.
How many real life apps have you created in next.js?
Front end has always been a somewhat ambiguous term. Thanks in particular for that bit. It can mean the browser client/local storage, cookies etc. as well as the code/files set apart to communicate with it. This is clearer to those I'm training after having watched the "create react app - why its bad" video. While technically on the server-side, it isn't meant for all the other backend stuff that node comes with. Helps to understand some of the contracts or boundaries between each piece. The browser's "contract" to not share too much of the end user's OS and also the server's need to protect its own OS by keeping isolated from its high value assets like data and secured files.
BTW, I am not sure exactly what "the edge" is or how to explain that. Seems like a new term for something else I know / could easily figure out but still a very overloaded newish term.
What I'm understand by the Edge:
It means the closest server to the users, yeah, CDN have servers and networks everywhere around the world, so when a user interacts with your site, not only the frontend but also the "backend" or functions will execute it's code in the closest server to the user. In traditional apps the code will always execute in your server, like the VPS on digital ocean or ovh server and so on. Pretty good isn't it?
@@carlosescobar5995i agree with everything except the bash of the digital ocean VPS. I have a question, on what do you think the CDN servers run? Themselves?
There is also a solution for long running server instances, it’s called geo-aware DNS and because of this you can have solutions like ‘the edge’
great , we really need full stack framework like Next.js
in this context, what's your take on HTMX features and capabilities?
For performance, would Next/React be better or Django python.
Can somebody tell me the BGM being played at the beginning . I was legit vibing to that . By the way i've always seen that people using react slowly shift to nextjs in the long run . Quite evident now
but compile it to run via localdb like nodejs or ttanslate it to web assembly, straight to cpu via web, with security in mind and then do drafting and page design separately and you dont need an app.
bro ditched excalidraws 🗿
"statefull backends"
So, it's basically what php was doing back in the 2002.
What a awesome evolution.
He's advocating for stateless backends (serverless), not stateful.
Hi, can you make a video on unit testing of APIs including typical moddlewares in Nextjs backend,
If this is a troll, it's a great troll 😂
Assuming this is not a troll & you aren't familiar with Theo's thoughts on unit testing, it's pretty simple really. Each API endpoint is just a *.tsx file containing a serverless function. Serverless functions are pure functions. All the data you need is either in the request object or your database. Either mock out your data fetch or have a test database and just make requests to the dev server. I recommend using Jest and Supertest. You can also use Mocha and Chai. Arange the test database, make your request, and assert the response. It's not true unit testing if you factor in middleware, but that's good. You should test the API the way you will use it, and that is by making requests.
Crons are very important for BE
Nice and distinguished explanation, but the same person was talking about Deno and Fresh and said that they are much faster, and yet he was saying that they are not good and he wants to create his own framework, so how can I believe the comparisons now?
Hello guys, c++ guy here. I am using web for fun not for main job. Its very hard for me to understand why db, business logic and rendering are in the same function??? Seperating real backend (db + business logic) and front end (rendering) is so much better. Easier to develop, scale, etc. What of a want to optimize business logic and rewrite the code in some other language and so on. I think this "full stack" works only for small projects.
this guy always looks like he just found out your dirtiest secrets
holy shit you're right
Bruhh I am super confused right now. We used next js with typescript and with graphql, redux scss for fronted but how it's possible for backend 😢
maybe with some sort of javascript backend would do
Some chasing JS fanboys, you will never caught them. A lot of them are being laid off right now. No real value from them.
How about NuxtJS and SvelteKit are they also backend frameworks like Next?
Nuxt supports SSR ( Server Side Rendering ).. But it's far from being a backend framework..
@@bishenpatel1676 LOL. So basically, Nuxt, which is a framework that does nearly the same thing as Next but for Vue, is not a backend framework, but Next is a backend framework? You front engineers have some wild logic.
Thanks for sharing Theo, would like to see some pairing with Next JS as an example of a complete full stack experience!
What about Flask and Django thou 3:32
Also isn’t this bad for Separation of Concerns?
Django is in the same category as Ruby on Rails. Flask is more lightweight, batteries not included.
As for separation of concerns, that's a tradeoff. Which concerns do you want to separate? Is separation more important to you than simplicity? You won't get a perfect solution across the board with any tool. You have to choose what you're optimizing for.
I have an Android, is that frontend too?
Great video Theo. TIL S3 presigned URL!
Why did you mentioned Astro as a backend framework? I don't get it.
How do you deal with public and private routes in a NextJS app? . Response: NO have in 12 , less in 13.
Might be too early to tell, but I haven't heard anything about the overhead costs of hosting such an app...there might be a catch
7:40 is this true that the serverless function will die after responding? Doesn't it have to wait for the function to return? Why wouldn't you be able to execute code after returning a response?
Usually what happens in serverless is that once the runtime has received a response from your application, after some tiny delay, the runtime pauses giving CPU time to your application instance, and it's basically frozen.
It may be unfrozen at a later time (e.g. when another request is received. In which case your code continues running after a long pause.), or the frozen instance may be thrown away (to be replaced with a new one on the next request. In this case the code after sending a response may not be run at all).
@@dtinth well that's pretty dumb.
I currently know react and am planning to become a fullstack dev. Will nextJS + react be called fullstack? How does next handle db? Can anyone explain me I'm dumb
You can call db queries from the api endpoints in NextJS, if that's what you're confused about.
Next.js vs Django (Django Rest Framework) ?
i thought he was a film actor because he looks like spiderman
Next.js is definitely a frontend framework with a sprinkle of backend, namely serverless functions which are not optimal for communicating with a database (they make a new connection for every request). Claiming anything else is pretty disingenuous.
Exactly!
6:38 the NextJS middleware, of course, runs ON your servers (not the edge and definitely not before your servers)… people abuse the term “edge”. It will typically mean an appliance/cloud service that requests pass through BEFORE sending to your app… your app cannot (should not) operate at the edge. This is not what “middleware” is in an isolated server process like your NextJS bundle. You can rate limit, IP block, defend DDoS, terminate SSL, etc. at the edge, you cannot (should not try to) do these things in your bundled middleware. Middleware is app-global preprocessing if requests to limit code/logic repetition across your project(s). That’s it.
I'm pretty sure they do run on the edge. Hosting providers like Vercel run middleware on an edge function, which uses a Cloudflare worker under the hood iirc
This is incorrect. On vercel the middleware runs on cloudflare edgeworkers and not in the AWS lambdas that the rest of code is executed in. Although Vercel are moving away from lambdas to run everything on the edge network. Middleware does however run on your local dev environment.
Theo Browne: "Next.js is a backend framework!"
Also Theo Browne: "Okay Next.js is just React + Express...if you want to do the things that a real backend framework does, just use 3rd party solutions!"
So dishonest...do better!
is this PHP ?
Yes but in a good way
And also no
This video is very useful for me
"Official Brand Ambassador of Next JS"
Theo is a great presenter and knowledgeable around the react ecosystem. The only issue is that he likes to encourage folks to use a ton of third-party services for trivial stuff that can be easily be done by any competent dev
That's far from his only problem lol.
Well, if you're willing to pay a dev to create & maintain services that those third-party services provides with way less cheaper price than the dev's salary. You can go for it - but I'd rather go with the third party services so I have tons of less bugs in the backlog
@@kaelxeth what do you do when those third-parties hike prices, go under, don't meet SLAs etc etc?
This is typical for content creators. They are incentiviced to continuously pump out new content; not to give good advice.
Furthermore, if you're recording videos instead of working as a programmer, you're not going to learn the skills that are necessary to give advice in the first place.
What are those "easy things" that "any competent dev" can do?
I like to hear how backend developers are feeling about nextjs 🤣, because as a front end developer i feel responsible🙁
It ain't a backend framework. People need to stop this shit talk immediately. Frontend engineers get dumber and dumber.
@@uziboozy4540 Convincing arguments, bro.
@@angelurena ain't here to try to convince morons. The fact that people are using React in 2022 is enough
@@uziboozy4540 Good luck expecting people to stop using a tool that they enjoy using to solve real problems for what I assume is nothing more than your personal preference. I'm guessing that you consider yourself above React plebs because your favorite tool is better at everything, right?
@@angelurena its about using the right tool for the job, and React hasn't been one of them for years
The look: 1 year ago and now 💀
It all makes sense now.
Is this video still relevant and what is it actually saying?
it is also not an SPA framework
...but react is
@@Chris-zt4ol yes but we cant leverage that behavior of react in nextjs since nextjs uses its own router not the react router and the app somewhat reloads on navigating to different link/url.
@@smartize uhh..... did you read the docs?
@@smartize No it does not, unless you implemented it wrong
@@smartize maybe they've updated since the last time I used it... I too ran into this. I had to implement react router for spa
This looks like what Django has tried to do for a long time
LOVE your CONTENT!!!!!!!!!!!!!!!!!!!!
Livewire makes this possible for laravel.
Inertia is also nice
Nextjs can custom server, express, that is fullstack
Working with file uploads on the server side with next js sucks. You have to use a third party library just to process the uploaded file data. Not mature yet.
this is awesommmmme
Thank you.
Maybe spell his name right in the thumbnail.
But it is also an ember js framework
Don’t compare it to Ember . Ember is awesome
so is next is pretty much like laravel
So unusual that a product needs defining years after going live. 😆
ayy it's ya boy theo
Finally 😮💨
Using thrid party to run cron jobs. Really?
That’s disastrous
THEO MA MAN 🤩🤩🤩🥳❤️
Finally
anyone else hate this guy for no real reason?
The reason you probably reference to is his smugness. While his "character" does not really resonate with me, he is indeed quote knowledgeable to I still Listen.
Nextjs is PHP++
good shit. I left FE development for BE development and now those fuckers are coming for my job
haha.. true.. but there are alternatives no/low code tools for building dashboard stuffs
@@_thehunter_more like for tinkering inside of a browser at 20fps to edit code without formating/autocompletion/vim commands or having to to rewrite the thing from scratch (or move if it's not FOSS) if your use case isn't handled.
Those tools are good for non devs or if you have half a day to accomplish the task
Backend devs will get paid less now that frontend devs are becoming fullstack
@@perc-ai that is so far from truth you have no idea. Big companies want specialists not generalists. Even if that happens I'll be retired by then probably
@@froggy3496 theres not that many big companies lol... theres far more mid to small cap companies that LOVE generalists. Frontend devs are quickly taking over backend developers jobs, unless your domain knowledge is really specific your safe. But if your just building CRUD API's rip
Follow Theo:
Twitch: twitch.tv/theo
TH-cam: th-cam.com/users/TheoBrowne1017
No, sorry. The fact that you can build backends in NextJs does not make it a backend framework. Rendering components on the backend does not count, sorry. I would welcome NextJS to go in this direction though (like BlitzJS tried / are trying to, like RedwoodJS aspires to).
Nice meme
Clown 🤡
for me, even react feels like backend
You feel wrong.
@@emreaka3965 yeah, i just use hugo, anyway.. 😅
This is already outdated aka Next 13 is out.
💻💯✨
Vercel, please don't promote this guy. He's a troll working every angle he can for his attention addiction. The guy is a child who will attack anyone who disagrees with some very immature and malformed takes. We don't need people like this.
Hard disagree, I enjoyed it. You sound like a crybaby being threatened by opionions and ideas
don't watch ez
Karens be like
@@johnbakhmat was he called into HR?
Theo and I had debate. We completely disagree. We left not agreeing. It was one of the best debates I've ever had
hi theo
Sup, nerd...
No, it is not backend framework.
Why not
@@Scrubzei for example th-cam.com/video/Rrz2q5uCHdE/w-d-xo.html
Every frontend framework is a backend framework as long as your boss is greedy enough to avoid hiring people who actually knows backend. I am very tired and scared of that trend when people who supposed to be centering a div inside another div starting to get responsible for handling proper authorization, predicting SQL-injections and so forth.
Sounds like someone's having self-confidence issues.
bad day?
Have you heard of the term "full stack"?
"display:flex;justify-content:center;align-items:center;"
done centering, now i can focus on my favourite activity:
forwarding user inputs directly into my sql statements
its actually not trivial since im using a orm but fortunatly prisma has the $queryRaw und $executeRaw function 💪💪💪
Everyone's tough until they actually have to use CSS, it'll make you lose your god damn mind
Full circle complete, yikes.
this guy should open a twitter or something
this man knows his shit
next.js single handedly saving react
killing*
no one is using vanilla anymore