"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.

_"You're dissatisfied with your current modern framework"_ Me, generating HTML from Go templates: *Well, not really.*

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.

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.

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.

I'd let Slack take up 2 cores and half of my RAM if they made code snippets less ass

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

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.

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

Oh boy 😆nice confusion technique at the beginning bro, 9 seconds in and I already liked the video.

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.

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.

I left Next.js for Astro and havent looked back. For internal SPAs, vite + typescript

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.

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.

Hey Prime, I loved the way you explained both the sides and gave your feedback, I would love to know more about the problem with Browser Router from React Router, since I am a "new developer", I would like to why its not really a good way, when you say it flattens the URL in React Router. I definitely would love to have a good explanation video

41:41 my dockerized nextjs app broke after updating a patch release.

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.

Whats your thoughts on Axum and Tower since it follows a pattern quite similar to express (req, res, next)?

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

At work we have the same backend written in C, serving HTTP JSON for multiple interfaces... ExtJS (main ui), ReactJS (responsive ui), ReactNative (mobile ui), AngularJS (modular ui/templates). As a 'fullstack' for 20years (web/backend/db). I had seen a lot of changed in the market. Ajax, jquery, templates, Web_Components and stuff. For me, we are just rewrite the well for a long time, to gain control over the loader and the components (elements). The best, for me, is leave the ui for the ui, leave the backend for the backend. When you have ui construction in the backend (html and on) you lost control over the backend, since the backend is doing the frontend part. This approach will only work for that ui.

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.

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!

Every feature in nextjs is designed for lock in to vercel imo

i have used react. then i tried not using react. the next web project i made with 0 react, the icon in the tab is the react favicon. infected mushroom.

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.

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 😔

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'll pickup Next when its finished.

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.

The good partner is Svelte or Htmx with golang for the backend api.

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.

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 never have to use any React Context again when using Remix 😂 the router has already handled everything

0:45 reminded me of rick prime. he shall forever be missed. farewell rick c-137

In our experience the problem with Next.js is that it's opinionated beyond anything reasonable for a general-purpose framework.

love the potion seller opener frame lol

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.

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

My problem right now with server actions is the amount of javascript added by making the user do a fetch request is so small.

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 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

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?

Prime really loves Angular

Shout-out to helpers as opposed to faćades or other non-useful abstractions that imply dependency management.

Server side rendering looks cool but that video confused me. So, after vanilla js what should I learn? React?

Im considering switching to Remix, after NextJs transferred to a PHP

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.

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.

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.

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.

Bohr-Einstein debates are quite different nowadays.

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?

What about just using file based routing and image optimization and treat remaining nextjs just as react and build server on nodejs .

He got a reply to that article from Nextjs

i wish i could hit the like button twice. once for the "rawdog fetch vs caching fetch"; once for "that S.O.B. MooTools";

Why everybody loses the chance to call him "Can't see dots"

When nextjs introduced serverless functions it got bad. When it removed data mutation it became worthless. But the web stamdards suck too so I don't know if Remix is a good alternative.

When you work on an abstraction of an abstraction, you can no longer make anything of the reason of its very existence. It would end like a Picasso painting, missunderstood by most and explored by none.

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.

6:17 is just a great point

Have you try litelements without compilation?

Could we have an answer from the Lee link?

1:52 he got you covered, there is a huge link on the header

NEXT_PUBLIC_ env vars being build time is the only wrinkle I've encountered moving from Vercel deployment to vanilla kubernetes or eks/ecs/gcp/azure/self-hosting a Next.js app.

What is your matrix id?

I completely agree. The real winners here are the chip makers

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 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 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 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.

"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 don't use next JS, or previous JS, or current JS; all my homies hate JS

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?

"Huh whats this Remix thing? I've never heard of this." >React, again Dropped.

i like Remix a lot

Hot take on app router - they made a judgement mistake when defining their APIs for it. They went with a "side-effects" approach, reminiscent of Meteor, where a lot of features are enabled/disabled by the usage of adjacent APIs. for example, it turns on/off various caching features, based on whether or not you access methods on the Request object. This is a giant mistake, and a big step backward. It IS well documented, but it's not clear what state you are mutating, and which features that's going to effect, when you access these APIs. I always prefer direct descriptive APIs. It's not bad, it does make sense, and it's well considered. But it's got that element of magic, and that tends to come back to you at some point, in some head scratching edge cases. That said, it has far too many great features, and enables far better data pipeline (last mile) patterns, to ignore. It's simply better than pages router many other ways. And, the defaults are well considered - they will mostly help, rather than get in your way.

It's amazing how you post something about not using next.js literally days after being in their conference, lmfao

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 )

"As Next is a popular alternative to Remix" ? ... Got the order reversed there.

I don’t play yet the video but for the title and the picture, totally agree! 😂

Was going to get a heart attack in the first second.

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"

Which stack do you prefer for the midlevel devs? (On a serious note)

"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.

“Never worry about a bundler” and “Any JS Framework” is like saying oil and water mix easily 😂

I jumped into next I put “use client” on my root page I keep usestate hooks n every component I use Link for conditional rendering 😂

"preface the universe" 😂

new hour long video from prime? i click. i simple man

wrappers: evil helpers: Good

kent vs lee cage match 🥊

Why is Dr. Disrespect reading javascript blogs?

Regarding self-hosting of Next, my biggest struggles definitely come from handling of environment variables especially when working with containers. The conditions in which Next variables are compile time vs non compile time in conjunction with trying to have a single image running across Test, Staging and Prod definitely left a sour taste for me. The further blurring of the lines between server and client code adds to this where I really do struggle recommending the framework to people without adding caveats

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..

/* Intentionally left blank */

That was a great one

This video made me appreciate Vue and Quasar even more!

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.