I have nothing but good things to say about Next.js, one of the few web libraries that I'm really excited about. Great developer experience, the API is simple and very stable and the feature set is really powerful.
Every time I see someone on this site complain about the build setup complexity of modern frontend and having to fiddle with webpack/babel for ages I'm thinking of all the times I have done:
yarn create next-app my-app & cd my-app & yarn dev
and be up and running in 2 minutes.
Shameless plug, but if you plan to pair Next with an headless CMS, we (DatoCMS) make it super easy to handle responsive, progressive, lazy-loaded images with blur-up thumbs, as our edge CDN takes care of everything for you, without paying any cost at build time.
https://www.datocms.com/blog/offer-responsive-progressive-lq...
so happy for this, been using canary `nextjs` + `now` for all my non work projects
my favorite feature of `now` is environment variables, and `next.js` 9.4 has even better support. so if using `now`, you store your env vars / secrets in your project on https://vercel.com/ in separate buckets for prod, dev, etc
then on your local environment run `now env pull` and get the latest dev env vars populated in `.env` of your project. this is super great for remote teams where you don't have to share .env files via communication channels / ask someone for the latest variable value
"Fast and reliable HMR". I had to look this one up. It means "Hot Module Replacement".
For a simple static site, is this a better option than Gatsby?
Having absolute imports and aliases built-in is huge. This was a pain to set up before, so I'm really excited to try this out.
Incremental Static Regeneration sounds awesome for pages where you don't mind the data being a request behind but you don't want it completely static at build time. Seems like a really nice middle ground that lets you keep the backend simple and get the speed of serving static pages.
Next.js teamed with SWR[1] means I could totally remove redux from my app
I love static site generators but I often feel they are geared towards one type of site (like Jekyll or Hugo for blogs etc.)
We have a huge web based “operating system” and constantly adding more stuff. I spent a couple months architecting and implementing i18n and translations, for example. I looked at GNU language files and other formats and made our own JSON based one.
I tried my hand at static site generation, and it basically takes an existing site and renders certain URLs from the config (including looping through variable values) as a specific browser would fetch them. If you serve different versions of a resource to different browsers (eg mobile browser or css vendor prefixes) you’d have to generate different directories for each one, which can be cleanly chosen by a web server based on the user agent string.
This led to a whole host of issues that made us refactor our framework’s server->client data exports into two parts: session data and regular config data. So a static page would not have any session data. Any experience of being logged-in would have to be added via Javascript or widgets hosted in iframes.
We also have scripts like “combine.php” and “update.php” which minify and combine files, or look at file modification times and set up metadata with timestamps and hashes to use for subresource integrity.
Actually, I would say that the idea of “static site generation” can be a special case of CACHING. To achieve 90% of the benefits, just host your site through a CDN and set your web app server as an origin server. Pages can be rendered on demand and then cached on a CDN. You will have to separate out your session stuff, though! And any dynamicall generated content will need to go under that.
Finally... I would say that all this is actually pointless :) Because you should be building client-first apps. Assume Javascript is available and do all your routing, layouts, header, footer, locally.
There are TONS OF REASONS WHY THAT IS THE FUTURE. The rabbit hole goes much deeper:
https://qbix.com/blog/2020/01/02/the-case-for-building-clien...
If I want some requests resolved at runtime with Next, what are my choices of a production-ready server? I assume `npm start` does not scale very well. What are production practices with Next?
Do you just build your static website and then fetch the data from the browser like React would? Because if so, why would I use Next and not pure React?
SSR frameworks sound very attractive to me due to Kubernetes and hitting internal resources that shouldn't need to be exposed to the world, but I find myself again and again creating gateway services exposing backend services for Ingress.
Dumb question, but what is the benefit of something like Nextjs over react/redux? So many things to learn...
I rerender pages on demand like this, but also rerender the entire site every 6 hours. There's some computer science theorem that says tracking the dependency of which outputs are sensitive to which inputs is actually identical to solving the halting problem... i.e, no framework can actually track which pages are affected by which pieces of data. (This is true if you run custom code. If you are running in some type of limited non-Turing complete language it could be done.)
I'm going to shill my own product https://www.prerender.cloud because it's (mostly) solved this since Chrome headless was finally released in fall 2016.
If you can be patient enough to cache any state you might have in a special global var that gets serialized during the "server side render", then it works for any JavaScript framework that can rehydrate/reattach to SSR'd HTML.
Environment variables being exposed to the client is great assuming this means they can be configured at runtime and available on the client
Anyone managed to get latest next.js to work with reasonMl? There is an excellent tutorial on yt, but it is a bit outdated
Can I use nextjs or ssr react with websockets? Does that go against the pattern of server side rendering?
If I have a large app that has a few pages which use websockets so I'm not sure if nextjs is something that makes sense for me or if I should just start with create-react-app and go from there.
I've been waiting for aliases to come out canary!
Love NextJS, it just keeps getting better at each new release...
Fast Refresh seemed impressive in some GIF's in tweets a couple weeks ago.
Good work! Was very happy with 9.3s new SSG functions. Excited to see further development in this space.
So Vercel is like Netlify but with their own web site development framework (NextJS), and Netlify is like Vercel but with their own CMS (Netlify CMS), and together they have raised about $120MM.
the only reason I use Nextjs is to avoid going through setting up the router, I found Gatsby complex to learn in 10 mins.
you guys might be interested in a current Reddit thread (also on HN: https://news.ycombinator.com/item?id=23136688):
https://old.reddit.com/r/javascript/comments/ghfyd2/secondgu...
specifically this sub-thread of Mithril's author and myself doing a "Hello World" Next.js perf assessment vs a full-blown ecommerce page:
https://old.reddit.com/r/javascript/comments/ghfyd2/secondgu...