"I haven't used it enough to have a strong opinion" If we can just... normalize this sentence/approach, discourse around software dev would become so much more enjoyable.
I said this exact same thing when people asked me about Tailwind. I had researched it, but I had never used it, and I had a strong negative opinion about the class bloat on your HTML. But when people asked me about it, I didn't mention my negative opinions, I said "I haven't gotten around to play with it myself, so I don't have an accurate opinion about it yet." A month later I picked up tailwind and I've liked it ever since. I still dislike the class bloat, but I love everything else.
I met a guy recently in Japan and he builds JS apps without any library and handles all DOM manipulation manually with a bunch of functions he created himself. It was impressive to see what he could achieve and was writing code on a Chromebook without any build steps. His code was so so ugly, but he was able to build some interesting projects.
worked with a guy who did this, he was adamant about me and the rest of the team has to follow suit, i kind of didnt like him for that view because no way in hell am i going to use pure javascript to do dom manipulations, i cant spent 2 years building a dashboard
@@ThePrimeTimeagen I'm also trying not to use JS on my website, even in form of HTMX. For now it exists only in my html5 games that I host there. Every other page is server-side generated and sent with full reloading just as in good old days of PHP or something like that (which I didn't catch).
@@clickadelic7681 and I don't think there's anything wrong with it. Also I'm writing my own server with minimalistic router and markdown parser. Hugo is cool but "too static" for me (:
I know you are mostly just being funny but I am firmly in the Rich Harris camp that the problem with web performance isn't JavaScript and frameworks, it's commercial decisions.
Big oof. Gotta disagree slightly on this one. Yes the triple backtick is rubbish in Teams BUT if you haven't already try clicking on the "Text Formatting" toggle button and then click the "Insert Code" It's actually shockingly good imho 😇
Nextjs is a wired framework, if you use it without thinking about it, it seems nice, but when you start really thinking about how it works internally and how the deployment/hosting work, it start to be confusing
And, if there weren't so many glitches in the matrix, I wouldn't have to think about it! 😂 I unfortunately learned more about Next than I wanted to, so I am not excited to use it for my next project.
I dont know...some things I see in web dev remind me on the developments my industry (civil engineering infrastructure design) went through decades ago when computers etc. became a thing. 50 years ago, designing, calculating and building bridges was a pretty straight forward thing. why? because the tools were limited. there were tables for some predefined situations, and calculations and drawings were done by hand. when you do stuff by hand, you automatically reduce it to the necessary. when the tools came that should fasten and simplify everything, a lot of often unnecessary complexity was added to the projects in a "we have the tools now!" mindset. so much that you can argue that the advantages seem to be completely gone or even turned to less effiency. thats what probably also happens with a lot of web projects. people use frameworks because "it`s fast and simple" and then they stuff their most of the time pretty simple app with shit until they realise it`s not fast and simple anymore.
I think the increasing divergence from Remix's philosophy / approach with Next JS's philosophy / approach is overall a good thing for both frameworks. They are becoming increasingly distinct from one another as time progresses. Next js is your shiny brand new sports car with the latest gizmos while Remix is like a simple and efficient EV sedan that is plenty fast, but not focused on the bells and whistles.
More like remix is a car with wheels and you understand how it brings you from a to b, if you hit the gas. Nextjs teleports you trough some subspace conduit to anywhere in the Galaxy while you are trying to visit your friend from down the street, but you have no understanding how you teleports and what it will do to your organs long term, even though teleporting is cool and all your friends do it.
@@gm42069 At first yes, when it was just React + a file based router and easy SSR/SSG, now it's different buddy, they're reinventing the wheel with each iteration and deliver beta software under a "stable" label
next started as a tool for react users to build websites.. not apps. every unintuitive stems from that root. It's like html css, it was created for people to assemble documents... static documents like newspapers and magazines. Future capabilities are built onto of that
We had a bunch of frontend oriented devs that really wanted to move to React, they landed on Next JS. The best compromise we came to was only using the static export of Next JS. CSR, SSR, vercel hosting, serverless what the hell are those? We just have a bundle of html, js, and css that calls our APIs.
Its like working with children when they tell you their Lego's House is better than your Wood and Brick House. You start questioning what the heck the modern industry is doing? Its like its being controlled by non-programmers that want to do it the hard way.
@@complexity5545 Nah, the hard way is creating over-engineered and unnecessarily complex solutions like Angular. Next.js - or any other framework for the matter - isn't even close to "the hard way".
After manually making a site with nothing but pure JS, I appreciate the work these frameworks do. Sometimes just because you can so something doesn’t mean you should!
It's like I always tell people, if I want to make you love JSX I will force you to work with the DOM for anything that is not a tutorial and has some meaningful functionality.
100% man. I see these frameworks basically being developed for industry. They evolve as the demands of companies evolve, and unsurprisingly they end up being very complicated, with lots of choices to pick from, many ways to make the wrong choices. Then someone comes along and ditches 90% of that complexity. Their solution is much easier to apply to most non-commercial projects and harder to shoot yourself in the foot with. But DX
I felt this when I discovered a complete lack of support for controlling the response Expiry header. I thought “these folks are smart engineers, surely they can’t have misunderstood how HTTP caching layers work?”. With that in mind, it became painfully clear why. It encourages you to use stale-while-revalidate, which lets Vercel then provided cache control as a “feature” instead. I fell out of love with Vercel that day. I hate greedy companies. Especially when they intentionally make things worse, so you have to pay for them to be better, under the guise of “open source”. Open source isn’t the same when your cronies control what’s in and what’s out, intentionally hobbling the design so that it plays into using your platform for features that’d be designed in from the outset if you were using anything other than NextJS.
Self hosting nextjs for production is not the save as using vercel. Caching doesn't scale as it uses local files as a store. Next has an experemental feature to use other cache storage, but it doexn't work with revalidatePath() so it's not easy to just self-host nextjs app
What we do and what works very well for us is to just use SSR behind a CDN with s-maxage being like 100 years. Instead of revalidating paths in Next, you just invalidate them in your CDN and you’re pretty much good to go. Next request will cause a render and after that (at least with CloudFront origin protection) that should be it.
I use Nextjs professionally, and while it's getting more bloated with every major version bump, and there's a lot to dislike about it, I really fail to see why people have issues deploying it? I've deployed it on bare metal, VPS and cloud infra, always in a Docker container, never had any issues running it self-hosted. If you want api versioning and elaborate caching, you have to set it up yourself, it is self-hosted and much cheaper after all.
I did not find it very difficult to host NextJS when I was still using it (I stopped after trying to accept that version 13 was all of a sudden an entirely different thing). But I host everything within Kubernetes for years now, so basically I just run it with Node and Nginx as two separate docker containers. This way it can auto-scale and it becomes super easy to host it on any cloud or other infrastructure.
Same. Do it everyday in one of the cloud providers. That said, there were some serious growing pains to get the dockerfile running correctly, but there are now good examples of how to get the dockerfile going.
Am I the only one who feels like nextjs isnt getting any faster even with their new 14 update. Im using shadcn and tailwind and im literally restarting the server every 3 minutes cuz it wont render the component or the tailwind classes i added. Its frustrating 😔
Not putting all of your eggs in one basket if that basket is managed by a company that is not profitable is a great piece of advice. What happens when the VC looses interest and hope?
That problem isn't limited to small companies either. Google is notorious for randomly killing off its projects. The Linux community is arguably the most aware of this phenomenon in the tech world, after repeatedly getting burned by corporate interests (most recently with the RedHat/IBM debacles). Proprietary platforms, and even "open" tech heavily reliant on proprietary services are just risky business for the average user/developer.
@@LambdaCalculatortrue, a lot of companies and other organisations have lost tones of money and time integrating with Google platforms that were discontinued a short while later. So you are right that there are many factors in longevity.
But the React team explicitly stated that the canary features used in Next are stable for the framework, even though they're technically canary in the overall React project. The projects are mutually exclusive, but obviously collaborate well enough that certain canary features are being prioritized during development, at least whatever the Next team needs.
Moving through nextjs major versions over 4 years, I think those version numbers do carry weight, app router was the last straw. Glad to see remix collapsing into react router in the future.
"your tool choice matters much less than your skill at using the tool to accomplish your desired outcome" if you wouldnt get anything from this than this sentence you would get a lot
My last experience with react router was having to downgrade it a major version because they just completely pulled out the feature to block a route change that was necessary to meet the deadline I had at the time, and then they just didn't really mention it... I'll avoid react-router, thanks.
@@ThePrimeTimeagenthat's a poor take prime you know go and see what ryzen has done on recent years. I agree with Intel about that but amd especially ryzen is so impressive. Probably you should look at the performance difference from ryzen 1000 to 5000. So 4 generation of CPUs.
Migrating from page-based routing to app routing in Next.js can be quite frustrating, especially when dealing with a lot of server-fetched data that requires security measures. It's often more practical to have a dedicated backend and a separate frontend. Trying to determine what should be handled on the server and what on the client within the same project for a large application can lead to issues, resulting in an app that doesn't function properly and inconsistent, frustrating logs. A framework should solve complexity, not add to it.
Same. Pages router is quite understandable and it's relatively easy to figure out what's happening. The page is a huge React component, gets this and this props, gets rendered on server as HTML, and then client-side React takes control over that HTML. I just need to remember that if there's some code that can run in the browser only, it goes to useEffect. There are (very rare and usually old) libraries that can run in the browser only, and dynamic import handles them. App router - I have no idea what's happening there.
The main issue I have with Vercel is that most of my customers use Azure or AWS by default. It'll be quite a process to suggest anything else. I mentioned this to the Vercel people at Web Directions Summit in Sydney last month. I'd really love to use them, but without them being available via AWS/Azure marketplace or something like that, I have to pretend they don't exist for most projects, which makes me wonder about nextJS also.
finally this clarified so many aspects that was painful adopting app router and still learning the react ecosystem. so many things just broke. now more of it make sense. thank you for the content 🎉
07:00 very good point, similar experience with Kotlin's extension functions, you can just add you own set of tools to anything you want, without creating your own abstraction over it, which is usually another abstraction over another abstraction
React Server Components and Next 14 has made me appreciate the fundamentals of the Web Platform a lot more than during my time building React apps completely without meta frameworks. I wouldn't worry about newcomers not learning about them! In any case thanks for this video, I enjoyed it!
On magic: yes, it's magic in the sense of transpiling Typescript, etc - but it is nice to work with something that is works closely to web standards, rather than abstracting them away
It's server side framework with a lot of things already included and not possible to remove. It's literally not for everyone, and I think Remix is totally the same. I was thinking that he is going to compare Next with Vite-react or React-create-app (at least much smaller starter kits, without defined structure, server-side, own router implementation, etc), or building react app from scratch (with webpack configuration etc). But he is comparing 2 most predefined high-weight frameworks out there. Doesn't make sense. And actually I think in JS world it's more crucial to understand libraries under the hood, than experience to use one of "all included" frameworks. But for sure, experience with one of those frameworks would be also beneficial. But for me, experience off setting up builder like webpack from scratch looks like much more reusable knowledge
the upgrade from version 5 to version 6 of react -router took out the ability to block navigation, it was like a year of development that they finally nrough back that functionality
4:20 - 4:47 Liked the video because of this. Started building games in Python + Pygame a couple years ago, and although it's not industry standard or "super performant" I've learned so much from using pygame. Everything from high-level things like control flow to low level things like SDL surface blitting. When to use functional vs OOP... "What You See Is What You Get", and when you always resort to the industry standard, you only ever get industry results. Games in these AAA engines really just end being reskinned Copypasta architecture. You can only learn so much this way. You're supposed to break the rules.
On features vs capabilities: I think the distinction here is that a "feature" is something the thing does, and a "capability" is a something the thing lets _you_ do. A lot of the time this is a distinction without a difference, but sometimes the difference can be staggering.
I hate react but I love remix. If you’re soloing a project that requires a really interactive front end and you’re not an expert level front end dev sticking remix on Supa base and deploying serverless is a dev speed cheat code. Next is too but only to launch cause you can’t understand shit after. Remix is really easy to reason about. Reminds me of Elixir in terms of how quickly I was bootstrapping and building cool things I could easily maintain and extend. And it’s super easy to sub out the server components with api calls as you scale. Like maybe elixir api calls. Just stick with jquery or your backend language/wasm though if you don’t need a super interact web app.
I like nextjs but im not happy about its current state. I love its potential. The "use client" drives me crazy and i have the feeling it shoudlnt be so complicated.
These methods (headers and cookies) access the current execution context. The current execution context is one per request. So that's a little DI magic here. More precisely, a service locator. The practice of calling a request context through a service locator outside of a controller is considered an anti-pattern in all languages and frameworks. But sometimes there are cases that need to be handled in this way, these cases never occur in application code, only in the code of the framework or shell for the framework.
I agree that if you are using react you are already using magic. But this is true for any farmework. Since a framework means that you inject your code into an already existing codebase, there will be some degree of magic in every framework. I do not agree that stops you from saying that a framework is doing too much magic. There is a difference of being able to understand the principle of a framework and than being able to use that framework more or less with knowledge you already have and having to consult the documentation on almost anything new that you are doing.
At the end of the day, even if a company is "in it to make money" they can only do so by pleasing customers not by pissing them off which would eventually lead to their failure.
Here's my criteria for a worthwhile JavaScript library/framework: 1. You can write a 1 line (that's entirely visible in your editor without wrapping) js program that uses it. 2. Using it reduces the syntax required for that 1 line program. Otherwise it's more trouble than it's worth.
Hehe. I'm kidding a little bit, but I'm mostly serious. Before ES6, I liked jQuery, because it provided CSS querying capability. Now ES6 gives you that without jQuery, so I might not bother with jQuery. I liked Knockout, a bit, because it gives you a way to put things into your html that would in effect say "this element (and its children) are visible depending on the state of this boolean js variable" or "this text input has the value that is in this js variable" or "the color of this thing is bound to this js var." HTML declared, two way data binding, basically, that could be contextualized/scoped within a js object that is provided to a partial-DOM-walking binding function that would set up the bindings. Those are really the only two things I find to be enough of a help to be worthwhile: CSS DOM Querying and HTML-declared two-way data binding. All the rest of angular/react/etc is just a big pointless pita imo.
"Go to MDN instead of Remix docs". I can't tell you how many times I've had to navigate between 3 or 4 different framework or library docs trawling for information on a convoluted manufactured error message and stack trace. Then my journey would end once I finally found the Github Issue that pointed out that the error handling/typing had trapped and obscured the actual problem which is answerable by Node or MDN documentation.
I was really wondering why most new frontend frameworks are built on react, and why react encourages these frameworks instead of pure react. it makes business sense, but it holds back actual new ideas.
@@ThePrimeTimeagen Yeah, I use search and have it open for days. It does go nuts from time to time though. But on the whole it seems the Slack team have the electron beast better under control than say VSCode.
that's still terrible, there's absolutely no reason it should be using 400mb even when in use. i have to close slack on my work machine because i would run out of memory otherwise. i also have had to give up on vscode and switch to vim full time because I don't have enough memory to run vscode. now I won't go back because vim is just better, and with tmux its goated
I leaved Next.js when 6month after I build my biggest project with next12, they made me rewrite it for next13. Why do I have to rewrite a entire project to have the same functionalities…
Just because you can containerize NextJS and then deploy it to "anywhere" doesn't mean it's portable, I think Kent mean something else, if you've ever written a REST API for AWS Lambda behind API Gateway, you'd understand what he meant. People calling him out and using the skill-issue burn on him are simply suffering from a self-induced illness called superiority complex and their arguments are as trash as their personality. The thing I like the most about Remix is how they achieve this, because remix isn't a server, it's just a request handler, so you can literally put it behind anything. You can see this even today, a lot of people are asking how to deploy nextjs on aws lambda, and others have pointed out that you can use aws-amplify -- but that uses docker behind the scenes! The problem with using docker in AWS Lambda is that it increases cold start times, unlike with remix, you can build your own adapter and just simply pass the request to remix, simple as that. Moving to a containerized environment? Simply change adapter. A new faster server was invented, faster than fastify? Simply change adapter. It's literally portable. Yes, I use NextJS, but I've actually been looking at Remix recently and might start using that instead.
The wrong people aren't getting weeded out. Corporate businesses are 5% principal engineers and the other 95% are doing in vain useless busy work that translates to "customer relations management." You gotta spin that hamster wheel.
10k for web stuff 10k for angular 10k for react 10k for next 10k for vue 10k for svelte 10k for svelte kit 10k for solid 10k for webpack 10k for misc Congratulations, after 100k hours you are a junior web dev!
You can use the following example to differentiate between features and capabilities: Humans have hands and legs that are features, but you do with them consider capabilities. Do correct me if my example is wrong.
I need some advice. I am still somewhat of a newbie, but I want to start a solo project that will require handling many pictures and probably some infinite scrolling. What choice can I make from the beginning to avoid too much dependencies and secure longevity, even if it takes a bit more development time.
I have spent the last 8 months working in next.js. but because we are trying build offline first next is a bad idea. Finally got the go-ahead to convert to create-vite-app and react-router-dom. I can't even begin to tell you how nice and refreshing it is! I am definitely never going to choose next as an engineering decision ever again. Maybe remix depending on my use case. But next is just a bloated mess.
We have been using NextJS for the last 3 years I guess at least. We have never used Vercel for deployment. Frankly, ( this will sound dumb ), I didn't know Vercel nor that it had hosting options, until last year. Definitely deployment is not that big a deal as he is claiming it. Do it in ec2, droplet, it works with an easy pm2 command like any NodeJS application ( using a reverse proxy )
Last time I used next on a prod app we threw it in a container and since it compiles into static content it doesn't run any processing on env vars and breaks the 12 factor app model. We found a way around it but there are some fundamental flaws in how it deals with config.
Why is Dr. Disrespect reading javascript blogs?
I guess im not the one whos doubting too hahahahahaha
@@riskyleeeSame here but checked and wasnt the same guy haha. Almost convinced he was tho.
😂😂😂😂😂😂😂
Dr. Disrespected legal consent
He misunderstood and wanted to have a bitcoin minor.
"I haven't used it enough to have a strong opinion"
If we can just... normalize this sentence/approach, discourse around software dev would become so much more enjoyable.
"I don't need to have an opinion" would be nice too. Or "I have one, but no one needs to hear it"
I said this exact same thing when people asked me about Tailwind. I had researched it, but I had never used it, and I had a strong negative opinion about the class bloat on your HTML. But when people asked me about it, I didn't mention my negative opinions, I said "I haven't gotten around to play with it myself, so I don't have an accurate opinion about it yet."
A month later I picked up tailwind and I've liked it ever since. I still dislike the class bloat, but I love everything else.
This is a great comment
I met a guy recently in Japan and he builds JS apps without any library and handles all DOM manipulation manually with a bunch of functions he created himself. It was impressive to see what he could achieve and was writing code on a Chromebook without any build steps.
His code was so so ugly, but he was able to build some interesting projects.
worked with a guy who did this, he was adamant about me and the rest of the team has to follow suit, i kind of didnt like him for that view because no way in hell am i going to use pure javascript to do dom manipulations, i cant spent 2 years building a dashboard
These are solo devs. Its impossible to do this at scale with a team devs.
Unfortunately this is exactly how the company i work at does it. It is a pain in the ass at scale especially without error/type mismatching handling
Does he have a github? or a name?
If you don't use a framework you just create your own
_"You're dissatisfied with your current modern framework"_
Me, generating HTML from Go templates: *Well, not really.*
hey... that's where i am at
@@ThePrimeTimeagen I'm also trying not to use JS on my website, even in form of HTMX.
For now it exists only in my html5 games that I host there. Every other page is server-side generated and sent with full reloading just as in good old days of PHP or something like that (which I didn't catch).
To be fair, things like Hugo are cool, but dev experience is like Hugo itself - static.
@@clickadelic7681 and I don't think there's anything wrong with it.
Also I'm writing my own server with minimalistic router and markdown parser. Hugo is cool but "too static" for me (:
Are you guys using the standard library for templates? If you like jsx, there's an interesting library called templ which is sort of jsx for go.
There are so many next and remix devs just from being React devs. Is like being trapped in quicksand and trying to solve it by adding more sand.
the children we devs have will look back and wonder: "how the fuck did you guys get anything built back then"!
"Every great cause begins as a movement, becomes a business, and eventually degenerates into a racket." - Eric Hoffer
I know you are mostly just being funny but I am firmly in the Rich Harris camp that the problem with web performance isn't JavaScript and frameworks, it's commercial decisions.
may not be wrong
Best comment I seen on RUclips. As a Software Architect it's frustrating.
Is it alright if you elaborate a bit on that?
Last slow one I worked on was because they wanted to use AWS for everything but didn't have users to justify paying for it so used slow services.
Client: Hey, the website is slow
Me: Of course, your GTM is full of shit
I really like the format of reading two opposing articles back-to-back. Very juicy knowledge and fresh perspectives
I'd let Slack take up 2 cores and half of my RAM if they made code snippets less ass
impossible
Slack breaking code blocks if you add a blank newline hurts me physically and emotionally.
Try using code blocks in Teams. You'll never complain about Slack again
Big oof. Gotta disagree slightly on this one. Yes the triple backtick is rubbish in Teams BUT if you haven't already try clicking on the "Text Formatting" toggle button and then click the "Insert Code"
It's actually shockingly good imho 😇
@leila-codes and then you then want to paste the code from teams, good luck deleting the extra newlines 😂
Nextjs is a wired framework, if you use it without thinking about it, it seems nice, but when you start really thinking about how it works internally and how the deployment/hosting work, it start to be confusing
And, if there weren't so many glitches in the matrix, I wouldn't have to think about it! 😂 I unfortunately learned more about Next than I wanted to, so I am not excited to use it for my next project.
I dont know...some things I see in web dev remind me on the developments my industry (civil engineering infrastructure design) went through decades ago when computers etc. became a thing.
50 years ago, designing, calculating and building bridges was a pretty straight forward thing. why? because the tools were limited. there were tables for some predefined situations, and calculations and drawings were done by hand. when you do stuff by hand, you automatically reduce it to the necessary.
when the tools came that should fasten and simplify everything, a lot of often unnecessary complexity was added to the projects in a "we have the tools now!" mindset.
so much that you can argue that the advantages seem to be completely gone or even turned to less effiency.
thats what probably also happens with a lot of web projects. people use frameworks because "it`s fast and simple" and then they stuff their most of the time pretty simple app with shit until they realise it`s not fast and simple anymore.
I think the increasing divergence from Remix's philosophy / approach with Next JS's philosophy / approach is overall a good thing for both frameworks. They are becoming increasingly distinct from one another as time progresses. Next js is your shiny brand new sports car with the latest gizmos while Remix is like a simple and efficient EV sedan that is plenty fast, but not focused on the bells and whistles.
More like remix is a car with wheels and you understand how it brings you from a to b, if you hit the gas.
Nextjs teleports you trough some subspace conduit to anywhere in the Galaxy while you are trying to visit your friend from down the street, but you have no understanding how you teleports and what it will do to your organs long term, even though teleporting is cool and all your friends do it.
teleport me daddy uwu
@@guidobit if you don't understand how NextJS teleports you, I think you need to do some more reading buddy
I laughed a lot with your comment. Spanish hahaha. @@guidobit
@@gm42069 At first yes, when it was just React + a file based router and easy SSR/SSG, now it's different buddy, they're reinventing the wheel with each iteration and deliver beta software under a "stable" label
Dear devs, please remember you are working to give the customer a good experience. Not to scratch ur itch.
I don't use next JS, or previous JS, or current JS; all my homies hate JS
Do they also hate money, because if you don't use JS, you hate money and instead of being a rich nerd, you are just a full nerd. Never go full nerd.
next started as a tool for react users to build websites.. not apps. every unintuitive stems from that root. It's like html css, it was created for people to assemble documents... static documents like newspapers and magazines. Future capabilities are built onto of that
Agree
We had a bunch of frontend oriented devs that really wanted to move to React, they landed on Next JS. The best compromise we came to was only using the static export of Next JS. CSR, SSR, vercel hosting, serverless what the hell are those? We just have a bundle of html, js, and css that calls our APIs.
ye if it isn't an single page app, i wouldn't touch react, react was made for single page apps.
Its like working with children when they tell you their Lego's House is better than your Wood and Brick House. You start questioning what the heck the modern industry is doing? Its like its being controlled by non-programmers that want to do it the hard way.
@@complexity5545 Nah, the hard way is creating over-engineered and unnecessarily complex solutions like Angular. Next.js - or any other framework for the matter - isn't even close to "the hard way".
Is this Jamstack?
Has anyone ever noticed the way prime selects text ? He skips the first and last letter of a sentence and it’s very pleasing to me
i love it and it appears that some people love it and some people hate it
It drives me nuts lol
What has been seen, cannot be unseen
OCD in the wild
Makes zero sense to do it like this.
After manually making a site with nothing but pure JS, I appreciate the work these frameworks do. Sometimes just because you can so something doesn’t mean you should!
It's like I always tell people, if I want to make you love JSX I will force you to work with the DOM for anything that is not a tutorial and has some meaningful functionality.
100% man. I see these frameworks basically being developed for industry. They evolve as the demands of companies evolve, and unsurprisingly they end up being very complicated, with lots of choices to pick from, many ways to make the wrong choices. Then someone comes along and ditches 90% of that complexity. Their solution is much easier to apply to most non-commercial projects and harder to shoot yourself in the foot with. But DX
Every feature in nextjs is designed for lock in to vercel imo
That's the plan 🙃
Yep 😂
NextJS is sanskrit for Vercel :P
I felt this when I discovered a complete lack of support for controlling the response Expiry header. I thought “these folks are smart engineers, surely they can’t have misunderstood how HTTP caching layers work?”. With that in mind, it became painfully clear why. It encourages you to use stale-while-revalidate, which lets Vercel then provided cache control as a “feature” instead.
I fell out of love with Vercel that day. I hate greedy companies. Especially when they intentionally make things worse, so you have to pay for them to be better, under the guise of “open source”. Open source isn’t the same when your cronies control what’s in and what’s out, intentionally hobbling the design so that it plays into using your platform for features that’d be designed in from the outset if you were using anything other than NextJS.
This is why I love svelte and svelte-kit because it doesn't hide the web standards behind new APIs that you have to remember.
Self hosting nextjs for production is not the save as using vercel. Caching doesn't scale as it uses local files as a store. Next has an experemental feature to use other cache storage, but it doexn't work with revalidatePath() so it's not easy to just self-host nextjs app
imagine if laravel did this. Taylor Otwell would have bought two Lamborghinis
@@ea_naseerhighly doubt it
@@ea_naseer lmfao
@@spicynoodle7419 laravel now runs ads when you go into debug mode. don't underestimate men and sport cars
What we do and what works very well for us is to just use SSR behind a CDN with s-maxage being like 100 years. Instead of revalidating paths in Next, you just invalidate them in your CDN and you’re pretty much good to go. Next request will cause a render and after that (at least with CloudFront origin protection) that should be it.
In our experience the problem with Next.js is that it's opinionated beyond anything reasonable for a general-purpose framework.
Django is also opinionated but I don’t see anyone complaining about it as much as next js
react was supposed to be not opinionated library, where u create everything as you want, but suddenly it isn't...@@netdoom
@@netdoom React is not opinionated at all I'd say. It has limitations due to how it is structured, but opinionated? Not really.
@@CottidaeSEAfunny how he said nextjs, and you responded with react, you made kenn's point lol
@@theangelofspace155 No, that guy absolutely did say React. His reply is removed though.
I use Nextjs professionally, and while it's getting more bloated with every major version bump, and there's a lot to dislike about it, I really fail to see why people have issues deploying it? I've deployed it on bare metal, VPS and cloud infra, always in a Docker container, never had any issues running it self-hosted.
If you want api versioning and elaborate caching, you have to set it up yourself, it is self-hosted and much cheaper after all.
I'll pickup Next when its finished.
We would be here for a while then
I did not find it very difficult to host NextJS when I was still using it (I stopped after trying to accept that version 13 was all of a sudden an entirely different thing). But I host everything within Kubernetes for years now, so basically I just run it with Node and Nginx as two separate docker containers. This way it can auto-scale and it becomes super easy to host it on any cloud or other infrastructure.
Same. Do it everyday in one of the cloud providers. That said, there were some serious growing pains to get the dockerfile running correctly, but there are now good examples of how to get the dockerfile going.
Am I the only one who feels like nextjs isnt getting any faster even with their new 14 update.
Im using shadcn and tailwind and im literally restarting the server every 3 minutes cuz it wont render the component or the tailwind classes i added.
Its frustrating 😔
Something wrong with your system, mine never had any problems like these
Bohr-Einstein debates are quite different nowadays.
Vercel does not play dice
@@SandraWantsCoke It always bets on the dollar
Not putting all of your eggs in one basket if that basket is managed by a company that is not profitable is a great piece of advice.
What happens when the VC looses interest and hope?
That problem isn't limited to small companies either. Google is notorious for randomly killing off its projects. The Linux community is arguably the most aware of this phenomenon in the tech world, after repeatedly getting burned by corporate interests (most recently with the RedHat/IBM debacles). Proprietary platforms, and even "open" tech heavily reliant on proprietary services are just risky business for the average user/developer.
@@LambdaCalculatortrue, a lot of companies and other organisations have lost tones of money and time integrating with Google platforms that were discontinued a short while later. So you are right that there are many factors in longevity.
I never have to use any React Context again when using Remix 😂 the router has already handled everything
But the React team explicitly stated that the canary features used in Next are stable for the framework, even though they're technically canary in the overall React project. The projects are mutually exclusive, but obviously collaborate well enough that certain canary features are being prioritized during development, at least whatever the Next team needs.
Moving through nextjs major versions over 4 years, I think those version numbers do carry weight, app router was the last straw. Glad to see remix collapsing into react router in the future.
"your tool choice matters much less than your skill at using the tool to accomplish your desired outcome" if you wouldnt get anything from this than this sentence you would get a lot
41:41 my dockerized nextjs app broke after updating a patch release.
"Huh whats this Remix thing? I've never heard of this."
>React, again
Dropped.
Prime: "Kent is not going to say negative things about Next.js"
5 seconds later
Kent: "I am going to say negative things about Next.js"
My last experience with react router was having to downgrade it a major version because they just completely pulled out the feature to block a route change that was necessary to meet the deadline I had at the time, and then they just didn't really mention it... I'll avoid react-router, thanks.
Exactly the same experience, the feature is there now, 3 years later, but still unstable.
I completely agree. The real winners here are the chip makers
being able to release a new computer with relatively small changes every year for the last 15 years is pretty wild
@@ThePrimeTimeagenthat's a poor take prime you know go and see what ryzen has done on recent years.
I agree with Intel about that but amd especially ryzen is so impressive.
Probably you should look at the performance difference from ryzen 1000 to 5000. So 4 generation of CPUs.
@@dgdev69Small changes for 15 years? He's obviously trolling you. 😅 Weren't processors 33-bit, single-threaded 15 years ago?
Fetch requests are no longer cached by default in Next 15. Won't be jumping over to it myself but its just worth noting.
Migrating from page-based routing to app routing in Next.js can be quite frustrating, especially when dealing with a lot of server-fetched data that requires security measures. It's often more practical to have a dedicated backend and a separate frontend. Trying to determine what should be handled on the server and what on the client within the same project for a large application can lead to issues, resulting in an app that doesn't function properly and inconsistent, frustrating logs.
A framework should solve complexity, not add to it.
been struggling with the same
Same.
Pages router is quite understandable and it's relatively easy to figure out what's happening. The page is a huge React component, gets this and this props, gets rendered on server as HTML, and then client-side React takes control over that HTML. I just need to remember that if there's some code that can run in the browser only, it goes to useEffect. There are (very rare and usually old) libraries that can run in the browser only, and dynamic import handles them.
App router - I have no idea what's happening there.
People are fighting over a framework and here in India all small to giant tech companies don't give you a job if you're not using WordPress or Wix.
I love React but companies here don't.
What about webflow and what about php and laravel? Do you use that more often?
Prime really loves Angular
caught me red handed
@@ThePrimeTimeagen
@@ThePrimeTimeagen I would like to hear your opinion about new control flow syntax of Angular
@@ectn26it won't happen.
Why everybody loses the chance to call him "Can't see dots"
The main issue I have with Vercel is that most of my customers use Azure or AWS by default. It'll be quite a process to suggest anything else.
I mentioned this to the Vercel people at Web Directions Summit in Sydney last month. I'd really love to use them, but without them being available via AWS/Azure marketplace or something like that, I have to pretend they don't exist for most projects, which makes me wonder about nextJS also.
I've used AWS Amplify to deploy nextjs applications without any issues
Vercel is on the AWS Marketplace! Not Azure yet tho
finally this clarified so many aspects that was painful adopting app router and still learning the react ecosystem. so many things just broke. now more of it make sense. thank you for the content 🎉
"Why I Feel Like You, Along With Hundreds of Others, Have Said This Exact Same Statement"
My problem right now with server actions is the amount of javascript added by making the user do a fetch request is so small.
It's amazing how you post something about not using next.js literally days after being in their conference, lmfao
I really like NextJS and don't use Vercel for hosting. I self host using Linode and a self hosted mySQL database. It's a great setup.
How do you handle the db clustering?
@@DeJangum1231 I don't use db clustering.
@@DeJangum1231 he don't
07:00 very good point, similar experience with Kotlin's extension functions, you can just add you own set of tools to anything you want, without creating your own abstraction over it, which is usually another abstraction over another abstraction
"As Next is a popular alternative to Remix" ? ... Got the order reversed there.
React Server Components and Next 14 has made me appreciate the fundamentals of the Web Platform a lot more than during my time building React apps completely without meta frameworks. I wouldn't worry about newcomers not learning about them! In any case thanks for this video, I enjoyed it!
On magic: yes, it's magic in the sense of transpiling Typescript, etc - but it is nice to work with something that is works closely to web standards, rather than abstracting them away
It's server side framework with a lot of things already included and not possible to remove. It's literally not for everyone, and I think Remix is totally the same. I was thinking that he is going to compare Next with Vite-react or React-create-app (at least much smaller starter kits, without defined structure, server-side, own router implementation, etc), or building react app from scratch (with webpack configuration etc). But he is comparing 2 most predefined high-weight frameworks out there. Doesn't make sense.
And actually I think in JS world it's more crucial to understand libraries under the hood, than experience to use one of "all included" frameworks. But for sure, experience with one of those frameworks would be also beneficial. But for me, experience off setting up builder like webpack from scratch looks like much more reusable knowledge
"NextJS is like Kubernetes". Webdevs need to be stopped
once i tried to criticize a feature of remix. and one of the maintainers told me that i am using a free app and i should fckoff. now im using nextjs.
the upgrade from version 5 to version 6 of react -router took out the ability to block navigation, it was like a year of development that they finally nrough back that functionality
0:45 reminded me of rick prime. he shall forever be missed. farewell rick c-137
4:20 - 4:47 Liked the video because of this. Started building games in Python + Pygame a couple years ago, and although it's not industry standard or "super performant" I've learned so much from using pygame. Everything from high-level things like control flow to low level things like SDL surface blitting. When to use functional vs OOP... "What You See Is What You Get", and when you always resort to the industry standard, you only ever get industry results. Games in these AAA engines really just end being reskinned Copypasta architecture. You can only learn so much this way.
You're supposed to break the rules.
On features vs capabilities: I think the distinction here is that a "feature" is something the thing does, and a "capability" is a something the thing lets _you_ do. A lot of the time this is a distinction without a difference, but sometimes the difference can be staggering.
To be fair: It is not JavaScript that takes a lot of Gb of RAM (Slack) - it is Chromium.
I hate react but I love remix. If you’re soloing a project that requires a really interactive front end and you’re not an expert level front end dev sticking remix on Supa base and deploying serverless is a dev speed cheat code. Next is too but only to launch cause you can’t understand shit after. Remix is really easy to reason about. Reminds me of Elixir in terms of how quickly I was bootstrapping and building cool things I could easily maintain and extend.
And it’s super easy to sub out the server components with api calls as you scale. Like maybe elixir api calls.
Just stick with jquery or your backend language/wasm though if you don’t need a super interact web app.
Hmmmmm 🤔 just straight remix? Nothing else?
You have one hell of a voice. It's like gilbert gottfreid but without any of the talent that man has.
chefs kiss*
I like nextjs but im not happy about its current state. I love its potential. The "use client" drives me crazy and i have the feeling it shoudlnt be so complicated.
Did a double take every time he said canaries were sentient 🤣
i struggled with that
@@ThePrimeTimeagen I think it's endearing and possibly prophetic; I hope you don't think this is a complaint
HOLD ON STOP RIGHT THERE. Let me get my popcorn...... ..... ..... .... .. . . .. OK, LFG~!
These methods (headers and cookies) access the current execution context. The current execution context is one per request. So that's a little DI magic here. More precisely, a service locator.
The practice of calling a request context through a service locator outside of a controller is considered an anti-pattern in all languages and frameworks. But sometimes there are cases that need to be handled in this way, these cases never occur in application code, only in the code of the framework or shell for the framework.
i wish i could hit the like button twice. once for the "rawdog fetch vs caching fetch"; once for "that S.O.B. MooTools";
The helper functions should allow you to consume the features ad hoc without going all-in on the extra abstraction layer's opinions in the wrapper.
kent vs lee cage match 🥊
haven't read either post yet, so I'll let you read them to me. prime bedtime stories, a public service
BTSAAS
You know what's not magic? PHP
Oh boy 😆nice confusion technique at the beginning bro, 9 seconds in and I already liked the video.
“Never worry about a bundler” and “Any JS Framework” is like saying oil and water mix easily 😂
Shout-out to helpers as opposed to faćades or other non-useful abstractions that imply dependency management.
I agree that if you are using react you are already using magic. But this is true for any farmework. Since a framework means that you inject your code into an already existing codebase, there will be some degree of magic in every framework.
I do not agree that stops you from saying that a framework is doing too much magic. There is a difference of being able to understand the principle of a framework and than being able to use that framework more or less with knowledge you already have and having to consult the documentation on almost anything new that you are doing.
Helpers are the way to go, more flexibility, less coupling.
At the end of developing you will apprecieate how good php is.
The good partner is Svelte or Htmx with golang for the backend api.
At the end of the day, even if a company is "in it to make money" they can only do so by pleasing customers not by pissing them off which would eventually lead to their failure.
Here's my criteria for a worthwhile JavaScript library/framework:
1. You can write a 1 line (that's entirely visible in your editor without wrapping) js program that uses it.
2. Using it reduces the syntax required for that 1 line program.
Otherwise it's more trouble than it's worth.
Hehe. I'm kidding a little bit, but I'm mostly serious. Before ES6, I liked jQuery, because it provided CSS querying capability. Now ES6 gives you that without jQuery, so I might not bother with jQuery. I liked Knockout, a bit, because it gives you a way to put things into your html that would in effect say "this element (and its children) are visible depending on the state of this boolean js variable" or "this text input has the value that is in this js variable" or "the color of this thing is bound to this js var." HTML declared, two way data binding, basically, that could be contextualized/scoped within a js object that is provided to a partial-DOM-walking binding function that would set up the bindings. Those are really the only two things I find to be enough of a help to be worthwhile: CSS DOM Querying and HTML-declared two-way data binding. All the rest of angular/react/etc is just a big pointless pita imo.
Guys, turn on the news, Vercel declared war on Remix.
"Go to MDN instead of Remix docs". I can't tell you how many times I've had to navigate between 3 or 4 different framework or library docs trawling for information on a convoluted manufactured error message and stack trace. Then my journey would end once I finally found the Github Issue that pointed out that the error handling/typing had trapped and obscured the actual problem which is answerable by Node or MDN documentation.
1:52 he got you covered, there is a huge link on the header
I was really wondering why most new frontend frameworks are built on react, and why react encourages these frameworks instead of pure react. it makes business sense, but it holds back actual new ideas.
I have slack open and it takes about 400MB and 0.3%CPU. Ok that's not great for what it is but it is hardly the worst offending app on my system.
but are you using it? when i use it slack goes nuts (not just check a message but search, and do a few activities)
@@ThePrimeTimeagen Yeah, I use search and have it open for days. It does go nuts from time to time though. But on the whole it seems the Slack team have the electron beast better under control than say VSCode.
that's still terrible, there's absolutely no reason it should be using 400mb even when in use. i have to close slack on my work machine because i would run out of memory otherwise. i also have had to give up on vscode and switch to vim full time because I don't have enough memory to run vscode. now I won't go back because vim is just better, and with tmux its goated
He got a reply to that article from Nextjs
I leaved Next.js when 6month after I build my biggest project with next12, they made me rewrite it for next13.
Why do I have to rewrite a entire project to have the same functionalities…
One Day We Will Come Back To Vanilla JS Or TS and nothing else
Just because you can containerize NextJS and then deploy it to "anywhere" doesn't mean it's portable, I think Kent mean something else, if you've ever written a REST API for AWS Lambda behind API Gateway, you'd understand what he meant. People calling him out and using the skill-issue burn on him are simply suffering from a self-induced illness called superiority complex and their arguments are as trash as their personality.
The thing I like the most about Remix is how they achieve this, because remix isn't a server, it's just a request handler, so you can literally put it behind anything. You can see this even today, a lot of people are asking how to deploy nextjs on aws lambda, and others have pointed out that you can use aws-amplify -- but that uses docker behind the scenes! The problem with using docker in AWS Lambda is that it increases cold start times, unlike with remix, you can build your own adapter and just simply pass the request to remix, simple as that. Moving to a containerized environment? Simply change adapter. A new faster server was invented, faster than fastify? Simply change adapter. It's literally portable.
Yes, I use NextJS, but I've actually been looking at Remix recently and might start using that instead.
If you need 10k hours to master a craft, wtf are we doing? This is worse than tv!
The wrong people aren't getting weeded out. Corporate businesses are 5% principal engineers and the other 95% are doing in vain useless busy work that translates to "customer relations management." You gotta spin that hamster wheel.
10k for web stuff
10k for angular
10k for react
10k for next
10k for vue
10k for svelte
10k for svelte kit
10k for solid
10k for webpack
10k for misc
Congratulations, after 100k hours you are a junior web dev!
Most of the banks and very big tech dont use even reactjs most of them angular
You can use the following example to differentiate between features and capabilities:
Humans have hands and legs that are features, but you do with them consider capabilities.
Do correct me if my example is wrong.
Was going to get a heart attack in the first second.
You use React,
I use Preact,
We are not the same
I use Postact
I need some advice. I am still somewhat of a newbie, but I want to start a solo project that will require handling many pictures and probably some infinite scrolling. What choice can I make from the beginning to avoid too much dependencies and secure longevity, even if it takes a bit more development time.
Server side rendering looks cool but that video confused me. So, after vanilla js what should I learn? React?
Typescript for sure. And then depends on what you want.
@@LSS94 thank you
@@valsimotkarpis9120 ty
TypeScript
Learn React
I have spent the last 8 months working in next.js. but because we are trying build offline first next is a bad idea. Finally got the go-ahead to convert to create-vite-app and react-router-dom. I can't even begin to tell you how nice and refreshing it is! I am definitely never going to choose next as an engineering decision ever again. Maybe remix depending on my use case. But next is just a bloated mess.
"I'm about 50% agreement." Come on...
We have been using NextJS for the last 3 years I guess at least. We have never used Vercel for deployment. Frankly, ( this will sound dumb ), I didn't know Vercel nor that it had hosting options, until last year. Definitely deployment is not that big a deal as he is claiming it. Do it in ec2, droplet, it works with an easy pm2 command like any NodeJS application ( using a reverse proxy )
Wow, so this video helped me determine a solution for a customer 2 months after it theprimetime posted it.
Last time I used next on a prod app we threw it in a container and since it compiles into static content it doesn't run any processing on env vars and breaks the 12 factor app model. We found a way around it but there are some fundamental flaws in how it deals with config.
What did you replace it with?