Next.js 12
nextjs.org
nextjs.org
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.
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...
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).
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...
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.
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?
And Vercel itself allows you to install backend services such as Redis caching, databases, or queues that you can pull in from those functions.
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.
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.
/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.
Vercel itself I believe runs on a combination of Google Cloud and AWS.
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
This feels like a weird criticism considering Next is React only.
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!
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
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
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)
- 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)
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).
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
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!
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 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 ;^)
.. oh, and keep up the good work. I really do love the product!
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..
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.
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.
> 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.
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 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.
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
If folks are interested in working on something like this, my email address is in my profile. Don't hesitate to reach out.
- 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!
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 :)
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.
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.
Deno is using the same compiler (SWC) so there is data point number two on the question. esbuild is another...
Vercel just has first class support where everything just works, but can you host it yourself.
* https://github.com/vercel/next.js/discussions/11552#discussi...
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?
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.
I understand that the Next philosophy is very monolithic but so far I’m having trouble getting it to play nice with build tooling.
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!
Vercel doesn't have 4 regions, we have 17 :)
$ 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?
> 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.
[1]: https://nextjs.org/docs/advanced-features/react-18#react-ser...
https://github.com/vercel/next-rsc-demo/tree/main/components
It’s very similar to what Astro is doing. Only adding the JS if it’s actually necessary.
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/...
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).
“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
And all the new features including server side rendering give me whiplash
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.
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.
Meanwhile everyone is also trying to have a decoupled infrastructure and going with microservices. It's an endless loop I guess.
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.
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.
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.
> 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.
It's part of why I suggested this issue:
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.
> 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.
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.
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"
They took all the ease of the old PHP approach and made it better.
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.
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...
Aren't they just taking a feather out of Golang's hat?
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.
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.
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!
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
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/ )
SFC, single file components.
That's not true... I use Vue's SFC without Babel using vite.
That's the dependency I am speaking to here
[0]: https://github.com/vuejs/vue-next/blob/master/packages/compi...
This is trivial to do with esbuild, for what it's worth.
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
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.
Make a plugin, add acorn and escodegen. It isn't difficult.
I don't see what is difficult to understand.
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
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
[0]: https://www.bleepingcomputer.com/news/security/52-percent-of... [1]: https://news.ycombinator.com/item?id=28962168
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.
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.
They are speaking of the potential bugs and security vulnerabilities all that code might/probably has, given track records.
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.
It would be nice to be able to run them on multiple CIs and compare the SHAs.
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.
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...
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.
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.
> 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.
There are solutions available to all of these problems today. You can pick the ones which you prefer or fit your workflow.
* like Gatsby Cloud https://www.gatsbyjs.com/products/cloud/
> 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
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:
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 ?
If building a vercel for PHP was such an obvious idea, I imagine someone would jump on it.
IMO React is also an amazing abstraction and I like writing components better than stitching together HTML or other template/DSL based systems.
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'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.
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 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.
Looks like the highest version of `GLIBC` is 2.18, so I think you'll be fine!
Already added a story to investigate the upgrade from Next 11 to 12.
Do you see getServerSideProps and getStaticProps going away in the next release or two ?
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
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 :)
And from my limited understanding, Supabase is psql with extras.
Anything that speeds things up and gives us more control is great though.
Next offers using React as your templating language as well as adding in server side code if you want instead of static site generation.
JS bad; SPA bad; React bad; Next bad
It does seem a bit complex though, perhaps something you would use on large projects only.