Live data from Hacker News

Next.js 12

nextjs.org

41–50 of 293 posts

Re: Next.js 12

#41

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…

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.

Re: Next.js 12

#42

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

Re: Next.js 12

#44

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.

Re: Next.js 12

#46

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

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

Re: Next.js 12

#47

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

Have you ran it in production install mode, because my app dockerfile (using alpine base) isn't even that big total.

Re: Next.js 12

#48
If Next.js + Vercel is the leader of the production-ready frontend-as-a-service space, why hasn't a similar leader emerged in the backend-as-a-service space?

I would love a clean Vercel-like abstraction on top of standard cloud primitives (functions, queues, events, workflows, etc.) with everything wired up nicely and focused on developer experience. It just seems like AWS is so configuration heavy that it is ripe for a Vercel-for-backend to emerge.

Does anyone know of an existing open source framework + hosted cloud platform that is a one-stop-shop for writing a production-ready backend in the vein of Next.js + Vercel?

Re: Next.js 12

#49
post #18

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

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.

Re: Next.js 12

#50

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

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.

Post reply on HN