> With this RFC, you can start using React features I’m guessing this should say React 18 instead?
Fixed!
Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
101–110 of 123 posts
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#102Frameworks like nextjs are in an eternal existential battle to stay relevant. In my 4 years of using Next, I experienced a large number (6 or 7 releases) of major version releases. What the industry needs is not more breaking changes, but solidified frameworks that companies can rely on. Every major release adds another wave of technical debt as things become deprecated. I appreciate updates, but to me this particula…
We've been very intentional about incremental adoption and reducing the number of breaking changes, as well as giving folks codemods when they upgrade and providing escape hatches. For example, when upgrading to Next.js 12, which turned on SWC by default, we had already been testing an experimental version for many months which folks could try out. Then with 12, you could opt-out in the config if you didn't want to use it by default.
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#103Quoted post unavailable.
Please don't do this. You're doing a disfavour to all the hard work you've put into Joystick framework. Keep up the effort and try to be positive.
I’m remarkably positive. Just trying to ruffle some feathers but unfortunately my sense of humor falls on deaf ears here.
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#104Quoted post unavailable.
Next.js looks so, so much more mature than Joystick, the latter appearing to be one person's pet project. I don't understand why you shared it in this thread, and i really don't understand the "don't do drugs" bit.
Yes, it’s been around for several years. I’ve been working on Joystick for a year. The “don’t take drugs” is a joke.
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#105Earlier quoted context omitted.
CRA isn’t really an alternative because it doesn’t have a server-side component. It’s also a lot less opinionated around things like routing. I’d say Remix is probably the main competitor to Next, that’s built around React Router and already has support for nested routes/layouts, and has opinionated support for the server-side too.
I'm implying that if you "don't need Next.js", because it's too heavy-weight (because e.g. you already have a dedicated team working on the back end API using a different language), then too bad: there's no lighter-weight alternative that is viable.
Nextjs has useful defaults and enough basic elements for front-end.
create-react-app is just a bunch of oppinions on how to config your app that dont really add much productivity if you are already familiar with webpack. Depending on the need I'd either go with react and my webpack config copied from last project or nextjs. Don't see the point of cra
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#106Earlier quoted context omitted.
According to Ryan Florence (Remix's creator) they are "ripping features straight from Remix". https://twitter.com/ryanflorence/status/1528859776930545665
Ryan and his insufferable Remix evangelists are the reason I never went beyond a quick hello world. And I like the concept. A while ago he had a Twitter series “spot a React app” where he just shits on other peoples work. Such an odd way to promote his work.
And this weird obsession with form methods and the way they make it like if you dont use form method you are an idiot.
Like get on with it, are there are other things in remix? I'd like to hear about them too!
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#107Earlier quoted context omitted.
Static isn't going anywhere. In my opinion, one the best parts about Next.js is you can blend static with dynamic, on a per-page basis. Your landing page can be completely static + periodically updated in the background (i.e. ISR) and your /dashboard page could be a fully server-rendered application behind auth. You can do both without ejecting from the framework and being able to update and receive performance/secur…
I suspect the fear was about "next export" going away, not the SSG functionality within a next.js server-side app.
Yes you are correct, thanks this is a great clarification!
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#108Earlier quoted context omitted.
According to Ryan Florence (Remix's creator) they are "ripping features straight from Remix". https://twitter.com/ryanflorence/status/1528859776930545665
Ryan and his insufferable Remix evangelists are the reason I never went beyond a quick hello world. And I like the concept. A while ago he had a Twitter series “spot a React app” where he just shits on other peoples work. Such an odd way to promote his work.
> insufferable Remix evangelists
That is so true. It's been driving me insane since Remix was announced/opened but I couldn't quite put my finger on why. It's because overnight there was an army of people preaching the new religion of Remix all over the place, and not a single one I asked could (at the time at least) tell me why it was better/different than Next.js (a project which IMHO rose on its merit and had to fight for every inch). They had clearly never looked seriously at Next.js before because every "feature" of Remix they were excited about was something Next.js already did. After a bit they started linking to a very long blog post from the Remix creator that supposedly explained why they were different, but after 10 minutes of looking through a post that was supposed to answer my question, all I had was anecdotal performance numbers about how Remix is "faster."
In software we definitely do tend to cargo cult and worship good languages/frameworks, but the Remix "love" is (or was at least) over the top even for us.
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#109Frameworks like nextjs are in an eternal existential battle to stay relevant. In my 4 years of using Next, I experienced a large number (6 or 7 releases) of major version releases. What the industry needs is not more breaking changes, but solidified frameworks that companies can rely on. Every major release adds another wave of technical debt as things become deprecated. I appreciate updates, but to me this particula…
My comment is probably not super helpful, but after several years in javascript land I found myself exhausted by the churn and constant rapid change. I've found myself really happy to be using the PETAL stack (Phoenix Elixir Tailwind Alpine LiveView) where the pace is a lot slower. There are now similar options in Rails (Hotwire) and Laravel (LiveWire), and probably others. If you haven't heard of those, it's definitely worth a look. The only situations in which I don't use them now are when there's a need for rich offline functionality. I still have several static sites in Next.js that I'll leave in place but I've been a lot happier since shifting my bulk to PETAL. (I'm also close to replacing my last big WordPress site with an Elixir one!! Knock on wood.)
Re: Next.js Layouts RFC: Nested routes and layouts, designed for Server Components
#110Earlier quoted context omitted.
theres a lot of cognitive dissonance in monetization of open source by consumers of the product. If you can't charge money for the software, selling courses is the next best thing. Why is it yucky?
You can make convoluted software which creates an artificial need for your training or consulting service. Also using OSS as a funnel for your business and then use your training to hype up your OSS projects
We've deviated from the OP, but I wanted to mention that this is why react-table and react-query bother me endlessly.