Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Unix tools should do something well in CLI, and be transparent enough to deconstruct the command into series of commands if it is a complex process. Piping is not always practical (see make).

Your definition of a unix tool is a strange one.



I don't think you understand the unix philosophy.

If a tool does everything for you from start to finish, it's not following the unix philosophy.

Unix command line tools are basically meant to be like small library functions in an ad-hoc text-based interpreted language.

Commands are supposed to be focused on one specific task.

More complex tasks are supposed to be achieved by orchestrating several commands in the right order.

The interface between commands is a stream of text.

https://en.wikipedia.org/wiki/Unix_philosophy

For example, one of the core items in the list:

> Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.

But as you can see, esbuild is nothing like that. It doesn't expect itself to take input from other programs, nor does it expect its output to be piped to other programs.

Another formulation:

- Write programs that do one thing and do it well.

- Write programs to work together.

- Write programs to handle text streams, because that is a universal interface.

Again, esbuild conforms to none of these points.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: