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