3 ms·

> 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

> 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.
  - Oddskar 5y ago
    Not everything needs to be architected to be "enterprise grade" though. And a lot more languages can handle DB than just Java and C#.

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.
- Oddskar 5y ago
  Not everything needs to be architected to be "enterprise grade" though. And a lot more languages can handle DB than just Java and C#.