5 ms·
> problem 1: libraries that tell you to npm install them Agreed. I wish `npm install` was just some option for those who wanted it. But no! Somehow it became t
by hsn915 5y ago
> problem 1: libraries that tell you to npm install them
Agreed. I wish `npm install` was just some option for those who wanted it. But no! Somehow it became the defacto standard and everyone just expects everyone else to already be onboard.
I got onboard reluctently because that's the only way to use the libraries I cared about.
> problem 2: I don’t understand frontend build tools
Absolute and total agreement.
I can't agree enough.
I think no one really understands them.
> “webpack” which I will not try to explain much because I don’t understand it, I think it’s a system with a million plugins that does a million things
I haven't worked with anyone who understood webpack. They just use a scaffold-builder to set it up in a pre-configured way and then you just never touch it.
> Recently I learned about esbuild which is a more Unix-style tool.
esbuild is the best thing that happened to frontend development. It finally freed us (well, me anyway) from the messy js build systems.
But I'd like to strongly object to describing it as a "unix-style" tool. Unix style tools to me are tools that deal with plain text and expect you to pipe them with other tools to get the job done. esbuild is nothing like that. It's the entire build pipeline in one tool. You don't work with it by piping its inputs and outputs to other tools. It provides you a programming interface and you write code to make it do what you want.
EDIT:
To clarify, I think it's a very good thing that esbuild is not a unix-style tool. I know the common wisdom on HN is in favor of the unix philosophy, but I don't buy into that.
- pastage 5y agoUnix 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.
- hsn915 5y agoI 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 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.
- rudian 5y ago(Misunderstood comment)
- hsn915 5y ago> If you want a unix-style tool I actually don't. esbuild not being unix-style is a good thing in my opinion.