Explain Management Issues

[tareqtms]

Hi Tony,

Thanks for creating this repository which I think helps a lot to everyone who wants to go serverless with Nuxt. But I am a bit confused after reading your note about shifting to Next. Can you please explain the issues you were facing to manage the site.

I am new to Nuxt and serverless, so it would be very helpful for me to choose the right tool for my future projects.

[tonyfromundefined]

• Because most convenience functions provided by nuxt.js are provided as a black box.
• Also, because the entire project is implemented in JavaScript rather than TypeScript, there may be unexpected API changes.
• Nuxt.js is a good community based project, but at a large production level I don't recommend adventure.

[tareqtms]

Nuxt.js is a good community based project, but at a large production level I don't recommend adventure.

Can you please elaborate a bit more on this? Like how it will affect the large production level?

[TheAlexLichter]

Nuxt core team member here

@tonyfromundefined I'm happy to discuss that topic in-depth but writing "switch to another framework" in a nuxt starter is no nice move at all. I'm a huge supporter of freedom of speech but the context here is not appropriate IMO and I'd personally ask you if you could think about removing the statement from the README.

To the topic itself:

As your application grows larger, Nuxt.js can go beyond the complexity you can afford.

How is this different from any other framework?

Nuxt.js is more abstract than Next.js

Could you go more into detail here?

Because most convenience functions provided by nuxt.js are provided as a black box.

Which functions are a black box? 🤔 I'd like to hear more info here.

Also, because the entire project is implemented in JavaScript rather than TypeScript, there may be unexpected API changes.

Not all software has to be written in TypeScript... Next.js wasn't as well for long. Also, TS doesn't fully guarantee unexpected API changes. We use semver, have a huge test suite and are giving our best to avoid that. There weren't major API changes / breaking changes in minor versions besides experimental features which we classified as such

Nuxt.js has a very rapid API change for each version

Which? The largest change was from Nuxt 1 to Nuxt 2 but still the upgrade time was quite low for a major bump (usually a couple of hours).

Nuxt.js is a good community based project, but at a large production level I don't recommend adventure.

There are lots of enterprises using Nuxt.js as go-to framework for their web applications and sites. Are they all wrong?

[aldarund]

Also, because the entire project is implemented in JavaScript rather than TypeScript, there may be unexpected API changes.

Can you elaborate how language of tool is anyhow connected to api changes in tool? I honestly see like near zero connections.

[tonyfromundefined]

@tareqtms @manniL @aldarund

First, I apologize if the phrase in README.md has offended you. This repo is definitely designed to help the Nuxt.js ecosystem. The phrase was inappropriate at that point. I was complaining about the issues I met without contributing to the Nuxt.js project. Sorry.

First, let me explain the context in which I created this repo. Nuxt.js is basically a framework designed to run in a server environment. I've gone through a number of twists and turns to deploy Nuxt.js in a serverless environment since version 0.*, and I have left the results in this repo. In the process, I used the edge version and had to manually manipulate the files in node_modules/nuxt. This is because Nuxt.js did not natively support serverless deployments.

1. Nuxt.js has many features than Next.js.

I described this part as high complexity and abstraction. Here is my words,

"As your application grows larger, Nuxt.js can go beyond the complexity you can afford."
"Nuxt.js is more abstract than Next.js"
"Because most convenience functions provided by nuxt.js are provided as a black box."

For example, file-based dynamic routing (this feature was also included in Next.js 9), middleware, modules, layout, etc. These features make development easier, but for me it's an uncomplicated complexity for a serverless deployment. Serverless deployments, by default, do not include node_modules in their packages due to AWS Lambda's capacity limit (approximately 250 MB), and ultimately my goal is to bundle the bundle into a single .js file. In that situation, many of the features of Nuxt.js made it difficult for a complete serverless deployment. As a result, I could not fully understand the structure of Nuxt.js, and this repo had to be a semi-serverless deployment implementation. Next.js supports a full Serverless deployment, which allows you to create bundles per page.

2. About frequent API changes

Here is my words,

"Also, because the entire project is implemented in JavaScript rather than TypeScript, there may be unexpected API changes."
"Nuxt.js has a very rapid API change for each version"
"Nuxt.js is a good community based project, but at a large production level I don't recommend adventure."

This is my mistake. To be precise, it's right to think of a change in internal behavior, not an API change. I've been using Nuxt on AWS Lambda environments since version 0. *, and I've had quite a few problems with every version update. For example, there was a problem with bundling. (This was marked as a caption at the bottom of this repo until the API was available. - 8d2e2b7) I've always been tired of this part and this has led to a negative perception of Nuxt.js.

I'm also a big fan of TypeScript, and I think that helps to spot changes in the API. For example, I am Korean and have read the Korean documentation of Nuxt.js frequently. However, the document still has version 0.10.7. Most Korean novice developers are studying Nuxt.js based on this document, which is often confusing. TypeScript can catch this problem at compile time if you use the wrong property name in the option or the wrong function name. So I think TypeScript can be a big help in catching API information. (Nuxt.js already supports TypeScript, so this discussion doesn't make much sense - https://typescript.nuxtjs.org/)

I will keep this issue open even after the README.md has been modified.

[tonyfromundefined]

b395e2d

[tareqtms]

@tonyfromundefined
Just FYI, you can include node_modules in your serverless package as long as it's under 250MB. You can also keep the node_modules in a layer, to speed up the deployment process. But it's true that keeping all node_modules is not a good solution if you are adding more and more packages (and that go beyond 250MB). If Next.js is providing a solution for that, it's great!

[TheAlexLichter]

@tonyfromundefined Thanks for the quick action and response! Really appreciate that 🙏

To 1.

We are working on a smoother serverless experience and have released a (mostly undocumented and experimental) standalone mode which bundles all server dependencies ☺️

If you have any ideas on how to improve, we are always open for recommendations, suggestions and contributions 🙌

To 2.

Yes, TS support was a highly desired feature and I'm glad we tried multiple approaches and finally settled on a good fundament.

The out-of-sync localized docs are a real issue indeed but also a non-trivial one. Anyway, we are working on a solution for it for quite some time. Hope we can resolve that too!