Live data from Hacker News

Next.js 12

nextjs.org

201–210 of 293 posts

Re: Next.js 12

#201
post #122

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.

No I had the exact same thought. Are we just re-inventing simple server side templating but with incredible new levels of complexity and obfuscation?

Re: Next.js 12

#202
post #199

Earlier quoted context omitted.

1. I'm not sure about this premise: "leader of the production-ready frontend-as-a-service space." They def seem like a good fit for some frontends -- but they're certainly not a good fit for ALL frontends generally. (For example, sufficiently small sites should probably just go with static hosting, and sufficiently dynamic web apps still will want a SPA.) 2. At the end of the day, web backends are just a lot more var…

This is a really strong argument. At the end of the day I think it is possible (with iteration) to get the level of abstraction correct for something approaching some semblance of the universality you refer to. 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…

Check out Amplify! I've heard good things and my limited experience is good so far. (Although running locally isn't the best, unfortunately... but that's always going to be an issue the more you lean on a cloud services.) Deployments are easy. In terms of scalability, it's all massively scalable AWS services under the hood, and it seems relatively easy to "eject" if you ever need to.

Re: Next.js 12

#203

Earlier quoted context omitted.

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 c…

This argument doesn't really make sense. > 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 a…

When I said hard, I didn't mean technically. I meant it's hard for Next.js to decide how to solve the problem so it works for everyone. I'm doubtful if it even makes sense for them to try to support every possible use case.

There are solutions available to all of these problems today. You can pick the ones which you prefer or fit your workflow.

Re: Next.js 12

#204

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! 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, muc…

Next.js still uses webpack. They basically replaced Babel with SWC.

Re: Next.js 12

#205

Earlier quoted context omitted.

Just use Gatsby v4 if you want good image support! v4 brings Gatsby in-line with Next.js because it introduced runtime SSR support like Next.

I assume that Gatsby generates the different widths/formats at build time. How well does that scale? Like if you have a thousand images, what's the build time like?

We have a job framework that can distribute image processing jobs on supported platforms* as well as automatically caching subsequent jobs. So it scales easily and as most builds don't have that many image changes (if any), the impact on warm builds is negligible.

* like Gatsby Cloud https://www.gatsbyjs.com/products/cloud/

Re: Next.js 12

#207
post #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 fo…

What about Firebase? It’s not open-source I know, but it brings tremendous primitives to backend (cloud functions, database, queues (with Google Cloud Tasks), etc.)

Re: Next.js 12

#208
post #122

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.

Eh. Perhaps you're looking through rose colored glasses on the days of Rails dominance? I've worked at multiple companies using Rails and not one was simple. Especially when you have 100+ engineers working on different aspects of a massive product. Anecdotal but Rails has a ton of magic to make things work but its only simple if you're product is a super basic CRUD app

Re: Next.js 12

#209
post #31

Earlier quoted context omitted.

How does it compare to esbuild? Seems they both want to achieve exactly the same thing, but somehow it's two different efforts.

One thing to keep in mind is that SWC is a compiler, whereas esbuild is a bundler. SWC has limited bundling capabilities last time I checked, so if you're looking for something to traverse your code and generate a single file (or multiple files at dynamic import boundaries, etc.) esbuild is what you want. Next.js bundles with webpack, so it uses SWC in lieu of Babel (or the TypeScript Compiler).

If you want a bundler built using SWC as a base today, check out Parcel: https://parceljs.org

Re: Next.js 12

#210
post #79

Earlier quoted context omitted.

Tried a couple shots at it 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

This appears to be a framework and not a hosted backend service

We tried https://m3o.dev. It was a pretty hard thing to do with limited resources. Some sort of backend hosting will make its way back in soon.
Post reply on HN