nicksantos

Closure Library was originally designed based on the lessons learned from building Gmail in 2004/2005-ish. When it was archived, one of its founders wrote a great thread about how much the JavaScript ecosystem has changed in the last 20 years. It's been a wild ride!

https://www.threads.net/@dpup/post/C2QsW5QsSPW/?xmt=AQGzV4jb...

Yay for conformance tests! What's the strategy for handling things that don't make sense for other platforms? Do you expect that they'll be removed from the spec eventually, or fit in as some kind of platform-specific extension mechanism?

Docker Compose has always been an awesome file format, built on top of an idiosyncratic orchestration engine that doesn't interoperate well with anything else.

Writing a spec is a good first step! If work is underway to make this a shared multi-service dev environment that works across Kubernetes, ECS, etc, that would be even better.

When I read the spec, there are ominous words about partial implementations. That makes me nervous. But I'm cautiously optimistic.

Local kubernetes solutions (like docker-for-mac and minkube) usually let you push your image directly to the local docker daemon. No need to upload to a remote registry only to re-download it. A lot of tools in this space are pretty good about detecting this optimization, including Tilt.

(disclaimer: I work on Tilt)