The CLI has become a central tool in the Herbs developer experience.
The current CLI has two problems in my opinion: the first is technical, with low test coverage and with many responsibilities, making it difficult to evolve. The second is a DX (developer experience) which is ok, but not amazing.
But the CLI, like the website, is where developers perceive the quality of the project. In addition, differentiated DX can have a real impact on the developer's daily life and performance.
With that in mind, I'd like to bring the teaser to the contributors: the CLI should be AWESOME!
This means:
Beautiful, nice and innovative UI
UX focused on the developers' job to be done
use the best practices
stay close to market trends
extract as much of the possibilities that the terminal allows
The developer using this CLI should feel like using something completely new, as well as feeling empowered to extract the maximum value from the tool. In short: developers need to love the CLI!
This could also be an opportunity to think about a new architecture that not only supports the evolution of the tool, but also brings concepts such as plugins, templates, etc.
I've been researching and doing some benchmarks and would like to share some here:
UI
When I look at projects like Ink and Textualize, I see that there are still a lot of UI possibilities in the terminal that we are not exploring.
These tools open up a world of possibility from the point of view of usability and new aesthetics.
The aforementioned tools can greatly improve the usability of the CLI. In addition, we can apply best practices from other established CLIs that are loved by developers.
For example, what would it be like to bring herbsshelf to the CLI? Or what would a new experience for Aloe on the CLI look like?
Documentation:
The DX for documentation can be raised to the tenth power, be it the doc from the CLI, from Herbs and of course from the project itself using Herbs.
Architecture
A new CLI is the opportunity to rethink the successes and mistakes of the past.
Responsibilities:
Currently there are responsibilities in the CLI that do not necessarily need to be in the CLI. Ex: Aloe test runner, complex and specialized file generation logics, etc.
What would an architecture that could be more modularized look like?
Tests:
By modularizing the CLI, it would be an opportunity to create more specific and decoupled tests, which could run in milliseconds, without file system dependency, for example.
Conclusion
For now I'm just putting everything in my head in terms of possibilities here. I believe that CLI can have a very high impact on the project and therefore deserves our attention and affection.
As next steps, the brainstorm is open to contributors. I intend to bring some ideas based on the content I brought here as well.
The CLI has become a central tool in the Herbs developer experience.
The current CLI has two problems in my opinion: the first is technical, with low test coverage and with many responsibilities, making it difficult to evolve. The second is a DX (developer experience) which is ok, but not amazing.
But the CLI, like the website, is where developers perceive the quality of the project. In addition, differentiated DX can have a real impact on the developer's daily life and performance.
With that in mind, I'd like to bring the teaser to the contributors: the CLI should be AWESOME!
This means:
The developer using this CLI should feel like using something completely new, as well as feeling empowered to extract the maximum value from the tool. In short: developers need to love the CLI!
This could also be an opportunity to think about a new architecture that not only supports the evolution of the tool, but also brings concepts such as plugins, templates, etc.
I've been researching and doing some benchmarks and would like to share some here:
UI
When I look at projects like Ink and Textualize, I see that there are still a lot of UI possibilities in the terminal that we are not exploring.
These tools open up a world of possibility from the point of view of usability and new aesthetics.
The possibilities are many!
https://github.com/Textualize/textual https://github.com/projectwallace/wallace-cli https://github.com/maticzav/emma-cli https://github.com/GitGud-org/GitGud https://github.com/kraanzu/gupshup https://github.com/aristocratos/btop https://github.com/jarun/googler https://github.com/helix-editor/helix https://github.com/chubin/wttr.in https://github.com/rastapasta/mapscii https://betterprogramming.pub/designing-beautiful-command-line-applications-with-python-72bd2f972ea
Let's not forget about images and animations! https://www.youtube.com/watch?v=ZjN6L_btw0Q https://asciiart.club/ https://ascii.co.uk/animated https://www.deviantart.com/zonedev/art/Logotypes-zoNE-ASCII-3D-Animation-GIF-913308765
DX
The aforementioned tools can greatly improve the usability of the CLI. In addition, we can apply best practices from other established CLIs that are loved by developers.
12 Factor CLI Apps https://medium.com/@jdxcode/12-factor-cli-apps-dd3c227a0e46
10 design principles for delightful CLIs https://blog.developer.atlassian.com/10-design-principles-for-delightful-clis/
CLI Style Guide https://devcenter.heroku.com/articles/cli-style-guide
Command Line UX in 2020 https://puppet.com/blog/command-line-ux-in-2020/
New DXs:
For example, what would it be like to bring herbsshelf to the CLI? Or what would a new experience for Aloe on the CLI look like?
Documentation:
The DX for documentation can be raised to the tenth power, be it the doc from the CLI, from Herbs and of course from the project itself using Herbs.
Architecture
A new CLI is the opportunity to rethink the successes and mistakes of the past.
Responsibilities:
Currently there are responsibilities in the CLI that do not necessarily need to be in the CLI. Ex: Aloe test runner, complex and specialized file generation logics, etc.
What would an architecture that could be more modularized look like?
Tests:
By modularizing the CLI, it would be an opportunity to create more specific and decoupled tests, which could run in milliseconds, without file system dependency, for example.
Conclusion
For now I'm just putting everything in my head in terms of possibilities here. I believe that CLI can have a very high impact on the project and therefore deserves our attention and affection.
As next steps, the brainstorm is open to contributors. I intend to bring some ideas based on the content I brought here as well.