Hacker News new | past | comments | ask | show | jobs | submit login

Vercel is an evil company in disguise.

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?

[0] https://nextjs.org/telemetry


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
Note the part that says "from your machine".

An issue was crated about it but they just closed without responding: https://github.com/vercel/next.js/issues/31360


THIS


Sure.

1. Last paragraph of that link you posted

2. https://github.com/vercel/next.js/issues/8851

3.https://github.com/vercel/next.js/issues/10713

4. Many similar discussions to this one here on hackernews.


Always a good idea to add some network policies for egress traffic


To disable Telemetry simply run `npx next telemetry status` or set

``` NEXT_TELEMETRY_DISABLED=1 ```

in your .env file. I mean it couldn't be any easier.


You seem to have missed this part.

> 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.


I'm sorry I don't see how they're tricking people or relying on them do it wrong... seems like you're really reaching there.


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.

This is exactly the evil part I'm talking about.


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.


You don't get it.

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.


So which framework should you use? It is easy to say XYZ is bad, but what do you use instead, ASP.NET?


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.

[0]: https://deno.land/api@v1.27.0?s=Deno.listen


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.


And Adonis is great if you want to stay in jsland


> ASP.NET?

I do - .NET (since 5) has been great. And you've got stuff like Blazor for the frontend if you want to avoid JS entirely.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: