Hacker News new | past | comments | ask | show | jobs | submit login
Next.js 12 (nextjs.org)
451 points by jacobwg 86 days ago | hide | past | favorite | 283 comments

The big innovation here seems to be 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.

We use this for TypeScript development at my company. Using swc for transpilation reduces build time from ~10s (small-ish codebase) to near instant. We can then wrap it in entr [1] to get live API reloading for free.

For type checking, you can run the TypeScript compiler in another window in watch mode, or just rely on editor warnings until the code hits CI.

[1]: https://eradman.com/entrproject/

How does it compare to esbuild? Seems they both want to achieve exactly the same thing, but somehow it's two different efforts.

I think esbuild is a fantastic project as well as a huge inspiration. I'll share two quick thoughts[1] I have on SWC that made it a fantastic choice for Next.js:

1. SWC is designed for extensibility

We were able to use `swc` as a crate[2], without the need to fork the project

This allowed us to effectively (no divergence) and efficiently (no loss in performance) extend it, especially to add syntax and plugin compatibility that is more common in the Next.js ecosystem. We added support for `<style jsx>`, with more React optimizations and Babel plugins coming.

2. We love the Rust ecosystem

It has a stellar, growing community. It has the best long-term performance prospects for us (e.g: absolute control over memory management) and safety. We don't want to be in a position where there's another enticing migration in just a couple years, and we think Rust is a durable non-regrettable choice.

[1] https://twitter.com/rauchg/status/1425520232202792962

[2] https://github.com/padmaia/next.js/blob/cf1d081c5b2f55085ceb...

One thing to keep in mind is that SWC is a compiler, whereas esbuild is a bundler. SWC has limited bundling capabilities last time I checked, so if you're looking for something to traverse your code and generate a single file (or multiple files at dynamic import boundaries, etc.) esbuild is what you want. Next.js bundles with webpack, so it uses SWC in lieu of Babel (or the TypeScript Compiler).

We are going all in on swcpack (spack) as well. One of the benefits of swc-as-platform is the rich ecosystem of tooling we will see develop from it. Transforming, bundling, prettifying, optimizing… all at peak performance.

Am I being cynical in that you could have simply replaced swcpack with “webpack” 6 years ago and it would have made perfect sense? Feels like we have been here before…

If you want a bundler built using SWC as a base today, check out Parcel: https://parceljs.org

I’ve tried both; found that both definitely solve the performance issues that they’re intended to address; and decided that I just prefer using esbuild. As much as I appreciate Rust, the idea that Rust (swc) vs. Go (esbuild) would matter in this context doesn’t make sense to me. The switch to a compiled language is what’s night-and-day.

I wonder if it's the compiled code entirely or also the architecture. Babel has a notoriously flexible design with tons of extensions reaching in and messing with things.

I'd bet that you could probably get close to 2x the performance if you stripped it down to the same feature set (it would still be 2-3x slower, but a dramatic improvement).

That's basically what Sucrase.js is:


esbuild is a bundler like webpack, it also does Typescript transform but the API is limited, e.g. you can't access the ast. Meanwhile swc is a Rust alternative to Babel.

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.

> I believe esbuild was started first

That seems incorrect.

- "put on github" - evanw committed on Jan 15, 2020 - https://github.com/evanw/esbuild/commit/23c40b1b6a76a8626f1d...

- "initial commit" - kdy1 committed on Dec 22, 2017 - https://github.com/swc-project/swc/commit/0f9532dd5d379292cc...

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.

Esbuild doesn't polyfill, it's a bundler that also transpiles.

It's pretty similar, but esbuild is still a bit more mature.

It’s already used in Deno

AFAIK ParcelJS also uses it.

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?

I'm the founder of WunderGraph. https://wundergraph.com/ We're doing exactly this. Our philosophy is simple, instead of forcing you into a specific stack, we can "introspect" multiple data sources like GraphQL & REST APIs, MySQL and PostgreSQL, S3 for file storage and OpenID Connect for authentication.

This way you can plug and play any of your existing infrastructure and services and turn them into your own private Firebase.

Finally, because we "introspect" all your data sources, we get end-to-end type safety. We don't just generate an API for you but also a truly type safe client.

Controlling everything from backend to API client allows for a lot of optimizations, e.g. the generated client knows if authentication is required to fire off a Query and therefore waits until the user is authenticated.

If you have any questions or feedback, feel free to join our discord: https://wundergraph.com/discord

We're going OSS 100% soon, exciting times ahead..

Hey I really like the product, I would recommend you embed the video you've made[0] somewhere in the website's homepage or docs.

I'm sure a lot of devs mostly get started by reading docs, but I personally love videos which show me what's possible and I follow along.

[0] :https://www.youtube.com/watch?v=1_Nl6ZQJJQY

https://supabase.io has:

- Postgres DB (+ admin panel + realtime sync + search + workflows)

- Auth

- Storage

- Functions (beta)

(disclosure: am small angel investor)

its interesting that you consider workflows a "standard cloud primitive". what do you currently use? (i work on a workflow engine myself)

As far as I know, Supabase is unique in this space in that you really are given a postgres db. You can log into it with any postgres client and do just about anything you want. Combine that with its "backend as a service" layer of niceties and it's a really potent combo.

Current company's infrastructure is currently all on AWS, so using Step Functions. However I really _really_ like temporal.io's code-first solution (just didn't want to self-host).

Perhaps the dust on best practices / tech for workflows or sagas just hasn't settled yet to include in a framework like the one I am envisioning.

In general I think Supabase is fantastic in terms of the interoperability of all of the features they introduce. Just waiting on functions (and perhaps events / queues for async communication).

ah nice! make sure to fill out our waitlist if you want our managed service: https://temporal.io/cloud

meanwhile if you like workflows as code and want to stay in the AWS world what about AWS SWF? our CEO used to be tech lead of that and it shares similar ideas.

yeah we are hoping to establish what best practice/architecture for workflows looks like. Feedback/questions welcome: https://docs.temporal.io/blog/workflow-engine-principles

am an ex-AWS engineer who worked on a service team that depends on SWF and also on one that depends on Step Functions. IMO the serverless-ness (?) of Step Functions and not having to manage pollers like SWF is huge.

yeah we hear that a bunch. long term we'll host pollers. gotcha tho :) thanks for the thoughts

I use pg-boss (https://www.npmjs.com/package/pg-boss) which plugs really nicely into Postgres.

It allows you to define task queues or scheduled jobs, and if you're already running Postgres you don't have to host any other infrastructure!

Does anyone in a larger company (say 100+ devs) have experience with supabase (or similar tool) real world projects to increase rate of experimentation before "graduating" services to more standard supported infrastructure that is using standardized monitoring etc?

I'm using Hasura for that right now to handle the API + database part. Fairly satisfied with GraphQL API generators so far - they get the ball running quickly and take over the boring CRUD parts so that I don't have to.

Hasura is at that level of being a full-featured back-end platform. I think that the best way to get started with Hasura is https://www.nhost.io

Why not use Hasura Cloud and also support the developers?

For me it is because og the pricing model. Free or $99

I’d pay more to get eur datacenter, but not that much when I can host it myself for $5 on DO with the same performance (for my usage)

Would gladly pay to support them, so I have given them feedback on my pereicament

Disclaimer: Work at Hasura

  > "I can host it myself for $5 on DO with the same performance (for my usage)"
Yeah for sure, I know what you're getting at. Though it's not really so much about performance (there is caching) -- There's a chunk of functionality that comes with Cloud/Enterprise. The majority of this has to do with metrics/observability and monitoring tools, or access-control tools for teams.

If you check here:


And look under "Features" and "Security" you can get a decent idea of what the differences are between OSS and the Cloud product.

There's 2 demographics I think Cloud stands out to -- those who want convenience ("I don't want to think about/manage my own instance"), and those who want an integrated APM tool or more security & access-control features, or are working on teams/orgs.

  > Would gladly pay to support them, so I have given them feedback
This is always neat to hear! I don't blame you, with Cloud being $99 there could be potential for some future tier to fill the gap between OSS and Cloud. Like "I have some weekend projects but nothing I can afford to blow $100/mo" on, you know?

I don't know enough (or really anything) about the business side though. It could be that $99 might be the only number where it starts to make sense to offer this sort of thing, based on infra costs/complexity. Or this could be the stupid thing I've ever said. I'm not a Cloud-Scientist ;^)

Exactly! I really do think a tier is missing. I was very excited about hasura cloud when It came. My dream was to move all my hasura instances to the platform. However I could not defend spending $99/month on each weekend projects or small client work just to get my instances to europe (US = very high latency). Hopefully a ‘hobby-pro’ tier will come at some point :)

.. oh, and keep up the good work. I really do love the product!

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.

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.

Welcome to the Jamstack.


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.

Check out supabase


For this sort of thing I really like fauna (https://fauna.com/). I don't think you really "need" a "backend backend" anymore, and small dev teams are probably better off without them.

Right, they don't host the databases, but they do integrate with other database, etc. providers: https://vercel.com/integrations

Vercel itself I believe runs on a combination of Google Cloud and AWS.

Yep, I'm using Vercel + Supabase for a SaaS right now. Easy, fast, cheap, and effective.

Definitely get that it works as a backend as well. I guess I am imagining a frontend-agnostic platform that is more backend-centric, rather than targeted directly for frontend web development.

Ideally I just get an endpoint from my backend-as-a-service (Supabase style) I can pop into Vercel as an environment variable, and use it as well in my moblile apps, public api, etc.

If you're already using likes of Supabase, Firebase etc. then Parse.com (RIP) was that OG BaaS but Facebook acqui-killed it. Now it's available as a open-source project and is used by several providers to provide BaaS[1].

I had used both proprietary & open-source Parse until 4 years back for several production applications but has since gone back to relational DB(pgSQL), so don't know the current status of the ecosystem.

[1] https://parseopensource.github.io/

I would suggest render.com and fly.io if you’re looking for something that has a similar deployment experience to Vercel.

+1 for render. Great experience so far building an airbnb like marketplace on top of their services

1. I'm not sure about this premise: "leader of the production-ready frontend-as-a-service space." They def seem like a good fit for some frontends -- but they're certainly not a good fit for ALL frontends generally. (For example, sufficiently small sites should probably just go with static hosting, and sufficiently dynamic web apps still will want a SPA.)

2. At the end of the day, web backends are just a lot more varied and complex than web frontends. On the technical side, a web frontend is always just bundles of JS, HTML, CSS, that have to be transmitted to the client. And functionally, there's a relatively large set of common things they pretty much all do (routing, serve images, etc.) Therefore, it's relatively simple to build an opinionated framework that can still cover a good number of situations.

By contrast, a "backend" is really a lot of different things (like the four you mention, plus various types of storage and caching), which can use many different languages/technologies, all working together in different ways. It's hard to conceive of a universal "backend" framework that could cover all of that complexity.

3. There are some efforts to do this kind of thing (to some extent). Google's Firebase and AWS Amplify are the two that I think are closest -- they try to give low-configuration generic backend building blocks. (I'm currently using Amplify for a project -- still too early to tell. It also works with Next.js!) There's also platform-as-a-service options like Heroku.

Backend is probably a lot easier than the frontend, which is why you can see service like hasura and supabase. Backend is a highly patternized work, which is why it can be low to no code, whereas front end as a service is merely just deployment as a service.

> At the end of the day, web backends are just a lot more varied and complex than web frontends.

> No, they aren't. On the technical side, a web frontend is always just bundles of JS, HTML, CSS, that have to be transmitted to the client.

First, that's factually untrue; web front-ends can contain a wide array of things beyond those three (WASM, content in formats other than HTML that is read and used by the JS/WASM, etc.)

Second, on a similar level of reductionism, web backends are just bundles of bytes that need to be deployed on servers.

Even completely leaving aside the language/software diversity, the point is that the vast majority of web "frontends" are really just one thing (rendering the UI and responding to inputs) whereas web "backends" are frequently not really one thing (1 or more types of storage, 1 or more types of computation, responding to requests, perhaps event processing and scheduling, etc.)

I did not mean to imply that all, or even most backends are more complex than frontends -- only that the problem space of backends is larger and more varied (for typical web use these days, at least.)

Not sure I agree with your first point. Next can output static sites easily, I've used it for some tiny marketing sites recently and I think its fine for small sites. You get auto routing, and can use react components without any hassle.

And 'sufficiently dynamic web apps still will want a SPA' doesn't make much sense to me because you can just use nextjs in full SPA mode and its just as 'dynamic' as any react app

This is a really strong argument. At the end of the day I think it is possible (with iteration) to get the level of abstraction correct for something approaching some semblance of the universality you refer to.

I really just want a framework that allows me to:

1) Run locally like Next.js's "npm run dev"

2) Do end-to-end unit tests because the framework provides the abstraction layer

3) Deploy to the cloud via push to Github and have it run exactly the same as (1), but do it at scale (deploy to serverless functions, use actual SQS Queues, Eventbridge, etc.)

Of course the core would a developer experience like Vercel, Stripe, etc.

Check out Amplify! I've heard good things and my limited experience is good so far. (Although running locally isn't the best, unfortunately... but that's always going to be an issue the more you lean on a cloud services.) Deployments are easy. In terms of scalability, it's all massively scalable AWS services under the hood, and it seems relatively easy to "eject" if you ever need to.

Once u have enough experience in AWS tooling world, Amplify is probably the last one you want to use for your product, just so unpolished…..

Why not using Caprover ? That's an open source self hosted PaaS that use Docker and let you configure almost everything through their GUI, as well as checking Logs, easily scale horizontally, spinning up Postgres/Redis/Next cloud or whichever docker images in one click and letting you communicate via different parts of your projects through environment variables set through the GUI.

That way instead of learning a new and likely less advanced framework you can use your favorite and likely more mature and well maintained backend framework and just deploy in a minute with caprover, as long as you can dockerize it it should work, you just have to write a single dockerfile ( they also have a way to not write dockerfiles directly and use their abstraction ).

You take advantage from the backed framework you already know with all its advantages and also benefit from Docker's huge community. Their UI is really good to be honest, you can enable and force https in one click and other goodies like that, DigitalOcean also have a preconfigured Ubuntu droplets with caprover preinstalled to make it even smoother.

I am developing a framework that might handle some of these needs. Right now it incorporates:

- an RDS postgres instance with a curated set of DB scripts with auditing baked in

- Lambda/API Gateway based API

- fully implemented with users, roles, groups

- application level authorization

- Cognito for user authentication (sign up or admin created)

- S3/CF for hosting/files

- React frontend

- all in Typescript with a robust type-set; same types for the whole stack

- deployed via CF template along with some custom scripting I have done to tie it all together

It's been a work in progress for some time on the side, but I am now formalizing it. It might seem a bit rough on the edges at first, but it gets the job done, and can more or less be extended into other AWS services as needed. I haven't really received much feedback yet.

It's all open source, you just pay for the AWS resources, and it installs from npm and deploys in about 10 minutes based on how long the DB and CF distribution take to deploy. Here's a sped up install video: https://www.youtube.com/watch?v=b3mzwtIyt9s

And here's the git, https://github.com/keybittech/awayto

I am in the midst of drafting formal documentation, how-tos, and other media that I can share with the community to help make it easier to understand and use. Any feedback is greatly appreciated!

Tried a couple shots at it

Go Micro (17k stars) https://github.com/asim/go-micro

Micro (10k stars) https://github.com/micro/micro

M3O (1.7k stars) https://m3o.com

This appears to be a framework and not a hosted backend service

We tried https://m3o.dev. It was a pretty hard thing to do with limited resources. Some sort of backend hosting will make its way back in soon.

Maybe something like https://encore.dev? Looks like a similar mindset.

This certainly is akin to what I had in mind, and looks really great. A couple of thoughts:

1) Ideally the framework is polyglot (Go seems sensible though)

2) I wish they had queues/events that were wired up to functions

3) Not sure if using autoscaling k8s services under the hood as opposed to serverless functions is the right choice

4) A bit too opinionated on DB/Auth (maybe I don't want to use Postgres)

5) With all of the above you could get really great end-to-end integration tests as unit tests that I don't see them taking advantage of

Thanks for the feedback! (I'm the founder of Encore)

Your thoughts are very much in line with where we're going. We're working on natively supporting queues, pubsub, object storage, etc. Our roadmap is available at https://encore.dev/roadmap which should give you an idea.

We definitely intend on supporting more storage options. We already do provide end-to-end integration testing out of the box that integrates with Go's built-in testing support.

The authentication should be pretty flexible; was there something you were thinking of that makes it too opinionated or inflexible?


I guess https://dapr.io/ could also be considered a contender in that space, though the developer experience is not as polished as next.js (yet?).

> 4) A bit too opinionated on DB/Auth (maybe I don't want to use Postgres)

This feels like a weird criticism considering Next is React only.

I think your criticism of my criticism is fair. Perhaps this is somewhere you simply cannot provide a clean abstraction and need to be opinionated.

I think that's the case. On the other hand, at a very large scale you may want to move out from Postgres while React can still be fine. I'm not sure if people change more often frontend frameworks or databases.

We are finding that Next.js + Nest.JS to be a really strong combo so far.

Sounds interesting! Do you have any templates, resources, or just tips to share?

Great choices. I love Nest.

We're working on something like this at Deref: https://exo.deref.io/ - The version of our Exo tool that is out there now is a local process & docker container orchestrator with log viewer etc. We're working on adding support for a rich set of component types like functions, queues, workflows, cron jobs, etc. Everything would have a nice console GUI, so you don't need to be an expert at infrastructure-as-code, yet you'd get a version-controlled manifest file that you can use for reproducible deployments. We plan to support deployment to your own infrastructure or an eventual PaaS platform.

If folks are interested in working on something like this, my email address is in my profile. Don't hesitate to reach out.

If you like the idea of getting developers out of the backend plumbing and repair business you might want to check out https://stepzen.com (I work there). We agree that APIs and the data sources behind them need to be modernized the way that companies like Vercel and Netlify are modernizing frontends. Our platform is built on top of GraphQL to give developers that one-stop shop for any and all data sources; we'll keep your API fast and secure. Next week we're going to release a new product to make that even easier.

I would give MongoDB Realm a try, it has all the building blocks you need!

Most of the modern frontend hosting services also push for a backend as a service. Whether it be a DBaaS, like Fauna https://www.fauna.com, or Headless CMS, like Cosmic https://www.cosmicjs.com as it gives you the auto-scaling capabilities without the infrastructure time and headache (Disclaimer: I'm CEO at Cosmic)

Supabase is headed in that direction and already works for most simple CRUD like apps.

Supabase is overly SQL heavy.

can you elaborate on what "overly SQL heavy" even means? it's just a postgres db as a service, use as much or as little as you want

The authn/authz is heavily tied to PSQL. It lacks the polish and ease of use of Firebase. It takes too much configuration to get started. Poor support for things like migrations management and generation.

Oh hello there! I'm the founder of https://railway.app/ and "Vercel for Backends" is what we get a lot

You can give us a go at https://dev.new/

We're working on making the project connections a bit better so that generalizable connected services are as trivial to build as stateful monolithic backends in the current platform

Anything else we've missed and I'm happy to sit down with you (or anybody else) and hear what your needs are. Arbitrary evented triggers are coming pretty soon as well as the API so the infrastructure should be fully composable/meta.

P.S We integrate with the lovely lads/lasses/fiends at Vercel :)

What about Firebase? It’s not open-source I know, but it brings tremendous primitives to backend (cloud functions, database, queues (with Google Cloud Tasks), etc.)

We are working on this right now at https://Flightcontrol.dev

Others have posted various solutions but I haven't seen Redwood mentioned yet. Would that be something you're looking for?

I think because the answer here is using Next.js with hosted backend solutions like Firebase, Supabase, Pusher, etc.

The reason I love Next.js + Vercel though is because I don't need anything else for the frontend (besides a CMS maybe).

If I have to use:

1) Pusher for realtime

2) Supabase for DB

3) Temporal for workflows

4) Vercel / Netlify, etc. for functions / cron jobs

My backend becomes primarily a bunch of stuff glued together, rather than something cohesive like Next.js

And you end up with tons a network calls and services to monitore, logs, manage and pay.

I'd do the exact opposite by default, trying to have the most cohesive service, and occasionnaly use some external APIs when I can't do the stuff by myself (eg. Stripe)

Nhost.io does functions, database, Graphql API, rate-limiting, authentication. Basically everything you need.

I think amplify wants to be this? Also Hasura, not that I used or like them.

Blitz.js is a superset of NextJS that should do what you want

Postgraphile, Hasura, Supabase etc might be of interest to you

Django + Django rest framework ? A headless CMS ?

Google App Engine?

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.

I'm personally curious how the Next is able to achieve the claim of "zero client-side JavaScript" mentioned here[1] using react server components? It just doesn't seem to make sense to me, and the HN clone example and my barebones test project also clearly still load about 74.2 KB of JavaScript. Is the claim supposed to mean that the server components won't require additional JS, or maybe that they won't need to execute any client-side JS to be fully rendered?

[1]: https://nextjs.org/docs/advanced-features/react-18#react-ser...

I think it means that any page that only renders server components can just push the built html to the browser. If there were to be client components, like an upvote button, react would be required for that to hydrate the DOM.

It’s very similar to what Astro is doing. Only adding the JS if it’s actually necessary.

From my understanding from watching the keynote earlier today, the reason that demo has JS is that repo opted in to have client side code to handle the upvote functionality. If it didn't require that interactivity it could be shipped with no client side JS. The client side js code is defined in the component files ending in .client.js


You can read more here on the original RSC announcement: https://reactjs.org/blog/2020/12/21/data-fetching-with-react.... RSC are still experimental, and as mentioned, this demo has some client-side functionality (upvotes).

Thank you for your response! However, the linked content further seems to support my suspicion that having websites without any client-side JS is not in the scope of RSCs. The linked RFC, in my opinion, clearly states for it to be expected that a client-side framework and React accept and handle the streamed React response[1]. So while it may be possible to eliminate a lot of client-side JS, at least those would always have to be available on the client, correct?

I would also like to make it understood that I'm not here to bash the Next project, I am simply interested in the technology.

[1]: https://github.com/josephsavona/rfcs/blob/server-components/...

Seems he missed your question, which I’m also curious about.

I would assume "no client side js" means "works fine in w3m". I'm guessing that's not the case?

Also, does "no client-side JS" also work with Cloudflare Workers?

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#discussi...

It is not part of Next.js 12 – still working on it!

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).

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.

It's available to try today under an experimental flag. React 18 is still in alpha. We'd love to hear your feedback!

Any chance we’ll get a proper official routing mechanic that doesn’t rely on the file system and magical file names?

Also excited about the Rust compiler! Apologies if this is far from reality, but by looking at recent commits in GH[1] it looks as though this has been rushed for a v12 release, so I was wondering how much of internal testing has this been going through before pushing it to the broader public.

[1] https://github.com/vercel/next.js/commits/canary

We've been testing SWC for months now, both with early community members on canary releases and with Vercel customers. Lots of the rushing at the end was for minification, which is opt-in because of this. But compilation with Rust (replacing Babel) is stable (which is why it's on by default).

Thanks for clarifying, Lee!

The Rust compiler is just swc which has been around as another project for ages. Checkout it’s home page. Many people are using it.

Yeah, Deno is using it as well!

And Parcel: https://parceljs.org

How do you achieve no cold boots on edge functions? Is it the same approach as Cloudflare (https://blog.cloudflare.com/eliminating-cold-starts-with-clo...) or something else? Are there any tradeoffs to be aware of with your approach vs theirs if they're different?

Vercel's Edge Functions are built on top of Cloudflare Workers. The runtime is designed for any similar provider, but we've chosen Cloudflare for now because they have an amazing product.

Awesome!! Thanks for the answer :)

Excellent decision!

I'm building a custom server (which hopefully now can be replaced with middleware?) which I build with tsc:

$ tsc --strict --esModuleInterop --moduleResolution node --jsx react --outdir build server.ts node_modules/next/dist/server/config-shared.d.ts:1:15 - error TS2724: '"next/dist/compiled/webpack/webpack"' has no exported member named 'webpack5'. Did you mean 'webpack'?

1 import type { webpack5 } from 'next/dist/compiled/webpack/webpack'; ~~~~~~~~

Probably there's some workaround but the compile error seems legit. Is there something I can do about it until I figure out middleware?

Webpack is no longer a dependency of Next.js - this was the big announcement about the compiler. You will have to opt out of the new SWC compiler (if this is an option atm)

That doesn't seem correct. Next _does_ still use Webpack - it's what does the actual bundling:

> Underlying webpack improvements: We've made numerous improvements to webpack, including optimizing Fast Refresh and making on-demand entries more reliable.

> After making webpack 5 the default in Next.js 11, we've now officially removed webpack 4. We've worked closely with the community to ensure a smooth transition to webpack 5.

SWC is the equivalent of Babel for transpiling JS, not Webpack for bundling.

Hey Lee! Loved the new features and your session on edge.

One further-future question - would react server components ever be able to execute on the edge or will those always run from the datacenter you've deployed to?

And regions - Cloudflare Workers offers 44 regions in North America and Vercel currently offers 4. Does your team have any plans to add some more edges around the world to bring the speed benefits closer to end users?

Thanks to you and your teams incredible hard work on all the new features. Next.js has been a blast to use the past 5 years. Looking forward to the next 5!

Yes, the Hacker News demo shown does run at the Edge (using Vercel Edge Functions) when deployed. If you self host, it would run on your server of choice.

Vercel doesn't have 4 regions, we have 17 :)

Hey Lee. I am not entirely sure how server-side components replace the dynamic/static balance next.js is now the market standard for.

1) Do the .server files require any special infrastructure for self hosted solutions?

2) If we move to ISR to a component level, would that mean that a page with multiple components will generate a backend-process thrash of multiple refreshes? (say 10 components, each with a revalidate 1 s)

3) Is there a good mapping to translate ISR to server side components from both UX and infrastructure/implementation?

1. No, when self-hosted, server files will just run on your server :)

2. You can use the `keys` prop to prevent that (this is still very experimental and the API is not finalized).

3. We will be sharing more on this soon, but yeah still early days.

Are there any plans to address Bazel compatibility?

I understand that the Next philosophy is very monolithic but so far I’m having trouble getting it to play nice with build tooling.

We may investigate this more in the future, but nothing planned currently.

Does Next 12 allow for getStaticProps() in _app.js?

It does not, but with React Server Components, you can achieve the same result.


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?

> in a future where most build tooling is written in languages like rust/go

You really think most of the build tooling will be written in other languages than JS? Compilers make sense, they are very CPU bound, but otherwise build tooling should also be accessible to modify to the developers working in the project, not just those who use Rust/Golang. And I'm sure we'll still use JS projects for some of the tooling.

"You really think most of the build tooling will be written in other languages than JS?"

Deno is using the same compiler (SWC) so there is data point number two on the question. esbuild is another...

We're working on making it easier for developers to write Rust plugins to handle their own transformations.

The module federation story was a bit complicated pre-webpack 5. Are there plans in the roadmap to further support module federation?

When can we expect the docs to be updated?

They are now updated! Sorry for that. The NPM release took a bit longer than expected.

Is Next.js Live only available if the project is hosted on Vercel?

No, it works fine with any static hosting system, like S3+CDN, Netlify or others. The API feature (FaaS) needs special server handling to run, but they're just Node functions, so other systems also add support.

Vercel just has first class support where everything just works, but can you host it yourself.

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.

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

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.

This quote really made my day and embodies my approach to software engineering. Thanks for this.

Eh. Perhaps you're looking through rose colored glasses on the days of Rails dominance? I've worked at multiple companies using Rails and not one was simple. Especially when you have 100+ engineers working on different aspects of a massive product. Anecdotal but Rails has a ton of magic to make things work but its only simple if you're product is a super basic CRUD app

I don't think 100s of engineers working on a massive next.js application would be any easier. At scale everything is complex.

Of course. I didn't say Next.js solves the complexity of building a massive product, no framework will prevent complexity at scale. That's my point since this thread seems to put Rails on a pedestal like it was the main thing making products built with Rails simpler compared to other frameworks in other languages when in reality, the product requirements are most likely pretty simple

No downvote - it definitely is crazy complex, or at least intimidating for anyone from the 'before times' of Rails (myself included). Everything is taken over by engineers and so is now over-engineered and feels totally geared towards developers developers developers and a weird obsession with performance.

And all the new features including server side rendering give me whiplash

Over-engineering is not exclusive to the JS world. It's just in the spotlight nowadays. Rails also just hides its magic well because of Ruby and most experienced devs are already used to the Rails magic so its simpler compared to the new stuff like Next.js.

I understand your point, but having worked with Rails and now working on a React + Flask app, Next.js is the closest thing to Rails we have so far.

And, having worked on a Rails + React app a few years back, I can safely say that is about as complext as a Next.js full-stack app.

I do love Rails and I still think the React + Something on Backend environment is still not there yet (at least not like Rails 4 and 5, which were the ones I used), but Next.js is getting there.

When you factor stuff like Redwook.js and possible Remix.js when it gets open-sourced, for me it gets pretty clear that the trend now is to try to make the Rails of the JS world.

And I would love that. Honestly, people complain about Node and JS, but working in Python/Flask can be just as frustrating. Issue for me is more lack of conventions than language.

I was looking for a mention of Redwood JS - I assume your post has a typo in it.

It's not 1.0 yet but from what I have played with it's the backend (PostgreSQL with Prisma, graphql, services) + frontend (react with data retrieval components (Cells)). That sounds buzz wordy but in practice it works nicely.

But why do we need a new rails? That's what I don't get. Just because we want to use JavaScript?

Simply because Rails is not designed to solve frontend problem where complex user interactions and client side state are included, not to mention partial rendering and transition. Rails is a backend framework after all, spitting a HTML is all it can do in terms of a frontend part. Just don’t know why you think you can solve all the modern frontend user interaction with a backend framework like rails and Django,,,,,,,,,,,,,,

Github, Hey, and so many others are examples of Rails applications with complex interactions. Server templates and partials rendering doesn't mean "I reload the page on every click and can't write any javascript because I only do ruby". You have tools for doing dynamic html too, just not your usual redux/rxjs/thunk/observable/typesafeactions stuff.

Agree that Django is a backend framework, but Rails is not, you can certainly do frontend in Rails. Just not SPAs, but you need a more open mindset for understanding how it is intended to be used.

Of course, if you are building Google Docs or Maps then you're probably better with a SPA framework. But not for 90% of applications out there which are just CRUD apps.

Because React is now a standard in the frontend I guess, so people are looking for a way to get that Django/Rails fullstack experience but with React instead of templating language and because it's extra work to write a django/node/rails api and a decoupled JS framework frontend.

Meanwhile everyone is also trying to have a decoupled infrastructure and going with microservices. It's an endless loop I guess.

No I had the exact same thought. Are we just re-inventing simple server side templating but with incredible new levels of complexity and obfuscation?

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.

> 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.

I'm so done with CRUD work, it sucked the soul out of me

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact