Performance improvements after dropping external pipeline and Webpack for Vite Ruby

#1

I’ve just written up a few blog posts about my attempts to implement Vite with Middleman. The first post walks through setting up Vite with the external pipeline and then I came across Vite Ruby which looks great so I wrote another blog post which talks through that setup and that’s what I opted for in the end.

Here is a brief summary of the improvements I saw over my original Webpack setup.

  • 171 fewer dependencies - 14% improvement
  • 4.08s faster dev server - 49% improvement
  • 13.65s faster build - 65% improvement
  • 35.8MB smaller Netlify cache - 15% improvement
  • 14.1kb less JavaScript shipped overall - 26% improvement

I really like the new setup and wondered if anyone was using Vite with Middleman and what their experiences were?

2 Likes
#2

Thank you so much for writing these!

I am wondering if you have a starter repo with these settings? I tried to follow the blog post bit by bit but am not sure I have all the pieces or if I’m doing it right?

Also, I noticed you run vite and middleman separately - why did you choose that vs using vite as an external pipeline?

vite: bin/vite dev
web: bundle exec middleman serve
#3

Hi @andreimoment, no problem at all, glad you liked them!

I don’t have a started repo but feel free to view the repo for my personal website which is using these new settings. Give me a shout if there’s something you’re stuck with as I might not have explained it well in the blog posts or quite possibly left something out!

The main reason for splitting out was that Vite Ruby was really able to handle everything as a separate build system and had a lot of useful Padrino helpers plus performance improvements which meant I didn’t need to use the external pipeline. From what I understand, the external pipeline also requires the files that are handled by your asset bundler to be output to temp files so Middleman can read them. This means they have to be bundled which loses the benefit of Vite in dev mode.

#4

Looking at the repository - where are you compiling scss to css? Middleman’s built-in asset pipeline?

#5

Hey :wave: I ended up swapping out SCSS to use PostCSS because it works out of the box with Vite. There’s more detail on it in the first post but the config is in postcss.config.js. I didn’t know much about PostCSS before but I added plugins to replicate the features I was using in SCSS and it works really well.

#6

I see. Am I reading correctly that this postcss co fig let’s you process all your scss files with dart-sass ?

Asking because I don’t see anything related to scss in it and you mention that your files are pure css.


module.exports = {
  plugins: [
    require("postcss-import-ext-glob"),
    require("postcss-import"),
    require("postcss-preset-env")({
      browsers: "last 2 versions",
    })
  ]
}
#7

Hey, sorry for the late reply I’ve been away on holiday. I now no longer have any scss files at all and have no need for dart-sass or node-sass because of that. Everything is just handled by postcss.

My scss files previously were just pure CSS and the only scss feature I was making use of was @import statements. For me, then switching these scss files involved just renaming them to .css and then using the postcss config above. The previous scss use of @import could then be replaced in postcss by using postcss-import