Dude, the thumbnails... Please stop

@FumezCreates

6 ай бұрын

The thumbnails are the best part 😅

@timelessnesses

6 ай бұрын

i do love his thumbnail not gonna lie 😂

@MrLucasEss

6 ай бұрын

I tend to skip watching some his videos just because of the thumbnail… what kind of audience is he trying to reach with these things?

@coder159

6 ай бұрын

I just want to be able to share these videos at work without coworkers being weirded out.

@TreTurnerDesign

6 ай бұрын

Yea the thumbnails make me not want to watch the video. I get it, the algorithm likes it when your mouth is open and stuff, but these are a bit much.

Love the Data access layer. It's almost like it "controls" the view layer. It might be helpful to model the domain after that? Not sure, though. Probably nothing that no one has thought about since the 70's.

@jameleddinelassoued7228

6 ай бұрын

Lmao can't believe we went full-circle back to DTOs. Why not just drop JavaScript and go back to writing Spring apps instead?

@nekogami87

6 ай бұрын

At that point, I'm just gonna stay on rails, and try the NoBuild pattern they push in their latest version.

@christiannickel9801

6 ай бұрын

Lol, next we could create more jobs by having sysadmins manually move deployments to production servers.

@KapnKregg

6 ай бұрын

It's hilarious how JS libraries and frameworks are always announcing some new way to do things that have already been well established by other languages decades earlier.

@drewhjava

6 ай бұрын

@@jameleddinelassoued7228 I Love how they called them DTO's and not DAO to prevent the negative connotation in Java community. Can't wait to add a new layer called EJB's

It seems that when React and Next.js address one issue, they also tend to introduce additional issues

@pablom8854

6 ай бұрын

I'm getting bored of Next man, too many updates that aren't stable and I'll never finish studying. I started an app with the t3 template 2 months ago to find out there's a new router, now next 14, fkit I'll explore more and do thing by my self (ssr)

@essach9750

6 ай бұрын

just use bun man @@pablom8854

Do I lookup “Taint” with Merriam-Webster or do I use Urban Dictionary? Just want to get the right definition.

This is just madness at this point. I'm 100% certain this is going nowhere and everyone gonna go back to using old school API way.

@theklr

6 ай бұрын

Jokes on you that’s what this is….

@thesaintnoodle

6 ай бұрын

API is old school?

@vishalsangole836

6 ай бұрын

@@thesaintnoodle yeh, they just didn't call it Api?

The react team has been trying to cleanup their own mess for years now while introducing footgun after footgun. Don't like where this is going at all. Personally will stick with a little SSR and mostly client side react for existing projects, and just use solid or svelte for new projects.

given these footguns, it really makes me wonder if the app directory is worth it...

@jimbobu

6 ай бұрын

Theo watcher don't say "footgun" for 10 minutes challenge *difficult*

@theklr

6 ай бұрын

This isn't necessarily app dir, this is RSC.

@PhilipAlexanderHassialis

6 ай бұрын

Arguably, the same problems can appear in the traditional pages directory with getServerSideProps. You don't sanitize stuff, you expose it as props, you store them in a local object in the code that will run in the client or (gasp) as initial useState variables and a simple extension can expose stuff. So, it's not the "app directory" itself. It's the huge, ridiculous gap between people who will throw a takeout's amount in two Udemy courses and say "oh, I know React and Next" and the seasoned developer who understands problematic stuff when they see them happening.

@wrux

6 ай бұрын

After years of bad practices, I'm guessing the app directory will push React devs to work in a much better way

@jafetguzman5012

6 ай бұрын

My biggest concern is that it was called "tainted" when it should've been called "flagged".

Band-aids on an architecture that MAYBE we shouldn't even be doing.

@go371211

6 ай бұрын

Every new React features feels like band-aids for problems they created in the first place

This is madness. Seems like throwing complexity at a problem that shouldn't exist in the first place. Just use an API.

@nickwoodward819

6 ай бұрын

*see also: React in 2023

@JoffeDall

6 ай бұрын

Yeah, what the heck.

@Patrickdaawsome

6 ай бұрын

Nothing JS engineers love more than complexity

@FacadeMan

6 ай бұрын

JS thrives only cuz of complexity.

@go371211

6 ай бұрын

Yeah, it's cringe

What are we even doing anymore? Feels like the result of a lot of bored engineers finding ways to invent problems to solve.

And here we are again... re-adding already solved problems... The Pages Router + API was ok, why do this tbh?

People complaining about app directory don't understand that this is a thing that can happen in any kind of framework that talks to the server or any templating language like php and django. If you're not careful what you're returning you can expose data that you're not meant to expose. Because RSC is js/ts in both server and client you're able to do these kind of checks and actually make your app more safe especially when working in a big team. Edit: Most of comments say that APIs are better. They are better because you don’t think about it because someone else has done that work. That doesn’t mean it’s less work in fact that’s more work because you need a layer between the database and the frontend. Also anytime you need another field you will need to rely on someone exposing that from the API which can take a lot of time.

@ea_naseer

6 ай бұрын

Hmm as a php dev this is true. Usually the only way to solve this is to use something like Laravel Model or just discipline.

this is cool and all, though the syntax seems so counter intuitive to me. i love the way Remix does data flow, even if it's route level and not component level like RSC + server actions. if we could land somewhere in the middle, it would be so cool.

Problem with layers is that coupling (while giving a big advantage first) will eventually overcomplicate things. Suddenly you will have a method used at 16 different places. Sounds like goal achieved, no? No. Use-cases should not all be generalized, but optimized for. Usually you would use vertical slices architecture, but it's weird to do in NextJS because of the file-based (API) routing.

@Calinica93

6 ай бұрын

Adding a data access layer per route works just fine. Been doing this along with dtos since class components.

Considering how easy is to leak stuff this way i reckon best practice is to use http apis and old school “ajax” to mutate data, otherwise its inevitable that sooner or later stuff will Leak

@pacifico4999

6 ай бұрын

All these frameworks are obfuscated ajax anyway, let's return to the og

@ea_naseer

6 ай бұрын

​@@pacifico4999fetch right? right?

Thank you for posting this video before I go to bed 🙏

So, we are coming around to MVC patterns again uh?

@27sosite73

2 ай бұрын

looks like yes ...

Can you make a video explaining the new partial prerendering feature of Next 14? Because I don't understand it from the release blog post 👀

@t3dotgg

6 ай бұрын

Soon!!

@codinginflow

6 ай бұрын

Thanks @@t3dotgg

I've deleted my api directory and have only been using server actions for some time now. Is this not safe? Would trpc help?

Is there more reading material on why this is an issue only with SSR? Would this be a non-issue with CSR and traditional rest apis

So we invented this new model, it came with lots of problems so we invented new tools to fix those problems but they also have some problems. also keep your data fetching in a single layer. At this point just use Remix and avoid the minefield altogether

@27sosite73

2 ай бұрын

okay feel free to use remix i will stay with next js

This is very informative. Thanks a lot!

Remixjs just became a much more attractive alternative, may be just because of this. Use it in the meantime while you get used to all these commandments of RSC in Nextjs😂

10:34 Honestly, I'd never, EVER, define the secret in a component file in the first place. It'd have to be restricted to the server.

Audio sounds great on this one!

8:05 Server actions went from experimental to canary. They're two separate release channels.

can someone please make it clear to me that if i have sensitive info inside a Server component is it secure or still an issue? i understand that inside client components it is an issue as that code gets compiled on the client side but if the server components are not secure in execution of that and the need to use "use Server" to specifically tell it why is it even a server component then besides from the rendering part.

I use the nextJS api route as a proxy to the express backend where the magic happens

7:16 - *MEOOOOOW*

@geekofia

6 ай бұрын

🤣

Next 14????? Holy Crap, Next 13 STILL HAS MAJOR ISSUES.... this company....

@derek123wil0

6 ай бұрын

sometimes you have to make a new version to fix the old version

@V3LOXy

6 ай бұрын

@@derek123wil0 They should have proper release cycles and LTS versions

@venicebeachsurfer

6 ай бұрын

@@derek123wil0 v13 is the new version...

Your thumbnails don't match your audience sir

I feel like Theo is the type of youtuber who doesn't need weird thumbnails and he's such a good dev compared to many of us. Definitely much better than I am. Am I the only one who thinks this? I mean, we're the type of people who look for information, not overstimulation.

@t3dotgg

6 ай бұрын

What if I just like having fun with thumbnails?

I really liked this breakdown.

a safety boundary between frontend bits and backend bits

@nickwoodward819

6 ай бұрын

a boundary they themselves violated?

React invented Java... gotta get all the dto's

I.. I'm going back to simple ssr templates. JSX works on the server too just fine.

I don't see how you can possibly look at this feature and think "this is a sensible way to write code."

Without unneeded complexity react and next developers would be out of business

I am in the camp of what real benefits all this complexity is giving the developers. The real security is to reduce the client side code, since that is visible to the user and having a large codebase also slows down the page. Using the newer features built-in to the web browsers is more secure and should allow for a smaller codebase on the frontend. React is getting too large to be a great solution. I know that React might be needed for a little while longer as support for these new features have to have higher browser support.

thanks for posting this

Ah the classic React stylez, let's re-invent a pattern that's been known for year.

Overengineered much? Big fan of making the right thing to do the easy thing to do. This is certainly not that.

This is so dumb. They are trying so hard to have their cake and eat it too. Separation of concerns is a good thing. I wish react would go back to trying to be a great framework for frontend.

Am I missing something? What the hell is this syntax 2:43 line 18? With sql`....`

@beratbayram

6 ай бұрын

Template Literals. It is a JS feature not related to next or react. Lit also have these: html`Hello from my template.`;

@borisoid

6 ай бұрын

@@beratbayram oh, it lets you override string interpolation logic. So you can prevent sql injections while keeping the code clean. Nice

No mutations? not even an analytics event?

yoo what browser is that though? looks sick

@aftercamp4322

6 ай бұрын

it's arc browser

Do you even shave?

Seems a bit barebones. It could benefit from more/custom Taint Types like in PHP Psalm

So what we get out of this?, After doing all of these things and probably leak sensitive data (dont lie to yourself either you or your co-worker gonna mess up)

I feel like everything they do to mitigate these very valid and bad security issues is an afterthought now. The taint thing feels like PHP called to get its very old, very flawed, security mitigations back.

React and Next are becoming so intertwined that I lost myself multiple times in the video. Who's Sebastian working for again? It's so awful to watch this happen.

@theklr

6 ай бұрын

That’s usually how metaframe works go… Next depends on the react team to implement upcoming features and with majority of the old react faces moving to vercel it shouldn’t be surprising

In the CSRF part of the video, I think you're mixing CSRF and XSS, no ? CSRF has nothing to do with injecting HTML that comes from a user. This exposes you to XSS. CSRF is kind of "the other way around", usually (request made to your backend, from another website).

can you please enlight us about SSR vs SSG vs ISR ..........🙏🙏🙏🙏🙏

nice, more bullshit to worry about. everyday i want to use react less and less.

@RaZziaN1

6 ай бұрын

they are coming back to ways thing were done back in the days, but using it in next/react is pointless. We already have spring/NET and api approach and client, react should be only view layer and client nothing more. Next is NOT fullstack framework, it just has some fullstack functionalities but its not fullstack.

I don’t understand the point of server side components if they just render on the client anyways or expose your data. All of this unnecessary complexity to just serve data to a front end. SSR was supposed to make things easier, not add even more levels of abstraction. I love Next.js and React is fine, but this is absolute madness

@theklr

6 ай бұрын

They don’t. They render html and then js. It’s still server side rendering, just like two decades ago, same issues with moving data around.

@orosales123e

6 ай бұрын

​@@theklr 2 decades ago is not really a good 1:1 comparison here. I was mistaken on the rendering part, but there's no way this "let's add another layer to solve this problem" is a good pattern

@theklr

6 ай бұрын

@@orosales123e it’s the principle of MVC and separation of concern. Then SPAs introduced the idea of collocation. This just blends both in where streams now have stages

@orosales123e

6 ай бұрын

@@theklr Right, which is why IMO this pattern of "let's just add another layer" is flawed. It's overcomplicating something that never needed to be complicated in the first place. At the end of the day it's just taking data from one place and putting it in another. With MVC there is no need for stages, you just send what you need and you can trust that the important data is hidden due to SOC.

It would be great if we could name columns in the database with a prefix or metadata that marks that column as private info. Then we can easily filter out those columns before sending it to the client. Postgres has row level security, but we also need is column level security.

Ok. Got it. Nextjs tries to be a backend solution and doing a not so good job at it, taking into account all the hard work these people give into it. Can't figure out why this wont end up in a coupling hell. Seems like it introduces new problems that we already solved way back just to reinvent something for a 0.01% benefit. I guess that's why true backends exist. So long and thanks for all the fish. I will come back in six months to see the video explaining why this was eventually bad and show the new way. Coloring all this as progress and not beta.

Say the line... footgun taint trpc next tailwind

Only here for the taint definition and bc the thumbnail is strong with this one. Yo-duh told me so.

Tainting your backend with JavaScript is a code smell

@vikingthedude

6 ай бұрын

Coding your backend with javascript is a taint smell

@brunocabral88

6 ай бұрын

Backending your code smell with a taint is a Javascript

@thatarif

6 ай бұрын

coding your smell with javascript is a taint

I envy simple minds that can get exited about such crap.

Performing SQL calls in a javascript framework, whether they call it "back-end", just smells bad practise. Let a real backend framework handle this, like .NET. Also, the Data Access Layer was something we, as backenders, used a lot 10-15years ago. DTO is still used and has been used quite a lot. So my point is that now that JS has become more and more "back-end", it's not really adopting newer trends, but rather trying to re-invent the wheel.

Wow, its almost like js devs keep reinventing the damn wheel over and over again. Everyone should just go back to templating and some real backend language with just plain js on the frontend when and only when needed 🤦‍♂️

I'm sorry but this RSC paradigm is becoming a joke the more they work on it

all of this so we don't have a lot of spinners on screen

As someone who’s proficient in Angular and Vue (in addition to React) this is kinda why a lot of people still prefer Angular.

Its almost like the React and Next teams wants to make vulnerable software at this point. Wtf are they thinking? How is blurring the lines between the frontend and the backend at this level a good thing? Juniors are going to commit atrocious security vulnerabilities everywhere if this crap gets adopted. What if someone forgets to import this "server-only" or whatever package its called into a file? Which is going to happen. It's just insanity

Ok, so I can stick with Trpc both for mutations and RSC, without worrying about these problems. Separate the client from a backend API still feels superior, even when you're doing SSR.

@gotifly4477

5 ай бұрын

I use nextjs api route as a proxy to the the express based backend where the magic happens

I switched to Nuxt. Next is doing too much.

React devs reinventing the same wheel the rest of the world invented 20 years ago.

Theo, I think you reframe from calling the bullshit, probably cause vercel funds you

Yay first taint taint woo

07:15 miauw

Seems to me that RSC is exposing lots of footguns that newer devs won't be aware of or know to look for, and those devs likely don't watch this channel or even know it exists. As for the word "taint", what a terrible choice. The obvious anatomical reference not withstanding, this data isn't "tainted", it's just not appropriate for the context it's in. Come on, thesaurus nerds - what should it be called?

@nickwoodward819

6 ай бұрын

SUS

@ea_naseer

6 ай бұрын

overshadowed

No thanks

Should I put this skill on my resume?

Starts video, “So React showed me its Taint”… woah there buddy pause 😂

Urban dictionary 😂

Developer Experience on Nextjs still sucks. Waiting for 10+ seconds for HMR to reload after code changes is not acceptable (on other Linux/Windows pc/laptops that are not Apple M1/M2 Macbooks). Any new features are completely useless/meaningless if you have to constantly stare at the loading screen.

All this added complexity is for what?

Or…gasp…just separate your backend and frontend.

Bye Next. Your priorities are the wrong ones.

This is madness, its like back in Holocaust where I am suffocated by React smoke

7:16

I don't like this direction at all. I work in security for quite a while and complexity is usally not making a piece of software more secure.

@doc8527

6 ай бұрын

Harsh reality: most devs are extremely stupid, giving them more options to achieve same thing, they will screw up everything. Not just for React, but for every framework, every engine and every architecture. Those versatile options always belong to minority, there is a invisible skill gate behind it.

i'm so glad i left nextjs

One more reason not to use NextJS I would say

Nuxt anyone?

im never going to recommend ssr

This is Progress ehh? NextJS/React is failing us. Thankfully, so many great alternatives exist.

first

Just send HTML/X

@gotifly4477

5 ай бұрын

X? You mean JSX?

All of these directives, like use client, use server and import server-only are actually just horrible hacks. I don't know how we got here. This is NOT an improvement, and I really hope NextJS dies because of this. It's not a pleasant developer experience at all.

@RaZziaN1

6 ай бұрын

they are coming back to ways thing were done back in the days, but using it in next/react is pointless. We already have spring/NET and api approach and client [react], react should be only view layer and client nothing more. Next is NOT fullstack framework, it just has some fullstack functionalities but its not proper fullstack.

While talking can you stop chewing the words would be more clear what you are trying to say.