4 ms·

Of course you don’t need it, I don’t think anybody would argue you do. The article even acknowledges that in the 3rd sentence :) Personally I use Next/React al

Of course you don’t need it, I don’t think anybody would argue you do. The article even acknowledges that in the 3rd sentence :) Personally I use Next/React along with all the fun stuff that goes with it for basic personal sites because it’s the same stack I use at my day job and I can be productive quickly. The skills are transferable, I frequently learn something while working on a personal project that I can apply to a work project, and vice versa. That part is very valuable to me.

benatkin 4y ago
> The skills are transferable Are the big projects using Next because it's useful or because it's trendy? (Maybe that's the wrong word, it's "trendy" with some staying power, like Apple.) Sometimes, particularly when caught in a difficult upgrade cycle, Next is more trouble than it's worth. I'm don't know if that's the case now. It is a marketable skill, that's for sure. I just don't know if you should choose a framework just because it's popular.
- somehnguy 4y ago
  I think popularity is a completely valid reason for choosing one framework over another. It means I’m more than likely not the first person to run into problem x or need y, and don’t need to reinvent the wheel. That means I can focus on developing useful things instead of getting tangled up in the tech. Which can be super fun of course, but most of the time I need to accomplish something other than playing with fun tech.
  - benatkin 4y ago
    Well, Bright is a good example of this, in the post. Sure, you may need RSC to use it (or at least React). But it seems like it could have be written to support multiple frameworks without losing much of anything. That may be possible in the future because it says it's "RSC-first".
- bottlepalm 4y ago
  It's legit useful. Same language on the front and backend. Easily share dtos and libs across server/client. Able to render server side and/or client side. Same template logic on both (React). State is seamlessly transferred from server to client. The compiler creates optimal javascript bundles for every page on your site. SSR, SSG, ISR, CSR - are all options you can choose per page. I've use almost most frameworks out there over decades, currently Next feels like the most productive. My wish list for it includes better static typing of api routes like trpc. A first class solution, like DI maybe for structuring backend code and accessing it via api or props.
  - benatkin 4y ago
    > Same language on the front and backend. Yes, isomorphic JS. With React it can be annoying if you have a component that you never intended to run on the server and you get a hydration warning. It also complicates the decision of what language to use on the backend. It is often useful though.

benatkin 4y ago

> The skills are transferable Are the big projects using Next because it's useful or because it's trendy? (Maybe that's the wrong word, it's "trendy" with some staying power, like Apple.) Sometimes, particularly when caught in a difficult upgrade cycle, Next is more trouble than it's worth. I'm don't know if that's the case now. It is a marketable skill, that's for sure. I just don't know if you should choose a framework just because it's popular.

somehnguy 4y ago
I think popularity is a completely valid reason for choosing one framework over another. It means I’m more than likely not the first person to run into problem x or need y, and don’t need to reinvent the wheel. That means I can focus on developing useful things instead of getting tangled up in the tech. Which can be super fun of course, but most of the time I need to accomplish something other than playing with fun tech.
- benatkin 4y ago
  Well, Bright is a good example of this, in the post. Sure, you may need RSC to use it (or at least React). But it seems like it could have be written to support multiple frameworks without losing much of anything. That may be possible in the future because it says it's "RSC-first".
bottlepalm 4y ago
It's legit useful. Same language on the front and backend. Easily share dtos and libs across server/client. Able to render server side and/or client side. Same template logic on both (React). State is seamlessly transferred from server to client. The compiler creates optimal javascript bundles for every page on your site. SSR, SSG, ISR, CSR - are all options you can choose per page. I've use almost most frameworks out there over decades, currently Next feels like the most productive. My wish list for it includes better static typing of api routes like trpc. A first class solution, like DI maybe for structuring backend code and accessing it via api or props.
- benatkin 4y ago
  > Same language on the front and backend. Yes, isomorphic JS. With React it can be annoying if you have a component that you never intended to run on the server and you get a hydration warning. It also complicates the decision of what language to use on the backend. It is often useful though.