I am using ParcelJS v2 (nightly), and my builds are really fast for a medium-sized project. It takes about 5s from scratch (no-cache) and Do I recommend Parcel? Not sure, it feels like every time I update the package something breaks (in their defense, it is still in Beta).
Esbuild – An extremely fast JavaScript bundler
221–230 of 288 posts
Re: Esbuild – An extremely fast JavaScript bundler
#222I am using ParcelJS v2 (nightly), and my builds are really fast for a medium-sized project. It takes about 5s from scratch (no-cache) and Do I recommend Parcel? Not sure, it feels like every time I update the package something breaks (in their defense, it is still in Beta).
I have to note that the project is a TypeScript project.
Re: Esbuild – An extremely fast JavaScript bundler
#223We recently switched on a few of our project from Webpack and the difference is incredible. Running a watch using this is practically instantaneous compared to our previous setup. I've been recommending it to all my colleagues and we're replacing Webpack slowly but surely. The main draw for me is the simplicity of the config too. Webpack config (even using things like Symfony's Encore) is pretty convoluted and confus…
Do you have a public example of a PHP/Symfony project that you've ported from Webpack to esbuild?
I'm afraid not, it's all internal and not open-source. :(
Re: Esbuild – An extremely fast JavaScript bundler
#224What do you think of the importmap approach propagated by dhh on rails 7?
I'm using it right now, it's fantastic. Also been playing around with Deno, importmaps are also used there, it's so much nicer than the bundle and compile everything workflow. It's the direction everyone should be going since it actually uses the browser and browser standards to their potential.
Also if people don't want to use CDNs both Rails and Deno do allow you to serve ES modules from your server.
Re: Esbuild – An extremely fast JavaScript bundler
#225Earlier quoted context omitted.
I really wish people would stop idolising so called '10x' developers. Anyone that is comfortable and familiar with their toolset (e.g. go, .NET, Java, C++) and has a deep understanding of a problem (and has likely solved it once already), can churn out code far, far, faster than an onlooker.
And I really wish people would stop denying that there can be a massive difference in productivity from one individual to the next. It doesn't really matter what the theoretical limits are. What matters is the people you have and are hiring, and whether or not they are moving the needle. Maybe we can put aside whether or not there is No True 10x Developer. But there are certainly 0.1x developers, and even -1x develop…
I totally agree with you, but I also love the context of this quote with your username ;)
Re: Esbuild – An extremely fast JavaScript bundler
#226Often overlooked things when discussing esbuild here: 1. It's not just a faster replacement for a single %tool_name% in your build chain: for the vast majority of cases, it's the whole "chain" in a single cli command if you're doing it right. That is, you don't just stick it inside, say, webpack as a faster replacement for babel (although you can). No, you look carefully through your webpack configs and its myriad of…
> 3. The most impressive part about esbuild development is not just that it's one guy writing it: it is the level of support and documentation he manages to provide alongside. And the one guy writing it is Evan Wallace, co-founder and CTO of Figma. I don't know how he has the time!
Figma's tech is mindblowing. Their entire engine is custom-built in C++ : https://www.figma.com/blog/building-a-professional-design-to...
> Instead of attempting to get one of [HTML/SVG/JS Canvas] to work, we implemented everything from scratch using WebGL. Our renderer is a highly-optimized tile-based engine with support for masking, blurring, dithered gradients, blend modes, nested layer opacity, and more. All rendering is done on the GPU and is fully anti-aliased. Internally our code looks a lot like a browser inside a browser; we have our own DOM, our own compositor, our own text layout engine, and we’re thinking about adding a render tree just like the one browsers use to render HTML.
To most people, esbuild would be a full-time job. Based on the above, it seems that to Evan it's a fraction of the work he did in Figma's early days all at once!
Re: Esbuild – An extremely fast JavaScript bundler
#227I started with webpack using create react app, I tried parcel, I tried esbuild. I tried parcel 2. I use esbuild. As a sole developer it takes no thought, and it still lets me do odd things pretty easily - like I have a particular process for dealing with odd cases in mdx files. Not a ringing endorsement or an exhaustive analysis. I'm just happy I don't have to spend time thinking about it. :-)
I am currently using Parcel 2, I like it because I don't have to bother with any configuration. From what I've seen, with esbuild you still have to fiddle with configurations and loaders for specific filetypes? Can I just give it an entry point and let it figure out everything (update production HTML file with bundle links, import external images, target last X browser versions, etc) ?
Re: Esbuild – An extremely fast JavaScript bundler
#228Earlier quoted context omitted.
I really wish people would stop idolising so called '10x' developers. Anyone that is comfortable and familiar with their toolset (e.g. go, .NET, Java, C++) and has a deep understanding of a problem (and has likely solved it once already), can churn out code far, far, faster than an onlooker.
10xer is not about churning out code. "Why is DJ Bernstein so great? I too can churn out CRUD apps very fast in ruby rails" - some webshit says this every day on HN.
Calling people "webshits" is not really in the spirit of HN imo.
Re: Esbuild – An extremely fast JavaScript bundler
#229Earlier quoted context omitted.
I don't understand this perspective. Everyone only has so many hours in a day, and there's only so fast you can work. If he's writing esbuild that is taking time away from being the CTO of Figma. Either he's working a shit ton, one of the things (Esbuild or Figma) is being somewhat neglected, or his output is actually not as high as it looks.
To echo what others have said here, my role as CTO and now CEO has gone from 95% coding to about 5% these days. So some nights I code on ideas and things that have been swirling in my head, just because it’s nice to just quietly write code and solve a finite (but possibly difficult) problem without interruptions. It actually IS therapeutic.
Same
Re: Esbuild – An extremely fast JavaScript bundler
#230Often overlooked things when discussing esbuild here: 1. It's not just a faster replacement for a single %tool_name% in your build chain: for the vast majority of cases, it's the whole "chain" in a single cli command if you're doing it right. That is, you don't just stick it inside, say, webpack as a faster replacement for babel (although you can). No, you look carefully through your webpack configs and its myriad of…
> 3. The most impressive part about esbuild development is not just that it's one guy writing it: it is the level of support and documentation he manages to provide alongside. And the one guy writing it is Evan Wallace, co-founder and CTO of Figma. I don't know how he has the time!
What in the world? And some say 10x engineers don’t exist…