Thank you for your input (and time!) looking at the previous article, @andreidascalu
! This kind of feedback is especially useful for improving how we present in the future.
Your point seems to focus on Kool CLI as a simple "replacement" for Docker/Docker Compose CLI tools - with the recognized CLI sugar. It's important to take a comprehensive look at what the Kool project offers:
Custom Docker images, as you mentioned. We aim to optimize for development and production usage.
Presets - pre-configured Docker environments for popular frameworks.
Scripts - kool.yml for standardization of tasks related to dev environment paired with kool run for running them.
Kool CLI - is the tool that brings it all together, and allows us to offer more features and the desired better DX through the CLI sugar!
kool create - to get a new app environment with one command (from our presets).
kool share - to create a live URL for your local environment.
Sugar: kool start/kool stop/kool status with more fluent interfaces for what an environment is, not an inert group of containers is.
Sugar: kool exec/kool run without the need to worry about dockerTTY allocation whether running locally or in a CI environment.
It's important to make clear we don't intend to be a full replacement to docker compose by any means, we just recreate the necessary commands we find useful for a better developer experience. All the rest stays where it belongs and is always reachable - you can always keep using docker compose with an application using Kool Preset configs if you don't like the sugar!
Many developers should be familiar with the usual custom Bash scripts with helpers created for each dockerized project they have worked, and we hope - like us - they are not a big fan of that. Kool's standard UX/DX across projects we hope will be seen as valuable to others, just like it currently is to us! I can't say this enough - Docker is great for managing containers, but all the time new people realize something is missing, a gap for using it effectively for local development. We are in the missing to help with that!
Having said all this - we know we have a long road ahead, with many features to add - then perhaps at some point it could change your view as to kool CLI adoption - i.e more presets and images for different stacks (community actively working on this); kool cloud command for K8S deployment (soon); kool doctor for guaranteeing Docker environment setup is correct (soon).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you for your input (and time!) looking at the previous article, @andreidascalu ! This kind of feedback is especially useful for improving how we present in the future.
Your point seems to focus on Kool CLI as a simple "replacement" for Docker/Docker Compose CLI tools - with the recognized CLI sugar. It's important to take a comprehensive look at what the Kool project offers:
dockerTTY allocation whether running locally or in a CI environment.It's important to make clear we don't intend to be a full replacement to
docker composeby any means, we just recreate the necessary commands we find useful for a better developer experience. All the rest stays where it belongs and is always reachable - you can always keep usingdocker composewith an application using Kool Preset configs if you don't like the sugar!Many developers should be familiar with the usual custom Bash scripts with helpers created for each dockerized project they have worked, and we hope - like us - they are not a big fan of that. Kool's standard UX/DX across projects we hope will be seen as valuable to others, just like it currently is to us! I can't say this enough - Docker is great for managing containers, but all the time new people realize something is missing, a gap for using it effectively for local development. We are in the missing to help with that!
Having said all this - we know we have a long road ahead, with many features to add - then perhaps at some point it could change your view as to
koolCLI adoption - i.e more presets and images for different stacks (community actively working on this);kool cloudcommand for K8S deployment (soon);kool doctorfor guaranteeing Docker environment setup is correct (soon).