-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Add Next.js as a specialized stack #763
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
@@ -67,6 +67,13 @@ in the Core Stack, most developers won't learn these technologies, and the | |||
specialists who learn these stacks are unlikely to be able to learn many layers | |||
in the Core Stack. | |||
|
|||
### Next.js for Web | |||
|
|||
- Use Next.js for web applications that benefit significantly from static site |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jimmythigpen I'd somehow mention that it's also a good choice for companies whose developer team is already heavily invested in the JS ecosystem
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@FerPerales I know we've used Next.js in past clients, but maybe other full-stack options like Remix, Adonis.js or Blitz.js are closer to Rails.
We've gained a lot of expertise in Next.js, but I'd hesitate before recommending it to a client. There are a lot of sharp edges. However the other JS frameworks (Matheus mentioned Remix, Adonis, Blitz) are not as well established as Next and/or are in flux. |
@pangolingo I'd love to add info about these sharp edges, let's chat about this. @MatheusRich I agree those are closer to Rails, especially Remix, but I'm also considering what Dave mentioned - Next.js is the most established at the moment and there are a ton of resources available when we do inevitably run into problems. We actually attempted to spin up a Remix application once but pivoted to Vite due to the time it was taking to ramp up on Remix. @FerPerales suggested that it may be more appropriate to put Next.js (and others?) in an "Alternative Stacks" section.. does sticking these JS frameworks in another stack make sense though? We may need to tweak the way "stacks" are framed if going that route:
I feel like folks can more easily pivot between Rails and JS frameworks vs Rails and native iOS/Android. I know there aren't many of us that pivot between Rails and JS projects but still think it's worth mentioning our recommendations and "go-to" JS tooling. I'm still not sure how to best add this info - up for ideas if y'all think of something! |
@@ -67,6 +67,13 @@ in the Core Stack, most developers won't learn these technologies, and the | |||
specialists who learn these stacks are unlikely to be able to learn many layers | |||
in the Core Stack. | |||
|
|||
### Next.js for Web | |||
|
|||
- Use Next.js for web applications that benefit significantly from static site |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is Next.js our current preferred stack for static sites?
Also you highlighted SEO. Is tech stack that relevant when it comes to SEO?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JoelQ these are good questions, as I bet there are ways to enable something like static site generation and improve SEO optimization in Rails. Out of the box Next.js does make it pretty easy to manage metadata for routes, and incremental static regeneration (ISR) is nice if your site depends on a headless CMS like Contentful and content is constantly updating. I think Next.js was chosen for WorkMoney for example for these reasons- though there may be others I'm unaware of.
I guess we should ask ourselves.. was choosing Next.js in the past a fluke? Can we see ourselves choosing it again for a future project? If we decide to add it as a stack choice somehow we should probably also list why we would choose it over Rails, and make sure to mention pros/cons, and concerns.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah Rails is not the tool for static sites. I'm happy to have a recommendation for static sites. I know there is a whole panoply of tools for this in a variety of languages. If we find that we have strong opinions on what our go-to tool for static sites should be, I'm happy to include that in the guide. I know back in the day go-tos were jekyll and middleman (the thoughtbot blog used to be middleman!).
My understanding is that the new generation of static site generators have a fancier build process that allows you to include more dynamic elements. I've not done a lot of work in that space for years though so I'm not sure what is the the expected feature set of a static site generator framework these days.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd still use Jekyll today, but I have had success with https://bridgetownrb.com/ too (recommended by @FerPerales)
We've chosen Next.js over Rails for a few projects in the past because of special circumstances, and it feels worth mentioning this in our guides.