esbuild VS Next.js

Vite is not a bundler but a frontend tool that intelligently uses ESBuild and Rollup for their best use cases.

esbuild 0.21 is out! (https://github.com/evanw/esbuild/releases/tag/v0.21.0) by Evan Wallace Decorators for the win.

Vite is currently the best build tool for bundling Front-end applications. It's so fast because it uses esbuild under the hood. Vite hot reload is the fastest among other development tools I have used.

A big part of my work revolves around JavaScript tooling, and as such it's important to keep an eye on the ecosystem and see where things are going. It's no secret that recently lots of projects are native-ying (??) parts of their codebase, or even rewriting them to native languages altogether. Esbuild is one of the first popular and successful examples of this, which was written in Go. Other examples are Rspack and Turbopack, which are both Rust-based alternatives to Webpack, powered by SWC ("Speedy Web Compiler"). There's also Rolldown, a Rust-based alternative to Rollup powered by OXC ("The JavaScript Oxidation Compiler"), but Rollup itself is also native-ying (??) parts of their codebase and recently started using SWC for parts of their codebase. And finally, there are Oxlint (powered by OXC) and Biome as Rust-based alternatives for Eslint and Prettier respectively.

Angular 17 introduces a significant performance boost by harnessing the capabilities of esbuild, a swift JavaScript bundler. This integration optimizes the build process, reducing build times and enhancing the overall performance of web applications developed with Angular. Developers can now expedite the application development cycle and deployment, leading to a more seamless development experience.

At first we wanted to just get rid of all the helper utilities. Keep only the kernel, but this would mean a loss of backward compatibility. We needed some efficient code processing instead with recomposition and tree-shaking. We needed a bundler. But which one? Our testing approach relies on targets, not sources. We rebuilt the project frequently, speed was critical requirement. In essence, we chose a solution from a couple of among all available alternatives: esbuild and parcel. Esbuild won. Specifically in our case, it proved to be more productive and customizable.

During my search for deploying Lambdas via GitHub actions, I came across a tutorial that utilized ncc for converting TypeScript and bundling. While ncc is effective, I discovered esbuild, which proved to be significantly faster and perfectly suited to my requirements.

The advent of esbuild, the native support for ES Modules in browsers, the widespread adoption of import map, the emergence of tools like Native Federation, and the Nx ecosystem all combine to forge a flexible and well-maintained Micro Frontend Architecture.

EsBuild is a relatively new, blazing-fast JavaScript bundler and minifier. It stands out for its high performance, significantly speeding up the build process in development pipelines.

Current state of web development for some time now includes JS frameworks and libraries springing like mushrooms after the rain. Among these, Next.js has emerged as the most popular choice for any developer that wants to build a beautiful SEO-friendly website. However, as its popularity grows, I noticed Next.js websites are beginning to look eerily similar. In this article, we'll explore the reasons behind this and is this bad or maybe even a good thing.

Further Reading/Resources React Documentation: React Official Site Angular Documentation: Angular Official Site Vue.js Documentation: Vue.js Official Site Svelte Documentation: Svelte Official Site Next.js Documentation: Next.js Official Site

Repository: Next.js

Next.js: npx create-next-app@latest

Remix is a very cool React-based framework that makes the final jump back from the browser to the server. After starting with SPAs that fully ran in the browser, Next.js got the idea of rendering React components in the server, reducing the initial load time and improving crawlability. Remix takes this a step further: while Next.js cannot render dynamic content on the server, Remix can. As a user, this means even faster loadings times for any kind of dynamic content, and as a developer, you don't need to think about server-side vs client-side components. You just write React code, and it works.

Here is the tricky situation and that's why CRA is in a semi-dead state, it has not been deprecated but isn't receiving any updates not even security updates, along with that the new React.dev documentation doesn't mention CRA but suggests using React meta-frameworks like Next and Remix for new projects. You can read more about React's reasoning for it in this github issue discussion.

Probably the most known example https://github.com/vercel/next.js/discussions/19065

It was not an issue if you host in Vercel, as they provide the image optimization as a premium feature.

Implementing the requested feature would make the framework much better when self-hosted elsewhere. But there is neglection to resolve the issue. This is just one case.

This Reactjs version also includes React Server Components, so you can easily render components on the server. If you’re familiar with Next.js, whose components are server components by default, this is the same idea. Server components have advantages such as faster page load time, better SEO optimization, and overall better performance.

Next.js - for creating the application’s user interface and backend.