I know this sounds more efficient, but this kind of attitude has serious downsides too. There is no "best" of each type of thing, it's subjective, so it's not necessarily duplicated effort to write your own parser. If you always use 3rd party libraries you also have less of a holistic view, it's hard to see different ways to do things... this is basically why the author of eslint didn't use something like the official typescript compiler, it simply has different goals and could never be as fast.
What a philosophical take on something super technically strict -- namely language parsing. Yes, there absolutely should be one and best way of doing it. We should get this done and finally move on to more productive activities.
I disagree, but Evan Wallace (who wrote eslint) puts it better than I could:
> Everything in esbuild is written from scratch.
> There are a lot of performance benefits with writing everything yourself instead of using 3rd-party libraries. You can have performance in mind from the beginning, you can make sure everything uses consistent data structures to avoid expensive conversions, and you can make wide architectural changes whenever necessary. The drawback is of course that it's a lot of work.
> For example, many bundlers use the official TypeScript compiler as a parser. But it was built to serve the goals of the TypeScript compiler team and they do not have performance as a top priority. Their code makes pretty heavy use of megamorphic object shapes and unnecessary dynamic property accesses (both well-known JavaScript speed bumps). And the TypeScript parser appears to still run the type checker even when type checking is disabled. None of these are an issue with esbuild's custom TypeScript parser.
> There are a lot of performance benefits with writing everything yourself instead of using 3rd-party libraries.
In my production experience correctness always trumps speed.
And language parsing is not a trivial task. Not every programmer can write a program to do it well (and fast). I know that so far I am not one of the programmers who can, for example.
I prefer to defer to the expertise of those who do it for a living and/or their academic pursuits (as long as they write clean and maintainable code).
So while the general point you quoted can absolutely be viable in many situations -- I've wrote stuff from scratch no small amount of times so I definitely can relate -- the original point here was language parsing where I believe your (and Evan's) take is prioritizing idealism to reality. And the reality is, most programmers aren't good with this stuff, and that's okay.
As for him and esbuild, I only have huge respect to show. But he's one of the few, not one of the many. He should be doing that and he did it very well (I use esbuild and adore it).
> So while the general point you quoted can absolutely be viable in many situations [...] the reality is, most programmers aren't good with this stuff, and that's okay.
I understand where you are coming from, I'm not suggesting this is some widely applicable principle (perhaps the emphasis in my previous comment was suggestive of that).
Absolutism never works in this arena: code reuse and libraries will always have it's place, and can have their own advantages (e.g shared correctness), but sometimes tearing it all down and writing from scratch also has it's place, and I think it is undervalued by comparison - Although I agree it takes a certain kind of person with not only enough experience and wisdom but a level of care and attention to detail that few are capable of.
