Netlify has done nothing but innovate and push the needle forward for front-end devs. I’ll be there until there’s a VERY strong reason not to be.

i'd be curious to know what portion of websites they scan they know this for.

Java/Kotlin/Go/Rust/Ruby/Python/JS/TS are a lot less leaky about what language the server-side is written in. Usually the webserver used advertises itself name and in a server string, but it is considered bad practice and thus often switched off.

Reading "php" extensions in paths is a clear giveaway, so are "htm" extensions for microsoft products. Tools usually guess the language/framework based on some of these giveaways and the better the tools the less this is evident.

I jut checked some web apps I worked on, and only the one I last touched 10+ years ago is detected with buildwith.com; it's a Rails site.

All the Java/Kotlin/Rust/Hasura+Elm apps I worked on since are now shown as "Nginx" (the rev proxy in front of it).

Every programming language has holes, its just that with PHP the attack surface is much larger, so i guess people find more holes, etc..

Are you advocating “security by obscurity”?

Back in the day (!), server software used to honestly respond with things like the software name and exact version number it was running.

Naturally, that meant scanning for vulnerabilities was a lot easier than it needed to be.

There's also the way of most using runtimes/libraries that (constantly) have CVEs in them; and understanding why it is that these languages have CVEs in the first place (see my comment on "eval()").

obscurity is absolutely part of good security practice, as long as it's not all you're relying on.

Information-gathering is a common early step in any attack against a system; knowing the language & libraries involved (especially their versions) allows you to search for any existing CVEs that apply.

> Are you advocating “security by obscurity”?

I don't think OP was implying that security by obscurity alone is sufficient, just that it's unwise to advertise information that's not relevant to end users, that could help would-be attackers.

These things are not so easy, say, with a C++/Rust/Go app. Or even in most JVM configurations. JS has similar issues, that Deno is trying to mitigate to some extend.

We are also building a real, longterm sustainable enterprise business. We're not a non-profit and we're here to create a big lasting company that can keep investing into the future of the web.

Almost every feature you charge for is something you can achieve for free inside of a basic VPS. I understand you have the classic SV "Hotel California" model where you can check in but you can never leave. But frankly this makes the internet worse in every way possible and part of the point of the original article.

I struggle with even Digital Ocean and just want my site to freaking run.

Digital Ocean in particular has great guides to get you from the starting line to something that in most cases will work okay, but as a long-term solution to “I have an app I want to run on some infrastructure”, I agree that there’s a non-zero cost to managing a server that, like you, I’d much rather not deal with.

Seriously, it is orders of magnitude faster to deploy a static website on Netlify (drag and drop a folder from desktop) than it is to spin up just a single VPS on Vultr… by the time you’ve configured that VPS I could have done a dozen revisions to the website.

Do I wish all of Netlify was free? Sure, yes I do. Does this mean it’s not valuable? Of course not.

The irony of this is that you seem to be saying that (a) Netlify locks the customer in and (b) it can be trivially reimplemented in an entirely customised VPS which will also cost money.

Which is it?

Also, by your own standards this is a comparison between a paid Netlify account and a free VM. Right?

> Almost every feature you charge for is something you can achieve for free inside of a basic VPS

I have plenty of experience with both Netlify and VMs, and I don't think they are even remotely comparable.

> You can search all of this yourself with all of one google query.

You're the one making the claims - I'm not even sure what I would be searching for since the parameters of a VM are vastly different to those for Netlify. How could I even find TTFB for a free Oracle VM? In fact, my personal experience with Oracle VMs (granted it's from before 2018) is that the jitter would be very high, such that any TTFB would probably be meaningless. And it would depend on the deployment region, too. Not to mention the HTTP server being used.

Words are cheap. Unless you're willing to substantiate your claims with some actual facts, nobody learns anything.

Netlify’s free plan is awesome. You might get more bandwidth with a VPS. But you won’t get a CDN and you won’t get atomic deployments without a bunch of work. You’ll use half your VPS storage on the operating system. You’ll need to keep updating your software and maintaining backups. You’ll spend hours or weeks a year maintaining this thing, versus zero for Netlify.

It’s not just about the cost of bandwidth or storage. You gotta compare like with like.

1. Full server control (install any package) 2. Host any kind of server - Django, Rails, etc. etc. 3. Run database servers: MySQL, PostgreSQL, MongoDB, etc. 4. Background processes (cron or systemd) 5. Run VPNs and proxy servers for personal use at the same time. 6. Host email servers 7. Multi-purpose usage (Use for remote dev environments, cloud storage, AI/ML platforms, etc.)

All. For. *Free*.

How is it vendor lock-in when I can easily move my JS app to Render.com, AWS s3, Cloudflare, etc?

Do they? Or do they just use Wordpress? This is important to differentiate because people's idea of PHP on traditional servers ITT is a far cry from setting up wordpress.

Sure, there are some plugins that you can use to transmute the result builds and there's Edge functions, but nothing is hard to move to another provider.

Unfortunately netlify went from loved to hated overnight.