Earlier quoted context omitted.
That doesn't seem like a good comparison because what was missing in her case was the Vue equivalent of the JSX compile phase.
esbuild works with jsx out of the box. Most of the examples in the docs are jsx.
[deleted]
Some notes on using esbuild
201–205 of 205 posts
Re: Some notes on using esbuild
#202I’ve gotten so tired of the near infinite complexity of the angular / react / webpack / typescript / sass projects at work that for my home projects I’m now exploring no build tool solutions. Modern browsers are now so powerful that a lot of the things we needed build tools for no longer apply: - http/2 multiplexing has made it unnecessary to limit the number of script or css files loaded at once. Faster connections…
> - vue and preact are designed to be used without build tools. An app deployed as a static site can use hash routing to need no builds and no server-side router. So is React. JSX and React are 2 different things. But honestly, React without JSX is a pain to write. Minification and hashing for secure script embedding are still needed, but it could provided directly by a server middleware, depending on the language on…
Instead of JSX I’ve been using htm, which fulfills roughly the same role but runs entirely in the browser: https://github.com/developit/htm
I find typescript useful for libraries, less so for application code.
Re: Some notes on using esbuild
#203Earlier quoted context omitted.
> The amount of churn in the JS build tool space easily outstrips any one time learning you need to do to surpass the Gradle knowledge cliff. Android Gradle Plugin: here, hold my beer. https://developer.android.com/studio/releases/gradle-plugin?... I find working with Gradle infuriating. It's layers upon layers of magic. When something breaks, you get a baroque error message, a usually useless stack trace, and a sugg…
This is what I was referring to the knowledge cliff. Gradle is incomprehensible until it isn't. It has a very steep but short learning curve and understanding is completely binary. It's very unfortunate but it is how it is. I still take it over the JS stuff but I do acknowledge it's shortcomings. I also don't do Android development so I don't know if it's particularly bad there.
The knowledge cliff doesn't end with Gradle because it's infinitely extensible. So you have to understand all the plugins as well. Because there is so much implied magic happening behind the DSL, when it breaks, you don't have a clue why. Reading the documentation is often insufficient, you have to track down the source code for the version of the plugin you're using.
In general, I find DSLs make my life harder, not easier.
Gradle is my least favorite build tool ever. It's just too much magic in too many places.
This is not an endorsement of the JS ecosystem either. It also sucks, but it has wasted less of my time than Gradle (again, in the context of Android).
Re: Some notes on using esbuild
#204I'd love a whole series on JavaScript that shares this plain, pragmatic, and information dense style.
Re: Some notes on using esbuild
#205> 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…
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.