It's purely demo code. I personally subscribe to the "modules should be deep" school of thought (Ousterhout).
> tests test the same thing twice: once with a unit test, and once with an integration test
Again, purely a demonstration that Playwright handles E2E, integration, and unit tests equally well, not an endorsement of testing the same thing twice. Note the absence of jest, mocha, etc.
> somehow better
Hopefully, you can achieve similar gains to [0], e.g. 50% less time to load and 95% less bandwidth in that case, by avoiding frameworks and other runtime dependencies.
> more sustainable
Hopefully, code produced this way is less susceptible to framework churn and other changes in the environment. Also, knowledge gained by following the approach will be about the standard web platform, not about a particular framework (and version thereof).
FWIW Vite would indeed handle the responsibilities of sass, typescript (partly), s4d, terser, cbst, vendoring (but not eslint, stylelint, prettier, playwright, c8, exdom). It's certainly a good option!
One thing to consider is that Vite promotes a plug-in ecosystem, of which many plug-ins are maintained by individuals. I think this increases the chance for incompatibilities over time significantly.
Also, having more documentation is not necessarily good. Each tool in Vanilla Prime has its own documentation, but they are self-sufficient. Vite combines lots of things in the background, which already have documentation, then adds their own documentation, and often requires additional plug-ins that take care of integration.
Maybe Vanilla Prime could be the car you can repair yourself, whereas Vite is the modern car that is so tightly engineered that repairing without external support becomes difficult.
I like to look at it as a spectrum from "truly vanilla" to "same old bloated". I've previously looked at the dogmatic vanilla approach here [0] and wanted to try something else this time, on a different location on that spectrum.
In all honesty, I've never got to properly look into Vue, but it has been mentioned multiple times in the comments. Time to study it I guess :)
The "src/js" directory was initially called "src/scripts" but it kind of clashes with the top-level "scripts" for the shell scripts. Agreed it's not ideal though.
Not sure who said it but I was aiming for the "Simple Ain't Easy" trope here ;)
I agree that the JS build scene can be churning a lot as well (e.g. ESLint's recent config changes), that's why I tried to make everything as orthogonal and disposable as possible.
I was pondering if "vanilla" should be part of the name as well. In the end I felt I got sufficiently close to the vanilla flavor you describe, and the name conveys the "as little as possible" approach. Hope it's not too misleading!
I do like the "plus" idea, now that you mention it! Will think about it :)
Vanilla JS has also been a long-time joke about how modern javascript has advanced far enough not to need libraries for a lot of stuff people still reach for: http://vanilla-js.com/
reply