Projects are rarely about the thing that I want them to be about. In my recent Headless WP w Go Front-End project, the focus was on learning Go and Go’s templates. Instead it turned into the nightmare of trying to slap WordPress into Docker Hub’s official PHP container. Nightmare.
I’m building a strong suspicion that my Go Bakersfield Technology project will be about me fighting with Vite. I spent the past few days fighting Templ. I’ve fought Webpack and Parcel on every project I’ve ever used them on. Why wouldn’t I fight Vite?
Vite seemingly assumes that you’ll build an SPA. It seemingly assumes that anyone reading the config is using it as a reference and already understands it. In fairness, this kind of documentation is very challenging to do well.
The Great Churn Machine
The JS ecosystem in particular places little value on teaching to solve commodity problems, yet it places a high value on building packages to solve problems in a general purpose way. Unfortunately, the JS ecosystem also places high value in keeping up with trends and “Rethinking Best Practices.” When Remix started advocating for JS to be closer to web, SWR followed. And that’s why I can’t upgrade my SWR project. React has gone from createClass() to ES6 classes to hooks to server components. Vite’s magical v3 back to less-magical runes.
JS hype beasts will say that this is a Good Thing, that this shows that the ecosystem is finding better ways to program. I call hogwash. The level of npm-ifacation of programming deprives developers the opportunity to learn how to build better patterns of programming themselves. This responsibility is pushed to the maintainers, who then bestow us with their superior wisdom.
I’ve long held the opinion that open source has killed Design Patterns. I don’t need to master the strategy pattern when Laravel’s file abstraction does that for me. But it’s on a different level in the JS ecosystem. You can’t just make a GET request with useEffect–you’ll do it wrong! You have to use React Query. You can’t just validate forms–you won’t nail the UX! You need to reach for one of a dozen form libraries. It’ll be far more productive: don’t worry about the hours or days you spend comparing these libraries, just to pull the trigger and find that it makes your specific use-case almost impossible.
The argument is that these tools will raise the level of abstraction and make software quality better. In front-end web development in particular, I don’t think there’s evidence of this claim. Far too many developers use paragraph tags as links and divs as buttons. The web fundamentals are completely missing, and there’s not a tool in the world that can fix that. The only way to fix this is by practicing web fundamentals.
This is veering dangerously close to a “you need to learn JS before you learn React,” but this really isn’t that. There is no right order to this thing. This is advocating for using libraries like React, Redux, Form Hook, and React Query sparingly. Learn HTML. Try to build some stuff with JS every now and then.
That said, this is ignoring the main benefit of the npm-ification of web development: documentation. Most internal documentation just doesn’t exist, and a lot of application code is so bad that its incomprehensible. This story also isn’t great with JS packages though: most packages don’t have an easy way to view old versions of their docs, and API changes between versions can be drastic. I have no answers.
I wasn’t really expecting this to turn into a full-blown anti-JS rant, but here we are. Anyway.
Back to my problem: integrating Vite
While Google was basically useless for finding examples of how to integrate Vite with a back-end project. I searched for guides for how to integrate Vite with Express, Rails and Go. Instead of examples, I found convoluted, general-purpose packages. I really just wanted a basic example, but the documentation’s Backend Integration page fell massively short of providing useful code.
I tried reading through the source of the Laravel Vite plugin. The various function calls made it too non-linear for me to understand, so I went into a Laravel project and logged out the config that Laravel built. The config wasn’t a complete Vite config, but instead just the plugin settings, which presumably would be parsed by Vite elsewhere.
After failing at several more Google searches, I thought to check the repo for examples. I found a backend-integration folder in the playground directory. Apparently the purpose of this directory is not to serve as examples but instead for running tests. Annoying.
The playground isn’t documented, so it’s difficult to suss out exactly what it’s supposed to do. I’ll spend some time with it soon to see if I can figure it out and use it to solve my immediate problem. My hopes are not high.
I’ll end this post with some thoughts I posted on Twitter while I was writing this.
Noise in F# 