211–220 of 293 posts
Do you see getServerSideProps and getStaticProps going away in the next release or two ?
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…
If folks are interested in working on something like this, my email address is in my profile. Don't hesitate to reach out.
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…
We are finding that Next.js + Nest.JS to be a really strong combo so far.
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…
https://supabase.io has: - Postgres DB (+ admin panel + realtime sync + search + workflows) - Auth - Storage - Functions (beta) (disclosure: am small angel investor) its interesting that you consider workflows a "standard cloud primitive". what do you currently use? (i work on a workflow engine myself)
It allows you to define task queues or scheduled jobs, and if you're already running Postgres you don't have to host any other infrastructure!
Earlier quoted context omitted.
I think one of the biggest issues with node-sass was that it only supported a narrow set of node versions and platforms, which resulted in a lot more compilation from source. I definitely remember fighting with node-gyp and such, and pretty quickly ditched it for dart sass as soon as that was a viable alternative. Next.js looks like it's shipping binaries for swc for a wide Node range (>=10), on a pretty comprehensiv…
I actually upgraded my team's Jest config to use https://github.com/Brooooooklyn/swc-node a few weeks ago. However, our Jenkins CI agents run RHEL7, and neither of the Linux binary targets would run. The `x64-gnu` binary needed a `GLIBC_2_23` symbol when only 2.18 was available, and the `x64-musl` binary had no `musl-libc` on the machine. I don't own the Jenkins agents, so I couldn't install other deps myself. I ende…
Looks like the highest version of `GLIBC` is 2.18, so I think you'll be fine!
Earlier quoted context omitted.
> you get a Babel like plug-in ecosystem for AST transformations and such This is trivial to do with esbuild, for what it's worth.
ESBuild does not support any AST transforms directly You can add it, via plugins, but its a serious limitation for a project like Next.js which require's these types of transforms You also end up with diminishing returns with the more plugins in you add to esbuild, and I imagine its worse with js plugins than it is with go based ones, none the less, you have zero access to it directly
Our build times remain at 0.5s with pretty extensive source transformers in JavaScript plugins in esbuild. This is down from 5-8 minutes using rollup.
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 downvote - it definitely is crazy complex, or at least intimidating for anyone from the 'before times' of Rails (myself included). Everything is taken over by engineers and so is now over-engineered and feels totally geared towards developers developers developers and a weird obsession with performance. And all the new features including server side rendering give me whiplash
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…
> At the end of the day, web backends are just a lot more varied and complex than web frontends. > No, they aren't. On the technical side, a web frontend is always just bundles of JS, HTML, CSS, that have to be transmitted to the client. First, that's factually untrue; web front-ends can contain a wide array of things beyond those three (WASM, content in formats other than HTML that is read and used by the JS/WASM, e…
I did not mean to imply that all, or even most backends are more complex than frontends -- only that the problem space of backends is larger and more varied (for typical web use these days, at least.)
Earlier quoted context omitted.
I think because the answer here is using Next.js with hosted backend solutions like Firebase, Supabase, Pusher, etc.
The reason I love Next.js + Vercel though is because I don't need anything else for the frontend (besides a CMS maybe). If I have to use: 1) Pusher for realtime 2) Supabase for DB 3) Temporal for workflows 4) Vercel / Netlify, etc. for functions / cron jobs My backend becomes primarily a bunch of stuff glued together, rather than something cohesive like Next.js
I'd do the exact opposite by default, trying to have the most cohesive service, and occasionnaly use some external APIs when I can't do the stuff by myself (eg. Stripe)
The big innovation here seems to be https://swc.rs/ 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. Looking forward to see where else this gets adopted and it's stability.
How does it compare to esbuild? Seems they both want to achieve exactly the same thing, but somehow it's two different efforts.