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?
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
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
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 😅
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
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...
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...
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
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.
"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"
@@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
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
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.
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
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.
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 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.
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
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.
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.
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.
When svelte/sveltekit enters the room , poor react, angular, and vue bow down. Svelte is the future of the Web 4.0. It has transitions of DOM elements, API back end, SSR , app initiating by ssr and taken over by csr, whole app ssr, which are out of the box and pleasant developer experience, less LOC, smaller bundle size. Most importantly we are writing 99% plain JavaScript which is close to my heart. It has typescript also which is optional. What else do we need?
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!
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
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.
My biggest reason for being bullish on Remix is how focused it is on using the fundamentals of the web at it's core. Yes, they have nice abstractions but the simple things like using the Fetch API and forms using method="post" are really big wins for me.
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.
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.
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.
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
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.
SSR nah, I will keep paying tribute to SPA gods for the time being. Juggling fetched data between the loader and the component, what the heck is that. React's own code splitting, suspense, error boundry and React Router 6 makes me happy already I think.
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...
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.
If you know fror sure you'll deploy your finished app to AWS Lambda, is it a good idea to choose that option during initialization - i.e. the app will run fine on your local host correct during development. Or is it best, for the time being to just choose "Remix App Server" ?
Hey... The Classical WinForm that you showed, I'm working on a simmilar application and we are looking up for a very intensive database and data bound application... Can you suggest what would be best framework for inexperienced front-end developer with ton of back-end and Database handling?
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
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.
Sir please make a discord community for fireship channel. It is very helpful to communicate between people. RUclips comments is very inconvenient to use and it is easy for question and answer.
Developers, can we stop making comercial/public frameworks? It ruins programming especially for new developers. We might as well be arguing over tabs and spaces. BTW great video Jeff! Keep it up!
Now that React Router 6.4 has come out, I feel like we could build Remix apps without even using it. The new router kind of turns React the library into React the framework which for me as someone who has only used React alone feels a bit unnatural, but very exciting for sure
it stray away from just bring a router, wish the data api were a separate library instead, i already use redux actions on express middlewares, to get data on the client and SSR. No need the overhead
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
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
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!
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
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
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
"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
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.
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...
"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
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 :-)
"It's a lot easier to lose money and get acquired versus trying to sell a JavaScript framework."
- Jeff
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.
"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
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
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
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
Damn, frontend web development is getting more and more complex, so much to learn!
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
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.
Now we need meta frameworks to help evaluate them so we can figure out what framework to use for a project.
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 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.
you know that a video is awesome when there is a lack of "use me as dislike" comments, great work!
Time goes faster than normal while watching your videos :)
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
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.
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.
"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
I'm glad you also mentioned Rich and Svelte as well as Nuxt 3 . Great video.
everyday!! new contents from fireship :D
If people ask me what was so special about RoR I always say it had a Rest endpoint on each controller back in 2006.
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.
When svelte/sveltekit enters the room , poor react, angular, and vue bow down. Svelte is the future of the Web 4.0. It has transitions of DOM elements, API back end, SSR , app initiating by ssr and taken over by csr, whole app ssr, which are out of the box and pleasant developer experience, less LOC, smaller bundle size. Most importantly we are writing 99% plain JavaScript which is close to my heart. It has typescript also which is optional. What else do we need?
What's Web 4.0? I think we are entering to Web 3.0, first time I heard about web 4.0, what's the difference between web 3.0 and web 4.0?
None of the features you listed is exclusive to svelte though.
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!
What !!!! Yesterday only me and colleagues were discussing about remix and today he uploaded the video.
A new JS framework brings more options for experienced devs and more confusion for beginners
😅
2:05 I'm sold with the rainbow
Great, another framework what companies can highlight as a requirement in their job description
5 years Remix experience pls.
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
Make a youtube video series talking about the different licences used in repos and what they mean to us programmers.
Loved the Two minutes papers reference at the end :)
Remix seems to have really great potentials. I will definitely look into it next month.
I like NextJS because I don't think it's going to go away anytime soon.
Their website is just amazing
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.
My biggest reason for being bullish on Remix is how focused it is on using the fundamentals of the web at it's core. Yes, they have nice abstractions but the simple things like using the Fetch API and forms using method="post" are really big wins for me.
Can't believe PHP patterns from 15 years ago are hip and trendy again
This channel saved my college career
You always make me hyped up 🎉
Angular SSR is so good. With PWA as an added insensitive.
8:38 no way! I love Svelte Kit
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.
Woooo! New Fireship vid!
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.
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?
Insightful as always!
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.
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
Wonder if I can use Formik with the component...
Having worked with both, NextJS still feels better but will keep an eye on Remix - promising
@0:23 referring to rental prices in NYC, in the 80s, with Dave Letterman.
Is “What a time to be alive” a reference to Two Minute paper channel? Both are one the greatest RUclips channels!
And on the 7th day, the lord said "let there be JavaScript frameworks"
Two years later, I see that Remix was ahead of Next.js, yet still is simple and agnostic 👏.
This video is super helpful! thanks for creating it~ it was also entertaining to watch
Whoa dude, nice video
Oh boy! Another JS framework I'll never use, but will have a 5+ years experience requirement for every single dev job.
I think is time to build my new framework
Great video! I liked the part where you talked about Remix
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
they have the coolest website ever
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.
For sure OpenAI watched this
Incredible!
Great video, as always.
I keep forgetting to breath watching these videos.
SSR nah, I will keep paying tribute to SPA gods for the time being. Juggling fetched data between the loader and the component, what the heck is that. React's own code splitting, suspense, error boundry and React Router 6 makes me happy already I think.
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...
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.
A new javadcrjpt framework...what a surprise
Nah I'm excited for blitz js plus setting it up with tailwindcss boom 💥
If you know fror sure you'll deploy your finished app to AWS Lambda, is it a good idea to choose that option during initialization - i.e. the app will run fine on your local host correct during development.
Or is it best, for the time being to just choose "Remix App Server" ?
Hey... The Classical WinForm that you showed, I'm working on a simmilar application and we are looking up for a very intensive database and data bound application...
Can you suggest what would be best framework for inexperienced front-end developer with ton of back-end and Database handling?
Next video about SvelteKit ☝️
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 ;) ruclips.net/video/cuHDQhDhvPE/видео.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.
Great video!
Deno support? Let's goooooooo!
Long life to Vanilla JavaScript!
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.
Sir please make a discord community for fireship channel. It is very helpful to communicate between people. RUclips comments is very inconvenient to use and it is easy for question and answer.
"What a time to be alive"... For a second I nearly squeezed my paper, but realized that's another channel... aahhahaha
I used remix because I can actual pair it with a normal node server. Something next.js makes harder to do.
Developers, can we stop making comercial/public frameworks? It ruins programming especially for new developers. We might as well be arguing over tabs and spaces.
BTW great video Jeff! Keep it up!
That guy is really, really funny. He has almost all of my sense of humor. :D
Onnnn spot thanks for the vid
Three things are certain in life : Death, Taxes and a new Javascript framework every month
Now that you have mentioned it, what happened to Gatsby? Never have heard it since quite a while...
Now that React Router 6.4 has come out, I feel like we could build Remix apps without even using it. The new router kind of turns React the library into React the framework which for me as someone who has only used React alone feels a bit unnatural, but very exciting for sure
it stray away from just bring a router, wish the data api were a separate library instead, i already use redux actions on express middlewares, to get data on the client and SSR. No need the overhead