Earlier quoted context omitted.
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.
> 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 pos…
Next.js 12
41–50 of 293 posts
Re: Next.js 12
#42With server component, i really think next.js hybrid app with cordova will achieve high performance even better than native app (like react-native).
Re: Next.js 12
#43Re: Next.js 12
#44I like that they have finally provided a fast Webpack alternative.
Re: Next.js 12
#45I like that they have finally provided a fast Webpack alternative.
Re: Next.js 12
#46Earlier quoted context omitted.
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.
Deno is using the same compiler (SWC) so there is data point number two on the question. esbuild is another...
Re: Next.js 12
#47The 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.bleepingco…
Re: Next.js 12
#48I 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?
Re: Next.js 12
#49I 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...
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.
Re: Next.js 12
#50The 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.bleepingco…
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.