22 ms·

Next.js 12

451 points by jacobwg 5y ago

CGamesPlay 5y ago
I don't want to hate on Next, because I do like using the framework, but a new major version every 5 months for the lifetime of the project? How does anybody actually develop an application when you have to spend so much time keeping your framework up to date?
- eyelidlessness 5y ago
  To be fair, some of these updates are more significant than others. This one is probably the biggest since I first tried Next. React Server Components has the potential to make me consider using Next for static (MPA) sites again, which I’d previously written off because of the double payload problem.
- swyx 5y ago
  the major versions are mostly marketing new features. Next has been pretty conservative about how it deprecates APIs, i'd wager many Next.js 8 apps could just be updated to 12 with no change
- gherkinnn 5y ago
  Next has proven to be very backwards compatible to me. Even large steps, like moving from a server to handle routing (and i18n) to dynamic routing or that whole SSR business were bug chunks, yes. But in the right direction and without blowing up in my face. And could be adopted incrementally and in our own time.
- Rauchg 5y ago
  Stories like this[1] are not uncommon: > One of our users upgraded from Next.js 2.0-beta to 11 in 5 minutes. > As @timneutkens said in the Q&A, Next.js incrementally improving without breaking changes is worth the investment. If this is not the case, please let us know. We try to be very careful around this, and always leave breadcrumbs for easy upgrades in the DX if we absolutely must change something to move the project forward. [1] https://twitter.com/rauchg/status/1405241003653484546 https://twitter.com/rauchg/status/1405241003653484546
  - throw123123123 5y ago
    I've done at least 20 upgrades (user since next 1.0) and it is getting easier and easier to migrate.
  - tunesmith 5y ago
    This was not our experience earlier this year. We experienced a sequence of breaking changes in various dot-releases that led us to not being able to upgrade from 10.0.6 until 11.0.1 came out. Basically every single release in the 10.1.x and 10.2.x lines were unusable for us. We're very cautious about upgrading now. It's part of why I suggested this issue: https://github.com/vercel/next.js/issues/26827 https://github.com/vercel/next.js/issues/26827
    - Rauchg 5y ago
      Thanks for the feedback. I’ll bring this to the team
leerob 5y ago
Hey everyone, Lee from Vercel here! Happy to answer any questions about Next.js 12. Personally, I'm extremely excited for the new Rust compiler.
- vrepsys 5y ago
  How about on demand page revalidation* ? I can't find if it's part of Next 12. * https://github.com/vercel/next.js/discussions/11552#discussioncomment-2655 https://github.com/vercel/next.js/discussions/11552#discussi...
  - leerob 5y ago
    It is not part of Next.js 12 – still working on it!
- tofuahdude 5y ago
  How does middleware work when using a CDN to host the JS bundles? ie what happens when I've already loaded the bundles and am transitioning to a page that has different middleware requirements? Is it a client-only middleware implementation? (I want this and have implemented a poor man's version in my _app.tsx).
- emadabdulrahim 5y ago
  What's the timeline on React Server components? It seems next 12 experimental feature of Server component is a very early look? Since React 18 is not out yet, and it's not planned to have Server component in that release.
  - leerob 5y ago
    It's available to try today under an experimental flag. React 18 is still in alpha. We'd love to hear your feedback!
- meowtimemania 5y ago
  Can we still use obscure babel macros with the new Rust compiler? And if so, what do you think the future will look like for babel macros in a future where most build tooling is written in languages like rust/go?
capableweb 5y ago
Nice, a completely new attack-vector: https://nextjs.org/blog/next-12#url-imports https://nextjs.org/blog/next-12#url-imports Documentation still not there, so can't check if they actually compare any checksums or anything. They also introduce their own `next.lock` which supposedly new tooling have to built around as well. Versioning management? What, we don't need that for where we're going. Finally it's fun to see it ending with: > We set out to build a zero-configuration React framework that simplifies your developer experience. And if you read the beginning, you'd see: > Middleware enables you to use code over configuration I guess replacing configuration with code is one way of achieving "zero-configuration". Feels like all tooling starts out with "We're simple, no config or code needed!" and eventually ends up so extensible that it's hard to figure out how to even use it. Then another competitor appears and shouts "We're so simple compared to X, no config or code needed!", and the cycle repeats.
- deleted 5y ago
  [deleted]
- dude187 5y ago
  Anything sold as erasing away reality eventually becomes overly complicated, as you inevitably have to work around it to address reality
  - gr__or 5y ago
    > I guess replacing configuration with code is one way of achieving "zero-configuration". > Feels like all tooling starts out with "We're simple, no config or code needed!" and eventually ends up so extensible that it's hard to figure out how to even use it. Then another competitor appears and shouts "We're so simple compared to X, no config or code needed!", and the cycle repeats. I think that is missing the point of middlewares. They are not a thing you _have to_ configure before you can even get going (which is what zero-config usually alludes to). Instead middleware is a mechanism for sharing code between different routes. Now that code might contain functionality that can be eliminated through strong conventions (i.e. always parse JSON instead of having to configure a content-type aware body-parser middleware). But that is a very specific use case and middlewares do a whole lot more than that. So even with goodest faith, I think your point does not land.
deleted 5y ago
[deleted]
ilovecaching 5y ago
Seems like a ton of tools/dependancies/frameworks to do something relatively simple. What is the benefit of this over using Hugo with Go templates?
- jjice 5y ago
  I'm not sure how extensible Hugo is, but Next allows full server side code. From my understanding (which may very well be wrong), Hugo is for static site generation.
- IceWreck 5y ago
  If you want a fully static site, go with Hugo. Site generation is way way faster. Next offers using React as your templating language as well as adding in server side code if you want instead of static site generation.
- waprin 5y ago
  The main benefit of NextJS is that it makes it very easy to write code once and quickly swap whether it's going to be statically generated ahead of time, rendered on the server, or rendered dynamically on the client. It also comes with a bunch of features you'll likely need for a modern web page like image optimization and a really nice PaaS to deploy it to.
- matsemann 5y ago
  One benefit is that it's JS. Yes, really. For every Go developer, there are a thousand that know JS.
- colesantiago 5y ago
  Go's templating system is woefully awful.
dmix 5y ago
The big innovation here seems to be https://swc.rs/ https://swc.rs/ If it works as advertised this is going to be great for a ton of JS/TS projects. Particularly having a 20x typescript compiler boost when running large test suites would be great. Maintaining 5-8 different babel related projects in packages.json is also annoying and often buggy. Looking forward to see where else this gets adopted and it's stability.
- capableweb 5y ago
  How does it compare to esbuild? Seems they both want to achieve exactly the same thing, but somehow it's two different efforts.
  - jacobmischka 5y ago
    They are two different efforts, started a little while ago, one in Go and one in Rust. I believe esbuild was started first, but they both seem to be maturing rather well lately.
    - capableweb 5y ago
      > I believe esbuild was started first That seems incorrect. - "put on github" - evanw committed on Jan 15, 2020 - https://github.com/evanw/esbuild/commit/23c40b1b6a76a8626f1d160f89677ed2c73b6090 https://github.com/evanw/esbuild/commit/23c40b1b6a76a8626f1d... - "initial commit" - kdy1 committed on Dec 22, 2017 - https://github.com/swc-project/swc/commit/0f9532dd5d379292cc2d67777a108d88803bad91 https://github.com/swc-project/swc/commit/0f9532dd5d379292cc...
      - hardwaregeek 5y ago
        Judging by the commit messages the first esbuild commit seems like Evan moved an existing project onto GitHub while the SWC commit seems like a genuine start. But also pretty unlikely that esbuild was being worked on for 3 years before being put on GitHub so your point still stands.
  - 5y ago
r6203 5y ago
I don't get it. It's still not possible to use next/image (without some fancy loader or 3rd party service) when exporting a SSG build. Are people really not using responsive images when exporting a static site? Seems quite ridiculous to rely on some 3rd party service for image optimization when the images could be generated locally when exporting the site...
- throw123123123 5y ago
  It is definitely an awkward design choice, but image services often generate the images on demand, by having one and creating the otherones at request + caching. A static build does not have the capacity to cache images, unless it generates a really large number of them during build!
  - tevon 5y ago
    Right, this could work for small sites, but not sites with a ton of images.
- tevon 5y ago
  Agreed on this, I'd much rather do the image optimization at build time and just push it in an /asset folder or similar. However I assume this isn't done because it doesn't scale well. On my website with 10 images it might work, but what happens when I have 1,000, that doesn't bundle well.
- wereHamster 5y ago
  I have a system that supports optimized images in SSG that doesn't rely on any third-party services. But it requires custom config (babel macro plugin), though it only works for the most trivial websites. Let's break it down why its hard. If you want responsive, optimized images in a SSG context, without any dependency on 3rd party services, your only option is to pre-generate images at build time. Fair enough, you can go through all your images and pre-generate them at different size and different format. You can do that manually, or automate that for example by using a babel macro. Let's say you want provide resized images at 4 different widths, and support jpeg, avif, webp. That means a whole lot of CPU that you need to burn during build (even with sharp, resizing images takes time), and uses up loads of storage (that you need to ship to your static web server). If your site has anything but a trivial amount of images, the CPU usage will turn your 60 seconds deployment into a 30 minutes deployment (or longer), that doesn't scale. You can store the generated images in the git repository, but that quickly blows up the repository size, so it's not ideal either. You can use a cloud storage service to cache the generated images (self-hosting that on AWS, GCP or your own blob storage service is not difficult) but introduces a dependency on an external service. How do you imagine optimized and responsible images in a SSG context to work? I (and pretty sure the Next.js developers as well) am curious about any suggestions… PS. I'm happy to share my babel macro, but as I said, it's only usable for the simplest of simple websites.
revskill 5y ago
With server component, i really think next.js hybrid app with cordova will achieve high performance even better than native app (like react-native).
- yesimahuman 5y ago
  Agreed! Next.js works great with this model! I’d recommend Capacitor over Cordova (similar but more modern). Here’s an example: https://github.com/mlynch/nextjs-tailwind-ionic-capacitor-starter https://github.com/mlynch/nextjs-tailwind-ionic-capacitor-st...
  - clivestaples 5y ago
    Not to sidetrack but how is this better than wrapping Rails/Hotwire app in a Capacitor web view? I'm looking for reasons to use Next because it seems super cool.
    - yesimahuman 5y ago
      I am not very familiar with Rails/Hotwire but the biggest difference is this would be a static app bundled into your app binary, which is an important consideration when targeting native mobile. Beyond that I think it's personal preference.
yewenjie 5y ago
I like that they have finally provided a fast Webpack alternative.
- williamstein 5y ago
  Minor correction: They have not provided a fast Webpack alternative. Next.js extensively uses Webpack, both for code that runs on the frontend and for code on the backend. They even hired the lead developer of Webpack. Next.js has very, very strongly embraced Webpack. The "Rust Compiler" functionality is more an alternative to Babel.
- STRiDEX 5y ago
  webpack 5 is still used, SWC would replace babel-loader
segphault 5y ago
The install footprint from npm is 302 packages weighing in at 504mb. It includes a lot of superfluous debris, with packages containing single functions like "is-string" and multiple polyfills for functions like object.assign. That's a very large attack surface considering the poor security practices in the npm ecosystem[0] and the growing frequency of attacks on transitive dependencies[1]. [0]: https://www.bleepingcomputer.com/news/security/52-percent-of-all-javascript-npm-packages-could-have-been-hacked-via-weak-credentials/ https://www.bleepingcomputer.com/news/security/52-percent-of... [1]: https://news.ycombinator.com/item?id=28962168 https://news.ycombinator.com/item?id=28962168
- joshmanders 5y ago
  Have you ran it in production install mode, because my app dockerfile (using alpine base) isn't even that big total.
- sergiomattei 5y ago
  I wonder why they don't replace these simple packages like `is-string` with Lodash, which has all these functions and more. Bundle size isn't a problem: they're ES modules, so you can do something like `lodash/isString` and import only what you need. Seems like that would cut down on a lot of dependencies. I'm curious why the ecosystem hasn't adopted this or a similar approach.
  - Waterluvian 5y ago
    Also tree shaking out the stuff you don’t need has never worked better. It’s pretty trivial with lodash.
  - alexfrydl 5y ago
    They're probably dependencies of dependencies. You depend on some very useful package and somewhere down the line it depends on something written to be platform agnostic in 2012 when lodash wasn't modular and JavaScript wasn't as mature. The ecoystem hasn't adopted a better approach because it would require every individual package developer to understand the problem, get on board, then update and test everything they've written.
bowlingx 5y ago
Congrats! This is a very exciting release!
jekude 5y ago
If Next.js + Vercel is the leader of the production-ready frontend-as-a-service space, why hasn't a similar leader emerged in the backend-as-a-service space? I would love a clean Vercel-like abstraction on top of standard cloud primitives (functions, queues, events, workflows, etc.) with everything wired up nicely and focused on developer experience. It just seems like AWS is so configuration heavy that it is ripe for a Vercel-for-backend to emerge. Does anyone know of an existing open source framework + hosted cloud platform that is a one-stop-shop for writing a production-ready backend in the vein of Next.js + Vercel?
- chrisco255 5y ago
  Vercel / Next.js does function as a backend, too. You simply add an api folder and create 'routeName.js' files in there and you've got an endpoint backed by a lambda. And Vercel itself allows you to install backend services such as Redis caching, databases, or queues that you can pull in from those functions.
  - letmeinhere 5y ago
    but (at least last I checked and from what I can glean from current docs) Vercel doesn't host databases, or integrate on a network level with the major cloud providers that do, so if you run your "back end" on Vercel you still need a "back back end" from a different provider and are opting into a huge amount of network operations burden to securely connect the two.
    - gherkinnn 5y ago
      Welcome to the Jamstack. /snark I'd think of a Next-driven BE as a BE for FE. And since it's co-located, You can share types, validators, utilities, (mental) models, etc. across the same codebase. A technique that does have its place. Not always. Maybe not even half the time. But cleverer people than me use it to some effect.
    - sroussey 5y ago
      Check out supabase https://supabase.io/ https://supabase.io/
ramesh31 5y ago
>Compilation using Rust is 17x faster than Babel and enabled by default using Next.js 12, replacing transforming JavaScript and TypeScript files. I've never, ever felt constrained by Babel performance. Even in massive 100k+ LOC codebases. I have, however, been burned over and over again by introducing native binaries into the build process. We specifically moved off of node-sass to using PostCSS for this very reason. I'm not completely sure how these Rust binaries will work, but if they are in any way less universal than Node, it's going to cause problems across dev and CI build environments.
- matsemann 5y ago
  Hard disagreement here. Seen so many slow builds / hot-reloads over the years. It's draining to work on a project where changing a file takes a couple of seconds to be live in the browser. Almost so that I believe those not complaining about webpack's or babel's speed just don't know what they're missing out on.
- eyelidlessness 5y ago
  I haven’t used SWC extensively, but with ESBuild (written in Go) this has been a non-issue for me. I’ve experienced the pain of native bindings in other projects though, it largely depends on how resilient the native bindings are to different Node/V8 APIs across versions.
- dstaley 5y ago
  I think one of the biggest issues with node-sass was that it only supported a narrow set of node versions and platforms, which resulted in a lot more compilation from source. I definitely remember fighting with node-gyp and such, and pretty quickly ditched it for dart sass as soon as that was a viable alternative. Next.js looks like it's shipping binaries for swc for a wide Node range (>=10), on a pretty comprehensive combination of operating systems and architectures: - android-arm64 - darwin-arm64 - darwin-x64 - linux-arm-gnueabihf - linux-arm64-gnu - linux-arm64-musl - linux-x64-gnu - linux-x64-musl - win32-arm64-msvc - win32-ia32-msvc - win32-x64-msvc Unfortunately I don't have access to a system that _doesn't_ have a pre-built binary, so I have no idea what would happen if you tried to install Next.js on an unsupported architecture. That being said, I'd love to see the Next.js team ship a WASM version of SWC for such systems, which should ensure that when there's not a pre-built binary, at least you won't be asked to install a Rust compiler.
snarkypixel 5y ago
I was hoping for hosted postgreSQL database support as part of Next deployment.
- gherkinnn 5y ago
  Vercel does come with a Supabase integration: https://vercel.com/integrations/supabase https://vercel.com/integrations/supabase And from my limited understanding, Supabase is psql with extras.
  - burggraf 5y ago
    Supabase developer here. Supabase gives you full PostgreSQL access as well as a REST api interface (Postgrest) with integrated authentication (based on GoTrue), S3-based storage also integrated to authentication and integrated with your PostgreSQL instance, an easy dashboard interface and a bunch more. There’s a generous free tier and a hosted option that’s ready to scale immediately. Let us know if you have any more questions.
    - o_____________o 5y ago
      You guys should advertise the Postgres+Postgrest thing more prominently, I've been looking through your materials this morning and the Postgrest part wasn't clear. I would have been more apt to choose Supabase immediately since it seems like I wouldn't encounter vendor lock in, which was the main concern.
      - burggraf 5y ago
        It's considered our "API", which is part of the "Firebase Alternative" marketing idea, but your point is duly noted and I'll pass it on to our devrel guys. Thanks.
    - gherkinnn 5y ago
      I keep going back to your page. Very interested but lack the time and energy to build anything right now.
5350-uiop-1130 5y ago
This is nice as a more opinionated version of create-react-app. helps solve some of the problem with the fragmented react ecosystem. It does seem a bit complex though, perhaps something you would use on large projects only.
cyberpsybin 5y ago
Select your enlightened HN comment from below options JS bad; SPA bad; React bad; Next bad
- toinbis 5y ago
  Sad to see a very concise comment revealing arguably the deepest and biggest problem of the frontend world - frontend architectures naming problem - being downvoted.
  - 1_player 5y ago
    I agree with OP, but it is not constructive. Please let's not turn HN into Reddit.
kyleee 5y ago
This is great but im really looking forward to nextjs 13
- kgin 5y ago
  At this rate it should be ready in a few weeks
  - midrus 5y ago
    Best release ever
benatkin 5y ago
The production quality for both this and Jamstack Conf a couple weeks ago are very high. I really dig the retro graphics and music!
midrus 5y ago
I'm going to be downvoted to hell for this... but the more I see the level of complexity and amount of engineering going into this, the more I miss Rails and how simple things are there, given most of us are just building CRUD apps anyways.
- albertgao 5y ago
  Because in 21st century, not everyone likes a website with a lower-bar rendering experience… SPA or hybrid rendering is just plain better, but I get the point where time is limited for human being, so if modern frontend is hard to grasp for you, perfectly to stick with old tech. Pretty safe.
  - midrus 5y ago
    > SPA or hybrid rendering is just plain better, It is not for your end users, just for the developers building it because it has a better dev experience. As a proof of this try most sites out there which are built as an SPA vs the ones built with more traditional approaches. Also, building SPAs is incredibly more difficult and time consuming, that's why most of them work like shit.
- techpression 5y ago
  I keep thinking the same thing almost every day at work… “this is a CRUD app, who let it become this overly complex monster (multiple next apps)”. Then I remember why; “Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.” ― Edsger Wybe Dijkstra
  - enahs-sf 5y ago
    This quote really made my day and embodies my approach to software engineering. Thanks for this.
  - machiaweliczny 5y ago
    I worked with Rails and prefer this. Rails is more complex it's just easier to use but harder to understand with all that dynamic magic.
no_wizard 5y ago
This is really amazing, is the end result here that they are ultimately opting out of webpack in favor of SWC? It also compiles modules and such. Will have to take a look at the underlying infrastructure here! Interestingly I think that’s the major win of SWC over esbuild: you get a Babel like plug-in ecosystem for AST transformations and such. Downside: there currently isn’t a way to run asynchronous transforms, much like you can’t with Babel (easily anyway without some subprocess hacks) I love Vue, but it’s forever married to the Babel parser unless Evan moves over to using SWC for compiling SFCs, which would be awesome but he has signaled multiple times he doesn’t see the Vue Compiler ever being rust based, so it would be reliant on the Vue core team (though I think this is mainly his work) porting the SFC compiler to using SWC underneath. JSX frameworks won’t have this limitation and can get this massive speed gains and energy without such work. I could see Stencil and SolidJS adapting easily here Maybe JSX tools just needs some re thinking to get the same SFC experience
- nightpool 5y ago
  I find that React + styled-components in the same file gives me almost entirely the same experience as SFC.
  - swyx 5y ago
    for >10x the javascript weight of Svelte tho :upside down smiley:
- GordonS 5y ago
  Sorry, "SFC" and "SWC"?
  - abledon 5y ago
    man... web technologies are not getting simpler are they lol. it just keeps gaining more layers and layers
  - DaiPlusPlus 5y ago
    At least it isn’t SWF…
nickosmark 5y ago
Next.js reinvents so many things that already exist in PHP (also Python, Ruby). Check out for example what is already possible with Symfony in their docs[0]. Next.js "biggest" release just introduced middleware and html rendering with zero client-side js ! What people like in tools like next.js is not the framework itself but the abstraction over infrastructure, using platforms like vercel. Imagine a platform as cheap, modern and easy to use as vercel but for PHP, basically shared hosting on steroids. Do you believe people would still care so much about Next.js in that scenario ? [0] https://symfony.com/doc/current/index.html https://symfony.com/doc/current/index.html
- alasano 5y ago
  I think that people who like JavaScript are happy with getting the abstractions you mentioned. If building a vercel for PHP was such an obvious idea, I imagine someone would jump on it.
  - leerob 5y ago
    Fun fact, you can actually write PHP function on Vercel :) https://github.com/juicyfx/vercel-php https://github.com/juicyfx/vercel-php
  - archeroed 5y ago
    People just like React and the idea of decoupling frontend and backend ( Pretty sure just a few percentage of users use Nextjs with api routes and just use it as Create-React-App with SSG and SSR capabilities ). I haven't used Vercel that much in production but what does it bring compared to Heroku or cheaper and open source self hosted alternatives like Dokku or even caprover with it's really good UI and can deploy any backend as long as it's Dockerizable ?
- leodriesch 5y ago
  I think what is comforting for a lot of people is that they can write isomorphic code that mostly automatically works on the frontend and backend. IMO React is also an amazing abstraction and I like writing components better than stitching together HTML or other template/DSL based systems.
sandGorgon 5y ago
>Next.js now enables you to do data fetching at the component level, all expressed as JSX. By using React Server components, we can simplify things. Special functions like getServerSideProps or getStaticProps are no longer needed. This aligns with the React Hooks model of colocating data fetching with your components. Do you see getServerSideProps and getStaticProps going away in the next release or two ?
- 1_player 5y ago
  How often are they going to change their data fetching APIs?! There's libraries still using getInitialProps (like urql), now deprecated, because getServerSideProps and getStaticProps that were in vogue until now had very different semantics, and they're changing them again? I'm so glad I'm not maintaining the Next project at work anymore, I very much dislike how often it is changing yet it's still very restrictive. The JS ecosystem and the pace of change it's forcing on people with deadlines is ridiculous. /rant
  - rglover 5y ago
    https://cheatcode.co/meta/introducing-joystick-the-full-stack-javascript-framework https://cheatcode.co/meta/introducing-joystick-the-full-stac...
- shuding 5y ago
  No, these will not be going away in the near future as far as we can see. React 18 / RSC are still in alpha or experimental stage, and what we shared are just new ways to do data fetching that we are currently exploring. In fact, component-level data fetching doesn’t conflict with top-level data fetching like gSP and gSSP. Today you can already use gSSP with Suspense-based data fetching together with Next.js 12. It’s just that you normally don’t need to use both, doesn’t mean you can’t :)
CosmicShadow 5y ago
Some exciting stuff for sure, but the most exciting stuff we still have to wait on as it's all experimental until React is ready. Anything that speeds things up and gives us more control is great though.
brillout 5y ago
Shameless plug: https://vite-plugin-ssr.com https://vite-plugin-ssr.com a do-one-thing-do-it-well alternative to Next.js which is feature-complete & stable (no breaking changes in the foreseeable future).
- mariushn 5y ago
  Looks good! Why did you decide to do your own Filesystem Routing instead of introducing a dependency to vite-plugin-pages, especially as you mention upstream contributions?
  - brillout 5y ago
    The Filesystem Routing part is like less than 1% of the code; it wouldn't be worth it to externalize it in a separate library.
cusx 5y ago
Seems like Rust is eating JavaScript (in a good way).
- emteycz 5y ago
  In the same way C++ always did

451 points by jacobwg 5y ago

I don't want to hate on Next, because I do like using the framework, but a new major version every 5 months for the lifetime of the project? How does anybody actually develop an application when you have to spend so much time keeping your framework up to date?

eyelidlessness 5y ago
To be fair, some of these updates are more significant than others. This one is probably the biggest since I first tried Next. React Server Components has the potential to make me consider using Next for static (MPA) sites again, which I’d previously written off because of the double payload problem.
swyx 5y ago
the major versions are mostly marketing new features. Next has been pretty conservative about how it deprecates APIs, i'd wager many Next.js 8 apps could just be updated to 12 with no change
gherkinnn 5y ago
Next has proven to be very backwards compatible to me. Even large steps, like moving from a server to handle routing (and i18n) to dynamic routing or that whole SSR business were bug chunks, yes. But in the right direction and without blowing up in my face. And could be adopted incrementally and in our own time.
Rauchg 5y ago
Stories like this[1] are not uncommon: > One of our users upgraded from Next.js 2.0-beta to 11 in 5 minutes. > As @timneutkens said in the Q&A, Next.js incrementally improving without breaking changes is worth the investment. If this is not the case, please let us know. We try to be very careful around this, and always leave breadcrumbs for easy upgrades in the DX if we absolutely must change something to move the project forward. [1] https://twitter.com/rauchg/status/1405241003653484546 https://twitter.com/rauchg/status/1405241003653484546
- throw123123123 5y ago
  I've done at least 20 upgrades (user since next 1.0) and it is getting easier and easier to migrate.
- tunesmith 5y ago
  This was not our experience earlier this year. We experienced a sequence of breaking changes in various dot-releases that led us to not being able to upgrade from 10.0.6 until 11.0.1 came out. Basically every single release in the 10.1.x and 10.2.x lines were unusable for us. We're very cautious about upgrading now. It's part of why I suggested this issue: https://github.com/vercel/next.js/issues/26827 https://github.com/vercel/next.js/issues/26827
  - Rauchg 5y ago
    Thanks for the feedback. I’ll bring this to the team

leerob 5y ago

Hey everyone, Lee from Vercel here! Happy to answer any questions about Next.js 12. Personally, I'm extremely excited for the new Rust compiler.

vrepsys 5y ago
How about on demand page revalidation* ? I can't find if it's part of Next 12. * https://github.com/vercel/next.js/discussions/11552#discussioncomment-2655 https://github.com/vercel/next.js/discussions/11552#discussi...
- leerob 5y ago
  It is not part of Next.js 12 – still working on it!
tofuahdude 5y ago
How does middleware work when using a CDN to host the JS bundles? ie what happens when I've already loaded the bundles and am transitioning to a page that has different middleware requirements? Is it a client-only middleware implementation? (I want this and have implemented a poor man's version in my _app.tsx).
emadabdulrahim 5y ago
What's the timeline on React Server components? It seems next 12 experimental feature of Server component is a very early look? Since React 18 is not out yet, and it's not planned to have Server component in that release.
- leerob 5y ago
  It's available to try today under an experimental flag. React 18 is still in alpha. We'd love to hear your feedback!
meowtimemania 5y ago
Can we still use obscure babel macros with the new Rust compiler? And if so, what do you think the future will look like for babel macros in a future where most build tooling is written in languages like rust/go?

capableweb 5y ago

Nice, a completely new attack-vector: https://nextjs.org/blog/next-12#url-imports https://nextjs.org/blog/next-12#url-imports Documentation still not there, so can't check if they actually compare any checksums or anything. They also introduce their own `next.lock` which supposedly new tooling have to built around as well. Versioning management? What, we don't need that for where we're going. Finally it's fun to see it ending with: > We set out to build a zero-configuration React framework that simplifies your developer experience. And if you read the beginning, you'd see: > Middleware enables you to use code over configuration I guess replacing configuration with code is one way of achieving "zero-configuration". Feels like all tooling starts out with "We're simple, no config or code needed!" and eventually ends up so extensible that it's hard to figure out how to even use it. Then another competitor appears and shouts "We're so simple compared to X, no config or code needed!", and the cycle repeats.

deleted 5y ago
[deleted]
dude187 5y ago
Anything sold as erasing away reality eventually becomes overly complicated, as you inevitably have to work around it to address reality
- gr__or 5y ago
  > I guess replacing configuration with code is one way of achieving "zero-configuration". > Feels like all tooling starts out with "We're simple, no config or code needed!" and eventually ends up so extensible that it's hard to figure out how to even use it. Then another competitor appears and shouts "We're so simple compared to X, no config or code needed!", and the cycle repeats. I think that is missing the point of middlewares. They are not a thing you _have to_ configure before you can even get going (which is what zero-config usually alludes to). Instead middleware is a mechanism for sharing code between different routes. Now that code might contain functionality that can be eliminated through strong conventions (i.e. always parse JSON instead of having to configure a content-type aware body-parser middleware). But that is a very specific use case and middlewares do a whole lot more than that. So even with goodest faith, I think your point does not land.

deleted 5y ago

[deleted]

ilovecaching 5y ago

Seems like a ton of tools/dependancies/frameworks to do something relatively simple. What is the benefit of this over using Hugo with Go templates?

jjice 5y ago
I'm not sure how extensible Hugo is, but Next allows full server side code. From my understanding (which may very well be wrong), Hugo is for static site generation.
IceWreck 5y ago
If you want a fully static site, go with Hugo. Site generation is way way faster. Next offers using React as your templating language as well as adding in server side code if you want instead of static site generation.
waprin 5y ago
The main benefit of NextJS is that it makes it very easy to write code once and quickly swap whether it's going to be statically generated ahead of time, rendered on the server, or rendered dynamically on the client. It also comes with a bunch of features you'll likely need for a modern web page like image optimization and a really nice PaaS to deploy it to.
matsemann 5y ago
One benefit is that it's JS. Yes, really. For every Go developer, there are a thousand that know JS.
colesantiago 5y ago
Go's templating system is woefully awful.

dmix 5y ago

The big innovation here seems to be https://swc.rs/ https://swc.rs/ If it works as advertised this is going to be great for a ton of JS/TS projects. Particularly having a 20x typescript compiler boost when running large test suites would be great. Maintaining 5-8 different babel related projects in packages.json is also annoying and often buggy. Looking forward to see where else this gets adopted and it's stability.

capableweb 5y ago
How does it compare to esbuild? Seems they both want to achieve exactly the same thing, but somehow it's two different efforts.
- jacobmischka 5y ago
  They are two different efforts, started a little while ago, one in Go and one in Rust. I believe esbuild was started first, but they both seem to be maturing rather well lately.
  - capableweb 5y ago
    > I believe esbuild was started first That seems incorrect. - "put on github" - evanw committed on Jan 15, 2020 - https://github.com/evanw/esbuild/commit/23c40b1b6a76a8626f1d160f89677ed2c73b6090 https://github.com/evanw/esbuild/commit/23c40b1b6a76a8626f1d... - "initial commit" - kdy1 committed on Dec 22, 2017 - https://github.com/swc-project/swc/commit/0f9532dd5d379292cc2d67777a108d88803bad91 https://github.com/swc-project/swc/commit/0f9532dd5d379292cc...
    - hardwaregeek 5y ago
      Judging by the commit messages the first esbuild commit seems like Evan moved an existing project onto GitHub while the SWC commit seems like a genuine start. But also pretty unlikely that esbuild was being worked on for 3 years before being put on GitHub so your point still stands.
- 5y ago

r6203 5y ago

I don't get it. It's still not possible to use next/image (without some fancy loader or 3rd party service) when exporting a SSG build. Are people really not using responsive images when exporting a static site? Seems quite ridiculous to rely on some 3rd party service for image optimization when the images could be generated locally when exporting the site...

throw123123123 5y ago
It is definitely an awkward design choice, but image services often generate the images on demand, by having one and creating the otherones at request + caching. A static build does not have the capacity to cache images, unless it generates a really large number of them during build!
- tevon 5y ago
  Right, this could work for small sites, but not sites with a ton of images.
tevon 5y ago
Agreed on this, I'd much rather do the image optimization at build time and just push it in an /asset folder or similar. However I assume this isn't done because it doesn't scale well. On my website with 10 images it might work, but what happens when I have 1,000, that doesn't bundle well.
wereHamster 5y ago
I have a system that supports optimized images in SSG that doesn't rely on any third-party services. But it requires custom config (babel macro plugin), though it only works for the most trivial websites. Let's break it down why its hard. If you want responsive, optimized images in a SSG context, without any dependency on 3rd party services, your only option is to pre-generate images at build time. Fair enough, you can go through all your images and pre-generate them at different size and different format. You can do that manually, or automate that for example by using a babel macro. Let's say you want provide resized images at 4 different widths, and support jpeg, avif, webp. That means a whole lot of CPU that you need to burn during build (even with sharp, resizing images takes time), and uses up loads of storage (that you need to ship to your static web server). If your site has anything but a trivial amount of images, the CPU usage will turn your 60 seconds deployment into a 30 minutes deployment (or longer), that doesn't scale. You can store the generated images in the git repository, but that quickly blows up the repository size, so it's not ideal either. You can use a cloud storage service to cache the generated images (self-hosting that on AWS, GCP or your own blob storage service is not difficult) but introduces a dependency on an external service. How do you imagine optimized and responsible images in a SSG context to work? I (and pretty sure the Next.js developers as well) am curious about any suggestions… PS. I'm happy to share my babel macro, but as I said, it's only usable for the simplest of simple websites.

revskill 5y ago

With server component, i really think next.js hybrid app with cordova will achieve high performance even better than native app (like react-native).

yesimahuman 5y ago
Agreed! Next.js works great with this model! I’d recommend Capacitor over Cordova (similar but more modern). Here’s an example: https://github.com/mlynch/nextjs-tailwind-ionic-capacitor-starter https://github.com/mlynch/nextjs-tailwind-ionic-capacitor-st...
- clivestaples 5y ago
  Not to sidetrack but how is this better than wrapping Rails/Hotwire app in a Capacitor web view? I'm looking for reasons to use Next because it seems super cool.
  - yesimahuman 5y ago
    I am not very familiar with Rails/Hotwire but the biggest difference is this would be a static app bundled into your app binary, which is an important consideration when targeting native mobile. Beyond that I think it's personal preference.

yewenjie 5y ago

I like that they have finally provided a fast Webpack alternative.

williamstein 5y ago
Minor correction: They have not provided a fast Webpack alternative. Next.js extensively uses Webpack, both for code that runs on the frontend and for code on the backend. They even hired the lead developer of Webpack. Next.js has very, very strongly embraced Webpack. The "Rust Compiler" functionality is more an alternative to Babel.
STRiDEX 5y ago
webpack 5 is still used, SWC would replace babel-loader

segphault 5y ago

The install footprint from npm is 302 packages weighing in at 504mb. It includes a lot of superfluous debris, with packages containing single functions like "is-string" and multiple polyfills for functions like object.assign. That's a very large attack surface considering the poor security practices in the npm ecosystem[0] and the growing frequency of attacks on transitive dependencies[1]. [0]: https://www.bleepingcomputer.com/news/security/52-percent-of-all-javascript-npm-packages-could-have-been-hacked-via-weak-credentials/ https://www.bleepingcomputer.com/news/security/52-percent-of... [1]: https://news.ycombinator.com/item?id=28962168 https://news.ycombinator.com/item?id=28962168

joshmanders 5y ago
Have you ran it in production install mode, because my app dockerfile (using alpine base) isn't even that big total.
sergiomattei 5y ago
I wonder why they don't replace these simple packages like `is-string` with Lodash, which has all these functions and more. Bundle size isn't a problem: they're ES modules, so you can do something like `lodash/isString` and import only what you need. Seems like that would cut down on a lot of dependencies. I'm curious why the ecosystem hasn't adopted this or a similar approach.
- Waterluvian 5y ago
  Also tree shaking out the stuff you don’t need has never worked better. It’s pretty trivial with lodash.
- alexfrydl 5y ago
  They're probably dependencies of dependencies. You depend on some very useful package and somewhere down the line it depends on something written to be platform agnostic in 2012 when lodash wasn't modular and JavaScript wasn't as mature. The ecoystem hasn't adopted a better approach because it would require every individual package developer to understand the problem, get on board, then update and test everything they've written.

bowlingx 5y ago

Congrats! This is a very exciting release!

jekude 5y ago

If Next.js + Vercel is the leader of the production-ready frontend-as-a-service space, why hasn't a similar leader emerged in the backend-as-a-service space? I would love a clean Vercel-like abstraction on top of standard cloud primitives (functions, queues, events, workflows, etc.) with everything wired up nicely and focused on developer experience. It just seems like AWS is so configuration heavy that it is ripe for a Vercel-for-backend to emerge. Does anyone know of an existing open source framework + hosted cloud platform that is a one-stop-shop for writing a production-ready backend in the vein of Next.js + Vercel?

chrisco255 5y ago
Vercel / Next.js does function as a backend, too. You simply add an api folder and create 'routeName.js' files in there and you've got an endpoint backed by a lambda. And Vercel itself allows you to install backend services such as Redis caching, databases, or queues that you can pull in from those functions.
- letmeinhere 5y ago
  but (at least last I checked and from what I can glean from current docs) Vercel doesn't host databases, or integrate on a network level with the major cloud providers that do, so if you run your "back end" on Vercel you still need a "back back end" from a different provider and are opting into a huge amount of network operations burden to securely connect the two.
  - gherkinnn 5y ago
    Welcome to the Jamstack. /snark I'd think of a Next-driven BE as a BE for FE. And since it's co-located, You can share types, validators, utilities, (mental) models, etc. across the same codebase. A technique that does have its place. Not always. Maybe not even half the time. But cleverer people than me use it to some effect.
  - sroussey 5y ago
    Check out supabase https://supabase.io/ https://supabase.io/

ramesh31 5y ago

>Compilation using Rust is 17x faster than Babel and enabled by default using Next.js 12, replacing transforming JavaScript and TypeScript files. I've never, ever felt constrained by Babel performance. Even in massive 100k+ LOC codebases. I have, however, been burned over and over again by introducing native binaries into the build process. We specifically moved off of node-sass to using PostCSS for this very reason. I'm not completely sure how these Rust binaries will work, but if they are in any way less universal than Node, it's going to cause problems across dev and CI build environments.

matsemann 5y ago
Hard disagreement here. Seen so many slow builds / hot-reloads over the years. It's draining to work on a project where changing a file takes a couple of seconds to be live in the browser. Almost so that I believe those not complaining about webpack's or babel's speed just don't know what they're missing out on.
eyelidlessness 5y ago
I haven’t used SWC extensively, but with ESBuild (written in Go) this has been a non-issue for me. I’ve experienced the pain of native bindings in other projects though, it largely depends on how resilient the native bindings are to different Node/V8 APIs across versions.
dstaley 5y ago
I think one of the biggest issues with node-sass was that it only supported a narrow set of node versions and platforms, which resulted in a lot more compilation from source. I definitely remember fighting with node-gyp and such, and pretty quickly ditched it for dart sass as soon as that was a viable alternative. Next.js looks like it's shipping binaries for swc for a wide Node range (>=10), on a pretty comprehensive combination of operating systems and architectures: - android-arm64 - darwin-arm64 - darwin-x64 - linux-arm-gnueabihf - linux-arm64-gnu - linux-arm64-musl - linux-x64-gnu - linux-x64-musl - win32-arm64-msvc - win32-ia32-msvc - win32-x64-msvc Unfortunately I don't have access to a system that _doesn't_ have a pre-built binary, so I have no idea what would happen if you tried to install Next.js on an unsupported architecture. That being said, I'd love to see the Next.js team ship a WASM version of SWC for such systems, which should ensure that when there's not a pre-built binary, at least you won't be asked to install a Rust compiler.

snarkypixel 5y ago

I was hoping for hosted postgreSQL database support as part of Next deployment.

gherkinnn 5y ago
Vercel does come with a Supabase integration: https://vercel.com/integrations/supabase https://vercel.com/integrations/supabase And from my limited understanding, Supabase is psql with extras.
- burggraf 5y ago
  Supabase developer here. Supabase gives you full PostgreSQL access as well as a REST api interface (Postgrest) with integrated authentication (based on GoTrue), S3-based storage also integrated to authentication and integrated with your PostgreSQL instance, an easy dashboard interface and a bunch more. There’s a generous free tier and a hosted option that’s ready to scale immediately. Let us know if you have any more questions.
  - o_____________o 5y ago
    You guys should advertise the Postgres+Postgrest thing more prominently, I've been looking through your materials this morning and the Postgrest part wasn't clear. I would have been more apt to choose Supabase immediately since it seems like I wouldn't encounter vendor lock in, which was the main concern.
    - burggraf 5y ago
      It's considered our "API", which is part of the "Firebase Alternative" marketing idea, but your point is duly noted and I'll pass it on to our devrel guys. Thanks.
  - gherkinnn 5y ago
    I keep going back to your page. Very interested but lack the time and energy to build anything right now.

5350-uiop-1130 5y ago

This is nice as a more opinionated version of create-react-app. helps solve some of the problem with the fragmented react ecosystem. It does seem a bit complex though, perhaps something you would use on large projects only.

cyberpsybin 5y ago

Select your enlightened HN comment from below options JS bad; SPA bad; React bad; Next bad

toinbis 5y ago
Sad to see a very concise comment revealing arguably the deepest and biggest problem of the frontend world - frontend architectures naming problem - being downvoted.
- 1_player 5y ago
  I agree with OP, but it is not constructive. Please let's not turn HN into Reddit.

kyleee 5y ago

This is great but im really looking forward to nextjs 13

kgin 5y ago
At this rate it should be ready in a few weeks
- midrus 5y ago
  Best release ever

benatkin 5y ago

The production quality for both this and Jamstack Conf a couple weeks ago are very high. I really dig the retro graphics and music!

midrus 5y ago

I'm going to be downvoted to hell for this... but the more I see the level of complexity and amount of engineering going into this, the more I miss Rails and how simple things are there, given most of us are just building CRUD apps anyways.

albertgao 5y ago
Because in 21st century, not everyone likes a website with a lower-bar rendering experience… SPA or hybrid rendering is just plain better, but I get the point where time is limited for human being, so if modern frontend is hard to grasp for you, perfectly to stick with old tech. Pretty safe.
- midrus 5y ago
  > SPA or hybrid rendering is just plain better, It is not for your end users, just for the developers building it because it has a better dev experience. As a proof of this try most sites out there which are built as an SPA vs the ones built with more traditional approaches. Also, building SPAs is incredibly more difficult and time consuming, that's why most of them work like shit.
techpression 5y ago
I keep thinking the same thing almost every day at work… “this is a CRUD app, who let it become this overly complex monster (multiple next apps)”. Then I remember why; “Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.” ― Edsger Wybe Dijkstra
- enahs-sf 5y ago
  This quote really made my day and embodies my approach to software engineering. Thanks for this.
- machiaweliczny 5y ago
  I worked with Rails and prefer this. Rails is more complex it's just easier to use but harder to understand with all that dynamic magic.

no_wizard 5y ago

This is really amazing, is the end result here that they are ultimately opting out of webpack in favor of SWC? It also compiles modules and such. Will have to take a look at the underlying infrastructure here! Interestingly I think that’s the major win of SWC over esbuild: you get a Babel like plug-in ecosystem for AST transformations and such. Downside: there currently isn’t a way to run asynchronous transforms, much like you can’t with Babel (easily anyway without some subprocess hacks) I love Vue, but it’s forever married to the Babel parser unless Evan moves over to using SWC for compiling SFCs, which would be awesome but he has signaled multiple times he doesn’t see the Vue Compiler ever being rust based, so it would be reliant on the Vue core team (though I think this is mainly his work) porting the SFC compiler to using SWC underneath. JSX frameworks won’t have this limitation and can get this massive speed gains and energy without such work. I could see Stencil and SolidJS adapting easily here Maybe JSX tools just needs some re thinking to get the same SFC experience

nightpool 5y ago
I find that React + styled-components in the same file gives me almost entirely the same experience as SFC.
- swyx 5y ago
  for >10x the javascript weight of Svelte tho :upside down smiley:
GordonS 5y ago
Sorry, "SFC" and "SWC"?
- abledon 5y ago
  man... web technologies are not getting simpler are they lol. it just keeps gaining more layers and layers
- DaiPlusPlus 5y ago
  At least it isn’t SWF…

nickosmark 5y ago

Next.js reinvents so many things that already exist in PHP (also Python, Ruby). Check out for example what is already possible with Symfony in their docs[0]. Next.js "biggest" release just introduced middleware and html rendering with zero client-side js ! What people like in tools like next.js is not the framework itself but the abstraction over infrastructure, using platforms like vercel. Imagine a platform as cheap, modern and easy to use as vercel but for PHP, basically shared hosting on steroids. Do you believe people would still care so much about Next.js in that scenario ? [0] https://symfony.com/doc/current/index.html https://symfony.com/doc/current/index.html

alasano 5y ago
I think that people who like JavaScript are happy with getting the abstractions you mentioned. If building a vercel for PHP was such an obvious idea, I imagine someone would jump on it.
- leerob 5y ago
  Fun fact, you can actually write PHP function on Vercel :) https://github.com/juicyfx/vercel-php https://github.com/juicyfx/vercel-php
- archeroed 5y ago
  People just like React and the idea of decoupling frontend and backend ( Pretty sure just a few percentage of users use Nextjs with api routes and just use it as Create-React-App with SSG and SSR capabilities ). I haven't used Vercel that much in production but what does it bring compared to Heroku or cheaper and open source self hosted alternatives like Dokku or even caprover with it's really good UI and can deploy any backend as long as it's Dockerizable ?
leodriesch 5y ago
I think what is comforting for a lot of people is that they can write isomorphic code that mostly automatically works on the frontend and backend. IMO React is also an amazing abstraction and I like writing components better than stitching together HTML or other template/DSL based systems.

sandGorgon 5y ago

>Next.js now enables you to do data fetching at the component level, all expressed as JSX. By using React Server components, we can simplify things. Special functions like getServerSideProps or getStaticProps are no longer needed. This aligns with the React Hooks model of colocating data fetching with your components. Do you see getServerSideProps and getStaticProps going away in the next release or two ?

1_player 5y ago
How often are they going to change their data fetching APIs?! There's libraries still using getInitialProps (like urql), now deprecated, because getServerSideProps and getStaticProps that were in vogue until now had very different semantics, and they're changing them again? I'm so glad I'm not maintaining the Next project at work anymore, I very much dislike how often it is changing yet it's still very restrictive. The JS ecosystem and the pace of change it's forcing on people with deadlines is ridiculous. /rant
- rglover 5y ago
  https://cheatcode.co/meta/introducing-joystick-the-full-stack-javascript-framework https://cheatcode.co/meta/introducing-joystick-the-full-stac...
shuding 5y ago
No, these will not be going away in the near future as far as we can see. React 18 / RSC are still in alpha or experimental stage, and what we shared are just new ways to do data fetching that we are currently exploring. In fact, component-level data fetching doesn’t conflict with top-level data fetching like gSP and gSSP. Today you can already use gSSP with Suspense-based data fetching together with Next.js 12. It’s just that you normally don’t need to use both, doesn’t mean you can’t :)

CosmicShadow 5y ago

Some exciting stuff for sure, but the most exciting stuff we still have to wait on as it's all experimental until React is ready. Anything that speeds things up and gives us more control is great though.

brillout 5y ago

Shameless plug: https://vite-plugin-ssr.com https://vite-plugin-ssr.com a do-one-thing-do-it-well alternative to Next.js which is feature-complete & stable (no breaking changes in the foreseeable future).

mariushn 5y ago
Looks good! Why did you decide to do your own Filesystem Routing instead of introducing a dependency to vite-plugin-pages, especially as you mention upstream contributions?
- brillout 5y ago
  The Filesystem Routing part is like less than 1% of the code; it wouldn't be worth it to externalize it in a separate library.

cusx 5y ago

Seems like Rust is eating JavaScript (in a good way).

emteycz 5y ago
In the same way C++ always did