4 ms·

Come on, as someone that has worked professionally with Django and Next.js, the only similarity they have is that they're both web frameworks. Django is light y

Come on, as someone that has worked professionally with Django and Next.js, the only similarity they have is that they're both web frameworks. Django is light years ahead than Next.js is it's not even funny. Here's a very simple metric: Compare the Next.js documentation (https://nextjs.org/docs/getting-started https://nextjs.org/docs/getting-started) with Django's (https://docs.djangoproject.com/en/3.2/contents/ https://docs.djangoproject.com/en/3.2/contents/) - better yet, compare the actual API reference and exported classes/methods. Yes, Next.js is one of the better Node/Javascript frameworks, but it's incredibly inferior to any other established framework in Python, Java, PHP, Elixir, etc. — unless you only need a static page with some dynamic React components. I am in the unfortunate position of maintaining a more complex Next.JS app, using most of its "advanced" features such as dynamic routing, SSR, GraphQL, API, and it's the most painful project I have ever had the misfortune to work on, because the upstream interface and API is so woefully under-documented, buggy, changes too quickly it's hard to stay up-to-date, etc. etc. I weep every time someone on this forum suggests to start a new project with Next.js. In theory Javascript on the server and client is a productivity boost, in practice it is not by any measure.

nicoburns 5y ago
The similarly named (but completely different) Nest.js is much closer to Django than Next. Still a ways behind in terms of maturity, but it seems to be more or less on the right path.
sillyquiet 5y ago
> Yes, Next.js is one of the better Node/Javascript frameworks, but it's incredibly inferior to any other established framework in Python, Java, PHP, Elixir, et This is like saying a screwdriver is incredibly inferior to a impact hammer. > In theory Javascript on the server and client is a productivity boost, in practice it is not by any measure. This is in direct contrast to my personal experience across multiple projects and teams. In practice it IS a productivity boost, because JS does 99% of what anybody needs a web server to do.
- 1_player 5y ago
  > This is like saying a screwdriver is incredibly inferior to a impact hammer. I'm sorry, isn't the goal of web frameworks, including in this category Django, Next.js, Phoenix, Laravel, Nuxt.js to respond to HTTP requests and present users with an HTML page representing a document or a more complex web application? > because JS does 99% of what anybody needs a web server to do Brainfuck is Turing-complete and does 100% of what any other language can do as well. I stand by the fact that having to "know" only one language is great in theory, but in practice it's not. Node and client JS/Webpack are a leaky abstraction it's not very hard to get yourself cut with. In non trivial modules, you'll find it hard to be able to use the same code verbatim on the client and the server. Then add the complexity of server-side rendering, serialisation/hydration, React suspense, code that mysteriously works only when server-side rendered or viceversa, etc. and you'll ask yourself "is this really worth it?"
  - sillyquiet 5y ago
    > code that mysteriously works only when server-side rendered or viceversa, etc. It sounds like your opinion of server-side javascript comes from experience with badly written and poorly-understood server-side javascript, because none of that jives with my experience in writing node-based web applications.
- Oddskar 5y ago
  > because JS does 99% of what anybody needs a web server to do. Does talking to a DB really account for just 1% of what you want a web server to do?
  - sillyquiet 5y ago
    I think we are into semantics here, but I would posit if your web server is talking directly to a db other than a key-value store for tokens or what have you, your system is architected poorly. Your web server should be talking to a service written in Java or C# or something that handles the db stuff. edit: to address your point though, yeah, I think 99% of web sites don't need to be talking to a db. That's different from web applications, of course, but most web sites aren't, and shouldn't be, web applications.
Silhouette 5y ago
I am in the unfortunate position of maintaining a more complex Next.JS app, using most of its "advanced" features such as dynamic routing, SSR, GraphQL, API, and it's the most painful project I have ever had the misfortune to work on, because the upstream interface and API is so woefully under-documented, buggy, changes too quickly it's hard to stay up-to-date, etc. etc. Would you give some specific examples of where you've found Next to be buggy or where it's introduced breaking changes? We're evaluating a number of possible Node-related libraries for a new project right now, including Next, and there's no substitute for hearing from people with real experience of using them in production.
- midrus 5y ago
  Not the parent commenter, but maybe my experience saves you some time. Next js is awesome, and it is the best alternative in my opinion if you go the SPA route. Now, things get really, really, really messy and complicated when you start to implement on top of it everything else a typical web application would need. Authentication, validation, i18n, acceptance testing, background tasks or queues, etc.... We started out with next and prisma 2 and wasted a lot of time, in the end we rewrote the whole thing before launch with ruby on rails and turbo, some minimal stimulus and it was awesome. So much easier and simpler, and the application felt a lot more solid and robust. So, next is awesome if you're doing a landing or relying on an existing backend api, etc. If you need a full CRUD app, don't waste your time with it.
  - Silhouette 5y ago
    Thanks for the information. Would you mind elaborating on what made things "really, really, really messy"? Our use case is fairly typical, basically an SPA doing the heavy lifting, an API on the back end to support it, and then some largely static marketing pages. There is a potential fourth aspect if we want to customise any of those back end pages depending on who is logged in, for example to personalise help pages with the user's own details or to host some account management pages separate to the SPA. Next is under consideration because our SPA will be React-based, so being able to share components and styles for the rest of the site could be quite a time saver. We're reasonably sure we want to use some Node-based back end for this project, because that would allow us to share substantial functionality between the SPA and API implementations, but this would still apply if we used Express or another alternative to Next. It looks like the SPA and static pages wouldn't be a problem with Next in your experience, but maybe there could significant problems we haven't anticipated so far with using Next for the API and/or with using server-side rendered but not entirely static content?

nicoburns 5y ago

The similarly named (but completely different) Nest.js is much closer to Django than Next. Still a ways behind in terms of maturity, but it seems to be more or less on the right path.

sillyquiet 5y ago

> Yes, Next.js is one of the better Node/Javascript frameworks, but it's incredibly inferior to any other established framework in Python, Java, PHP, Elixir, et This is like saying a screwdriver is incredibly inferior to a impact hammer. > In theory Javascript on the server and client is a productivity boost, in practice it is not by any measure. This is in direct contrast to my personal experience across multiple projects and teams. In practice it IS a productivity boost, because JS does 99% of what anybody needs a web server to do.

1_player 5y ago
> This is like saying a screwdriver is incredibly inferior to a impact hammer. I'm sorry, isn't the goal of web frameworks, including in this category Django, Next.js, Phoenix, Laravel, Nuxt.js to respond to HTTP requests and present users with an HTML page representing a document or a more complex web application? > because JS does 99% of what anybody needs a web server to do Brainfuck is Turing-complete and does 100% of what any other language can do as well. I stand by the fact that having to "know" only one language is great in theory, but in practice it's not. Node and client JS/Webpack are a leaky abstraction it's not very hard to get yourself cut with. In non trivial modules, you'll find it hard to be able to use the same code verbatim on the client and the server. Then add the complexity of server-side rendering, serialisation/hydration, React suspense, code that mysteriously works only when server-side rendered or viceversa, etc. and you'll ask yourself "is this really worth it?"
- sillyquiet 5y ago
  > code that mysteriously works only when server-side rendered or viceversa, etc. It sounds like your opinion of server-side javascript comes from experience with badly written and poorly-understood server-side javascript, because none of that jives with my experience in writing node-based web applications.
Oddskar 5y ago
> because JS does 99% of what anybody needs a web server to do. Does talking to a DB really account for just 1% of what you want a web server to do?
- sillyquiet 5y ago
  I think we are into semantics here, but I would posit if your web server is talking directly to a db other than a key-value store for tokens or what have you, your system is architected poorly. Your web server should be talking to a service written in Java or C# or something that handles the db stuff. edit: to address your point though, yeah, I think 99% of web sites don't need to be talking to a db. That's different from web applications, of course, but most web sites aren't, and shouldn't be, web applications.

Silhouette 5y ago

I am in the unfortunate position of maintaining a more complex Next.JS app, using most of its "advanced" features such as dynamic routing, SSR, GraphQL, API, and it's the most painful project I have ever had the misfortune to work on, because the upstream interface and API is so woefully under-documented, buggy, changes too quickly it's hard to stay up-to-date, etc. etc. Would you give some specific examples of where you've found Next to be buggy or where it's introduced breaking changes? We're evaluating a number of possible Node-related libraries for a new project right now, including Next, and there's no substitute for hearing from people with real experience of using them in production.

midrus 5y ago
Not the parent commenter, but maybe my experience saves you some time. Next js is awesome, and it is the best alternative in my opinion if you go the SPA route. Now, things get really, really, really messy and complicated when you start to implement on top of it everything else a typical web application would need. Authentication, validation, i18n, acceptance testing, background tasks or queues, etc.... We started out with next and prisma 2 and wasted a lot of time, in the end we rewrote the whole thing before launch with ruby on rails and turbo, some minimal stimulus and it was awesome. So much easier and simpler, and the application felt a lot more solid and robust. So, next is awesome if you're doing a landing or relying on an existing backend api, etc. If you need a full CRUD app, don't waste your time with it.
- Silhouette 5y ago
  Thanks for the information. Would you mind elaborating on what made things "really, really, really messy"? Our use case is fairly typical, basically an SPA doing the heavy lifting, an API on the back end to support it, and then some largely static marketing pages. There is a potential fourth aspect if we want to customise any of those back end pages depending on who is logged in, for example to personalise help pages with the user's own details or to host some account management pages separate to the SPA. Next is under consideration because our SPA will be React-based, so being able to share components and styles for the rest of the site could be quite a time saver. We're reasonably sure we want to use some Node-based back end for this project, because that would allow us to share substantial functionality between the SPA and API implementations, but this would still apply if we used Express or another alternative to Next. It looks like the SPA and static pages wouldn't be a problem with Next in your experience, but maybe there could significant problems we haven't anticipated so far with using Next for the API and/or with using server-side rendered but not entirely static content?