I DONT USE NEXT JS
HTML-код
- Опубликовано: 30 окт 2023
- Recorded live on twitch, GET IN
/ theprimeagen
Reviewed article: www.epicweb.dev/why-i-wont-us...
By: Kent C. Dodds | x.com/kentcdodds?s=20
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Kinesis Advantage 360: bit.ly/Prime-Kinesis
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts 
Наука
Why is Dr. Disrespect reading javascript blogs?
"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"
_"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 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
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'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 😂
I really like the format of reading two opposing articles back-to-back. Very juicy knowledge and fresh perspectives
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"!
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.
"Every great cause begins as a movement, becomes a business, and eventually degenerates into a racket." - Eric Hoffer
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.
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 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
I left Next.js for Astro and havent looked back. For internal SPAs, vite + typescript
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 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 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.
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.
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
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.
41:41 my dockerized nextjs app broke after updating a patch release.
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
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.
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.
What did you replace it with?
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'll pickup Next when its finished.
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
Prime really loves Angular
caught me red handed
Hey @@ThePrimeTimeagen my hand is actually brownish
Thank you,
HR Team
@@ThePrimeTimeagen
@@ThePrimeTimeagen I would like to hear your opinion about new control flow syntax of Angular
@@ectn26it won't happen.
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!
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.
Oh boy 😆nice confusion technique at the beginning bro, 9 seconds in and I already liked the video.
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?
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
Bohr-Einstein debates are quite different nowadays.
Vercel does not play dice
@@SandraWantsCoke It always bets on the dollar
I don't use next JS, or previous JS, or current JS; all my homies hate JS
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.
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?
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
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
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.
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.
My problem right now with server actions is the amount of javascript added by making the user do a fetch request is so small.
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
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
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.
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.
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"
"Huh whats this Remix thing? I've never heard of this."
>React, again
Dropped.
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
Why everybody loses the chance to call him "Can't see dots"
love the potion seller opener frame lol
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.
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?
@@enkhbayarnyambayar9400 I suppose the UI is more complex
@@enkhbayarnyambayar9400 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?
The good partner is Svelte or Htmx with golang for the backend api.
"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
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.
What is your matrix id?
It's amazing how you post something about not using next.js literally days after being in their conference, lmfao
Shout-out to helpers as opposed to faćades or other non-useful abstractions that imply dependency management.
Helpers are the way to go, more flexibility, less coupling.
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.
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 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?
@@enkhbayarnyambayar9400 I don't use db clustering.
@@enkhbayarnyambayar9400 he don't
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
@@ymomoto43I'd go Typescript and a framework at the same time tbh. Now which framework not sure. Maybe whats hiring the most in your area?
@@valsimotkarpis9120 ty
TypeScript
"NextJS is like Kubernetes". Webdevs need to be stopped
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.
1:52 he got you covered, there is a huge link on the header
Could we have an answer from the Lee link?
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.
Im considering switching to Remix, after NextJs transferred to a PHP
Have you try litelements without compilation?
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.
“Never worry about a bundler” and “Any JS Framework” is like saying oil and water mix easily 😂
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.
He got a reply to that article from Nextjs
6:17 is just a great point
Was going to get a heart attack in the first second.
What about just using file based routing and image optimization and treat remaining nextjs just as react and build server on nodejs .
You have one hell of a voice. It's like gilbert gottfreid but without any of the talent that man has.
chefs kiss*
Your point at 4:24 is really, really important for some people to remember
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.
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.
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.
My main take from this video is that PHP is an amazing language because it has traits.
wrappers: evil
helpers: Good
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.
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
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
37:26 here the real winner in this😅
"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.
His first argument he says "oh, Remix just uses Request and Response. It's on MDN!". Next has been using Request and Response since Next 13 for route handlers and middleware. Haven't finished the video yet but this is an indicator that Kent hasn't used Next since 12 or earlier (at least a year ago)
Second argument: "it's hard to self-host a Next.js app as a Node.js application". No, it's not hard. You need a Node container that can run "next build && next start". It's literally that easy. Now, if you want to parse out your app so that every route handler runs as a lambda function, yes that is non-trivial, but do you really need this for your application?
i think we get to this
maybe self hosting next js is hard if you don't have the root access.
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.
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.
i like Remix a lot