The big innovation here seems to be <a href="https://swc.rs/" rel="nofollow">https://swc.rs/</a><p>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.<p>Looking forward to see where else this gets adopted and it's stability.
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?<p>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.<p>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?
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 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?
Nice, a completely new attack-vector: <a href="https://nextjs.org/blog/next-12#url-imports" rel="nofollow">https://nextjs.org/blog/next-12#url-imports</a> Documentation still not there, so can't check if they actually compare any checksums or anything.<p>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.<p>Finally it's fun to see it ending with:<p>> We set out to build a zero-configuration React framework that simplifies your developer experience.<p>And if you read the beginning, you'd see:<p>> Middleware enables you to use code over configuration<p>I guess replacing configuration with code is one way of achieving "zero-configuration".<p>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.
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!<p>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)<p>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.<p>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<p>Maybe JSX tools just needs some re thinking to get the same SFC experience
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].<p>[0]: <a href="https://www.bleepingcomputer.com/news/security/52-percent-of-all-javascript-npm-packages-could-have-been-hacked-via-weak-credentials/" rel="nofollow">https://www.bleepingcomputer.com/news/security/52-percent-of...</a>
[1]: <a href="https://news.ycombinator.com/item?id=28962168" rel="nofollow">https://news.ycombinator.com/item?id=28962168</a>
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.<p>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...
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 !<p>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 ?<p>[0] <a href="https://symfony.com/doc/current/index.html" rel="nofollow">https://symfony.com/doc/current/index.html</a>
>Compilation using Rust is 17x faster than Babel and enabled by default using Next.js 12, replacing transforming JavaScript and TypeScript files.<p>I've never, ever felt constrained by Babel performance. Even in massive 100k+ LOC codebases. I <i>have</i>, 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.<p>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.
Shameless plug: <a href="https://vite-plugin-ssr.com" rel="nofollow">https://vite-plugin-ssr.com</a> a do-one-thing-do-it-well alternative to Next.js which is feature-complete & stable (no breaking changes in the foreseeable future).
><i>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.</i><p>Do you see getServerSideProps and getStaticProps going away in the next release or two ?
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.<p>Anything that speeds things up and gives us more control is great though.
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?
This is nice as a more opinionated version of create-react-app. helps solve some of the problem with the fragmented react ecosystem.<p>It does seem a bit complex though, perhaps something you would use on large projects only.