Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we switched from Webpack to Vite

blog.replit.com

Post reply on HN
Print view View original

221–229 of 229 posts

Re: Why we switched from Webpack to Vite

#221

Post by yepthatsreality »

root_axis wrote: post #122
yepthatsreality wrote: post #120

Earlier quoted context omitted.

It's not much different but yet it needs a solution built in another language to "build" it. I understand the process is not much different from other scripted languages but I find it funny that JS cannot reasonably do this itself. (p.s. I'm aware)

Well, it's wrong to say that it "can't reasonably do this itself" since JS building itself is actually the status quo and has been for years, this particular solution is just a new take with an aim for improved performance.

And they didn't choose JS to do it is the cherry on top.

Re: Why we switched from Webpack to Vite

#222

Post by edem »

rk06 wrote: post #216
edem wrote: post #196

Why do we need yet another tool? Why can't we just improve the ones we already have?

because 1. ES modules support has increased to all major evergreen browsers. 2. Esbuild has come out which shows faster results than tools (babel, typescript) 3. Improving current ones means supporting hacks and incorrect code patterns, which is not wanted. The above factors has resulted in multiple build tools with vite being one of them

None of these are my concern as a developer. I just want a tool that works. I'd rather take som duct tape and 5 new features I __really want__ than a fancy new tool that'll be the same mess 5 years later and has less features.

Re: Why we switched from Webpack to Vite

#223

Post by jitl »

nojvek wrote: post #189
jitl wrote: post #48

We just switched from TypeScript/ts-node to esbuild for server-side code at Notion; it's been great. Would love to see the same kind of speed wins for our clients :')

Do you prebuild and run or use some kind of node -r (module register). Btw I interviewed at Notion but didn’t make the soft skill bar. Big fan of the product.

We’re using a node -r esbuild-loader.js kinda thing with very simple mtime-based cache. It’s like 50 lines; we opted to write our own because we wanted the absolute latest version of esbuild so we could use the recent speed ups to the sync interface.

Re: Why we switched from Webpack to Vite

#224

Post by brillout »

eliseumds wrote: post #205
brillout wrote: post #193

Earlier quoted context omitted.

> It just isn't suitable for proper server-side rendering, we'd need access to chunk names at build time You can at later rollup hooks (it doesn't make sense to access chunks that don't exist yet). Actually, there are SSR frameworks being built on top of Vite such as SvelteKit [1] or vite-plugin-ssr [2] (vite-plugin-ssr is not a framework but gives you a similar DX than Nuxt/Next.js; I'm its author), and many people…

Have you seen SvelteKit's source code? It looks like a toy project. [1] vite-plugin-ssr can't even be integrated with Vue Router (I saw you're working on deep integration though). They're both very rigid, early stage endeavours. [2] What happens, for ex, if you used nested lazy components in those pages, are they going to be included in the server render as well? I mean, fair enough that there are people trying to do…

Sounds like you are being biased here.

I mean, if you think vite-plugin-ssr to be rigid, then Next.js should feel like a 2sqm prison cell to you ;-).

If you want more flexibility than vite-plugin-ssr then use Vite's native SSR API.

Whereas with webpack: good luck with 1. using two webpack configs (one for Node.js and one for the browser), 2. synchronising between these 2 webpack configs, 3. implementing server-side HMR; it's incredibly painful and can cost you many weeks of dev time... whereas Vite's SSR API does all of this for you for free.

Sure, things are early stage, but saying that webpack is "definitely" on top for SSR is wrong in virtually any possible way.

Re: Why we switched from Webpack to Vite

#225

Post by root_axis »

Daishiman wrote: post #218
root_axis wrote: post #217

Earlier quoted context omitted.

Nothing is universal, you're seeing what you want to see. I could say the same thing about django, flask, and web2py or numpy and panda, or trio and asyncio.

Django doesn't occupy the same space as flask; not in the same way React and Vue seem to. Web2py is nonexistent. Numpy is a basic linear algebra library and Pandas is a high-level tabular data analysis library. None of these things compete with each other in any meaningful way.

> Django doesn't occupy the same space as flask;

This is just wrong. Django absolutely occupies the space as Flask, this is pretty obvious, but you're splitting hairs to defend your argument - the bottom line is that a Python developer building a web application has to decide if Django or Flask is a better choice for their engineering needs, you wouldn't use both (though you could, same as you could use react and vue together).

> Web2py is nonexistent

This is totally wrong. You can selectively discard every example that doesn't meet your arbitrary standard of popularity, but I could just as easily discard a criticism of Vite which is far more "non-existent" relative to webpack than web2py is to Django

> Numpy is a basic linear algebra library and Pandas is a high-level tabular data analysis library.

Once again you're splitting hairs. Yes, Pandas and Numpy have different specialties, but there is clear overlap between them and a developer who is unfamiliar with the ecosystem wouldn't necessarily understand why e.g. they might choose pandas dataframes vs numpy arrays, and this dynamic is also true in the JS world where different packages have overlap but particular specialties that make one more attractive than the other depending on the needs.

Re: Why we switched from Webpack to Vite

#226

Post by netvl »

kall wrote: post #42
MintsJohn wrote: post #22

Webdev truly is one of a kind. Not only do you have your source code, you also have your build code, oddly dictating the organization of your source code. For extra fun, some libraries don't build with build system a, others require build system b, when you're lucky enough to have a working mix, changing build systems is better to be avoided. Of course periodically the officially blessed build system for your used li…

Have you seen the android build system? I mean what the hell is a gradle wrapper. At least js tools are configured in .json or .js files not in a special purpose programming language. I don‘t mean to discuss which system is too complicated and which is not just to point out a lot of real world build systems are on that level.

Android apps are written in Kotlin, and Gradle config is also written in Kotlin. How come it is different from the JS situation? Even though Gradle can be configured in Groovy, and Android apps can be written in Java, it is still the same ecosystem - basically, the situation of TypeScript/PureScript/WhateverScript and JavaScript.

Gradle wrapper is just a name for a script (automatically created by Gradle btw) which allows one not to have any kind of Gradle-related tooling installed on the machine (basically, to run build tasks you execute `./gradlew someTask`, and it takes care about downloading and running the appropriate Gradle version) - which I think is a clear benefit over the fact that you need to have `npm` installed system-wide or via a tool like NVM in order to build JS projects.

Gradle has its own warts, and a lot of them, but at least there is only one major build system in this area, and it is simply impossible for a library published to a Maven repo to be dependent on the build system it is built with.

Re: Why we switched from Webpack to Vite

#227

Post by nojvek »

jitl wrote: post #223
nojvek wrote: post #189

Earlier quoted context omitted.

Do you prebuild and run or use some kind of node -r (module register). Btw I interviewed at Notion but didn’t make the soft skill bar. Big fan of the product.

We’re using a node -r esbuild-loader.js kinda thing with very simple mtime-based cache. It’s like 50 lines; we opted to write our own because we wanted the absolute latest version of esbuild so we could use the recent speed ups to the sync interface.

Did you open source it? Would love to use it as replacement for ts-node.

Re: Why we switched from Webpack to Vite

#228

Post by gwn7 »

dmitriid wrote: post #38
gwn7 wrote: post #14

I wonder how this compares to a proper manual Webpack configuration. Comparing it to CRA isn't really helpful to me, as CRA is already known to be very slow. I would consider trying it if it has significant performance benefits over a manual Webpack config, especially one making use of esbuild-loader ( https://github.com/privatenumber/esbuild-loader )

> compares to a proper manual Webpack configuration What is a "proper webpack config". It's such a complex and arcane beast, that I doubt anyone could really figure out a "proper" way to do anything with it.

> It's such a complex and arcane beast, that I doubt anyone could really figure out a "proper" way to do anything with it.

I'm sorry but you sound ignorant here. There are a lot of projects that can get away with around ~200 lines of simple Webpack configs.

And yes, Webpack is complex but an important part of that complexity is coming from the intrinsic complexity of the problem we call module bundling. You can see this complexity in older bundling solutions as well.

Regardless of whatever you'd like to believe, a lot of people figured out proper ways to do a lot of things with it. You may not be willing to deal with this yourself, that is understandable, but saying what you are saying about the most popular bundling tool in the ecosystem is a bit much.

I myself regularly write manual Webpack configs and usually ~200 lines of simple configs are enough for me, as well as very performant. And I know a lot of people like me.

Webpack is not perfect, and I'm not really a big fan, but come on. I guess what you have a problem with is people who write terrible Webpack configurations rather than Webpack itself. Maybe think about it.

Re: Why we switched from Webpack to Vite

#229

Post by jupp0r »

Shorel wrote: post #220
jupp0r wrote: post #200

Earlier quoted context omitted.

CMake only finds the dependencies, how do they get to your computer? Do you link statically or dynamically? What compiler toolchains are these libraries built with, do they use the same standard library as your code or different ones? When you want to cross compile, how do you find libraries for your target architecture? Conan makes much of this easier, but is not really suited for large software projects with the pr…

Well, I don't cross compile. If I need to test a new OS, then I get the VM and compile it there. About dependencies, if they can be found in the package manager then it goes that way. Else, they are a git submodule. The most problematic has indeed been the C++ MySQL connector, because it has changed a bit over the last five years, so I had to edit the #include lines in the source code files.

Chrome for example does not currently compile on darwin-arm64, cross compiling from darwin-x64 is the only way to build that target.

When you are using git submodules as package manager, what do you do if the dependency doesn’t come with CMake files, but with autotools for example?

I think bazel is becoming a great solution for these problems if you align with their philosophy.

Post reply on HN