Everyone's Making Fun of Next.js 14.0
Вставка
- Опубліковано 27 жов 2023
- So much stuff happened this week!!!
Honestly not a fan of server actions myself but people have really been memeing that one part of the Next.js Conf so much.. I feel like it's been ripped out of context a lot. So much new cool stuff to explore in 14.0!
Awesome article on SQL injection: neon.tech/blog/sql-template-tags
-- my links
Discord: / discord
GitHub: github.com/joschan21 - Наука та технологія
Your views and opinions are always helpful Josh, love your long-hours tutorials especially. Keep building 🙌
cheers dude
binod
great joke xD I deleted my subscription a long time ago, but youtube keeps recommending me this shit
Personally, I think you're doing a really good job, and sincerely, your long-hour tutorials help me learn and enjoy the dev world. Thank you for all. And if Kyle makes a video about you, that means you're doing a great job, and you're good at what you're doing. So, cheers, man.
Not only Kyle but Theo (in a good light) as well. Anyway being in my 40s, I enjoy watching Josh, great content.
keep up the good work, josh. your videos are super helpful. love the long ones where you implement an app from 0 to the end.
I’m convinced they used that sql example to create buzz by people who don’t understand basic JavaScript
I think people are more concerned about the seperation between frontend and backend
@@ramanujangunturu4996 it’s separated, via an api call
I must not understand basic JavaScript. I didn't even know functions could run like that.
@@jakehadley4044 Same. I have about 6 years of professional programming experience, have used javascript pretty much since day one and I have NEVER seen this be used like this, or this feature mentioned anywhere.
True, it’s not basic JavaScript
It's not the concern of SQL injection. Most of people are afraid of Seperation of concern of backend and frontend code. This reminds of the old php syntax that is hard to maintain.
if you’re so against frontend and backend getting mixed up then NextJs may not be the best option for you…it’s tagged as a “fullstack” framework for a reason…
@@mario_luis_dev Most modern full-stack frameworks still have separation of concerns. People ran to full-stack frameworks to get out of the PHP spaghetti code mess...now we're coming full circle.
Yeah, it seems unsustainable, love the way sveltekit does it
You can write unmaintainable code with any framework
Next JS is not Nest JS
Don't feel like your cancelled. You are one of youtuber I can count on to be up to date when it comes to web development space. I follow you content regularly. Keep up the great work.
He wasn't, lol. Kyle just pointed out a flaw in Josh's solution to a fetch problem. Since Josh is an influential content creator, Kyle believes that Josh gave out "wrong" information. The video is kinda clickbait, though
He wasn't canceled and that advice wasn't great. Kyle's argument was valid. I love the guy and his content is great, but no harm in owning to a mistake or offering a counter-argument (if any).
I bet that you not even have seen Kyle's video. You just said something nice to look nice.
Great video, I need to deep-dive server actions too in the next few days! The main issue i sssume people have is around seperation of concerns / PHP syntax but overall, I think it could be useful.
Impressive, very nice. Let's see Paul Allen's sql injection attack.
Heyyy dude, always appreciate your comments!!
You are the best, your explanations are as they should be, and your tutorials are of great help to everyone.
Jeez. Finally someone is talking about this. Giving hot takes before understanding basics is really bad. I am gonna subscribe to you for this ❤
You didn't get cancelled bro, you and Kyle are literally the only accounts I watch for web dev advice, tutorials, and current news.
Thanks for explaining so well Josh! Also do you plan on doing any videos/tutorials with React-native in the near future?
The Drizzle magic sql command works the same way, accepts a template literal that is then sanitized in the magic sql function.
I feel like the SQL Injection example is beside the point. They just wanted to give a simple example of what server actions would look like. Of course, in a real production system, you would design things in a more secure and scalable way, and not use the example on the slide on a real live system.
Yeah exactly, it was ripped out of context. It's super hard to fit all important stuff onto a single slide, I know from animating my videos with keynote lol. The talk was awesome
@@joshtriedcodingI totally agree with you man. People should really be applauding this release. We are getting good features and improvements. IMO, even if you don’t like or want to use the server actions approach, you don’t have to. It’s there if you’d like to not have to resort going through some API call, and Vercel is taking into account everyone’s feedback here. I truly think they have done a great job, and if people beg to differ, they should give some constructive criticism here. I don’t want to have blind hate here.
I am pretty sure they are using the @vercel/postgres npm library in their demo in which case the docs clearly states
"Isn't it a security risk to embed text into SQL queries? - Not in this case. Vercel sanitizes all queries sent to your Vercel Postgres database before executing them. The above code does not expose you to SQL injections"
If they're using the Vercel PostgreSQL library (and I assume they would be), the sql function is already a parameterized query, so there wouldn't be any chance of SQL injection.
Really great video, thank you for make me understanding something new in JS)
While I really enjoy the server components, I am getting increasingly worried about how new developers will now be able to write bad backend code straight in their react components. Also, this entire server actions feature, is it just me or do you think as well that this goes way against the "seperation of concerns" principle? I would not want to open a codebase where there is a button component which has an SQL query inside the JSX or the file for that matter.
I think they can be useful for just whipping up a quick app (assuming you don't need publically accessible APIs). I much prefer a regular API approach though. Especially because there are tools like tRPC & react-query that make error handling & loading states as intuitive as it gets
Its about being flexible. Instead of having an additional endpoint in your api folder you can have this function co-located. It can make it easier to use right and update. In our environment, we would have an api endpoint (used as a proxy) then call our .NET API from there that isn't exposed to the client. I can see it being useful. Is it absolutely needed no but as I said before it is more flexible.
Separation of concerns is very good if you want different pieces not depending on each other. Yes, it's super cool to have a "standalone" API if you want to one day build a frontend in a different language, with different technologies etc.
But if your app is by design made to stay "monolithic" and your backend is tightly coupled with your frontend and you will never add (or switch to) another frontend, then separating the concern just increases your codebase length, and sometimes complexity. Because it's that many more steps and files to dive through to understand what is happening when you press on the button. If the code is right there on the button component, then it's clear what it does.
Everything is contextual and has its pros and cons, as usual.
Do new developers write good backend code not in React components? I don't get your point.
Pretty much how JSP and ASP worked. Mixing everything together. A nice spaghetti mess but hyper productive
Hope you're doing okay and weren't too affected by Kyle's video :)) you're a huge inspiration mate
Appreciate you man!
But he was right....
@@codernerd7076 I actually feel both approaches are valid! Just for different use cases. Kyle's is appropriate for most general use cases in CRUD apps, where an initial timeout should not completely stop the query, and should just have a new loading state. However there are cases where you would want to completely stop the request on timeout, such as the server taking longer than usual, and you'd rather have your user re-request than wait.
You could have severala cases
1. Stop after first timeout (Joash's video, very valid for calls that will always be intensive and can be more represnetative of a slow server than a slow network. This could be something like getting an api call that is compute heavy on the server, and you know how long the server should usually take)
2. Stop after x timeouts - I've seen this used in zoomable image libraries like Openseadragon, where you don't want to keep waiting on data that is taking too long. You can timeout at 5 seconds, try 5 times and then stop. Completely valid)
3. Stop after the response is truly resolved/rejected, and use timeouts for loading states (Kyle's video)
I'm not experienced enough to suggest one as a gold standard, but I feel all 3 approaches have their place and just need consideration based on the use case you are applying it to
@@codernerd7076no one said he wasn't. Rest. No need to shove it down our throats
Kyle only brought one new perspective on the problem. It's normal: two great guys think better than one. This doesn't diminishes in anything Josh's great job, not even in that video -- it's good to watch both in sequence, but the way. If someone tries to "cancel" Josh for this, this person would be a moron...
Good luck, learning lots of cool stuff. Watching from Uzbekistan 🇺🇿
Honestly Next.js 14 just convinced me to learn php and be happy
I have been following for awhile probably subscribed much later (dont judge) but I love the way you explain things.
Please continue with the long hour tutorials. :)
And yes I mentioned once if it is possible to send you some “buy me a coffee” fund :)
Keep making some good tutorial I am learning alot from you thanks josh❤
really appreciate you man. happy to hear that
This is a hot take, but I'm personally glad that we at least have the option to couple the frontend/backend together again. I think we've taken the separation of concerns idea a bit too far. When I first started learning React, I admittedly loved the idea of keeping the backend/frontend far away from each other so that they could be developed separately, and either one could be reused for multiple web apps. But having worked in web development for over 8 years now, I can honestly say that that pattern hasn't really paid off on any project I've worked on. I've never once reused a frontend or an API, and I found myself having to bounce between multiple files and folders just to create a new page or form on a site.
Not saying that's the case for everyone, but for me, 95% of the time it just makes more sense to keep frontend and backend code together. It's faster to work with, and it's easier to see exactly what's happening. Yes you can shoot yourself in the foot, but can't you also do that with API routes?
Real life example for typical webstore: Backend (any implementation) + Admin on React + Website on NEXT. Perfectly reusable, but only in case it is normal REST API, not that buzz word server nonsense.
Hey Josh, once again a short and insightful video ! 👍🏻
And being cancelled is the prize of the fame ! It’s also the proof you re being watched
Great power means great responsibilities 😂
Finally I understand how to use template strings! greaat
I want my frontend and backend code completely separated. Just because we can do something technically, doesn't mean we have to.
Yeah exactly, it's nice to have the option and I'm sure they might be useful in some cases. I prefer to have them separated too, just makes the line between front- and backend much more clear
Just organize your folders and files separately then simply import a server function into the client code where you need any connection between client and server.
@@FaisalMahmood91 Yeah right, that's what I do, I separate Server Code & Client code. I prefer calling server function directly instead of exposing API from Server-side and accessing it from client side, it's just way too much work. That's the reason I love using NextJS over combination of React & NodeJS(Express).
Your videos helped me a lot more than todo's list guy
It’s indeed php/java/c# -like syntax, that was there since 90s, and thankfully forgotten. But at that time backend guys trying to embed frontend. Now it will be frontend guys trying to embed backend)
I’ve already seen react devs that exposed passwords and other internal thing to FE accidentally.
But now it will be next level, as while you using component’s tag you have no idea whether it is server or client :)
Anyway, the wall between worlds is no longer there, so it will be interesting to look at all this
Great to see this example. Do you think server actions could largely replace the need for trpc ?
i also thought about that! i think for most cases it's easier to use server actions but tRPC would still be great if you have your backend separately
I guess technically both are "tRPC's", because both offer you an rpc-style way to call your backend with typesafety in mind. For me, regular API routes are the winner because I feel like handling loading / error states in server actions is just not as intuitive. But we'll see how their adoption comes along, maybe it'll be a whole different story in a couple months time
Not every major version comes out with a lot of new features. Technically all of the minor releases after the last major release may just be part of the new major release but they're all debugged and working properly and the app is on to the next phase.
I don't understand the difference between "partial prerendering" and the way suspense streaming already worked before
thanks for your explanation josh!
Hey Josh, I can't seem to get video element events to fire if the parent component is a server component. Any insight? I'm trying to make a loading spinner and hide it when onLoadedMetadata fires.
I'll get on board with React and Next when they finish it.
Same as mine 🤣
Always wondered how people made those template string functions.
Josh , Kyle and Theo have helped us a lot. We are glad to have you guys in the community!
As someone who just started learning NextJS, I was worried about all the trolling as I didn't understand a thing and assumed I chose the wrong framework. But this video cleared many of my concerns. Thank you!
Can you use js,html and CSS without any other framework?
@@samanderson4881 yes, you can.
Seriously? People started to learn new lucking next 13 and even there is like no proper tutorial exist about it and they ship new next 14. I've done with next, if i don't especially demanded to write it i never write this kinda non stop changing framework. I'll go with svelte, it's best js framework we could ever saw.
The issue with sqli thing is that many people are used to syntax like
DB.query("...where id=$1;", id)
where it's clear that it's parametrized. No special syntax or anything, just a pure function call.
Not entirely sure myself if this is true for nextjs, but in Solidjs serverActions don't even make it to the client, all the client gets is a sort of RPC of the method.
Which is totally black magic fuckery, since we devs write something inside the "client code" but then that client code gets so heavily transformed.
Solidjs ❤
I learn a lot from you, please keep cooking ❤️
Tbf that problem of separation of concern already existed since the beginning of nextjs, server action is just a way send form data without defining an api route. In general most ssr frameworks will have this issue
Keep up the good work , learnt a lot from your videos
Your views are amazing, keep making good content Josh 👏
🎯 Key Takeaways for quick navigation:
00:14 ⚡ Next.js 14.0 brings significant speed improvements, with a 50% reduction in local startup server time and a 94% boost in hot module replacements.
00:43 🏗️ Partial pre-rendering allows defining a static HTML shell served immediately, followed by dynamic content streamed in later.
01:12 🤔 Server actions in Next.js 14.0 have sparked debate due to their syntax resembling old PHP days and potential security concerns, specifically SQL injection vulnerabilities.
02:21 🔍 SQL injection vulnerabilities explained, emphasizing the importance of parameterized queries for safe dynamic insertions.
06:49 🛡️ Template strings in Next.js 14.0's code example demonstrate a secure approach, utilizing tag functions to safely handle dynamic values and prevent SQL injection.
Made with HARPA AI
that is you personal opinion and i respect that.im working with react and satisfy with it.
I'm crying tears of joy, but mostly frustration with the broken caching system
next.js 14.1 will probably fix it, lol
What problem do you have? I had not use caching that much
@@neociber24 It's enabled by default in Next.js 13. Any page is cashed unless you explicitly tell it not to. This happens in the production build, so you won't notice it until you go prod and think something is wrong with the database or the server because the docs are a $$
Typescript flexing, right on your face!
Ok you answered just one of many questions/problems about this approach, but the bigger concern is about the separation between frontend and backend, that the community around the world agreed that is horrible to "mix" the server with client side, like the "old" PHP did, that's why we moved to an API and Client architecture instead of a MVC architecture. And running a SQL script asks for more than just calling it. When you have a proper backend you have many resources like: load balancer, caching, pagination, many things that are more complex than just calling the SQL itself. And what prevents the dev from making a big SQL query with many relationships inside the use server?
you say it like the API architecture is going to be replaced. This is a feature that if you want, u use it, if not dont. No one is forcing you to use server actions. It is at your discrimination when to use it or not, there is some situations where having an API is better like you mentioned, but there some situations server actions serve its purpose.
Parameterise function calling I learned something new
i dont think kyle cancelled you, he corrected you and showed a better approach plus gave you some spotlight, more like a shout out, i hope he contacted you first before publishing the video, he is one of the nicest guy i know
You're my favorite channel Josh. By far ;)
appreciate you man!
is there a library that provides that sql tagged function?
I’m confused isn’t partial pre-rendering just hydration? Isn’t the whole point of suspense to literally stream data later to not block the page?
No exactly, with partial pre-rendering you send the HTML without the inner content then the content is stream and place inside
One year later we still cannot opt out of default fetch cache! :(
Yeah that's a pretty classic injection issue and the exact reason they switched to database ORMs like 10 or 15 years ago. Development trends are an ongoing cycle.
Great content as always Josh, vielen Dank!
I would love to be able to try turbopack, unfortunately not a single one of my projects starts without throwing an error instantly when I use the flag 😅. There is also the whole caching saga that is going on for a year now. Overall lots and lots of broken things with the app router and very weird decisions from the team. We have come full circle from the php days but adding extra layers of complexity on the top for almost zero benefits. Still, I have faith in the Nextjs project…
Man, I don't care what anyone says, there is always something to learn from everything. Including you and that other guy, both of you are perfect content creators! I have learned a lot from both of you and will continue to do the same in the future. People on the internet are super harsh since they can, and no one can do anything about that. I'm pretty sure in the end we are all here to learn and improve and as a content creator, you will continue to provide and do your best even though it takes a lot of your time to come up with ideas and the hours you put in when no one is watching. Please continue to improve and provide us with more quality content. everyone is wrong, and no one can be right every time.
I think you care. If not you would not been watching this channels. If he said something wrong, people must point that out. Lets just be rational.
@@MRCDF7 Looks like you didnt notice, but I clearly stated everyone can be right or wrong, you just learn from that. So...of course he got corrected for the mistake he made, but what are you on about ??? lmao
I recently started to learn Next.js. I find it really funny how i get into the 14 version of framework that has barely any functionality and almost none conventions. Whoever invented Next.js have no idea what frameworks are, because only thing that i see is a messy library in which you need to build around, not otherwise, like you would expect to deal with library. I have literally flashbacks from using React for the first time 8 years ago. Next gives me the same vibes of immaturity of "wannabe framework"
Anyway great video :)
You gotta collab with WebDevSimplified bro!
As a Jhin main, 14 is when I will start using Next :
The art begins xD
bro it ain't an sql injection if you use a special string template thingy.
Like the function Prisma.$executeRaw`` you could pass in parameters as if they were regular string concatenation, but it is processed and sanitized by prisma automatically.
bruh your videos are pretty informative, no matter whatever people say.
It is good video that can help us get all in a secode.
I think new app router next still has many problems like how to stream a big video with a single response? because we can not pipe the streams with response. I had search a lot but no where I could find it, could you please help me.
but if the userId is still passed as a string in second approach, a hacker can still inject SQL query, right ?
man that code was an example just to people know that is running in server side, everyone uses an orm for crud
It uses all those canary-stable features and 'works' on 'all' none Vercel hosting... 😅
You basically summed it up at the end: people clowning and making stupid jokes about the "use server" statement in the demo need to give their heads a shake. Why would the Next team put that up if they knew how bad or broken that would be?
It's not about SQL injection, it's more about an architectural thing. And btw we also never done such things in PHP ✌️😁
How does parameterized query escape the illegal strings.
Where are you checking that dev test? How I can do that?
Or they may want us to talk about it;D
Great video Josh - but more important was you getting canceled this week and we didn’t explore that 😂
the example was just a simple way to demonstrate backend functions being called in the front safely, in a real world app a person will use a ORM not write a SQL statement.
Remix ftw with how they approach server actions
I'm getting this error while using puppeteer "Could not connect to the CAPTCHA service. Please try again.". Any idea how can I fix this?
We really don't know if the given code is vulnerable against SQL injection. We probably should assume that "sql" has defence mechanism for that. The problem is that they used overly simplified example for Server Actions which may encourage inexperienced devs into writing poor code.
Naw you’re not canceled. Web dev simplified just said “idk you’d cancel a pending promise after 2 seconds and error it out”.
Great vid. I think your vids bring alot to the table and lookin forward for more
I guess the promise got cancelled then lol. It's all good, his suggestion to let the user choose when to abort is great. Appreciate your comment man, cheers
ok, but is nextjs 14 any good?
People (wrongly) making fun of something they don't understand on the internet ? Not surprised at all.
cheers, thoroughly well explained
Man I can't believe how many people used to trash on SvelteKit for its "magic". NextJS's "use server", "use client", is pretty magic to me. Kind of an awkward one for JSX to be honest.
sveltekit have implemented the best way to handle server actions . next js now is just bunch of abstractions on top of each other server components was never a good idea
So, what do I do now?
Which framework to use?
What get the job done
@@neociber24 i expected a better answer
Great job there.
I think most of the critics come from the fact that they can't handle SQL injection issues. I'd say they get a crash course on SQL and they'd see its rather very simple to handle injections
How do ya compare it with Astro?
Hey josh can you make a project with three js
Everyone makes mistakes, and you are a very talented programmer, I'm still a faithful follower of you, your work is amazing and I love how you approach solutions and implement projects, keep doing your work, it's just amazing! 😉👍
History repeats itself
it was just an example. no one will use sql injection, when you can use ORM
Bro, your explanation is soooo good, ❤from India.
One suggestion please slow down your words if possible, This would be more helpful for people whose native language is not English.
Yeaa Im still getting error when use turbopack
Josh, i don't think I agree with your arguments about parametrized functions.
What is the difference, whether i call it like this:
const userId = "'; drop table users; --";
db.query(`select * from users where user_id='${userId}';`)
or like this:
const userId = "'; drop table users; --";
const sql = (strings: TemplateStringsArray, ...args: string[]) => {
// concat everything into a single string here manually and call db.query under the hood.
}
The problem stays the same and not related to the way we represent the request. The question is are we doing parameters sanitanization (sanitization?... whatever) or not. Somewhere deep inside the code some sophisticated parameter-checking methdod should be applied for every single parameter we're passing to ensure it does not break the scope.
Gets criticized, says he gets cancelled….
They released NextJS 13 after September 2021 and then they released NextJS after January 2022 so we have to learn it for real as we can not ask our Agents and Assistants to help us???
The fanny thing is going from naive SQL to ORM then back to SQL,... In this case, going down all the way to binary will be good 😂
next is the next overconfident noob magnet.
Next-Auth is still not stable with v14 😢
Actually Next13-beta became Next13 lol
Thank you for sharing this. I got some new tricks from your demo here.
However, I think you're kinda missing the point of the sarcasm being made on this feature. It's not really just about the security concerns (that you just discussed), but also about going back to the PHP style of coding years back. Like come on, can you convince someone that in 2023 you'll be writing SQL scripts in your FE app?! Where's the separation of concerns? Where's isolation?
I believe the mockery is about going back to ways of implementing the FE that's very obsolete and almost ancient by today's standards and this feature might produce more problems than benefits, if any .