141–150 of 216 posts
Outsider question: why use Rollup when Esbuild exist? Is esbuild not enough for production builds?
Very pleased to see such performance improvements in the era of Electron shit and general contempt for users' computers. One of the projects I'm working on has been going for many years (since before React hooks were introduced), and I remember building it back in the day with tooling that was considered standard at the time (vanilla react-scripts, assembled around Webpack). It look maybe two minutes on a decent deve…
It is especially weird because JavaScript was not supposed to be processed at all! This is all wrong if you ask me. Web development should strive to launch unchanged sources in the browser. TypeScript also was specifically designed so engine could strip types and execute result code. These build tools should not exist in the first place.
That's no less a build step than concating, bundling, minifying, etc. When people say "I'm against processing code before deploying it to a web site" but then also say "TypeScript is okay though" or "JSX is okay though," all they're really saying is "I like some build steps but not others." Which is fine! Just say that!
I have a small React project using vite 7 and have the following in my config so that vite interprets ".js" files as JSX: // See https://github.com/vitejs/vite/discussions/14652 esbuild: { loader: "jsx", include: /.*\.jsx?$/, exclude: [], }, optimizeDeps: { esbuildOptions: { loader: { ".js": "jsx", }, }, }, Note the comment at the top. I had no idea how to come up with this config by checking the documentation pages…
Earlier quoted context omitted.
Got back in to react after a few years’ hiatus and I struggle to even understand what the point of Next is. Bizarrely the official docs even reference Next. Are people using react for non-SPA’s? Why?
Vercel has slowly taken over Facebook's position as being the employer of the main developers of React. There's a debate to be had over how much they 'control' it or not, but the fact create-next-app is the first recommended option on the official installation page now does show it's had an impact. 5 or so years ago, Next was a pretty solid option to quickly build up a non SPA, when combined with the static export fu…
As a side note, I'm slowly moving out of Next.js, as you said, is bloated, full of stuff that is just noise and that benefits them (more network requests more money) for little user benefit.
Right now for me the gold standard is Vite + Tanstack Router. (And Elysia for api/server, but thats unrelated).
Yesterday I stopped hating AI because it converted an old webpack project with impenetrable plugin settings to a single simple Vite config. I still don't understand how people used to think scripts like this are the proper way to bundle an app. https://github.com/facebook/create-react-app/blob/main/packa... vite is great, is all I am saying
800 lines config to compile code that's later interpreted is wild. I get the general idea behind having a script instead of a static config, so you can do some runtime config (whether or not we should have runtime changes to config is a different conversation), but this is absurd. I'm a big believer in fully reviewing all LLM generated code, but if I had to generate and review a webpack config like this, my eyes woul…
The LLM generated vite config is 20 lines
[flagged]
Earlier quoted context omitted.
Jobs’ complaint wasn’t actionscript the language, it was the security and performance nightmare of the Flash runtime. Though it’s hard to imagine what the web would look like if the language had become the standard. JS is a pain but AS was even less suitable for general purpose compute.
And at least the "performance nightmare" is an irony from today's perspective as the Flash player wasn't actually slow at all! It was the incapability of the Safari browser to handle plugins in a good way and on mobile devices. Today's implementations of mobile application, JavaScript heavy applications and websites are much much more performance heavy. ActionScript3 was a very suitable language.
I have a small React project using vite 7 and have the following in my config so that vite interprets ".js" files as JSX: // See https://github.com/vitejs/vite/discussions/14652 esbuild: { loader: "jsx", include: /.*\.jsx?$/, exclude: [], }, optimizeDeps: { esbuildOptions: { loader: { ".js": "jsx", }, }, }, Note the comment at the top. I had no idea how to come up with this config by checking the documentation pages…
The solution here is working for me: https://github.com/vitejs/vite/discussions/21505 Though sometimes oxc complains about JSX in JS when running vite, but it still works fine.
Another instance is the use of rollupOptions.output.manualChunks that now has to be rewritten, maybe that would be less frustrating to fathom.
I have a small React project using vite 7 and have the following in my config so that vite interprets ".js" files as JSX: // See https://github.com/vitejs/vite/discussions/14652 esbuild: { loader: "jsx", include: /.*\.jsx?$/, exclude: [], }, optimizeDeps: { esbuildOptions: { loader: { ".js": "jsx", }, }, }, Note the comment at the top. I had no idea how to come up with this config by checking the documentation pages…
Yeah, it makes you wonder how much computing power the industry has wasted over the years on tools that nobody questioned because "that's just how long builds take." We planned our work around it, joked about creating breaks, and built entire caching layers to work around it. Kudos to the Vite maintainers!
Build performance has been a pet topic for me for quite some time when I realized I was wasting so much times waiting for stuff to build 14 years ago. The problem is especially endemic in the Java world. But also in the backend world in general. I've seen people do integration tests where 99% of the time is spend creating and recreating the same database over and over again (some shitty ruby project more than a decad…
Yea, cypress has this in their anti-patterns:
https://docs.cypress.io/app/core-concepts/best-practices#Usi...
Dangling state is useful for debugging when the test fails, you don't want to clean that up.
This has been super useful practice in my experience. I really like to be able to run tests regardless of my application state. It's faster and over time it helps you hit and fixup various issues that you only encounter after you fill the database with enough data.