As an aside, I haven't taken the time to pin point the exact problem, but as much I prefer to use Firefox, it doesn't seem to do a great job of managing resources for the SPAs we're building.
I agree, though, that it's next to unusable on a low-power dual-core system like the MBA if only for limited RAM.
(It generally does not. Instead it uses more lightweight isolation primtives. That has always been one of its main selling points.)
EDIT: see reply
> That does seem pretty heavy for a MBA of any generation?
It very much depends on what you are running inside the containers. I regularly have a dev environment with ~8 relatively lightweight containers running on my Early 2014 MBA without any problems.
If you change a small bit of css, the whole container is rebuilt? That seems super inefficient to me?
My backends arn't JS, but I still couldn't imagine rebuilding a container everytime I changed a piece of code. Right now I change a file, django picks up the change and reloads. No noticeable delay.
I think the attempts to make local workflows mirror production 1:1 (local k8s, for example) are misguided. They miss too hard on the productivity story. Especially once you start having to swap out local debugging for remote debugging (which only a handful of languages support effectively).
This is the biggest miss for many companies striving for microservice architecture. The local development story is terrible, and it stays terrible, without a lot of opinionated decisions around what your dev workflow needs to look like past the ~3-5 services mark. At a past gig I had to change 5 different repositories (5 separate PRs, all needing approval) to send an email. In a rails app that would have been a trivial task.
That sounds like no thought was put in the system before development. Well thought out scopes & contracts between services should not create a situation like that. Reminds me of a commenter on HN who were rolling back changes to all microservices if one service needed a rollback. These kinds of issues are dead giveaways that devs are paying lip-service to "microservices." Also, devs need to understand that they don't need to be on microservices or on the latest fad. Use what works for the team. A 10-team of devs cannot necessarily adopt workflows of a FAANG.
1. Terraform repo for AWS deploy
2. Step functions application logic (server-side polling daemon)
3. Email service template
4. Feature flag configuration
5. (Something in the monolith to trigger the workflow, probably?)
This wasn't an entirely small engineering org - 300-400+ devs?
I agree, though, is the point. I think folk don't put enough thought into the development story when going this route. I think monorepos are the only sensible way to go about it once folk have cross-service work to accomplish, and monoliths are a _good_ way to build applications for longer than folk give them credit. That said, some monoliths are more productive than others. Slow startup/compilation can destroy productivity.