> Who in 2021 is building web apps with no internet access?

Defense contractors? Government entities? Entities worried about chain of trust in packages? Choice of upgrade path instead of forced? Ability to keep working when the net is down?

There's a reason for lots of people to still want 'on prem' and to not want to have the whole Internet as a dependency.

> Defense contractors? Government entities? Entities worried about chain of trust in packages? Choice of upgrade path instead of forced? Ability to keep working when the net is down?

I think you partially misunderstood the parent comment - he was talking about requiring the internet for building the app ("Who in 2021 is building web apps with no internet access [while developing]?"), but you responded to using web apps w/o internet ("Who in 2021 is building web apps [for use] with no internet access?").

A bit of your point still stands, but, as the sister comment correctly pointed out, when you're building a web app for offline usage, Firebase is not the right choice of technology.

I don't think that is true. Having worked in regulated environments, the depedencies are mirrored internally with something like artifactory and must be approved for use after a license vetting, etc. The application build process would not touch the public internet to retrieve any content.

I think you're missing the original point. If your app is built on top of something like Firebase, then clearly your org has approved that use. So when developing the app, you should have access to Firebase.

If your org has not approved any cloud services, then you can run everything on your development machine (database, webapp, cache, etc.), or a provisioned dev environment if the full stack is too heavy for a single workstation.

How many of those people running airgapped systems are using firebase or s3 though?

Due to govcloud, S3 + docker is increasingly normal. We're helping a team who have that... but not much else (ex: no outside internet).

In utilities/industrial... docker, but not s3.

> Why can't you just use a "live" development environment in Firebase?

I have a live (as in online) dev environment with its own DB, which is good for most database reading/writing.

However, for Firebase Functions (FaaS), I really don't like the dev experience of using an online environment. You have increased latency for everything, but above all, logging is terrible.

So you have to set up the local emulators, which is not nearly as easy as doing `python manage.py runserver` or `nodemon` or what have you. I had problems with the setup this morning, and I've had to modify the code to write to the emulators instead of live functions depending on the environment (there is no way to do it purely through env variables, you have to do it though code).

I'll grant that it's improved massively over the last year or so - when I started the project I couldn't get the emulators to work at all, and SO and Github were riddled with issues on the topic.

On the topic of databases, I say it's good for most reading and writing, but last time I checked the data from emulated databases is not persisted so it's only good for fleeting tests, but not for playing around with data locally. I'm sure I'm not alone in that I often like to play around with bulk operations (such as big initializations or fetching) and manually explore the data (the "live" data explorer in the form of Firebase console web app is atrocious, there are infinitely better local solutions like pgAdmin, or the JetBrains' database explorers)

All in all the DX is just about acceptable, but I'm not impressed given that the product is almost a decade old, massively adopted, and led by Google. My original point is I believe web frameworks give me "tighter" DX, and I don't see a reason to pick Firebase over other options as a complete stack most of the time.

The complete emulator suite seems to be mostly suited for running tests. When working on firebase functions, I find running only them (`firebase emulators:start --only functions`), with everything else connected to the dev firebase project online, works pretty well. Persistent data but fast feedback loop for what I'm working on. You do need some scripts to manage what you are connecting to from the front end, as if you're just working on that it's probably nicer to not need the emulators at all.

I agree that it's just barely acceptable. I wish the web console wasn't so slow, and the data explorer needs a major overhaul.

> Who in 2021 is building web apps with no internet access?

Over the past 20 years, a lot of software development has shifted to apps that run in the client's browser.

But, there are still a lot of computers which are not connected to the internet. Sometimes it is because of security, sometimes environmental factors, sometimes it is simply because the use case does not necessitate it.

I have a computer that uses a web app that isn't connected to the internet on my desk right now -- a printer.

I imagine mostly because deploying to the cloud is slow - it would be the new waiting for compiling.

A fast-paced edit-compile-debug cycle is a huge development productivity benefit, and doing it via unit/integration tests and what have you is nice, but not equivalent.

My company was doing this when I joined (and to some extent still does this, but most of our data is in postgres now). It works ok as a development environment, but it's massively constraining for automated testing.

With a local instance, I can just spin a new one up for each test run. You can't do that with firebase projects (they do now provide an emulator which is just about workable).