I hate seeing it. Blood from my eyes. Millennials reinvented yet another basic stuff. Why for achieving simple things you have to fetch thousands of dummy packages and make development super complicated?
Great video! I loved the part where you talked about the types of apps Remix could be most useful for. Showed me the kind of thinking that goes into deciding how to construct the architecture of an app from the ground up. I would love to hear you speak more about fundamental things like modern app architecture, toolchains, programming patterns or JavaScript best practices. Your work is highly appreciated. 💚
DDD, CQRS, ES, SOLID, Design patterns... and probably FE or BE that's it... If u think in CQRS way, u will find that frameworks like next.js, remix or similar are just not need crap...
@@sebastiangudino9377 Sooner or later, eve medium projects, have issues with bad code structure with domain lgoic inside FE etc.. FE does not nead any framework jazz, 'like they solved your issues' u really don't need most of the time...
this channel is likely one of the largest influencers of the development of the net now. Clearly the best resource for information gathering from the development perspective. There is nothing else as concise informative and inspired. Its a bit like John Oliver was for silly injustices
The co-location of code is going to make a lot of ex PHP Devs happy as well 😅 SSR/SSG is what the web was designed for... SPA's were just an interim tool during a time where we lacked simple server side tools. It gave us a lot more freedom, but we were always fighting web fundamentals to do it 😅
8:37 this is why I switch to backend development. frontend guys are just crazy fixing unimportant problems with all the resources and just creating fragmentation among the solutions
Truer words have never been spoken. Reminds me of an XKCD comic where a dev says that they'll create a "universal tool" that will "cover every edge case" you know how that goes...
"In the beginning, new frameworks were spaced by twenty-four weeks, then twelve, then six, then every two weeks. The last one was a week. In four days, we could be seeing a new JS Framework every eight hours until they are coming every four minutes"
Excellent video 🔥Some things that folks might not learn from the video (critical when deciding tech though) 1. Remix - Incremental Static Site Generation - You can do this in Remix, setup your cache headers `state-while-revalidate` which is a browser standard. - is it over kill for static content? I don't think so, it just doesn't come out of the box, but you get to learn and use the platform which is nice IMO; small lines of code 2. Remix - Static Builds - You can achieve similar behavior by taking advantage of browser cache headers; once the page is built the first time, cache it for YOUR_DESIRED_TIME - if you're really want this; use Puppeteer/Playwright to build your page at build time (cache headers is simpler) My Summary - Both frameworks are excellente, I prefer Remix for a few reasons: - there is only 1 abstraction around data fetching in Remix (useLoader) vs 4 in NextJS (get{Static,ServerAide,Initial}Props) & client fetching - I prefer Remix's "simpler" API / mental model (try it if you don't believe me 😉) - there's a lot of other nuances, is Remix better than Next NO. Both frameworks have tradeoffs, I just really really like the tradeoffs Remix has made. Worth noting is that all these frameworks influence each other, so they each are getting better
I tried JavaScript frameworks but it did not really click to me, coming from Rails and Laravel environment it is much easier for me to work with server side logic. Thank you for sharing Remix, I might get my hands wet this weekend. Also client side validation is really just an option, since remix focuses on the server side it is intuitive to do validation on the server side as well.
I still believe NextJS is still the best. Now the latest version also has a rust compiler underneath, so I am definitely not leaving NextJS for some time now.
Would be foolish to ditch a mature, non shady, open source framework backed by a multi billion dollars fast growing company ( Vercel ) and which get better at each release.
@@darshandev1754 but they were always upfront about their intentions. Why are people complaining that Remix is doing what they said they would do? Isn't it a good thing that it doesn't cost anything to use Remix? Most of the people saying this is "shady" are not the same people that actually paid for a license to support the project. Also, most of the people saying this are Next.js fanboys (and girls). I love Next.js but it's a good thing that there is some healthy competition.
Both Michael and Ryan have been very transparent about their goals. People who paid them did so with the intention of supporting them. As a benefit they also got direct support from Michael and Ryan to migrate or start using Remix. This is like supporting your favorite open source projects, which is still pretty rare to see-especially from businesses who relies on it.
@@daniel29009 Or just lucky enough to have financial stability and a passion to support new projects. I don't know anyone that regrets supporting them. Just having access to a discord with some of the best web developers around for a whole year was worth it... I've learnt a crazy amount about the web, several new deployment platforms, library bundling techniques and more
considering PHP uses $ too I wonder if there's already lots of solutions to this. SRS devs probably have experience with that, but then again I found a XSS exploit in an ADDRESS FIELD at work the other day
I love the way you casually said the rainbow animation tricked your brain into thinking it must be good. I personally care a lot for aesthetics so I do get influenced a lot by the way a product is marketed visually. That's why I'm so torn when it comes to latex or vim. I rather use good looking editors like vscode with plugins instead of the more robust OGs
If you think about it, each react project are it's own framework, because more often than not, each react project is different in terms of libraries used.
Remix does support SSG and ISR, albeit not being "built-in" as a feature. You can set HTTP headers (max-age, stale-while-revalidate-, etc.) for ISR and optionally a CDN for SSG. You have full control over how your pages are cached. Also "pages" doesn't have to be pages that are rendered with UI. Just exporting a loader and/or mutation function will make it regular endpoint (e.g. for APIs). The default export is optional if you want to render something with React. Another major benefit in Remix is that it's built with the idea to avoid "waterfall" requests that often happen as a result of co-locating data fetching into components. While co-location has its benefits in terms of maintenance and separation, in a client-side app, it can really hurt user experience; especially when there are a lot of components that fetches data.
But with true SSG you can just upload the files to a storage bucket - no server runtime needed. Remix does not have a mechanism like getStaticPaths to do that. In theory, with perfect caching you could get the same perf, so I get what you're saying, but I'd bet on SSG being faster in the real world. The ability fetch data in parallel is really cool tho.
@@heroe1486 No, because CRA relies inherently on react-scripts which only bundles client-side (until React Server Components are a thing). You won't be able to statically render a CRA app without introducing a server and static rendering manually. It's not feasible to use CRA if your intention is to have SSG, SSR and ISR. CRA is different from React itself in that it is just a toolkit for building apps with React.
@@baggier I'm not sure if you are just messing or not haha They asked for support, got the support, built the thing, released it for free. No tomfoolery and they were incredibly transparent about it
It is like watching video with 2x speed. This is the only channel that I need to slow down the video speed 😃 . Anyway you do a good work, it's a fantastic channel!
I can't wait to build an application using it, deploy to production, and for no reason they just decide to remove stuff you are using. Just like they do on monthly-basis with React Router.
6:16 Totally agree, Yeah I have experience with those things and Let me tell you they are scary, like just try making that form in image shown at 6:16 in react, I bet it would be pain stalkingly difficult if you add validation. So yeah, They need to figure this out
Can we just appreciate the people that devote their lives to making us other developers lives easier. Personally, more than just the code, I’m so glad to be in a career path where people go out of their way to make a huge difference in the experience of literally thousands if not millions of people with what they write. It goes unappreciated, so if you’re one of those and you know who you are, thank you.
For anyone wondering, the licence was paid because it was initially just Michael and Ryan working on it full time (they have families to support) 😅 As they got more support, they brought on more talented devs, and eventually got enough independant funding to go open source and free! People normally take this approach as a negative without looking deeper into it which is a little disappointing!
@@assaulterpt unfortunately it's the nature of our world, we see so many frameworks and immediately think negative... At least this time its a pair of guys who've given us SOOO many great tools already over years Like react router, and unpkg alone have been game changers. That's the only reason I backed it from the start, if anyone's gonna do a good job it's them
@@tomrowe2181 Totally agree. If you want to build a business around technology, open source is really not sustainable unless you already have recurring funding. The majority of people (and businesses) that rely on open source don't support the maintainers, who can be under a tremendous amount of stress as the project grows. It's a sad reality.
@@Fireship All good, you didn't come off negative I've just been seeing "oh it must be bad because they had to stop charging for it" so frequently, It makes me sad 😅 I just want everyone to have a go for themselves and keep an open mind... Its first week of release, has such a talented/nice team, a great community and already showing so much potential 💯 Edit: I re-read my comment and updated it to read how I actually feel :P
kent c dodds seems to be super excited about it and joined them to make the docs and training for it. So if nothing else, it'll have the best documentation and tutorials you've ever seen.
Kent was the perfect fit, and unreal that we'll get his quality of content for free Going to be interesting to see how much he does with time, and not having to rush for launch 😅 he pumped out a deep dive tutorial in a day
Server components are totally distinct from server-side rendering (SSR), and can provide huge benefits to any existing SSR framework including Remix. They main advantage is that the React component code for server components *never* gets sent to the client, which is not the case for Remix (unless you disable JavaScript entirely, but that's a very heavy hammer). Another advantage is that React server components do not require sending the data necessary for hydrating the React components on the client. Server-side renders of traditional React components require sending the HTML representation of the React components (obviously) as well as all the JavaScript data required to hydrate those components on the client (usually serialized to JSON and embedded in the HTML in a script tag). For some components, like large blocks of rich text, this can be a significant increase in the total size of the SSR HTML response.
At the end of the day it's a way less Mature Rails/Django but with React/node as first citizen. People went away from monolith to a decoupled architecture for a reason. Most prefer having their backend on a side and use a Js framework alongside.
With Remix you get slightly better Lighthouse score == better SEO. Also because there is not SSG, I feel like it's easier to learn. Nested routing and catch/error boundaries are also useful features than can improve the UX and performance quite a bit. Remix is still behind when it comes to features like localization and image optimization (and SSG if you need it). Next also has better documentation IMO.
Hi, can you please introduce the best or easiest framework to build frontend? I am a backend developer and I work with Go and Python and I am looking for an easy way to build some frontend
Many patterns remind me of Sveltekit, just with a React flavour. Was only a question of time when the pendulum would swing back from all client to all server.
The most exciting part of the video was the news about Rich Harris joining Vercel to work on Svelte full-time. Remix feels a bit outdated already, full server-side rendering feels like PHP all over again.
I would like to hear what kind of applications would fit best for which framework around, or another saying, which framework covers which gap that others didn't? Thanks for the great content and criticism you just put in your videos.
My team has tried Remix, and sadly it has proved itself to be quite difficult to maneuver with ever-changing customer requirements. In an ideal world, with better processes and more workshops with the customers, there would be no need for just-in-time changes to the underlying architecture. But currently, it has to many mechanics to work around for it to be usable in the real world for us. Had we designed an application ourselves, with no unexpected requirements popping up, it would've been a different story. Maybe it'll become a more mature tool in the future. For its purposes it did great, it just created a lot of overhead for some things that would've been simple in Next.js.
Bit of a shame that it can't do SSG. In next, costs can be saved by setting it to SSG if the application built allows for it. That way we can scale it up and down as our requirements change.
Remix runs on (eg) Cloudflare. The costs are so tiny it's not worth worrying about. And we *can do SSG, we just write a function to build it all then cache that.
First the sites were rendered on the server. Then they were all contained in the client side code and only the data was fetched from the server. Now we're back to server rendering.
hey Fireship, great content, i've been a follower for a long time. Can you tell me (or anyone reading this comment) what is the name of the theme you are using here? Been meaning to ask for some time now, looks awesome
One of my junior devs was very confused when I mentioned SSR and the fact that you can build a website without all 1000 node modules, dependencies, builds etc...
I took a look and tbh I don’t see myself straying from me the for the few things it offers. The benefit of going static when you can is worth sticking to one framework imho
I love how JS frameworks have come full circle back to server-side rendering.
😂
Sshhhh! Dont tell them about PHP.
@@MarushDenchevthis is one language I've just been unable to learn 😂
@@MarushDenchevI'm still kinda shocked the JS Devs didn't see this car crash waiting to happen.
I hate seeing it. Blood from my eyes. Millennials reinvented yet another basic stuff. Why for achieving simple things you have to fetch thousands of dummy packages and make development super complicated?
Legend says there's not a single day without a new JS framework being born.
2 JS frameworks were born since this comment.
@@oskrm you wrong bro its 3 🗿
@@hesam3272 😶 which are they
haha each day confuse a dayb
Ain’t that what the dude in the video said
"hiring people with 7 years of Remix experience"
Any DJ: who summoned me?
40hrs*52wks*7yrs = 14,560 hours
If you constantly code remix 20hrs a day for 7300hours a year you can beat the requirement in 2 years.
@@TheNewton in 2 years time, the requirement will be 9 years+
I have 8
classic
"But it might be overkill if your just building a blog that you post to once a year"
I feel personally attacked
LMAO, same here.
😅
I was going to make that....
Now anyway I am only going to use github pages
fireship：wow cap, just let you know, nothing personal......
Me: .... To me it is!
wordpress being built on PHP: 👁️👄👁️
@@vaisakh_km Try Deno Deploy, my man
Jeff: "The last thing we need is another JS framework".
Also Jeff: "Remix is a NEW JS framework you MUST try"
bUt ThIs OnE iS DiFfErEnT
@@SteamDeckGameplay Yup and she says Im not like the other girls
Great video!
I loved the part where you talked about the types of apps Remix could be most useful for. Showed me the kind of thinking that goes into deciding how to construct the architecture of an app from the ground up.
I would love to hear you speak more about fundamental things like modern app architecture, toolchains, programming patterns or JavaScript best practices.
Your work is highly appreciated. 💚
Yes that would be great
I second this!
DDD, CQRS, ES, SOLID, Design patterns... and probably FE or BE that's it... If u think in CQRS way, u will find that frameworks like next.js, remix or similar are just not need crap...
@@MrEnsiferum77 Unless you are working for a big company and need a scalable easy to mantain application with great performance i guess
@@sebastiangudino9377 Sooner or later, eve medium projects, have issues with bad code structure with domain lgoic inside FE etc.. FE does not nead any framework jazz, 'like they solved your issues' u really don't need most of the time...
this channel is likely one of the largest influencers of the development of the net now. Clearly the best resource for information gathering from the development perspective.
There is nothing else as concise informative and inspired.
Its a bit like John Oliver was for silly injustices
It's great that web development is going back to its roots again with SSR.
Me, astonished: SSR you are back!
SSR: I never left
*epic music starts*
Meh, not a fan of SSR at all.
The co-location of code is going to make a lot of ex PHP Devs happy as well 😅
SSR/SSG is what the web was designed for... SPA's were just an interim tool during a time where we lacked simple server side tools.
It gave us a lot more freedom, but we were always fighting web fundamentals to do it 😅
Yup. Simple, scalable, stable. I never left 😂
@@tomrowe2181 Yea it's like trying to fit a square into a circle
8:37 this is why I switch to backend development. frontend guys are just crazy fixing unimportant problems with all the resources and just creating fragmentation among the solutions
Truer words have never been spoken.
Reminds me of an XKCD comic where a dev says that they'll create a "universal tool" that will "cover every edge case"
you know how that goes...
haha, for real tho, I switched to DevOps and some backend development.
"In the beginning, new frameworks were spaced by twenty-four weeks, then twelve, then six, then every two weeks. The last one was a week. In four days, we could be seeing a new JS Framework every eight hours until they are coming every four minutes"
Pelicans Law
@@DenfordBerriman ?
@@HELLO7657 Ohhhhh, don’t tempt me
Jeff you almost have a million subscribers holy crap man
Excellent video 🔥Some things that folks might not learn from the video (critical when deciding tech though)
1. Remix - Incremental Static Site Generation
- You can do this in Remix, setup your cache headers `state-while-revalidate` which is a browser standard.
- is it over kill for static content? I don't think so, it just doesn't come out of the box, but you get to learn and use the platform which is nice IMO; small lines of code
2. Remix - Static Builds
- You can achieve similar behavior by taking advantage of browser cache headers; once the page is built the first time, cache it for YOUR_DESIRED_TIME
- if you're really want this; use Puppeteer/Playwright to build your page at build time (cache headers is simpler)
My Summary
- Both frameworks are excellente, I prefer Remix for a few reasons:
- there is only 1 abstraction around data fetching in Remix (useLoader) vs 4 in NextJS (get{Static,ServerAide,Initial}Props) & client fetching
- I prefer Remix's "simpler" API / mental model (try it if you don't believe me 😉)
- there's a lot of other nuances, is Remix better than Next NO. Both frameworks have tradeoffs, I just really really like the tradeoffs Remix has made. Worth noting is that all these frameworks influence each other, so they each are getting better
Hi Clifford, nice to meet here and nice summary! Hope you are doing well!
"It's a lot easier to lose money and get acquired versus trying to sell a JavaScript framework."
- Jeff
Now we need meta frameworks to help evaluate them so we can figure out what framework to use for a project.
Time goes faster than normal while watching your videos :)
I tried JavaScript frameworks but it did not really click to me, coming from Rails and Laravel environment it is much easier for me to work with server side logic. Thank you for sharing Remix, I might get my hands wet this weekend.
Also client side validation is really just an option, since remix focuses on the server side it is intuitive to do validation on the server side as well.
I still believe NextJS is still the best. Now the latest version also has a rust compiler underneath, so I am definitely not leaving NextJS for some time now.
Would be foolish to ditch a mature, non shady, open source framework backed by a multi billion dollars fast growing company ( Vercel ) and which get better at each release.
yep
@@heroe1486 I really don't get how Remix is "shady".
@@michaelfrieze maybe it gives off some of those vibes with the change in their business model, $250 -> $0
@@darshandev1754 but they were always upfront about their intentions. Why are people complaining that Remix is doing what they said they would do?
Isn't it a good thing that it doesn't cost anything to use Remix?
Most of the people saying this is "shady" are not the same people that actually paid for a license to support the project. Also, most of the people saying this are Next.js fanboys (and girls).
I love Next.js but it's a good thing that there is some healthy competition.
Consider how those who paid for it must be feeling now that it is available for free.
Both Michael and Ryan have been very transparent about their goals. People who paid them did so with the intention of supporting them. As a benefit they also got direct support from Michael and Ryan to migrate or start using Remix.
This is like supporting your favorite open source projects, which is still pretty rare to see-especially from businesses who relies on it.
@@dealloc Good point
Haha, you must be insane to pay for a js framework.
@@daniel29009 Or just lucky enough to have financial stability and a passion to support new projects.
I don't know anyone that regrets supporting them.
Just having access to a discord with some of the best web developers around for a whole year was worth it... I've learnt a crazy amount about the web, several new deployment platforms, library bundling techniques and more
Honestly, supporting Remix was the best investment I've made in a long time :-)
That $ for dynamic routes is not so good for handling files in the terminal. You have to escape it when creating and deleting those files.
So very true
considering PHP uses $ too I wonder if there's already lots of solutions to this. SRS devs probably have experience with that, but then again I found a XSS exploit in an ADDRESS FIELD at work the other day
Use GUI
@@cheesebusiness nty
@@cheesebusiness because that scales
I love the way you casually said the rainbow animation tricked your brain into thinking it must be good. I personally care a lot for aesthetics so I do get influenced a lot by the way a product is marketed visually. That's why I'm so torn when it comes to latex or vim. I rather use good looking editors like vscode with plugins instead of the more robust OGs
my monkey brain instantly trusts websites if the css is pretty
Damn, frontend web development is getting more and more complex, so much to learn!
you know that a video is awesome when there is a lack of "use me as dislike" comments, great work!
"The last thing we need is another JS framework" ~ Jeff in test of 10 frameworks
I was looking for this comment, thanks
4:22 the most advance routing system is off line with advance fetching - ' offline JS container framework '
69 likes... nice
If you think about it, each react project are it's own framework, because more often than not, each react project is different in terms of libraries used.
everyday!! new contents from fireship :D
Remix does support SSG and ISR, albeit not being "built-in" as a feature. You can set HTTP headers (max-age, stale-while-revalidate-, etc.) for ISR and optionally a CDN for SSG. You have full control over how your pages are cached.
Also "pages" doesn't have to be pages that are rendered with UI. Just exporting a loader and/or mutation function will make it regular endpoint (e.g. for APIs). The default export is optional if you want to render something with React.
Another major benefit in Remix is that it's built with the idea to avoid "waterfall" requests that often happen as a result of co-locating data fetching into components. While co-location has its benefits in terms of maintenance and separation, in a client-side app, it can really hurt user experience; especially when there are a lot of components that fetches data.
But with true SSG you can just upload the files to a storage bucket - no server runtime needed. Remix does not have a mechanism like getStaticPaths to do that. In theory, with perfect caching you could get the same perf, so I get what you're saying, but I'd bet on SSG being faster in the real world. The ability fetch data in parallel is really cool tho.
@@Fireship Agreed it may not be viable if most of your app relies on being SSG, in which case Next.js would be a better alternative.
If not built in then you can also reproduce all of that with bare Create React App since all of these frameworks are just abstractions over bare React
@@heroe1486 No, because CRA relies inherently on react-scripts which only bundles client-side (until React Server Components are a thing). You won't be able to statically render a CRA app without introducing a server and static rendering manually.
It's not feasible to use CRA if your intention is to have SSG, SSR and ISR.
CRA is different from React itself in that it is just a toolkit for building apps with React.
@@dealloc Yes obviously, I just wanted to say react and not CRA
This video is super helpful! thanks for creating it~ it was also entertaining to watch
when u go from 1000 dollar license to free opensource MIT....
*i think they fired the CFO*
Didn't they raise capital?
Yeh, they got funding and immediately started the process of open sourcing
@@ortor massive tomfoolery
"Hey Tom remember we hired u 3 months ago to sell these licenses, *well we sold enough you're fired* "
@@baggier I'm not sure if you are just messing or not haha They asked for support, got the support, built the thing, released it for free.
No tomfoolery and they were incredibly transparent about it
They raised a tonne of money so they could open source it
It is like watching video with 2x speed. This is the only channel that I need to slow down the video speed 😃 . Anyway you do a good work, it's a fantastic channel!
I can't wait to build an application using it, deploy to production, and for no reason they just decide to remove stuff you are using. Just like they do on monthly-basis with React Router.
true, very frustrating
This.
6:16 Totally agree, Yeah I have experience with those things and Let me tell you they are scary, like just try making that form in image shown at 6:16 in react, I bet it would be pain stalkingly difficult if you add validation. So yeah, They need to figure this out
What !!!! Yesterday only me and colleagues were discussing about remix and today he uploaded the video.
Can we just appreciate the people that devote their lives to making us other developers lives easier. Personally, more than just the code, I’m so glad to be in a career path where people go out of their way to make a huge difference in the experience of literally thousands if not millions of people with what they write. It goes unappreciated, so if you’re one of those and you know who you are, thank you.
For anyone wondering, the licence was paid because it was initially just Michael and Ryan working on it full time (they have families to support) 😅
As they got more support, they brought on more talented devs, and eventually got enough independant funding to go open source and free!
People normally take this approach as a negative without looking deeper into it which is a little disappointing!
I didn't know that, although I didn't talk bad remix I thought badly of it. So thanks for that knowledge.
@@assaulterpt unfortunately it's the nature of our world, we see so many frameworks and immediately think negative... At least this time its a pair of guys who've given us SOOO many great tools already over years
Like react router, and unpkg alone have been game changers.
That's the only reason I backed it from the start, if anyone's gonna do a good job it's them
@@tomrowe2181 Totally agree. If you want to build a business around technology, open source is really not sustainable unless you already have recurring funding. The majority of people (and businesses) that rely on open source don't support the maintainers, who can be under a tremendous amount of stress as the project grows.
It's a sad reality.
I didn't intend to come off too negative about that. Tbh, I wish that model was more accepted. It's just a hard sell outside of loyal followers.
@@Fireship All good, you didn't come off negative I've just been seeing "oh it must be bad because they had to stop charging for it" so frequently, It makes me sad 😅
I just want everyone to have a go for themselves and keep an open mind... Its first week of release, has such a talented/nice team, a great community and already showing so much potential 💯
Edit: I re-read my comment and updated it to read how I actually feel :P
And on the 7th day, the lord said "let there be JavaScript frameworks"
You always make me hyped up 🎉
Remix seems to have really great potentials. I will definitely look into it next month.
kent c dodds seems to be super excited about it and joined them to make the docs and training for it. So if nothing else, it'll have the best documentation and tutorials you've ever seen.
Kent was the perfect fit, and unreal that we'll get his quality of content for free
Going to be interesting to see how much he does with time, and not having to rush for launch 😅 he pumped out a deep dive tutorial in a day
If people ask me what was so special about RoR I always say it had a Rest endpoint on each controller back in 2006.
2:05 I'm sold with the rainbow
4:34 why not const loader?
Good question, that's straight from their starter demo.
Personal preference of one of the Remix founders. It's just for the starter kit, so you're free to change it to your own preference.
Great, another framework what companies can highlight as a requirement in their job description
5 years Remix experience pls.
Their website is just amazing
Loved the Two minutes papers reference at the end :)
Great video! I liked the part where you talked about Remix
I'm glad you also mentioned Rich and Svelte as well as Nuxt 3 . Great video.
8:38 no way! I love Svelte Kit
"What a time to be alive"... For a second I nearly squeezed my paper, but realized that's another channel... aahhahaha
Insightful as always!
Server components are totally distinct from server-side rendering (SSR), and can provide huge benefits to any existing SSR framework including Remix. They main advantage is that the React component code for server components *never* gets sent to the client, which is not the case for Remix (unless you disable JavaScript entirely, but that's a very heavy hammer). Another advantage is that React server components do not require sending the data necessary for hydrating the React components on the client. Server-side renders of traditional React components require sending the HTML representation of the React components (obviously) as well as all the JavaScript data required to hydrate those components on the client (usually serialized to JSON and embedded in the HTML in a script tag). For some components, like large blocks of rich text, this can be a significant increase in the total size of the SSR HTML response.
@0:23 referring to rental prices in NYC, in the 80s, with Dave Letterman.
So we've come full circle. What about using Koa or Express with a templating engine such as handlebars? Or maybe mustache? Or some other?
It’s shameful to write a pure HTML instead of JSX
(sarcasm)
Doesn't Express have ejs templates for this exact purpose?
Make a youtube video series talking about the different licences used in repos and what they mean to us programmers.
Blitz seems very promising and I think It will be so good for simplifying backend work
At the end of the day it's a way less Mature Rails/Django but with React/node as first citizen. People went away from monolith to a decoupled architecture for a reason. Most prefer having their backend on a side and use a Js framework alongside.
I like NextJS because I don't think it's going to go away anytime soon.
A new JS framework brings more options for experienced devs and more confusion for beginners
😅
Ok. What's the advantage vs Next.js?
With Remix you get slightly better Lighthouse score == better SEO. Also because there is not SSG, I feel like it's easier to learn. Nested routing and catch/error boundaries are also useful features than can improve the UX and performance quite a bit.
Remix is still behind when it comes to features like localization and image optimization (and SSG if you need it). Next also has better documentation IMO.
I keep forgetting to breath watching these videos.
I think is time to build my new framework
This channel saved my college career
Angular SSR is so good. With PWA as an added insensitive.
Hi, can you please introduce the best or easiest framework to build frontend? I am a backend developer and I work with Go and Python and I am looking for an easy way to build some frontend
Here's 10 options to try out ;) ua-cam.com/video/cuHDQhDhvPE/v-deo.html
React
HTML
You can’t go wrong with SQL stored procedures which return HTML strings
Please do not even go nearby poor react js. That is horrible. React insist you to write very alien complex syntax which is nonsense.
why does the voice change after 6:20? different mic or different person?
Great video, as always.
Next video about SvelteKit ☝️
Many patterns remind me of Sveltekit, just with a React flavour. Was only a question of time when the pendulum would swing back from all client to all server.
I've tried it Its great.
I love ur icon pack
Can u tell which icon pack r u using
Is “What a time to be alive” a reference to Two Minute paper channel? Both are one the greatest UA-cam channels!
The most exciting part of the video was the news about Rich Harris joining Vercel to work on Svelte full-time. Remix feels a bit outdated already, full server-side rendering feels like PHP all over again.
Wonder if I can use Formik with the component...
Now that you have mentioned it, what happened to Gatsby? Never have heard it since quite a while...
Having worked with both, NextJS still feels better but will keep an eye on Remix - promising
A new javadcrjpt framework...what a surprise
2:20 which extension you are using to file icon
I would like to hear what kind of applications would fit best for which framework around, or another saying, which framework covers which gap that others didn't? Thanks for the great content and criticism you just put in your videos.
Thanks for the video! What is the icons plugin you're using???
That guy is really, really funny. He has almost all of my sense of humor. :D
Nah I'm excited for blitz js plus setting it up with tailwindcss boom 💥
Oh boy! Another JS framework I'll never use, but will have a 5+ years experience requirement for every single dev job.
Deno support? Let's goooooooo!
Two years later, I see that Remix was ahead of Next.js, yet still is simple and agnostic 👏.
My team has tried Remix, and sadly it has proved itself to be quite difficult to maneuver with ever-changing customer requirements. In an ideal world, with better processes and more workshops with the customers, there would be no need for just-in-time changes to the underlying architecture. But currently, it has to many mechanics to work around for it to be usable in the real world for us.
Had we designed an application ourselves, with no unexpected requirements popping up, it would've been a different story. Maybe it'll become a more mature tool in the future. For its purposes it did great, it just created a lot of overhead for some things that would've been simple in Next.js.
Oof
Bit of a shame that it can't do SSG. In next, costs can be saved by setting it to SSG if the application built allows for it. That way we can scale it up and down as our requirements change.
Remix runs on (eg) Cloudflare. The costs are so tiny it's not worth worrying about. And we *can do SSG, we just write a function to build it all then cache that.
For sure OpenAI watched this
they have the coolest website ever
Whoa dude, nice video
First the sites were rendered on the server. Then they were all contained in the client side code and only the data was fetched from the server. Now we're back to server rendering.
Wondering if localized routes are supported...
hey Fireship, great content, i've been a follower for a long time. Can you tell me (or anyone reading this comment) what is the name of the theme you are using here? Been meaning to ask for some time now, looks awesome
One of my junior devs was very confused when I mentioned SSR and the fact that you can build a website without all 1000 node modules, dependencies, builds etc...
@Fireship what icon plugins are you using?
awesome video like usual thank you so much !! , btw the image of remix's logo was so flow it hurted my eyes :'(
Next has SSR and SSG. Why would I use remix that only provide one of them?!
May be those who don't want the other and need more faster code....
Idk... I am only a Newbie
@@vaisakh_km i meant you can do everything SSR in next if you want or mix with static generation and/client.
@@vaisakh_km NextJS take care of all that, you can go full SSG or SSR and even mixing both in the same project
Long life to Vanilla JavaScript!
Onnnn spot thanks for the vid
The only framowork I'm waiting for now is a framework to help build frameworks
Im waiting for the framework that helps one decide which framework one should use without having to learn how to use all the frameworks.
I took a look and tbh I don’t see myself straying from me the for the few things it offers. The benefit of going static when you can is worth sticking to one framework imho
We've come full circle ⭕
Please do a video on Arc CDN. Would love to hear your opinion of it!