I’ve understood this and stopped using Next with all the enabled by default and intentionally difficult to disable metrics collection system they have in Next.
Having it enabled by default, without asking is already evil enough.
Refusing to have a setting you can easily commit into the repository to turn it off is next level.
They trick people with the “just set this env var” to turn it off, and rely on people doing it wrong, forgetting to do it in certain environments, etc. it’s intentionally complicated, when a frigging Boolean setting in next.config.is would be better. They refuse to do it. That’s what evil companies do.
Can you provide a source for 'They trick people with the “just set this env var” to turn it off'? I'm reading their documentation about telemetry and it says something different, am I missing something?
The documentation is purposefully deceiving. It makes you believe, in good faith, that disabling telemetry is per project when in reality it is per machine.
I just tried it myself on a brand new Next project:
$ npx create-next-app@latest
...
$ npx next telemetry disable
Next.js' telemetry collection is already disabled.
Status: Disabled
You have opted-out of Next.js' anonymous telemetry program.
No data will be collected from your machine.
Learn more: https://nextjs.org/telemetry
> They trick people with the “just set this env var” to turn it off, and rely on people doing it wrong, forgetting to do it in certain environments, etc. it’s intentionally complicated, when a frigging Boolean setting in next.config.is would be better. They refuse to do it. That’s what evil companies do.
And you're just falling into their trick. Just check how this works. And how easy it is to forget to do this on every environment you're deploying to, or for every other developer in your team.
What is the trick? They provide an easy way to disable telemetry and multiple ways to do it. It's up to your team to follow your organizations processes. If you don't want telemetry enabled, tell them to disable it and have checks in place to make sure it's disabled.
There's an easy way to do this, which is having a config setting. They don't want to put it easy, and provide all these more convoluted ways, because what you describe is an "ideal" which doesn't reflect real life at most workplaces. That's the whole trick. "It's easy, just put this environment variable and ensure everyone on your team does it on their laptops and ensure every staging and production environment also does it and setup checks and scripts to automate it and alarms and improve your processes... it's just that easy".
Can you explain what's wrong with having a friggin boolean in a config file? Like VSCode does? Like any other non-evil piece of software does?
That's what I mean with being evil. That's what I mean with tricks.
Of course it can be disabled, and it "seems easy". That's the trick.
Laravel looks like the most mature fullstack framework. .NET and Java might be nicer on the backend, but they are a decade behind the competition on the frontend. The javascript community doesn't seem to want a fullstack CRUD framework, the consensus seem to be that every project should make its own ad hoc framework, like the PHP community did 10+ years ago. This resulted in a lot of spaghetti code, and javascript, even with their advanced libraries, isn't much better.
The downside of not betting on javascript is that "everyone" knows javascript by now.
> The downside of not betting on javascript is that "everyone" knows javascript by now.
I'd say: everyone thinks they know javascript. Learning a new language is easy (especially with C-like syntax) but not the library. The language having nearly zero standard library makes it change under your feet on every different context. Deno started the initiative to supply what you get in the browser everywhere, but the browser being a GUI environment, the missing stuff need to come from somewhere, like the Deno.listen[0]. .NET is not much better with one million different runtimes with different platform support and capabilities.
I chanced on https://adonisjs.com/ the other day. It's modeled to be somewhat similar in ecosystem, batteries included and some syntax/layout to Laravel. Haven't really tried it yet but the community seems to be very active, there is also https://adocasts.com/ for eg.
First and foremost, I don't go SPA/React by default on every project, so that reduces a lot my need of the kind of framework I think you're thinking about.
Now, if I do need a lot of interactivity in the frontend, I use Inertia with Laravel, which gives me a real full stack, robust, battle tested, well integrated and very productive solution.
I’ve understood this and stopped using Next with all the enabled by default and intentionally difficult to disable metrics collection system they have in Next.
Having it enabled by default, without asking is already evil enough.
Refusing to have a setting you can easily commit into the repository to turn it off is next level.
They trick people with the “just set this env var” to turn it off, and rely on people doing it wrong, forgetting to do it in certain environments, etc. it’s intentionally complicated, when a frigging Boolean setting in next.config.is would be better. They refuse to do it. That’s what evil companies do.