7 ms·

Why I'm using Next.js

27 points by serial_dev 3y ago

the_gipsy 3y ago
> Because I work at vercel, and because we can monetize frontend with this server-side thing.
- lwhi 3y ago
  But you don't need to use Vercel?
  - the_mitsuhiko 3y ago
    Next’s support outside of Vercel is best effort it seems. Which is fine as Vercel funds it, but it feels like there is a conflict of interest. There is after all a reason for OpenNext’s existence.
    - lwhi 3y ago
      I definitely agree there can be a conflict of interest, but I also think it's very possible to self host.
    - Tehnix 3y ago
      I really don’t understand this sentiment, it is extremely easy to build and deploy Next.js yourself?? You either: - Build static files and host it like any other framework (e.g. throw it in an S3 bucket)[0] - Or, run a Node.js server Where’s the Vercel exclusive part there? [0] Here’s me doing exactly that, going through the same steps I would for literally any Frontend framework, including the WASM alternative I also build in the post (exact same deployment) https://codetalk.io/posts/2023-10-16-the-stack-part-3.html#next.js https://codetalk.io/posts/2023-10-16-the-stack-part-3.html#n...
      - lwhi 3y ago
        Exactly, I thought I was missing something.
      - poisonborz 3y ago
        Well that's the problem, you will not see the glass wall until too late. For my case, that you can add API middleware, but you can't run any "not edge compatible" code because of Vercel reasons.
      - ervine 3y ago
        It's easy but there are decisions made that hamstring you - like being unable to change cache-control headers in the next.config.js or middleware or have your middleware use node APIs, which is especially stupid because when self-hosting... it's running in node! They are optimizing for deploying to the edge, which when self hosting you don't need to. So whether malicious or not, their guard rails conveniently make it frustrating to self host once you need to do anything outside of their garden.
        leerob 3y ago
        Middleware works when self hosting. It's runtime is a subset of Node.js, since it's potentially running in front of every request in your application. We're still evaluating options here: https://github.com/vercel/next.js/discussions/46722#discussioncomment-6709529 https://github.com/vercel/next.js/discussions/46722#discussi...
        ervine 3y ago
        I never claimed middleware doesn't work when self hosting. I claimed that it's not as useful as it could be, because your company has prioritized edge deployments over supporting self-hosting. As someone in that discussion rightfully says: "We are grown-ups with access to the same tracing and profiling tools as you. There is nothing dangerous about us using Node.js as far as I’m concerned." Additionally, your comment just reeks of PR to me. I don't know if you do it on purpose or what, but to read my comment and then come back with "Middleware works when self hosting"... it has to be intentional on your part to misunderstand my comment that badly.
        verdverm 3y ago
        We put nginx in front to manage the cache headers. My biggest gripe is that they made design decisions that are optimized for their paid products, at the expense of the open source. Middleware is the main example, because it has to run on their edge.platform, it has no routing association. For all the magic they do, they dropped the ball here, making you use regex to decide of middleware should be applied. All this because users were getting hit with surprise bills, which is.really a product of who they architected and charged, not a technical issue
      - jitl 3y ago
        I helped stand up Notion’s marketing site (https://notion.so/product https://notion.so/product) on NextJS. It’s really annoying / impossible to implement all the fancy caching, incremental revalidation, etc if you need to run more than one instance to serve the load you get. Or you need a horrendously complex AWS buzzword graph that will kinda sorta do the things. We switched from AWS ECS deployment to Vercel after tiring of figuring out how to support Next features that require very tight cooperation from CDN/distributed cache magicks. The total product is good, the web presence team is happy with Next and Vercel, I’m liking RSC and server actions, but I wanted to share my experience that beyond modest scale running Next yourself needs a lot of effort.
        ushakov 3y ago
        Curious whether you considered any other frameworks?
        jitl 3y ago
        Site predates Astro, Remix, etc. There was some interest in Gatsby but I said no (seems horribly over engineered, adds GraphQL for no good reason, like storybook promises a lot but seems to leave the team doing extreme amount of npm upgrade work). I think Next was the clear winner, we knew what we were getting into with hosting it to some degree and it was still worth because of how well it fits the team.
        satvikpendem 3y ago
        > We switched from AWS ECS deployment to Vercel after tiring of figuring out how to support Next features that require very tight cooperation from CDN/distributed cache magicks. I guess that's how they get you, by making it onerous to self host and instead offering a clean yet more expensive solution.
  - meiraleal 3y ago
    Nobody need? They took over React tho.
- deleted 3y ago
  [deleted]
buf 3y ago
Pretty sure you use it because vercel likes the frontend engineers who don't know how/or care to deal with the backend.
- leerob 3y ago
  There's a lot of misunderstanding of what "frontend" and "backend" are: https://www.industrialempathy.com/posts/frontend-backend/ https://www.industrialempathy.com/posts/frontend-backend/
  - hu3 3y ago
    Perhaps with desktop apps or low level systems it can get confusing but for traditional web the definition is usually: If it runs in the browser, it's frontend. Server? Backend. There's SSR but the name itself clarifies: Server Side Rendering.
- van_de_builder 3y ago
  Yes. Learned this really quickly. I want to leverage Next.js but not Vercel (if I don't have to). I have experience with backend and devops, so I care about and want to deal with the backend myself (cost-savings, control, decoupling). The sentiment and complaints seem to sum up to, "if you're using Next.js, you basically [or eventually] have to use Vercel." But I do not want this to be true. That said, I also don't want to sacrifice benefits of Next.js or have to "fix" things constantly or unnecessarily.
pjmlp 3y ago
I use it, because SaaS vendors like Sitecore and many others, have agreements with Vercel to push it as the main SDK. While other SPA frameworks are supported, they are a kind of second line, without all the bells and whistles that Next.js users are given to enjoy.
colesantiago 3y ago
Because you work there, no need for this blog post. This is more of an ad than anything.
- lwhi 3y ago
  Why is it problematic to address criticism?
  - colesantiago 3y ago
    Because he is paid to address criticism of Vercel since he works there? It reads that Vercel told him to do this because he works there rather than him responding on his own accord. I don't see a 'DISCLAIMER: I WORK AT VERCEL' at the top on here, so I assume this reads like an ad.
    - lwhi 3y ago
      The original article was written by a guy who had a founding responsibility for a rival framework. Pot, kettle?
      - colesantiago 3y ago
        So both read like ads then. What is your point? Why are you rushing on every comment critical of vercel?, I'm assuming you also work for them or you have been sponsored or taken money by them in their marketing department. Judging from their latest release of Next.js, nothing has really changed or been done (except v0 which is cool which is besides the point from Next). But the fact that I don't see an explicit disclaimer here and the framework is overhyped, I see this as an ad. https://nextjs.org/blog/next-14 https://nextjs.org/blog/next-14
        lwhi 3y ago
        [flagged]
        Capricorn2481 3y ago
hnreport 3y ago
I never need to write separate backends for projects I want to create. I can build my entire project with Next.js. How have all these other developers been managing this whole time without Next?
- 3c6bYDXLMj 3y ago
  They were working as part of a team? Or they are simply too young.
plugin-baby 3y ago
My experience with NextJS has been very frustrating. - it adds a layer of opacity between the front and backends (or as they are in Next: the frontend, the frontend backend and the backend backend). - front end code can run in the frontend backend and consequently needs a lot of extra guards. - front end stack traces are almost completely useless in dev mode. If you’re lucky, they will include the file name where the issue occurred, but often in these cases the line number will point to an empty line. I think the common thread here is that Next has a lot of surprises, especially when not on the happy path. It frequently breaks my intuition about how the web works. I’m strongly considering migrating our Next projects to React.
Tehnix 3y ago
There’s a two simple reasons I would go for Next.js - It’s React-based: Almost everyone knows how to do React these days - It allows me to build and serve chunked static files, instead of just a single static files like classic SPA The last part is the main reason for that over other React-based frameworks. While SSR is hot these days, I’m firmly in the camp of “less servers I need to operate is better” and almost have “needs to be servable via S3+CloudFront” as a hard requirement for Frontend stacks.
- leerob 3y ago
  Yeah, a large number of Next.js apps use the static export functionality and host on S3: https://nextjs.org/docs/app/building-your-application/deploying/static-exports https://nextjs.org/docs/app/building-your-application/deploy...
robertjpayne 3y ago
> If you're new here, I'm Lee. I work on Next.js. I've also made some courses about using Next.js before I joined Vercel. This alone should be further up the post…
- lwhi 3y ago
  Why?
  - shmde 3y ago
    What why ? The term that you work for Vercel should be at the top so that people realise this isnt a neutral 3rd party but a company paid spokesperson.
    - lwhi 3y ago
      [flagged]
      - hu3 3y ago
        It's good practice to introduce strong biases at the top of articles so readers can take that into consideration right away. The article they are responding to did precisely that on their second paragraph: > I’ve been using Remix since it was first released in 2020. I loved it so much I joined the team for 10 months to help get the community going and now I recommend and teach Remix on EpicWeb.dev. [1] [1] https://www.epicweb.dev/why-i-wont-use-nextjs https://www.epicweb.dev/why-i-wont-use-nextjs
        lwhi 3y ago
        He _does_ introduce the fact at the top of the article! This feels very much like a targeted attack.
- 3c6bYDXLMj 3y ago
  Yep. Essentially a DevRel post.
lucasmerlin 3y ago
We've been having a lot of problems with weird bugs with nextjs, so I can't really recommend it. Feels like it's a eternal beta. First, we've had a problem with nextjs not caching the response code for 404 pages, so 404 pages would have a 200 status code. Now they've fixed this they have a bug where they are caching the 304 response code, responding with 304 to every request and completely breaking the site. This has been open for a month now and has affected a lot of people but it seems like Vercel just doesn't care. https://github.com/vercel/next.js/issues/56018 https://github.com/vercel/next.js/issues/56018
- lwhi 3y ago
  This is my big problem with proprietary software; and why open source pragmatically makes more sense. Fixing bugs is down to priority and incentives of the parent company.
  - lucasmerlin 3y ago
    I mean it is open source and someone even made a PR to fix the bug in question and I guess I could use their fork until it's fixed.
    - lwhi 3y ago
      Hmm, doesn't seem as much of an issue now.
    - chasd00 3y ago
      I was about to say, just fox the bug submit a pull request and use your fork until it’s merged. Isn’t that the point of all these fancy source control tools?
- ervine 3y ago
  Yep their github management is atrocious. I understand it's a popular product so you get a lot of low quality issues opened, but there tons of real problems where no developer ever appears, and then are closed by the bot because of inactivity. Infuriating. The longer I do this, the more that issue management responsiveness becomes a real consideration when choosing a dependency.
throwaway77384 3y ago
Next.js is such an odd experience. On the one hand, I've built three apps in Next.js, a business directory on Vercel with a separate (Firebase) DB, a blog (Cloudflare, Next on Pages) which pulls from an API and a little calendar management app (Vercel), which also only pulls from an API. The speed at which I could get something up and running was astounding. Before Vercel I tried Google's Firebase hosting, which was so hilariously bad that I switched to Vercel, where everything just worked. You'd expect that from the makers of the thing. However, I was wary of vendor lock-in. When Vercel decides to arbitrarily break something you relied on, you are at their mercy to figure out when your app will run again. And this is where things get hairy. The Next.js documentation is sparse. So you either get lucky and someone else has done the guesswork to figure out how to do the most basic things in Next.js (for example the transition from 12 to 13, aka pages-router to app router was ROUGH...you could only find SO issues related to 12 and all the libraries and structures you were used to had all changed in subtle ways). Caching is another one of these things. There are fetch calls in some routes in my app that get cached no matter what. I've tried every which way to get the damn thing to stop them caching (the most obvious one being the no-store header), but to no avail. It caches and I can only get it to stop by redeploying. And no, purging cache from the Vercel dashboard doesn't fix it either. Only a redeploy will get me updated data from the DB. It's bizarre. And so the story goes on. It's super easy to get up and running. There are many 'aha' moments, where you can see that a ton of work has gone into DX. So much so, that I really try to use Next.js where I can. However, when you run into problems, they are usually more difficult to solve than with React. And they are subtle and not infrequent. Don't get me started on debugging. Since Next.js is sort of 'backend' to a large degree (which, in Google's and Cloudflare Page's case means edge-functions), trying to tease a meaningful log that isn't severely character-limited out of either service is very difficult. Error messages in the frontend are useless to an astounding degree. So, it seems there's a lot of work to be done. Tread carefully, as it's very enticing to have this quick-start, but I'd hesitate to use this for anything too serious, as things will break for no reason and there will be issues that are nearly impossible to solve and I wouldn't want clients emailing me while I'm dealing with BS I simply wouldn't have had on any other stack.
- CafeRacer 3y ago
  > Only a redeploy will get me updated data from the DB. This caching thing, when it wad released, is one of the sneakiest bastards ever. I had to add a random string to a query of each request to avoid caching on the management panel. It happened that because of the cache, one client was able to see the cached data for another client. We have had 4 FE on next and now gradually moving to remix and away from vercel.
lovetocode 3y ago
Is anyone just using vanilla React with no TypeScript or Framework of any kind? I’ve tried Remix and Next js and just find them so cumbersome. Typescript causes me more headaches
- mplewis 3y ago
  After using TypeScript, I’m never going back to vanilla JavaScript if I can help it.
  - lovetocode 3y ago
    That’s great to hear! Did you find it hard to learn?
  - firejake308 3y ago
    Yeah, even for my simplest projects, like single-file scripts directly modifying HTML, I'll use `tsc` to compile .ts into .js, just so that I can get better IntelliSense while I'm working
- chasd00 3y ago
  Typescript is a real pain, I’m still trying to figure out why it’s so popular. The constant nagging and extra typing (no pun intended) when using it vs regular JavaScript makes it a pain. Then, there’s the extra parsing step to change it back to JavaScript. Idk I don’t see the value yet. Edit: I say “parsing step “ because that’s what it is. There’s no “compiling” and “transpile” is just a ridiculous way of saying parse and output.
  - ervine 3y ago
    Are you against typescript or types in general?
    - lovetocode 3y ago
      I love types I just struggle with Typescript a lot because it seems to get in the way for me. I might like it more if I buckled down and really tried to figure it out. It’s probably the slowest language for me to grasp maybe outside of Objective C. When you try to enforce typing on a language that wasn’t designed ground up with types in mind it just rubs me the wrong way. Python type hinting strikes a good balance though.
pier25 3y ago
This seems to be a response to this other one titled "Why I won't use Nextjs" https://news.ycombinator.com/item?id=38018217 https://news.ycombinator.com/item?id=38018217
- gnabgib 3y ago
  Seems to be? That's declared on the first line of the article. An attempt to balance sentiment on the web, perhaps.
  - pier25 3y ago
    Thanks I obviously didn't read the marketing piece.
lloydatkinson 3y ago
I can’t recommend Next after using it even on a small project. Whatever it sends to the browser is enough to eventually freeze the entire browser tab if you have the dev tools open. This was a daily recurrence. Also, the “fix” for many issues was to throw “use client” at the top of problem files. Serving the application whether first time load or dev time with hot module reload took an age. Really quite a miserable experience honestly. I have much better experiences with either a plain SPA or Astro.
- leerob 3y ago
  Sorry about your experience. > Whatever it sends to the browser is enough to eventually freeze the entire browser tab if you have the dev tools open. Is this with a fresh Next.js project of after you've added user code? If the former and there's a GitHub issue, let me know and we can take a look. Thank you. > Also, the “fix” for many issues was to throw “use client” at the top of problem files. The Server Components model is still really new. It'll take some time for the ecosystem to evolve here. Here's a good post if you want to learn more: https://github.com/reactwg/server-components/discussions/5 https://github.com/reactwg/server-components/discussions/5
ushakov 3y ago
What are better options out there (for a Node developer) if you're not using Next.js? Going to rails isn't really an option I guess
- chasd00 3y ago
  I’ve been learning more of these stacks and found out about remix here in the nextjs release 14 thread. Remix seems pretty ok so far but I don’t have super strong feelings on nextjs either, it seems to work for me. I’m functioning as a system liaison at work for a team on nextjs which was my first exposure to it. That got my interest so I’ve been exploring front end frameworks lately. I would give remix a shot.
  - ushakov 3y ago
    I've tried Remix and Astro, but I found it was too hard to even get started. SvelteKit looked interesting, but I didn't like the syntax. Nuxt with Tailwind has been my current go-to for last couple years, so seems like it might not be changing any time soon
- jstummbillig 3y ago
  Are you being ironic? If not: Rails is most certainly an option, if building web stuff is your goal. I think it's lame how bad the documentation around it is 40 years in, which I can kind of forgive because of how well thought out and complete pretty much everything is, once you figure it out. That is not to say that there aren't very sensible JS options – for example AdonisJS is well long running, constructed and feature complete TS backend framework, that has little traction – only that the community seems to value excitement and Apple marketing techniques to the point, where even their darlings core concepts are so absurdly unstable, that it feels insane to start any reasonably sized project with it.
  - ushakov 3y ago
    The problem with Rails is that I don't know Ruby. It's a different ecosystem than the one I'm used to (Node). I'm also not aware whether Ruby comes with built-in type-safety, which is a requirement for me. Another requirement besides type-safety is JavaScript on the frontend and TailwindCSS for styling
ushakov 3y ago
My last issue with Next was that when we were using SSR-mode with Server Components we couldn't change the env variables at runtime, unless the dev mode was enabled (otherwise it would just bundle them). We were deploying with Docker and needed for each deployment to have a different env variable. Sound like a simple task, until it's not
- leerob 3y ago
  This should be supported: https://github.com/vercel/next.js/discussions/44628#discussioncomment-7040424 https://github.com/vercel/next.js/discussions/44628#discussi...
meiraleal 3y ago
I know this one: Because you currently work as the VP of Developer Experience at Vercel
van_de_builder 3y ago
I'm using Next.js for a few reasons: - SEO was the initial draw. - First time doing real frontend web for prod, wanted to use React + MUI. - Did not want to use Django, Rails, WASM, etc. - I come from backend and devops (less a reason than a general note for context). Right now, I'm most curious about DIY hosting in EC2 with Go (or Rust) instead of using Vercel. This might seem old-fashioned in the days of ECS/EKS etc., but I'm really comfortable with EC2 and love the cost-savings and control (I build my own load balancers, NAT instances, reverse-proxies, health-checkers/deployment managers; saves a ton of money).

27 points by serial_dev 3y ago

the_gipsy 3y ago

> Because I work at vercel, and because we can monetize frontend with this server-side thing.

lwhi 3y ago
But you don't need to use Vercel?
- the_mitsuhiko 3y ago
  Next’s support outside of Vercel is best effort it seems. Which is fine as Vercel funds it, but it feels like there is a conflict of interest. There is after all a reason for OpenNext’s existence.
  - lwhi 3y ago
    I definitely agree there can be a conflict of interest, but I also think it's very possible to self host.
  - Tehnix 3y ago
    I really don’t understand this sentiment, it is extremely easy to build and deploy Next.js yourself?? You either: - Build static files and host it like any other framework (e.g. throw it in an S3 bucket)[0] - Or, run a Node.js server Where’s the Vercel exclusive part there? [0] Here’s me doing exactly that, going through the same steps I would for literally any Frontend framework, including the WASM alternative I also build in the post (exact same deployment) https://codetalk.io/posts/2023-10-16-the-stack-part-3.html#next.js https://codetalk.io/posts/2023-10-16-the-stack-part-3.html#n...
    - lwhi 3y ago
      Exactly, I thought I was missing something.
    - poisonborz 3y ago
      Well that's the problem, you will not see the glass wall until too late. For my case, that you can add API middleware, but you can't run any "not edge compatible" code because of Vercel reasons.
    - ervine 3y ago
      It's easy but there are decisions made that hamstring you - like being unable to change cache-control headers in the next.config.js or middleware or have your middleware use node APIs, which is especially stupid because when self-hosting... it's running in node! They are optimizing for deploying to the edge, which when self hosting you don't need to. So whether malicious or not, their guard rails conveniently make it frustrating to self host once you need to do anything outside of their garden.
      - leerob 3y ago
        Middleware works when self hosting. It's runtime is a subset of Node.js, since it's potentially running in front of every request in your application. We're still evaluating options here: https://github.com/vercel/next.js/discussions/46722#discussioncomment-6709529 https://github.com/vercel/next.js/discussions/46722#discussi...
        ervine 3y ago
        I never claimed middleware doesn't work when self hosting. I claimed that it's not as useful as it could be, because your company has prioritized edge deployments over supporting self-hosting. As someone in that discussion rightfully says: "We are grown-ups with access to the same tracing and profiling tools as you. There is nothing dangerous about us using Node.js as far as I’m concerned." Additionally, your comment just reeks of PR to me. I don't know if you do it on purpose or what, but to read my comment and then come back with "Middleware works when self hosting"... it has to be intentional on your part to misunderstand my comment that badly.
      - verdverm 3y ago
        We put nginx in front to manage the cache headers. My biggest gripe is that they made design decisions that are optimized for their paid products, at the expense of the open source. Middleware is the main example, because it has to run on their edge.platform, it has no routing association. For all the magic they do, they dropped the ball here, making you use regex to decide of middleware should be applied. All this because users were getting hit with surprise bills, which is.really a product of who they architected and charged, not a technical issue
    - jitl 3y ago
      I helped stand up Notion’s marketing site (https://notion.so/product https://notion.so/product) on NextJS. It’s really annoying / impossible to implement all the fancy caching, incremental revalidation, etc if you need to run more than one instance to serve the load you get. Or you need a horrendously complex AWS buzzword graph that will kinda sorta do the things. We switched from AWS ECS deployment to Vercel after tiring of figuring out how to support Next features that require very tight cooperation from CDN/distributed cache magicks. The total product is good, the web presence team is happy with Next and Vercel, I’m liking RSC and server actions, but I wanted to share my experience that beyond modest scale running Next yourself needs a lot of effort.
      - ushakov 3y ago
        Curious whether you considered any other frameworks?
        jitl 3y ago
        Site predates Astro, Remix, etc. There was some interest in Gatsby but I said no (seems horribly over engineered, adds GraphQL for no good reason, like storybook promises a lot but seems to leave the team doing extreme amount of npm upgrade work). I think Next was the clear winner, we knew what we were getting into with hosting it to some degree and it was still worth because of how well it fits the team.
      - satvikpendem 3y ago
        > We switched from AWS ECS deployment to Vercel after tiring of figuring out how to support Next features that require very tight cooperation from CDN/distributed cache magicks. I guess that's how they get you, by making it onerous to self host and instead offering a clean yet more expensive solution.
- meiraleal 3y ago
  Nobody need? They took over React tho.
deleted 3y ago
[deleted]

buf 3y ago

Pretty sure you use it because vercel likes the frontend engineers who don't know how/or care to deal with the backend.

leerob 3y ago
There's a lot of misunderstanding of what "frontend" and "backend" are: https://www.industrialempathy.com/posts/frontend-backend/ https://www.industrialempathy.com/posts/frontend-backend/
- hu3 3y ago
  Perhaps with desktop apps or low level systems it can get confusing but for traditional web the definition is usually: If it runs in the browser, it's frontend. Server? Backend. There's SSR but the name itself clarifies: Server Side Rendering.
van_de_builder 3y ago
Yes. Learned this really quickly. I want to leverage Next.js but not Vercel (if I don't have to). I have experience with backend and devops, so I care about and want to deal with the backend myself (cost-savings, control, decoupling). The sentiment and complaints seem to sum up to, "if you're using Next.js, you basically [or eventually] have to use Vercel." But I do not want this to be true. That said, I also don't want to sacrifice benefits of Next.js or have to "fix" things constantly or unnecessarily.

pjmlp 3y ago

I use it, because SaaS vendors like Sitecore and many others, have agreements with Vercel to push it as the main SDK. While other SPA frameworks are supported, they are a kind of second line, without all the bells and whistles that Next.js users are given to enjoy.

colesantiago 3y ago

Because you work there, no need for this blog post. This is more of an ad than anything.

lwhi 3y ago
Why is it problematic to address criticism?
- colesantiago 3y ago
  Because he is paid to address criticism of Vercel since he works there? It reads that Vercel told him to do this because he works there rather than him responding on his own accord. I don't see a 'DISCLAIMER: I WORK AT VERCEL' at the top on here, so I assume this reads like an ad.
  - lwhi 3y ago
    The original article was written by a guy who had a founding responsibility for a rival framework. Pot, kettle?
    - colesantiago 3y ago
      So both read like ads then. What is your point? Why are you rushing on every comment critical of vercel?, I'm assuming you also work for them or you have been sponsored or taken money by them in their marketing department. Judging from their latest release of Next.js, nothing has really changed or been done (except v0 which is cool which is besides the point from Next). But the fact that I don't see an explicit disclaimer here and the framework is overhyped, I see this as an ad. https://nextjs.org/blog/next-14 https://nextjs.org/blog/next-14
      - lwhi 3y ago
        [flagged]
      - Capricorn2481 3y ago

hnreport 3y ago

I never need to write separate backends for projects I want to create. I can build my entire project with Next.js. How have all these other developers been managing this whole time without Next?

3c6bYDXLMj 3y ago
They were working as part of a team? Or they are simply too young.

plugin-baby 3y ago

My experience with NextJS has been very frustrating. - it adds a layer of opacity between the front and backends (or as they are in Next: the frontend, the frontend backend and the backend backend). - front end code can run in the frontend backend and consequently needs a lot of extra guards. - front end stack traces are almost completely useless in dev mode. If you’re lucky, they will include the file name where the issue occurred, but often in these cases the line number will point to an empty line. I think the common thread here is that Next has a lot of surprises, especially when not on the happy path. It frequently breaks my intuition about how the web works. I’m strongly considering migrating our Next projects to React.

Tehnix 3y ago

There’s a two simple reasons I would go for Next.js - It’s React-based: Almost everyone knows how to do React these days - It allows me to build and serve chunked static files, instead of just a single static files like classic SPA The last part is the main reason for that over other React-based frameworks. While SSR is hot these days, I’m firmly in the camp of “less servers I need to operate is better” and almost have “needs to be servable via S3+CloudFront” as a hard requirement for Frontend stacks.

leerob 3y ago
Yeah, a large number of Next.js apps use the static export functionality and host on S3: https://nextjs.org/docs/app/building-your-application/deploying/static-exports https://nextjs.org/docs/app/building-your-application/deploy...

robertjpayne 3y ago

> If you're new here, I'm Lee. I work on Next.js. I've also made some courses about using Next.js before I joined Vercel. This alone should be further up the post…

lwhi 3y ago
Why?
- shmde 3y ago
  What why ? The term that you work for Vercel should be at the top so that people realise this isnt a neutral 3rd party but a company paid spokesperson.
  - lwhi 3y ago
    [flagged]
    - hu3 3y ago
      It's good practice to introduce strong biases at the top of articles so readers can take that into consideration right away. The article they are responding to did precisely that on their second paragraph: > I’ve been using Remix since it was first released in 2020. I loved it so much I joined the team for 10 months to help get the community going and now I recommend and teach Remix on EpicWeb.dev. [1] [1] https://www.epicweb.dev/why-i-wont-use-nextjs https://www.epicweb.dev/why-i-wont-use-nextjs
      - lwhi 3y ago
        He _does_ introduce the fact at the top of the article! This feels very much like a targeted attack.
3c6bYDXLMj 3y ago
Yep. Essentially a DevRel post.

lucasmerlin 3y ago

We've been having a lot of problems with weird bugs with nextjs, so I can't really recommend it. Feels like it's a eternal beta. First, we've had a problem with nextjs not caching the response code for 404 pages, so 404 pages would have a 200 status code. Now they've fixed this they have a bug where they are caching the 304 response code, responding with 304 to every request and completely breaking the site. This has been open for a month now and has affected a lot of people but it seems like Vercel just doesn't care. https://github.com/vercel/next.js/issues/56018 https://github.com/vercel/next.js/issues/56018

lwhi 3y ago
This is my big problem with proprietary software; and why open source pragmatically makes more sense. Fixing bugs is down to priority and incentives of the parent company.
- lucasmerlin 3y ago
  I mean it is open source and someone even made a PR to fix the bug in question and I guess I could use their fork until it's fixed.
  - lwhi 3y ago
    Hmm, doesn't seem as much of an issue now.
  - chasd00 3y ago
    I was about to say, just fox the bug submit a pull request and use your fork until it’s merged. Isn’t that the point of all these fancy source control tools?
ervine 3y ago
Yep their github management is atrocious. I understand it's a popular product so you get a lot of low quality issues opened, but there tons of real problems where no developer ever appears, and then are closed by the bot because of inactivity. Infuriating. The longer I do this, the more that issue management responsiveness becomes a real consideration when choosing a dependency.

throwaway77384 3y ago

Next.js is such an odd experience. On the one hand, I've built three apps in Next.js, a business directory on Vercel with a separate (Firebase) DB, a blog (Cloudflare, Next on Pages) which pulls from an API and a little calendar management app (Vercel), which also only pulls from an API. The speed at which I could get something up and running was astounding. Before Vercel I tried Google's Firebase hosting, which was so hilariously bad that I switched to Vercel, where everything just worked. You'd expect that from the makers of the thing. However, I was wary of vendor lock-in. When Vercel decides to arbitrarily break something you relied on, you are at their mercy to figure out when your app will run again. And this is where things get hairy. The Next.js documentation is sparse. So you either get lucky and someone else has done the guesswork to figure out how to do the most basic things in Next.js (for example the transition from 12 to 13, aka pages-router to app router was ROUGH...you could only find SO issues related to 12 and all the libraries and structures you were used to had all changed in subtle ways). Caching is another one of these things. There are fetch calls in some routes in my app that get cached no matter what. I've tried every which way to get the damn thing to stop them caching (the most obvious one being the no-store header), but to no avail. It caches and I can only get it to stop by redeploying. And no, purging cache from the Vercel dashboard doesn't fix it either. Only a redeploy will get me updated data from the DB. It's bizarre. And so the story goes on. It's super easy to get up and running. There are many 'aha' moments, where you can see that a ton of work has gone into DX. So much so, that I really try to use Next.js where I can. However, when you run into problems, they are usually more difficult to solve than with React. And they are subtle and not infrequent. Don't get me started on debugging. Since Next.js is sort of 'backend' to a large degree (which, in Google's and Cloudflare Page's case means edge-functions), trying to tease a meaningful log that isn't severely character-limited out of either service is very difficult. Error messages in the frontend are useless to an astounding degree. So, it seems there's a lot of work to be done. Tread carefully, as it's very enticing to have this quick-start, but I'd hesitate to use this for anything too serious, as things will break for no reason and there will be issues that are nearly impossible to solve and I wouldn't want clients emailing me while I'm dealing with BS I simply wouldn't have had on any other stack.

CafeRacer 3y ago
> Only a redeploy will get me updated data from the DB. This caching thing, when it wad released, is one of the sneakiest bastards ever. I had to add a random string to a query of each request to avoid caching on the management panel. It happened that because of the cache, one client was able to see the cached data for another client. We have had 4 FE on next and now gradually moving to remix and away from vercel.

lovetocode 3y ago

Is anyone just using vanilla React with no TypeScript or Framework of any kind? I’ve tried Remix and Next js and just find them so cumbersome. Typescript causes me more headaches

mplewis 3y ago
After using TypeScript, I’m never going back to vanilla JavaScript if I can help it.
- lovetocode 3y ago
  That’s great to hear! Did you find it hard to learn?
- firejake308 3y ago
  Yeah, even for my simplest projects, like single-file scripts directly modifying HTML, I'll use `tsc` to compile .ts into .js, just so that I can get better IntelliSense while I'm working
chasd00 3y ago
Typescript is a real pain, I’m still trying to figure out why it’s so popular. The constant nagging and extra typing (no pun intended) when using it vs regular JavaScript makes it a pain. Then, there’s the extra parsing step to change it back to JavaScript. Idk I don’t see the value yet. Edit: I say “parsing step “ because that’s what it is. There’s no “compiling” and “transpile” is just a ridiculous way of saying parse and output.
- ervine 3y ago
  Are you against typescript or types in general?
  - lovetocode 3y ago
    I love types I just struggle with Typescript a lot because it seems to get in the way for me. I might like it more if I buckled down and really tried to figure it out. It’s probably the slowest language for me to grasp maybe outside of Objective C. When you try to enforce typing on a language that wasn’t designed ground up with types in mind it just rubs me the wrong way. Python type hinting strikes a good balance though.

pier25 3y ago

This seems to be a response to this other one titled "Why I won't use Nextjs" https://news.ycombinator.com/item?id=38018217 https://news.ycombinator.com/item?id=38018217

gnabgib 3y ago
Seems to be? That's declared on the first line of the article. An attempt to balance sentiment on the web, perhaps.
- pier25 3y ago
  Thanks I obviously didn't read the marketing piece.

lloydatkinson 3y ago

I can’t recommend Next after using it even on a small project. Whatever it sends to the browser is enough to eventually freeze the entire browser tab if you have the dev tools open. This was a daily recurrence. Also, the “fix” for many issues was to throw “use client” at the top of problem files. Serving the application whether first time load or dev time with hot module reload took an age. Really quite a miserable experience honestly. I have much better experiences with either a plain SPA or Astro.

leerob 3y ago
Sorry about your experience. > Whatever it sends to the browser is enough to eventually freeze the entire browser tab if you have the dev tools open. Is this with a fresh Next.js project of after you've added user code? If the former and there's a GitHub issue, let me know and we can take a look. Thank you. > Also, the “fix” for many issues was to throw “use client” at the top of problem files. The Server Components model is still really new. It'll take some time for the ecosystem to evolve here. Here's a good post if you want to learn more: https://github.com/reactwg/server-components/discussions/5 https://github.com/reactwg/server-components/discussions/5

ushakov 3y ago

What are better options out there (for a Node developer) if you're not using Next.js? Going to rails isn't really an option I guess

chasd00 3y ago
I’ve been learning more of these stacks and found out about remix here in the nextjs release 14 thread. Remix seems pretty ok so far but I don’t have super strong feelings on nextjs either, it seems to work for me. I’m functioning as a system liaison at work for a team on nextjs which was my first exposure to it. That got my interest so I’ve been exploring front end frameworks lately. I would give remix a shot.
- ushakov 3y ago
  I've tried Remix and Astro, but I found it was too hard to even get started. SvelteKit looked interesting, but I didn't like the syntax. Nuxt with Tailwind has been my current go-to for last couple years, so seems like it might not be changing any time soon
jstummbillig 3y ago
Are you being ironic? If not: Rails is most certainly an option, if building web stuff is your goal. I think it's lame how bad the documentation around it is 40 years in, which I can kind of forgive because of how well thought out and complete pretty much everything is, once you figure it out. That is not to say that there aren't very sensible JS options – for example AdonisJS is well long running, constructed and feature complete TS backend framework, that has little traction – only that the community seems to value excitement and Apple marketing techniques to the point, where even their darlings core concepts are so absurdly unstable, that it feels insane to start any reasonably sized project with it.
- ushakov 3y ago
  The problem with Rails is that I don't know Ruby. It's a different ecosystem than the one I'm used to (Node). I'm also not aware whether Ruby comes with built-in type-safety, which is a requirement for me. Another requirement besides type-safety is JavaScript on the frontend and TailwindCSS for styling

ushakov 3y ago

My last issue with Next was that when we were using SSR-mode with Server Components we couldn't change the env variables at runtime, unless the dev mode was enabled (otherwise it would just bundle them). We were deploying with Docker and needed for each deployment to have a different env variable. Sound like a simple task, until it's not

leerob 3y ago
This should be supported: https://github.com/vercel/next.js/discussions/44628#discussioncomment-7040424 https://github.com/vercel/next.js/discussions/44628#discussi...

meiraleal 3y ago

I know this one: Because you currently work as the VP of Developer Experience at Vercel

van_de_builder 3y ago

I'm using Next.js for a few reasons: - SEO was the initial draw. - First time doing real frontend web for prod, wanted to use React + MUI. - Did not want to use Django, Rails, WASM, etc. - I come from backend and devops (less a reason than a general note for context). Right now, I'm most curious about DIY hosting in EC2 with Go (or Rust) instead of using Vercel. This might seem old-fashioned in the days of ECS/EKS etc., but I'm really comfortable with EC2 and love the cost-savings and control (I build my own load balancers, NAT instances, reverse-proxies, health-checkers/deployment managers; saves a ton of money).