ESbuild is getting fantastic traction. It’s the default in Phoenix from 1.6 and comes as a default option in the current alpha of Rails 7, which you can get with a simple
rails new your_app -j esbuild
The only sort of issue I’ve had with it so far is you can’t use it with Inertiajs[1] as it does not support dynamic imports out of the box. Although I’m hesitant to call it an issue if its not in the scope of the project. Perhaps there are plugins I can use.
Esbuild w/rails 7 is nice, but if you’re using rails, check out vite_ruby [1]. I used it in a side project and it comes with plugins for views HMR + all the good stuff that comes built into vite.
Yes 100% - I’m actually using Vite Ruby in a project as I really wanted to use Inertia + React and that was by far the easiest way to get everything up and running.
I’d go so far as to say I wish -j vite was an option in js-bundling :)
Does it not support dynamic imports at all, or does it just not support “dynamic dynamic imports” i.e. dynamic imports where the module path is not constant?
If it’s the latter, you could have your Inertia page resolver be a giant switch statement of every possible page, where each case is a dynamic import call with a constant module name.
Kind of a pain but I think I’d prefer that if it meant I never had to write a webpack config again.
For complex projects moving to esbuild from say Webpack is not necessarily easy.
Why would things be easy in a complex project? If you've built complexity into your project it seems a little unreasonable to expect someone else's tool to fix that for you. At some point you need to accept that building things that are simple is your own responsibility. But building things that are simple is incredibly hard so don't be too down on yourself if your project is complex. Software complexity is like entropy; it's very easy to add complexity to a system, and very hard to remove it.
It's also worth noting that you probably don't really want a tool to make your complex project appear more simple. That would only hide the complexity from you, but it would still be there. If your project is complex then your best approach to solving that is a lot of documentation, a lot of testing, and a lot of refactoring.
> How many scripts does a site need to make it feel faster when bundled?
Depends on what you're building. If you have many nested dependencies, you need to bundle them, and not rely on the browser to resolve them at runtime and do dozens of roundtrips to the server to fetch them.
There will definitely be an inflection point, and it's very dependent on many factors: number and size of scripts, how much of the initial content is SSRed, network bandwidth and latency etc.
If your dozens of scripts are top-level (on the html itself) then you can fetch all of them in parallel — so you wait your connection speed roughly twice (roundtripped).
If they’re nested dependencies (where you don’t identify the next necessary js until you have the first one in hand), the dependency won’t start getting fetched until the predecessor is retrieved. So you wait your connection speed multiplied by depth (x2; roundtripped)
The goal of the bundler is to take the second scenario and turn it into the first scenario.
You can use the Network tab of your preferred browser to see the waterfall. HTTP2 did improve a lot, but it can’t magically resolve N-deep transitive imports without additional information. It was originally designed to have that information provided at the server level, but HTTP Push has been dead for a while. There are physical limitations at work, optimizing requests on the wire is still important.
Unless your site is made of 4 files/modules, you simply must bundle. ESM will download the files in series, as each dependency is discovered. Then compression doesn’t work as well as it will be per-file. Then of course you can’t tree-shake dependencies from npm, so good luck downloading the whole of lodash on your client.
In short you lose the advantages of only download what you need pretty quickly.
> good luck downloading the whole of lodash on your client
I never felt the need to use loadash. But even if a site would do that, it does not seem like a big issue. It is 71k. A Twitter profile page is over 5MB. 70 times the size of that loadash library. An appartment page on AirBnB is over 9MB. An Instagram profile page is over 9MB too.
> When I visit websites that are rendered serverside, they usually feel instant to me. Even when they load a dozen scripts or so
Then they'll be faster doing only one request, this is regardless of ssr or spa
Bundling also gives you slatic analysis (typescript and linting), and frees developers from developing in the dark, like keeping track in their brain what component in what script exposes what global.
> Bundling also gives you slatic analysis (typescript and linting),
No it doesn't do that, typescript compiler does the static analysis and whatever linter does the linting, you don't need a bundler for that, a bundler just takes many source files and bundles them into one.
> How many scripts does a site need to make it feel faster when bundled?
It's because people are using these huge frameworks with a lot of bloated code, it's too big, now devs are forced to do tree shaking and what not to trim the fat... front end JS development has become a madhouse of unnecessary complexity, because of node.js as well...
I hope that with the help of DENO that doesn't suffer from all that cargo culting, front-end development can become a healthier ecosystem...
Yes, some apps are complex, but 99% of front-end UI aren't.
I just saw an (internal) presentation where presenter predicted that in a few coming months we will see a lot more RxJS being used in ReactJS projects. Cannot wait to see it included on webpages which would be just fine with zero JS.
I like Snowpack (https://www.snowpack.dev) because it doesn't actually do any bundling, it just makes sure that the files are in the right place to be loaded (it does compile Typescript files). Because the only thing I actually care about during development is that all the inter-package dependencies are resolved. I don't actually need a fat heap of JS that needs to be rebuilt every time I change something.
esbuild is fast but it has a lot of place you have to figure out yourself and get into your way of doing thing.
1. dev server: you have to write a bit of code for this server to act as webpack dev server
2. scss: need to install plugin, and plugin cannot use from command line then you need to write a bit of JavaScript
3. global function: if you do `process.env` now you need to inject into build script
4. node package: if the package use node stuff you have to define thing like `fs/stream` into package.json
very quickly it get into your way of doing thing.
However, once you get past that base line, the cost is constant, the complexity just stop right there and not adding up.
This is exactly what I found when I tried esbuild a few months ago. I gave up and went with Parcel 2 at the time as I found it easier to get going (although there were teething problems with Parcel being beta at the time).
How is the SCSS performance? I've tried just about every trick in the book in an attempt to get our bootstrap-based SCSS projects to compile faster, and I'm at my wits end with it.
Bundling, and even barreling, have pretty much been solved problems for a while. Right now I feel that unit test frameworks, linters, and type checkers are by far the main bottlenecks in the development workflow.
“What is” is a vague question with no clear details in the answer. For example, parcel may have the middleware mode while esbuild may not. But then it’s parcel 1, but not 2, where it was removed to streamline plug-in development, so I better stick with 1 for a while. That is the context. By not providing it, the root comment has zero value, because an interested reader cannot learn at least some of the whys by simply reading the frontpage. Almost everyone knows it and thus will not follow your “open mindness” advice, because it’s pointless in this case.
> It also doesn't include type checking for typescript.
If you use `@aws/sdk`, you are going to have bad time with Typescript. Resolving its types can easily take >50% of compilation time for small projects.
Are there any tools that transform HTML and other files? For example, lets say I have an <img> tag with a src attribute that points to a local image. Can I automatically replace that with a <picture> tag with various formats (jpg, webp, avif) and sizes?
SGML can transform HTML and all other forms of markup, though it's neither limited to that use, nor does it readily bundle image converters/compressors even though that sure has always been a plausible use case for SGML-based pipelines.
I think it’s a fantastic default. I’d argue most server rendered applications can get away with it. And if you ever need ESBuild you can install the js-bundling gem or pass “-j esbuild” for new Rails 7 apps.
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.
I'm using this to compile typescript lambda functions for AWS with great success.
Combined with cdk and its NodeJsFunction you can even deploy/compile without local docker.
I looked at using ESbuild and I use Typescript. It was all looking good until reading the docs and it said ESbuild doesn't typecheck Typescript and to rely on your IDE to flag errors.
Is that correct and how is that working for you practically if it is? The whole point for Typescript for me is to have a compiler typecheck my code and block errors at compile time. ESbuild not typechecking seemed like a major contradiction to using Typescript so I set up a Webpack build using the standard ts compiler.
I've been out the loop of client side stuff a couple of years so to start was bit of a rabbit hole. Grunt/Gulp had gone and now Webpack seems common with a growing fanbase for ESbuild because of it's speed.
Not blocking on typecheck failures is one of my favorite features of TypeScript -- you can rapidly test/debug/iterate on code with "broken" or incomplete types while in the prototyping stages of feature development.
This is pretty common if you're looking for build performance. E.g. typecheck as a lint step with tsc, build with babel removing your typescript (it doesn't typecheck either), etc. It's true that tsc on its own can replace a build step for some folks, but you'll quickly find it limiting both in the options to rollup or combine files and in its ability to be extended with plugins (unlike Babel), etc. On the other hand, tsc and its language server is a first-class type-checker when run with no-emit. ;-) I haven't played as much with esbuild yet but it's on my todo list.
Consider TypeScript like a linter. ESBuild doesn't run ESLint for you either - you can run it separately, or in parallel.
This means that for example, during development, you can see your running code quickly, while your editor runs tsc to highlight type checking errors. And in your build system, you can produce a production bundle to test while in parallel checking for type errors.
First, forgive my ignorance of the JS/TS and bundler ecosystems.
> while in parallel checking for type errors.
Why are you suggesting this not be done during development? Is it bc while ESBuild is fast and runs in parallel, it's still only as fast as the slowest parallelized task, and in this case the slowest task is checking for type errors? And I assume checking for type errors is the slowest because it has to invoke an external resource, tsc?
Would it not make sense to have two development bundlers then? One for getting your code up and running quickly, and a second that outputs a dummy build artifact, but allows a more thorough production-like build that includes type checking (or other long running activities)? That way you get all the verification you would like, but don't pay a price on waiting for your code to deploy?
You can absolutely run it during development! In fact, many people will use an editor that automatically does this and highlights any potential errors - which means you don't need your compiler to display them (or even block compiling) as well.
And yes, type checking is relatively slow, and also strictly extra work, since it's not required to make your code runnable.
You'll often see that people do still do a more thorough production build in their CI systems, but not necessarily by using a bundler that includes type checking; rather, they just run type checking and bundling as separate tasks. That way, you do indeed get all the verification you would like without having to delay deployment.
(To make it somewhat more confusing, a project like Vite does use a fast bundler (ESBuild) during development and a more thorough one for production (Rollup), but that's independent of type checking. It's more about the latter doing more optimisations, and the former merely making the code runnable by the browser.)
Only if a project is pretty small.
Change in one place, especially if it's a reusable code, might ruin code in multiple different places and IDE will not recompile the whole project on every change, it will only watch your currently opened files and, maybe, some files in opened folders.
By "supporting typescript" it parses typescript code and won't fail. That is what a bundler promises. Bundler doesn't have to do the typechecking. It is actually conventional to set it up that way for any bundler. In my job we have webpack bundling typescript with babel in the "build" step. We could've use ts-loader but we want hot reload to be fast. Then in the "check" step we have ts, linter, unit tests. Those run on CI.
You're likely literally doing the same thing with Webpack. There is only one complete implementation of the TS compiler in existence, so you have to use that to typecheck, it doesn't matter what bundler tool is used. If you need the type definitions as part of the output (eg you are distributing a library), then you have to involve the compiler to construct the output definition files, but for the code itself, it doesn't really matter because you're just generating JS. The TS compiler is very slow (and in any case is not designed to produce code bundles - it just dumbly translates all the TS to JS), so the standard way to speed this up is to use a module bundling tool that ignores the types and compiles the code as JS, and have the TS compiler set to not emit any files itself.
Nothing in the above precludes using the compiler to typecheck the code, that's the primary usecase & what sibling is saying about thinking of it as a linter: if typechecking fails, don't build
`eslint && tsc --noEmit && esbuild` or something like that, just simple process chaining. Means you can build something you know is going to be illegal to the TypeScript compiler, but you want to very quickly test an assumption, for example.
I had ignored this space for a while as I didn't see any need to fiddle with it. But there does seem to be quite a lot of movement now on Webpack alternatives. The speed improvements do look very interesting, though I'm not so sure how much of the delays I'm seeing with Webpack/Create React App are from the Typescript checking. I mean Typescript is awesome, but it's also not all that fast in building and type checking.
Vite seems to be one of the more interesting CRA alternatives. Though it uses esbuild only for development, and Rollup for production builds. It'll be interesting to see how this develops, and if the fast bundlers keep catching up in terms of features without getting slower.
Work on esbuild started at the start of 2020. It is primarily authored and maintained by Evan Wallace, who, in addition to making this tremendous contribution to the JavaScript ecosystem, is the CTO and co-founder of Figma. Incredible output.
> As a good CTO you shouldn't have anything to do.
Is this for real? I mean, yeah, I don't think a CTO should be debugging build scripts, but hiring a great team, mentoring, aligning teams with a common technical vision, meeting with other company leaders to ensure the technical direction meets the needs of the business is an immense amount of work.
I came here too say this. The man authored in the neighborhood of 100k LOC in a year, just on this. There's a living 10x dev, it's not a myth. What is ridiculous is to think someone can 10x a normal developer, it's more like the difference between the top few percent and the bottom 10-20%. Evan Wallace is a beast, no doubt.
While he is certainly an excellent developer with great productivity to boot, LOC is an obtuse metric. For example there is a package-lock.json commit which is almost 20K lines. Otherwise I totally agree.
Agree, if anything it should be the reverse, less LOC produced means more efficient developer. But that's also a shit metric, as then people start cramming in as much complexity in every line as possible.
Best would be if we could actually measure "complexity" in a objective manner.
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.
Perhaps that is what makes them '10x developers': a great familiarity with their toolset and a deep understanding of the problems they are solving. In this sense I don't think it's bad to idolize them, as familiarity and understanding are achievable by many people, and they could all become a '10x developer'.
Baloney. I don't think it's "black magic", but as a software engineer with some deep familiarity with my tool chain I'm not going to pretend that I could ever be as productive as some of these folks. It's like when I see another post about a Fabrice Bellard project, and I think "he gets done in a year what it would take me about a career".
I don't understand this fetishization of "everyone has nearly equal ability" in the face of tons of overwhelming evidence to the contrary.
I don't believe everyone has the same ability. What I do believe is that performance is explainable and there's a practical upper limit to raw output.
I made a side project that I spent 1-2years building on and off and had people saying "wow I could never build that". That's bullshit. If they were of similar intelligence and put in a similar amount of time and effort I'm sure they'd be able to replicate what I did.
The luxury of being able to spend ample amounts of time on a project or idea is also massively overlooked.
That's not all it is. Some people are just better than others. No matter how hard every tries to be the best football or basketball player, only an extremely small set of people even have the chance to make it. There are physical traits they'll never have and mental fortitude to use those traits. You can't grow yourself to 7 ft tall and you never will be able to. What makes you think the brain is any different.
I dont think the parent is just about LOC, but the quality of those LOC.
There are people producing JS bundler and are comfortable and familiar with their toolset along with deep understanding of the problem. And they dont even come close to what is being described here.
> has a deep understanding of a problem (and has likely solved it once already), can churn out code far, far, faster
Is this a bad thing to discourage? Perhaps one way to increase your output as a developer is to narrow your focus (rather than jumping on the latest framework or build system which require constantly re-learning new solutions to the same problem)
No. It's what I encourage people in my team to do all the time. In fact it's something I was also encouraged to do.
The full quote was:
"Become an expert in at least one thing in your job or preferably career, and do it while you have the time" (e.g. when you're junior and expectations are low, or not a manager).
That's a bit of a strawman. My full comment is that being familiar with your language of choice, and having a deep understanding of a problem means that can produce a solution faster than someone that doesn't. I used the phrase 'churn out', I could have simply said 'produce'.
I've worked in the industry for almost 30 years, and I've worked with a lot of people in that time. Those that you might qualify as '10x', all have had both of the qualities I mention.
I would not expect any of those people to switch languages and fields and still be a '10x' developer.
But isn’t what you said a bit of a straw man too? Back in the music comparison, no one would expect an excellent guitarist to take up playing piano and still be a virtuoso.
And yet… we do recognize that some people are impressively better than others at playing piano, running yards, fighting, and all sorts of other narrowly specific tasks.
It’s just that the more creative the task, the harder it to measure how much better someone is.
I would. Languages aren’t as important as you would think. Certain people can pick up the new idioms quickly and run with it.
Look at someone like Yehuda Katz. Substantial contributions in ruby (merb, bundler), JS (jQuery core team, created Ember.js), and rust (created cargo).
But trying to elevate him or make him uncomfortable (he’s also a really humble dude), but just saying there are examples of polyglots that make substantial contributions.
I’ve found that in any tech company, while there are many people that write good code and do a great job, there are always a handful (even at a place like Apple) that truly push the industry forward and in certain directions, partly because of how they see years ahead, partly because they are supremely talented, and partly because they attract other really good talent just to work with them.
And we know many of their names. Folks like Brian Cantrill, Yehuda Katz, Fabrice Bellard, John Carmack, Bret Taylor.
They aren’t just good programmers. They’re constantly dwelling in uncharted territory.
I’m not advocating worshipping them, just stating that their talent and output is hell of a lot more than even 10x.
I understand what you're saying, but I'd still argue that they're supremely familiar with their toolchain, and have a deep understanding of the problems they're trying to solve. My comment said they've usually solved the problem at least once already, but I don't discount people solving new problems.
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 developers.
Being proficient in your tech stack helps your output sure but it's only one part (and a small one IMO) of the equation for creating something like esbuild. The author of esbuild surely has a strong knowledge of computer architecture, data structure and algorithms, operating systems and some math.
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.
CTO and lead developer on a focused project are very different jobs - my guess would be he relaxes from the very strategy and soft-skill heavy day job by diving into a challenging problem that keeps his dev chops up and lets him focus on a finite problem.
No idea on Evan Wallace's perspective but there is a possibility that it isn't seen as work. It would like be me solving sudoku or some of my friends building LEGOs or solving extremely hard jigzaw puzzles
As someone that ran a company while working on side open source projects, don't underestimate the therapeutic value of writing code. (As a CEO, my job had almost no coding, and working on my opensource projects made me happy, and restored a lot of my energy.)
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.
I don't think rejecting a comparison with an uncomplete nightly build is unfair. It looks like it was added a little after this issue was closed because the blocker was fixed.
Parcel 2 was released as stable yesterday though and Evan has already updated comparison.
Although esbuild has been out for a while now, I think it's relevant today because the benchmarks have been updated to include Parcel 2, which was just released earlier today.
See also SWC, something similar to esbuild but written in Rust. NextJS uses SWC as well as Deno.
Rome is also being rewritten in Rust, it's more of a complete set of packages that subsume Webpack, Babel and all the other parts of the JS / TS development experience.
The announcements from NextJS has been really confusing. I don't think they are using SWC yet. They are just working on it. The reason for the confusion is because they write about the progress in the release notes, making it look like they are using it.
I'm sorry, but the node.js community needs to stop producing these stuff... it doesn't do anything better than all the webpack vs gulp vs parcel vs snowpack vs rollup vs how many bundlers again?
I recently switched to esbuild and I am delighed. My build time dropped from 30s to 2s and I was able to remove a lot of dependencies. So IMHO they need to continue producing these stuff to push the innovation forward.
We 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 confusing to track. This, at least in my experience, has greater readability and is simpler to understand.
I cannot count the days I've spend on webpack config breakage during the last years at work. It's never really been good at all either. The gulp setup we had before worked faster, better and didn't break once a month. Webpack really only is a pet project of the idiocratic React-community. Facebook not only screws your personal data over, also your dev workflow!
Esbuild actually made writing frontend bearable for the first time in years. It alone reduced our iterative build times from 45 seconds to something like .5 seconds.
While useful, it should be noted TypeScript ≠ JavaScript and this build tool is for TypeScript. Many of us are using different compile-to-JS languages, or no language at all.
It helps to get 80% of the way there, on a logarithmic scale. The remaining 20% is evanw saying no to adding any kind of option, feature and the kitchen sink to this project, which is one of the reason Webpack/Babel & co. are some of the heaviest objects in the universe.
> Why is esbuild fast?
> - It's written in Go and compiles to native code.
> - Parallelism is used heavily.
> - Everything in esbuild is written from scratch.
> - Memory is used efficiently.
> Production readiness
> - Used by other projects
> - API stability
> - Only one main developer
> - Not always open to scope expansion
The catch is that they focus on modern builds (I.e. not IE) it also doesn’t do type definitions, so if you want type defs you’ll need to compile with typescript anyway.
It doesn't always work in situations where 'require' can't be statically evaluated at run-time (webpack would work in this situation) - for example I filed a bug recently[0]
Even though the bug was closed I was impressed with the thorough and timely response from the esbuild developers which explained the reasoning behind it. For me it was worth changing my project just so I could continue using esbuild, it really is that good!
287 comments
[ 3.5 ms ] story [ 266 ms ] threadrails new your_app -j esbuild
The only sort of issue I’ve had with it so far is you can’t use it with Inertiajs[1] as it does not support dynamic imports out of the box. Although I’m hesitant to call it an issue if its not in the scope of the project. Perhaps there are plugins I can use.
[1] - https://inertiajs.com
1: https://github.com/ElMassimo/vite_ruby
I’d go so far as to say I wish -j vite was an option in js-bundling :)
If it’s the latter, you could have your Inertia page resolver be a giant switch statement of every possible page, where each case is a dynamic import call with a constant module name.
Kind of a pain but I think I’d prefer that if it meant I never had to write a webpack config again.
It works really well
Why would things be easy in a complex project? If you've built complexity into your project it seems a little unreasonable to expect someone else's tool to fix that for you. At some point you need to accept that building things that are simple is your own responsibility. But building things that are simple is incredibly hard so don't be too down on yourself if your project is complex. Software complexity is like entropy; it's very easy to add complexity to a system, and very hard to remove it.
It's also worth noting that you probably don't really want a tool to make your complex project appear more simple. That would only hide the complexity from you, but it would still be there. If your project is complex then your best approach to solving that is a lot of documentation, a lot of testing, and a lot of refactoring.
How many scripts does a site need to make it feel faster when bundled?
When I visit websites that are rendered serverside, they usually feel instant to me. Even when they load a dozen scripts or so.
Depends on what you're building. If you have many nested dependencies, you need to bundle them, and not rely on the browser to resolve them at runtime and do dozens of roundtrips to the server to fetch them.
If they’re nested dependencies (where you don’t identify the next necessary js until you have the first one in hand), the dependency won’t start getting fetched until the predecessor is retrieved. So you wait your connection speed multiplied by depth (x2; roundtripped)
The goal of the bundler is to take the second scenario and turn it into the first scenario.
The bundler will have those preprocessed and bundled together.
The creator of Rails talks about it here: https://world.hey.com/dhh/modern-web-apps-without-javascript...
- Single bundle
- No bundles (all separate files)
- Hybrid
https://blog.khanacademy.org/forgo-js-packaging-not-so-fast/
- fast TypeScript/JSX compile
- bundling shared code to reduce request waterfall/splitting to reduce redundancy
- bundle optimization (tree shaking/dead code elimination; minification is actually faster than not using it)
- a simple plugin system for use cases like other compiled frameworks like Vue or Svelte, or whatever else you might want in a build pipeline
While a website that loads scripts per page will only load the scripts that are needed on the current page.
In short you lose the advantages of only download what you need pretty quickly.
I never felt the need to use loadash. But even if a site would do that, it does not seem like a big issue. It is 71k. A Twitter profile page is over 5MB. 70 times the size of that loadash library. An appartment page on AirBnB is over 9MB. An Instagram profile page is over 9MB too.
Then they'll be faster doing only one request, this is regardless of ssr or spa
Bundling also gives you slatic analysis (typescript and linting), and frees developers from developing in the dark, like keeping track in their brain what component in what script exposes what global.
No it doesn't do that, typescript compiler does the static analysis and whatever linter does the linting, you don't need a bundler for that, a bundler just takes many source files and bundles them into one.
It's because people are using these huge frameworks with a lot of bloated code, it's too big, now devs are forced to do tree shaking and what not to trim the fat... front end JS development has become a madhouse of unnecessary complexity, because of node.js as well...
I hope that with the help of DENO that doesn't suffer from all that cargo culting, front-end development can become a healthier ecosystem...
Yes, some apps are complex, but 99% of front-end UI aren't.
1. dev server: you have to write a bit of code for this server to act as webpack dev server 2. scss: need to install plugin, and plugin cannot use from command line then you need to write a bit of JavaScript 3. global function: if you do `process.env` now you need to inject into build script 4. node package: if the package use node stuff you have to define thing like `fs/stream` into package.json
very quickly it get into your way of doing thing.
However, once you get past that base line, the cost is constant, the complexity just stop right there and not adding up.
Plus, the speed is amazing.
4. You can just use `target: node` (or node12, node14.6, etc)
I need to give esbuild another go I think.
- [0] https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil... - [1] https://vitejs.dev/
Any chance you can share your config?
This is the gist https://gist.github.com/v9n/c40a6ad2078d09dd86117924b415b7fb
As far as I know, esbuild has no intention to integrate with CSS and will outsorce it to plugin.
I used
I'll give this a shot really quick
This.
Bundling, and even barreling, have pretty much been solved problems for a while. Right now I feel that unit test frameworks, linters, and type checkers are by far the main bottlenecks in the development workflow.
https://eslint.org/docs/user-guide/command-line-interface#ca...
For TS, tsc has an —incremental flag. ts-fork-checker-plugin is non-blocking for the rest of the build too.
If someone has open mind, they can also google what is Parcel.
2. It’s written in Go
Why is esbuild fast? https://esbuild.github.io/faq/#why-is-esbuild-fast
- It's written in Go and compiles to native code
- Parallelism is used heavily
- Written from scratch with performance as a goal
- Efficient use of memory
If you use `@aws/sdk`, you are going to have bad time with Typescript. Resolving its types can easily take >50% of compilation time for small projects.
[0] https://parceljs.org/
[1] https://parceljs.org/recipes/image/
As a rails dev, I want one, strong opinion on what the default/best approach is. I don't want to configure anything
Also if people don't want to use CDNs both Rails and Deno do allow you to serve ES modules from your server.
Is that correct and how is that working for you practically if it is? The whole point for Typescript for me is to have a compiler typecheck my code and block errors at compile time. ESbuild not typechecking seemed like a major contradiction to using Typescript so I set up a Webpack build using the standard ts compiler.
I've been out the loop of client side stuff a couple of years so to start was bit of a rabbit hole. Grunt/Gulp had gone and now Webpack seems common with a growing fanbase for ESbuild because of it's speed.
This means that for example, during development, you can see your running code quickly, while your editor runs tsc to highlight type checking errors. And in your build system, you can produce a production bundle to test while in parallel checking for type errors.
But:
> Consider TypeScript like a linter
> while in parallel checking for type errors.
Why are you suggesting this not be done during development? Is it bc while ESBuild is fast and runs in parallel, it's still only as fast as the slowest parallelized task, and in this case the slowest task is checking for type errors? And I assume checking for type errors is the slowest because it has to invoke an external resource, tsc?
Would it not make sense to have two development bundlers then? One for getting your code up and running quickly, and a second that outputs a dummy build artifact, but allows a more thorough production-like build that includes type checking (or other long running activities)? That way you get all the verification you would like, but don't pay a price on waiting for your code to deploy?
And yes, type checking is relatively slow, and also strictly extra work, since it's not required to make your code runnable.
You'll often see that people do still do a more thorough production build in their CI systems, but not necessarily by using a bundler that includes type checking; rather, they just run type checking and bundling as separate tasks. That way, you do indeed get all the verification you would like without having to delay deployment.
(To make it somewhat more confusing, a project like Vite does use a fast bundler (ESBuild) during development and a more thorough one for production (Rollup), but that's independent of type checking. It's more about the latter doing more optimisations, and the former merely making the code runnable by the browser.)
If you want, your build script can include
to type check before the build.Nothing in the above precludes using the compiler to typecheck the code, that's the primary usecase & what sibling is saying about thinking of it as a linter: if typechecking fails, don't build
https://www.npmjs.com/package/metro-minify-esbuild
Vite seems to be one of the more interesting CRA alternatives. Though it uses esbuild only for development, and Rollup for production builds. It'll be interesting to see how this develops, and if the fast bundlers keep catching up in terms of features without getting slower.
Is this for real? I mean, yeah, I don't think a CTO should be debugging build scripts, but hiring a great team, mentoring, aligning teams with a common technical vision, meeting with other company leaders to ensure the technical direction meets the needs of the business is an immense amount of work.
Best would be if we could actually measure "complexity" in a objective manner.
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.
Add to it being able to work in YOUR headspace and not have to bring other people in a large-ish team along with you and you can get stuff done.
I don't understand this fetishization of "everyone has nearly equal ability" in the face of tons of overwhelming evidence to the contrary.
I made a side project that I spent 1-2years building on and off and had people saying "wow I could never build that". That's bullshit. If they were of similar intelligence and put in a similar amount of time and effort I'm sure they'd be able to replicate what I did.
The luxury of being able to spend ample amounts of time on a project or idea is also massively overlooked.
Being born with high intelligence and favourable traits is not an achievement.
Good question. Take it up with the people wearing jersey's with Lebron James' and Aaron Rodgers' names on them.
There are people producing JS bundler and are comfortable and familiar with their toolset along with deep understanding of the problem. And they dont even come close to what is being described here.
Is this a bad thing to discourage? Perhaps one way to increase your output as a developer is to narrow your focus (rather than jumping on the latest framework or build system which require constantly re-learning new solutions to the same problem)
No. It's what I encourage people in my team to do all the time. In fact it's something I was also encouraged to do.
The full quote was:
"Become an expert in at least one thing in your job or preferably career, and do it while you have the time" (e.g. when you're junior and expectations are low, or not a manager).
"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.
I've worked in the industry for almost 30 years, and I've worked with a lot of people in that time. Those that you might qualify as '10x', all have had both of the qualities I mention.
I would not expect any of those people to switch languages and fields and still be a '10x' developer.
And yet… we do recognize that some people are impressively better than others at playing piano, running yards, fighting, and all sorts of other narrowly specific tasks.
It’s just that the more creative the task, the harder it to measure how much better someone is.
Look at someone like Yehuda Katz. Substantial contributions in ruby (merb, bundler), JS (jQuery core team, created Ember.js), and rust (created cargo).
But trying to elevate him or make him uncomfortable (he’s also a really humble dude), but just saying there are examples of polyglots that make substantial contributions.
I’ve found that in any tech company, while there are many people that write good code and do a great job, there are always a handful (even at a place like Apple) that truly push the industry forward and in certain directions, partly because of how they see years ahead, partly because they are supremely talented, and partly because they attract other really good talent just to work with them.
And we know many of their names. Folks like Brian Cantrill, Yehuda Katz, Fabrice Bellard, John Carmack, Bret Taylor.
They aren’t just good programmers. They’re constantly dwelling in uncharted territory.
I’m not advocating worshipping them, just stating that their talent and output is hell of a lot more than even 10x.
Maybe we can put aside whether or not there is No True 10x Developer. But there are certainly 0.1x developers, and even -1x developers.
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.
> or his output is actually not as high as it looks
I wish more products had landing pages that looked like that.
Parcel 2 was released as stable yesterday though and Evan has already updated comparison.
https://github.com/evanw/esbuild/commit/186446eae8cc8c7439eb...
Rome is also being rewritten in Rust, it's more of a complete set of packages that subsume Webpack, Babel and all the other parts of the JS / TS development experience.
Overall I’m pretty bullish on Rust tooling and integration within the JS/ Wasm ecosystem !
- Run yarn add next@canary
- Add to your next.config.js:
I'm sorry, but the node.js community needs to stop producing these stuff... it doesn't do anything better than all the webpack vs gulp vs parcel vs snowpack vs rollup vs how many bundlers again?
People have said say that same thing each time a new one pops up since Grunt 10 years+ ago.
If you're going to use a JS bundler written in Go, just stick to MAKEFILE...
> If you're going to use a JS bundler written in Go, just stick to MAKEFILE...
What?
[1] https://github.com/evanw/esbuild/releases
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 confusing to track. This, at least in my experience, has greater readability and is simpler to understand.
Having junior team encounter a webpack breakage === them spending as much time on tooling, as coding itself
Modern Web Dev is the cause of Webpack though. Over complicated things.
The watch rebuild time went from 3-5s (actually a lot when you save your code very often) to something like .5-1 s
The full build time went from 120s to less than 5s
Edit: though I guess if you include the sibling project swcpack, it covers the same ground. SWC itself doesn't though.
Esbuild is written in GO.
> Why is esbuild fast? > - It's written in Go and compiles to native code. > - Parallelism is used heavily. > - Everything in esbuild is written from scratch. > - Memory is used efficiently.
> Production readiness > - Used by other projects > - API stability > - Only one main developer > - Not always open to scope expansion
1: https://esbuild.github.io/faq/
[0]: https://github.com/evanw/esbuild/issues/1619