"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
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 😔
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.
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
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.
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".
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.
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
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.
Год назад+12
Bohr-Einstein debates are quite different nowadays.
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.
"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
I was learning Go before, then was influenced by primeagen to learn Rust instead. In this video he praises Rust for having traits but then he says: "I like Go and Htmx right now" (at 10:25). The question is: Is Go better than Rust for web server?
Here’s my 2 cents (probably worth less than that 😅). 1. Go and Rust are both excellent 2. Learning one will make it much easier to learn the other later 3. They both work with HTMX. In fact, HTMX works with any backend language you wish to use.
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.
Deploy next.js to other places have been major issues for many people for years. They refused to acknowledge it, just keerp saying is skill. This is Redflag to me. Azure team has to do alot of thing in order to get most of the feature work on Azure Static web app. Deploying to aws is also a big pain for people. Route and FetchCache is very disliked, they removed in version 15 now. They can still use it, but need to opt in.
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
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.
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.
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.
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.
18:50 You really don't think that's a good argument? I could analogize it for you and perhaps you could see the argument a little better. Hypothetical: Let's say there's some microcontroller for a motor, it's a really good microcontroller and has some experimental functions on it. That microcontroller explicitly tells everyone that this particular function is experimental. Then an auto manufacturer uses that product, and the experimental feature, relying on an experimental feature. And offers that vehicle on the market. Not only has the auto manufacturer obscured and obfuscated the fact that it's using a microcontroller with experimental features, it's implicitly saying that the vehicle is fit to be used in production (on the highway). You might not think that's a problem since the auto manufacturer is assuming all responsibility and liability but the fact that it was hidden from the end user of the vehicle is the main problem to begin with. This analogy is used to describe that if we weren't talking about software and we were talking about something inherently more valuable or real life, I don't think anybody would have a problem with this argument being made. But simply because it's software and it's not regulated in every country that uses automobiles we just let it slide.
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…
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.
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.
Tbh @ThePrimeTimeagen, I have no idea where you were going with this at 7:13 How does having helper functions or Rust Traits changes anything ? Aren't those just abstractions ? In the case of helper functions you bind yourself to the data and abstract away the behavior. So if the data changes, you need to propagate those changes to your helper functions. Same with calling helper functions in other helper functions.. For Rust Traits, it's pretty much implementing the "interfaces" aka your abstractions. Same problem here, if data change or behavior change, you are coupled and need to change it everywhere too. I agree with you that everytime you make an abstraction, you couple your code to that abstraction. But i don't see how what you proposed here helps with anything ? You are still using abstractions..
you don't have to *wrap* you get to trait implement the functionality you want, then hand off that object. if they want the additional features, they import the trait, and boom, its there on the ORIGINAL object. *chefs kiss*
@@ThePrimeTimeagen So would that mean if I have an object that _doesn't_ implement some trait, I can implement it myself and use the object as if it always had it?
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
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 🎉
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 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
Doesnt the undici fetch (what next uses) de dupe requests? Like swc? Its not cahcing, the next request it does not contain the request data. Except when doing multiple serverside fetches, it dedupes. So you can fetch getOrganization in 10 components at the same time while doing 1 serverside render and 1 actual request. Not a next user btw, but this is what I remember from the docs. Feel free to correct me if I misunderstood.
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!
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
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.
@46:10 Prime completely missed the point that was being made here. The problem isn't that Vercel solves the api/ui versioning problem for you if you use their infra. The problem is that they make it literally impossible with server actions to solve it yourself without their infra. Yes it was always a hard problem and it's nice Vercel solves it. But with server actions the way Next.js implements them, it is now not a hard problem but an impossible problem to solve with self-hosting.
Your points about Magic are good, but, and maybe this just got cut for the vid, it seemed like you skipped over the part where the author said they actually liked Magic, as long as it was opt-in (at 21:40 or so)
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.
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 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.
i have a question to all the guys working with go and htmx, what do you guys use as frontend js? or is htmx so robust in its way, that i dont really need js in most cases?
@@DeJangum1231 lets say i want something like state management. I want to track the states of many things in the browser and only allow certain things based on the states. How would i do this in htmx? Is there a good way?
"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.
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.
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.
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.
Trying to learn NextJS at the moment and all I see are yt vits of devs bashing react/nextjs haha, it's making it hard to learn, I won't lie. I did start with Svelte, then as there weren't any jobs appearing, I jumped over to also pick up React. Albeit, I'm trying to learn programming, and not just the frameworks, but as a beginner, it's certainly a big hill to climb, especially with the negativity (or constructive criticism, I guess)
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.
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
"Every great cause begins as a movement, becomes a business, and eventually degenerates into a racket." - Eric Hoffer
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"!
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.
Dear devs, please remember you are working to give the customer a good experience. Not to scratch ur itch.
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.
41:41 my dockerized nextjs app broke after updating a patch release.
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
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
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.
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.
You're just fanboy php😂😂
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.
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
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.
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.
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?
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.
"Huh whats this Remix thing? I've never heard of this."
>React, again
Dropped.
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
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.
Bohr-Einstein debates are quite different nowadays.
Vercel does not play dice
@@SandraWantsCoke It always bets on the dollar
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.
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.
"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
I was learning Go before, then was influenced by primeagen to learn Rust instead. In this video he praises Rust for having traits but then he says: "I like Go and Htmx right now" (at 10:25). The question is: Is Go better than Rust for web server?
Here’s my 2 cents (probably worth less than that 😅).
1. Go and Rust are both excellent
2. Learning one will make it much easier to learn the other later
3. They both work with HTMX. In fact, HTMX works with any backend language you wish to use.
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.
Deploy next.js to other places have been major issues for many people for years. They refused to acknowledge it, just keerp saying is skill. This is Redflag to me. Azure team has to do alot of thing in order to get most of the feature work on Azure Static web app.
Deploying to aws is also a big pain for people.
Route and FetchCache is very disliked, they removed in version 15 now. They can still use it, but need to opt in.
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
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 problem right now with server actions is the amount of javascript added by making the user do a fetch request is so small.
I never have to use any React Context again when using Remix 😂 the router has already handled everything
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.
🤣
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
It's amazing how you post something about not using next.js literally days after being in their conference, lmfao
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?
What about just using file based routing and image optimization and treat remaining nextjs just as react and build server on nodejs .
I'll pickup Next when its finished.
We would be here for a while then
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.
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?
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
18:50 You really don't think that's a good argument?
I could analogize it for you and perhaps you could see the argument a little better.
Hypothetical:
Let's say there's some microcontroller for a motor, it's a really good microcontroller and has some experimental functions on it. That microcontroller explicitly tells everyone that this particular function is experimental.
Then an auto manufacturer uses that product, and the experimental feature, relying on an experimental feature. And offers that vehicle on the market.
Not only has the auto manufacturer obscured and obfuscated the fact that it's using a microcontroller with experimental features, it's implicitly saying that the vehicle is fit to be used in production (on the highway).
You might not think that's a problem since the auto manufacturer is assuming all responsibility and liability but the fact that it was hidden from the end user of the vehicle is the main problem to begin with.
This analogy is used to describe that if we weren't talking about software and we were talking about something inherently more valuable or real life, I don't think anybody would have a problem with this argument being made. But simply because it's software and it's not regulated in every country that uses automobiles we just let it slide.
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…
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.
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.
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?
Tbh @ThePrimeTimeagen, I have no idea where you were going with this at 7:13
How does having helper functions or Rust Traits changes anything ?
Aren't those just abstractions ?
In the case of helper functions you bind yourself to the data and abstract away the behavior.
So if the data changes, you need to propagate those changes to your helper functions.
Same with calling helper functions in other helper functions..
For Rust Traits, it's pretty much implementing the "interfaces" aka your abstractions.
Same problem here, if data change or behavior change, you are coupled and need to change it everywhere too.
I agree with you that everytime you make an abstraction, you couple your code to that abstraction.
But i don't see how what you proposed here helps with anything ?
You are still using abstractions..
you don't have to *wrap*
you get to trait implement the functionality you want, then hand off that object. if they want the additional features, they import the trait, and boom, its there on the ORIGINAL object.
*chefs kiss*
@@ThePrimeTimeagen So would that mean if I have an object that _doesn't_ implement some trait, I can implement it myself and use the object as if it always had it?
Fetch requests are no longer cached by default in Next 15. Won't be jumping over to it myself but its just worth noting.
Why everybody loses the chance to call him "Can't see dots"
"As Next is a popular alternative to Remix" ? ... Got the order reversed there.
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
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 🎉
Have you try litelements without compilation?
Thanks!
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
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 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
Oh boy 😆nice confusion technique at the beginning bro, 9 seconds in and I already liked the video.
Doesnt the undici fetch (what next uses) de dupe requests? Like swc? Its not cahcing, the next request it does not contain the request data. Except when doing multiple serverside fetches, it dedupes. So you can fetch getOrganization in 10 components at the same time while doing 1 serverside render and 1 actual request.
Not a next user btw, but this is what I remember from the docs. Feel free to correct me if I misunderstood.
Yes, NextJS dedupe requests
"Why I Feel Like You, Along With Hundreds of Others, Have Said This Exact Same Statement"
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!
Just tried this and I'm already confused about params and queries. Hope there is a solution that I haven't found, not that it's changed.
Whats your thoughts on Axum and Tower since it follows a pattern quite similar to express (req, res, next)?
axum is great and it's magic params make learning rust easier because you don't need to worry about the borrow checker as much
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
"NextJS is like Kubernetes". Webdevs need to be stopped
The good partner is Svelte or Htmx with golang for the backend api.
“Never worry about a bundler” and “Any JS Framework” is like saying oil and water mix easily 😂
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.
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.
@46:10 Prime completely missed the point that was being made here.
The problem isn't that Vercel solves the api/ui versioning problem for you if you use their infra. The problem is that they make it literally impossible with server actions to solve it yourself without their infra.
Yes it was always a hard problem and it's nice Vercel solves it. But with server actions the way Next.js implements them, it is now not a hard problem but an impossible problem to solve with self-hosting.
Your points about Magic are good, but, and maybe this just got cut for the vid, it seemed like you skipped over the part where the author said they actually liked Magic, as long as it was opt-in (at 21:40 or so)
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~!
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?
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 wish i could hit the like button twice. once for the "rawdog fetch vs caching fetch"; once for "that S.O.B. MooTools";
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.
i have a question to all the guys working with go and htmx, what do you guys use as frontend js? or is htmx so robust in its way, that i dont really need js in most cases?
Why do you need js if you already use htmx?
@@DeJangum1231 I suppose the UI is more complex
@@DeJangum1231 lets say i want something like state management. I want to track the states of many things in the browser and only allow certain things based on the states. How would i do this in htmx? Is there a good way?
You have one hell of a voice. It's like gilbert gottfreid but without any of the talent that man has.
chefs kiss*
Could we have an answer from the Lee link?
So is remix better option?
To be fair: It is not JavaScript that takes a lot of Gb of RAM (Slack) - it is Chromium.
He got a reply to that article from Nextjs
"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.
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.
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.
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.
Trying to learn NextJS at the moment and all I see are yt vits of devs bashing react/nextjs haha, it's making it hard to learn, I won't lie. I did start with Svelte, then as there weren't any jobs appearing, I jumped over to also pick up React. Albeit, I'm trying to learn programming, and not just the frameworks, but as a beginner, it's certainly a big hill to climb, especially with the negativity (or constructive criticism, I guess)
Learn it bro very much usefull to land a job
1:52 he got you covered, there is a huge link on the header
You know what's not magic? PHP
Shout-out to helpers as opposed to faćades or other non-useful abstractions that imply dependency management.
Im considering switching to Remix, after NextJs transferred to a PHP