Next.js 12(nextjs.org)
nextjs.org
Next.js 12
https://nextjs.org/blog/next-12
292 comments
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..
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
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
[deleted]
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)
- 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).
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
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!
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
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
If you check here:
https://hasura.io/docs/latest/graphql/cloud/index.html#hasur...
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.
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 ;^)
> "I can host it myself for $5 on DO with the same performance (for my usage)"
If you check here:
https://hasura.io/docs/latest/graphql/cloud/index.html#hasur...
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
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!
.. oh, and keep up the good work. I really do love the product!
[deleted]
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.
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.
/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.
/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.
Check out supabase
https://supabase.io/
https://supabase.io/
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.
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.
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 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.
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.
> 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.)
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
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.
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.
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!
- 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
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
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?
Thanks!
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?
Thanks!
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.
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 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 :)
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
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)
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?
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
“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
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.
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.
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.
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.
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.
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
>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 ?
Do you see getServerSideProps and getStaticProps going away in the next release or two ?
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 :)
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 :)
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
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
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...
[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.
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
https://github.com/vercel/next-rsc-demo/tree/main/components
https://github.com/vercel/next-rsc-demo/tree/main/components
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/...
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...
* 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).
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
[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.
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?
$ 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.
> 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!
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 :)
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) 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.
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.
Does Next 12 allow for getStaticProps() in _app.js?
It does not, but with React Server Components, you can achieve the same result.
https://nextjs.org/docs/advanced-features/react-18
https://nextjs.org/docs/advanced-features/react-18
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? 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...
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?
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.
Vercel just has first class support where everything just works, but can you host it yourself.
Nice, a completely new attack-vector: 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.
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.
Our absolute top priority is security, hence why it's under an experimental flag that forces you to whitelist the allowed domains that you accept URL imports from.
Not only that, but before the feature goes GA, we plan to double down on our Web runtime alignment, and execute URL imports exclusively in the context of the browser sandbox (e.g.: the V8 Isolate that backs a ServiceWorker).
This is the trajectory that we are taking for most code execution at development time, and it's the technique that backs nextjs.org/live, which is the version of the dev server that runs 100% in the native browser (no VMs!).
URL Imports represent an opportunity to build a system for sharing ES modules that's much safer than what folks are doing what npm today, in my humble opinion.
Not only that, but before the feature goes GA, we plan to double down on our Web runtime alignment, and execute URL imports exclusively in the context of the browser sandbox (e.g.: the V8 Isolate that backs a ServiceWorker).
This is the trajectory that we are taking for most code execution at development time, and it's the technique that backs nextjs.org/live, which is the version of the dev server that runs 100% in the native browser (no VMs!).
URL Imports represent an opportunity to build a system for sharing ES modules that's much safer than what folks are doing what npm today, in my humble opinion.
> I guess replacing configuration with code is one way of achieving "zero-configuration".
That's a weird thing to have beef with since this approach to middleware is completely inline with Next's zero-config philosophy.
They take common patterns in the industry and make them dead simple to use out-of-the-box.
In an alternate framework that uses middleware, you would have to manually configure the middleware on whatever server you are using and then attach all the middleware in a single place.
Their approach IS zero-config. You just add a file with your middleware function in the corresponding directory and you're done.
That's a weird thing to have beef with since this approach to middleware is completely inline with Next's zero-config philosophy.
They take common patterns in the industry and make them dead simple to use out-of-the-box.
In an alternate framework that uses middleware, you would have to manually configure the middleware on whatever server you are using and then attach all the middleware in a single place.
Their approach IS zero-config. You just add a file with your middleware function in the corresponding directory and you're done.
That code is config. Zero-config would be that those middlewares are enabled by default, so you have to do zero things to enable it. I guess maybe there is a difference in understanding the terminology. I always understood zero-config to be that you'd have to do nothing to get that particular feature, but maybe zero in zero-config is referring to something else.
That code is your application logic.
Next is a lightweight framework. It doesn't implement authentication for you. It's up to you to implement it, but the scaffolding is there for you to easily do it.
You're arguing against your initial comment:
> 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.
The point of Next.js is that the framework functionality is minimal. You learn the basic concepts and then build the rest out yourself. If they built all of these middlewares into the framework, then we would be in that state you're complaining about since now you have to learn how to use their specific implementation of that middleware because god knows their implementation won't work for your specific needs.
Next.js takes care of everything but the application code itself. It's a true framework.
Next is a lightweight framework. It doesn't implement authentication for you. It's up to you to implement it, but the scaffolding is there for you to easily do it.
You're arguing against your initial comment:
> 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.
The point of Next.js is that the framework functionality is minimal. You learn the basic concepts and then build the rest out yourself. If they built all of these middlewares into the framework, then we would be in that state you're complaining about since now you have to learn how to use their specific implementation of that middleware because god knows their implementation won't work for your specific needs.
Next.js takes care of everything but the application code itself. It's a true framework.
> Zero-config would be that those middlewares are enabled by default
What middlewares? Next has all basic middlewares needed enabled by default. What you're suggesting is that Next ships with every possible middleware that anyone could need, even the special snowflake middleware I want that adds a "foozlebozzle" property to the request context, just to say "We don't require you to do anything" and that's just not possible.
They have made it so you can hook into things and customize if needed, not "you have to now write all your own middleware for everything"
What middlewares? Next has all basic middlewares needed enabled by default. What you're suggesting is that Next ships with every possible middleware that anyone could need, even the special snowflake middleware I want that adds a "foozlebozzle" property to the request context, just to say "We don't require you to do anything" and that's just not possible.
They have made it so you can hook into things and customize if needed, not "you have to now write all your own middleware for everything"
Yes, it is a good thing but I do not see how it is zero config (and generally I do not think zero config is a good thing). Selecting your set of middleware is config.
The zero-config aspect is that in order to add my own middleware to my app, I drop in a file with my middleware function into a directory and that's it. There is nothing else I have to do. Just like if I want to define a new API endpoint, I drop in a file in the corresponding directory with the endpoint function defined and that's it. That's zero config.
They took all the ease of the old PHP approach and made it better.
They took all the ease of the old PHP approach and made it better.
[deleted]
The introduction of Middleware is specifically in alignment with our zero-config principle.
You should be able to open `pages/` and understand exactly the flow of traffic.
You'll open `pages/`, find `_middleware.js` which processes your request first, and then the rest of the routes. No magic, and heavily inspired in successful predecessors like Express.js.
Always open for feedback, let me know if this makes sense!
You should be able to open `pages/` and understand exactly the flow of traffic.
You'll open `pages/`, find `_middleware.js` which processes your request first, and then the rest of the routes. No magic, and heavily inspired in successful predecessors like Express.js.
Always open for feedback, let me know if this makes sense!
How to compose middleware then ?
Anything sold as erasing away reality eventually becomes overly complicated, as you inevitably have to work around it to address reality
> 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.
> 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.
Commonly known as: leaky abstraction.
Re attack vector: the outcome here will just be the same as a vanilla js + html website won't it?
Or are you saying that reverting to that mean takes away some of the security gained from SSR?
Since this is an optional opt in that mirrors current usage it doesn't seem like a bad thing...
Or are you saying that reverting to that mean takes away some of the security gained from SSR?
Since this is an optional opt in that mirrors current usage it doesn't seem like a bad thing...
> url imports
Aren't they just taking a feather out of Golang's hat?
Aren't they just taking a feather out of Golang's hat?
Deno's as well, I suspect there'll be a later version where next runs entirely on Deno.
That's certainly the trajectory I expect from a release that is shifting a lot of tooling to Rust, and focussing heavily on the server-side functionality.
I also expect that's going to be done to benefit Vercel/nextjs's saas offering. Deno's APIs follow the browser APIs so it seems sensible enough to evolve the project in that direction.
That's certainly the trajectory I expect from a release that is shifting a lot of tooling to Rust, and focussing heavily on the server-side functionality.
I also expect that's going to be done to benefit Vercel/nextjs's saas offering. Deno's APIs follow the browser APIs so it seems sensible enough to evolve the project in that direction.
[deleted]
[deleted]
[deleted]
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?
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.
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.
Go's templating system is woefully awful.
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.
Next offers using React as your templating language as well as adding in server side code if you want instead of static site generation.
One benefit is that it's JS. Yes, really. For every Go developer, there are a thousand that know JS.
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.
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/
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...
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).
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:
https://github.com/alangpierce/sucrase
https://github.com/alangpierce/sucrase
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...
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.
It's pretty similar, but esbuild is still a bit more mature.
Esbuild doesn't polyfill, it's a bundler that also transpiles.
It's being adopted in ts-node as well: https://github.com/TypeStrong/ts-node/blob/main/website/docs...
It’s already used in Deno
AFAIK ParcelJS also uses it.
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...
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...
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.
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.
This argument doesn't really make sense.
> That means a whole lot of CPU that you need to burn during build
This doesn't makes it hard, and I'd rather spend the CPU once than at every edge server on first request.
> uses up loads of storage (that you need to ship to your static web server)
Uploading to S3 (for example) is free, and the edge servers need to store the images anyways (because they are slow to generate as you just mentioned).
> your 60 seconds deployment into a 30 minutes deployment (or longer), that doesn't scale.
Says who? It's a static site so it's not being updated every 30 minutes, and with some intelligent incremental compilation I bet it would remain fast even for the largest sites.
> That means a whole lot of CPU that you need to burn during build
This doesn't makes it hard, and I'd rather spend the CPU once than at every edge server on first request.
> uses up loads of storage (that you need to ship to your static web server)
Uploading to S3 (for example) is free, and the edge servers need to store the images anyways (because they are slow to generate as you just mentioned).
> your 60 seconds deployment into a 30 minutes deployment (or longer), that doesn't scale.
Says who? It's a static site so it's not being updated every 30 minutes, and with some intelligent incremental compilation I bet it would remain fast even for the largest sites.
When I said hard, I didn't mean technically. I meant it's hard for Next.js to decide how to solve the problem so it works for everyone. I'm doubtful if it even makes sense for them to try to support every possible use case.
There are solutions available to all of these problems today. You can pick the ones which you prefer or fit your workflow.
There are solutions available to all of these problems today. You can pick the ones which you prefer or fit your workflow.
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.
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.
Just use Gatsby v4 if you want good image support! v4 brings Gatsby in-line with Next.js because it introduced runtime SSR support like Next.
I assume that Gatsby generates the different widths/formats at build time. How well does that scale? Like if you have a thousand images, what's the build time like?
We have a job framework that can distribute image processing jobs on supported platforms* as well as automatically caching subsequent jobs. So it scales easily and as most builds don't have that many image changes (if any), the impact on warm builds is negligible.
* like Gatsby Cloud https://www.gatsbyjs.com/products/cloud/
* like Gatsby Cloud https://www.gatsbyjs.com/products/cloud/
It's similar to generating compressed files with the build. I think it belongs on the web server layer.
Here's an open source, self-hosted one, that should be easy to integrate with Next.js:
https://github.com/willnorris/imageproxy
To define a custom one, you need only provide a function:
https://nextjs.org/docs/api-reference/next/image#loader
Here's an open source, self-hosted one, that should be easy to integrate with Next.js:
https://github.com/willnorris/imageproxy
To define a custom one, you need only provide a function:
https://nextjs.org/docs/api-reference/next/image#loader
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!
Right, this could work for small sites, but not sites with a ton of images.
Maybe I'm missing something, but aren't we able to use `next/image` to transform local assets since v10?
The imperative phrase is
> when exporting a static site
i.e. running `next export` to generate a bunch of HTML, JS and CSS files that you just serve from a static file server. It would be nice if that could generate responsive versions of your images too.
See for the feature request: https://github.com/vercel/next.js/discussions/19065
> when exporting a static site
i.e. running `next export` to generate a bunch of HTML, JS and CSS files that you just serve from a static file server. It would be nice if that could generate responsive versions of your images too.
See for the feature request: https://github.com/vercel/next.js/discussions/19065
With server component, i really think next.js hybrid app with cordova will achieve high performance even better than native app (like react-native).
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-st...
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.
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.
I like that they have finally provided a fast Webpack alternative.
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.
webpack 5 is still used, SWC would replace babel-loader
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... [1]: https://news.ycombinator.com/item?id=28962168
[0]: https://www.bleepingcomputer.com/news/security/52-percent-of... [1]: https://news.ycombinator.com/item?id=28962168
A huge bet we're placing on our Rust compiler is that we'll control the supply chain much more tightly. The core infrastructure of the project will ship as an architecture-optimized binary (for local dev) or WebAssembly (for browser dev).
In the process, we're being careful and empathetic about the incremental upgrade paths and ecosystem compatibility, so we're shipping a number of packages that'll completely disappear in the future.
You'll see us drop a ton of deps and weight in the short term. Watch this space. Thanks for your feedback, I'm on the same page.
In the process, we're being careful and empathetic about the incremental upgrade paths and ecosystem compatibility, so we're shipping a number of packages that'll completely disappear in the future.
You'll see us drop a ton of deps and weight in the short term. Watch this space. Thanks for your feedback, I'm on the same page.
> A huge bet we're placing on our Rust compiler is that we'll control the supply chain much more tightly.
This is great to hear, thanks for responding. I'm looking forward to seeing the Next.js dependency story improve in the future as you are able to complete that migration to swc. And hopefully Vercel's leadership in this space also encourages similar improvements in the broader node and react ecosystems.
This is great to hear, thanks for responding. I'm looking forward to seeing the Next.js dependency story improve in the future as you are able to complete that migration to swc. And hopefully Vercel's leadership in this space also encourages similar improvements in the broader node and react ecosystems.
How do you review a WebAssembly binary? Are builds reproducible? I just found this about Rust: https://github.com/rust-lang/rust/labels/A-reproducibility
It would be nice to be able to run them on multiple CIs and compare the SHAs.
It would be nice to be able to run them on multiple CIs and compare the SHAs.
Keeping in mind that these are generally build-time/server-side dependencies, not client-side dependencies, so size-on-disk isn't a very relevant metric
Have you ran it in production install mode, because my app dockerfile (using alpine base) isn't even that big total.
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.
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.
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.
> I wonder why they don't replace these simple packages like `is-string` with Lodash...
As someone who maintains a few dozen packages (public and otherwise), lodash has wasted more of my time than any other - due to its frequent security issues. It was almost always lodash, and I would have to update a dozen packages everytime.
Things may have improved; I no longer use lodash anywhere.
As someone who maintains a few dozen packages (public and otherwise), lodash has wasted more of my time than any other - due to its frequent security issues. It was almost always lodash, and I would have to update a dozen packages everytime.
Things may have improved; I no longer use lodash anywhere.
Also tree shaking out the stuff you don’t need has never worked better. It’s pretty trivial with lodash.
That kind of undisciplined rot is unfortunately widely accepted in the Javascript community.
[deleted]
Congrats! This is a very exciting release!
>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.
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.
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.
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.
I actually upgraded my team's Jest config to use https://github.com/Brooooooklyn/swc-node a few weeks ago. However, our Jenkins CI agents run RHEL7, and neither of the Linux binary targets would run. The `x64-gnu` binary needed a `GLIBC_2_23` symbol when only 2.18 was available, and the `x64-musl` binary had no `musl-libc` on the machine. I don't own the Jenkins agents, so I couldn't install other deps myself.
I ended up building `musl-libc` from source on another RHEL7 agent, committed the `.so` to our repo, and added that to the `LD_LIBRARY_PATH` in our Jenkinsfile, and actually got that working.
I did see some mentions that Rust could build to target an older GLibc ( https://kobzol.github.io/rust/ci/2021/05/07/building-rust-bi... ), so I'm curious if Next is going to use copies of SWC built that way for better compat or if it will require more workarounds on my part.
I can definitely see shipping a WASM version as a great workaround to those sorts of compat issues.
I ended up building `musl-libc` from source on another RHEL7 agent, committed the `.so` to our repo, and added that to the `LD_LIBRARY_PATH` in our Jenkinsfile, and actually got that working.
I did see some mentions that Rust could build to target an older GLibc ( https://kobzol.github.io/rust/ci/2021/05/07/building-rust-bi... ), so I'm curious if Next is going to use copies of SWC built that way for better compat or if it will require more workarounds on my part.
I can definitely see shipping a WASM version as a great workaround to those sorts of compat issues.
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.
SWC uses napi-rs to talk to N-API. NAPI-RS's convention is to ship binaries as npm packages which should avoid a lot of the pain which came from having to download pre-compiled files from a file server. Compiling other platforms shouldn't be necessary, but if it is it will be slightly more difficult than using traditional gyp or cmake. You would have to setup a Rust toolchain, but after thats its relatively easy.
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.
I was hoping for hosted postgreSQL database support as part of Next deployment.
Vercel does come with a Supabase integration:
https://vercel.com/integrations/supabase
And from my limited understanding, Supabase is psql with extras.
And from my limited understanding, Supabase is psql with extras.
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.
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.
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.
I tried supabase and went with another solution because it didn't have a good dev/stage/prod system
Supabase developer here. We’d love your input on what you’d like to see for dev / staging / production. Please let us know what you’re looking for or the model you’re interested in.
I keep going back to your page. Very interested but lack the time and energy to build anything right now.
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.
It does seem a bit complex though, perhaps something you would use on large projects only.
Select your enlightened HN comment from below options
JS bad; SPA bad; React bad; Next bad
JS bad; SPA bad; React bad; Next bad
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?
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
> 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
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
It's part of why I suggested this issue:
https://github.com/vercel/next.js/issues/26827
Thanks for the feedback. I’ll bring this to the team
I've done at least 20 upgrades (user since next 1.0) and it is getting easier and easier to migrate.
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.
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.
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
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.
The production quality for both this and Jamstack Conf a couple weeks ago are very high. I really dig the retro graphics and music!
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
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
> you get a Babel like plug-in ecosystem for AST transformations and such
This is trivial to do with esbuild, for what it's worth.
This is trivial to do with esbuild, for what it's worth.
ESBuild does not support any AST transforms directly
You can add it, via plugins, but its a serious limitation for a project like Next.js which require's these types of transforms
You also end up with diminishing returns with the more plugins in you add to esbuild, and I imagine its worse with js plugins than it is with go based ones, none the less, you have zero access to it directly
You can add it, via plugins, but its a serious limitation for a project like Next.js which require's these types of transforms
You also end up with diminishing returns with the more plugins in you add to esbuild, and I imagine its worse with js plugins than it is with go based ones, none the less, you have zero access to it directly
I never said it supports AST transformations directly. I just said they were trivial to do with esbuild.
Our build times remain at 0.5s with pretty extensive source transformers in JavaScript plugins in esbuild. This is down from 5-8 minutes using rollup.
Our build times remain at 0.5s with pretty extensive source transformers in JavaScript plugins in esbuild. This is down from 5-8 minutes using rollup.
I'd need a lot more context to understand what you mean by "trivial" and "extensive", respectfully
It is trivial to write extensions for esbuild. We've written extensive plugins to perform ast transformations that all run, collectively, in under 0.5 seconds.
Make a plugin, add acorn and escodegen. It isn't difficult.
I don't see what is difficult to understand.
Make a plugin, add acorn and escodegen. It isn't difficult.
I don't see what is difficult to understand.
Sorry, "SFC" and "SWC"?
SWC, a typescript/js compiler: https://swc.rs/
SFC, single file components.
SFC, single file components.
man... web technologies are not getting simpler are they lol. it just keeps gaining more layers and layers
At least it isn’t SWF…
Showing my age here, but IIRC, that was the file extension used by Flash files?
Correct. Flash “source” files (used by Macromedia Flash and then Adobe Flash) were binary .fla files that were impossible to manage with source-control. The .swf files (from the original name: Shockwave Flash) were the “compiled” output from Flash’s .fla source files. Flash’s dialect of JavaScript (ActionScript) from .fla files (and later .as files) were compiled to a compact bytecode format, along with compact binary representations of Flash’s own vector art files, animation paths, and optimised JPEG and PNG images (IIRC Flash supported alpha channels in JPEG long before official support was added to JFIF).
SWF is a very clever and optimised format - it’s amazing what they fit into the minuscule Flash runtime of yesteryear when it was only around 300KB in size IIRC. It’s a shame there *still* isn’t an approachable replacement tool for non-experts for making cartoon-style animations and groundbreaking interactive games in HTML+JS yet (e.g. Fault-Line: http://www.nitrome.com/games/faultline/ )
SWF is a very clever and optimised format - it’s amazing what they fit into the minuscule Flash runtime of yesteryear when it was only around 300KB in size IIRC. It’s a shame there *still* isn’t an approachable replacement tool for non-experts for making cartoon-style animations and groundbreaking interactive games in HTML+JS yet (e.g. Fault-Line: http://www.nitrome.com/games/faultline/ )
How many extent build-systems are there now for JS/TS? It's getting insane.
Realistically?
Just Babel, SWC, ESBuild, and TypeScript's own compiler.
I'm not really aware of anything else with serious momentum, or isn't simply built upon one of these projects,
SWC itself if I recall correctly was built to address speed problems with Babel
The other speed bottleneck I've found is postcss, which SWC is also trying to address with their own new CSS parser, which is the CSS parser they extended in Next.js 12, from what I can tell
ESBuild has also grown out of this, but takes a more opinionated direction
This isn't the gulp / grunt -> browserify -> webpack / rollup churn of the past in my opinion. These kinds of tools are much more targeting on being around in the long haul
Just Babel, SWC, ESBuild, and TypeScript's own compiler.
I'm not really aware of anything else with serious momentum, or isn't simply built upon one of these projects,
SWC itself if I recall correctly was built to address speed problems with Babel
The other speed bottleneck I've found is postcss, which SWC is also trying to address with their own new CSS parser, which is the CSS parser they extended in Next.js 12, from what I can tell
ESBuild has also grown out of this, but takes a more opinionated direction
This isn't the gulp / grunt -> browserify -> webpack / rollup churn of the past in my opinion. These kinds of tools are much more targeting on being around in the long haul
There's an interesting-looking build tool called Bun. Not sure if it's actually released yet, but the development tweets by the author look very promising:
https://twitter.com/jarredsumner/status/1390084458724741121
> Early benchmark from a new JavaScript bundler. It transpiles JSX files: > - 3x faster than esbuild > - 94x faster than swc > - 197x faster than babel
https://twitter.com/jarredsumner/status/1390084458724741121
> Early benchmark from a new JavaScript bundler. It transpiles JSX files: > - 3x faster than esbuild > - 94x faster than swc > - 197x faster than babel
Rome might join the list, but it's too early to tell
> I love Vue, but it’s forever married to the Babel parser
That's not true... I use Vue's SFC without Babel using vite.
That's not true... I use Vue's SFC without Babel using vite.
`@vue/compiler-sfc` which powers the vite Vue 3 SFC plugin (`@vitejs/vue`) has a dependency on the `@babel/parser` package[0]
That's the dependency I am speaking to here
[0]: https://github.com/vuejs/vue-next/blob/master/packages/compi...
That's the dependency I am speaking to here
[0]: https://github.com/vuejs/vue-next/blob/master/packages/compi...
I was not aware of this, thank you.
Next.js still uses webpack. They basically replaced Babel with SWC.
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
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
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.
IMO React is also an amazing abstraction and I like writing components better than stitching together HTML or other template/DSL based systems.
Symphony itself brought quite a few concepts from Rails to the PHP community. You can call the flow of ideas across communities "reinvention" but I think it's super healthy.
The web platform has had been an oddity in asking you to entirely switch languages when moving between backend development and frontend development. I think one of the most appealing pieces of these Javascript frameworks is that you can build everything in one common language. (You can—but don't have to.)
Fine-grained developer control of when data is fetched, when components are rendered, how they are rendered, and where they are rendered (server vs client) becomes a really welcome advancement.
The web platform has had been an oddity in asking you to entirely switch languages when moving between backend development and frontend development. I think one of the most appealing pieces of these Javascript frameworks is that you can build everything in one common language. (You can—but don't have to.)
Fine-grained developer control of when data is fetched, when components are rendered, how they are rendered, and where they are rendered (server vs client) becomes a really welcome advancement.
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.
If building a vercel for PHP was such an obvious idea, I imagine someone would jump on it.
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 ?
Fun fact, you can actually write PHP function on Vercel :)
https://github.com/juicyfx/vercel-php
https://github.com/juicyfx/vercel-php
Laravel Forge does exactly this and does it beautifully
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.
Anything that speeds things up and gives us more control is great though.
Shameless plug: 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).
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?
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.
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?