I wish it was easier to use no framework at all, no angular, vue, react ... but still benefit from npm/yarn package management, development server with hot reload and maybe even a test runner. As someone who only occasionally needs to build relatively simple frontends against existing APIs, using full-blown angular/react/vue just seems so wasteful. But the last time I tried to put such a setup together, I just couldn't make all the parts (yarn, webpack, jest, ...) work together, and lots of the various plain JS "starter" projects out there are broken as well. It's pretty bewildering – shouldn't this sort of thing be easy? Is there some kind of a vue-cli for frameworkless projects, or how do people get started building more lightweight web apps?
“Feeling wasteful” is not a logical evaluation of the technology. Does it feel wasteful when you used an incredibly powerful computer capable of almost anything to post a text comment to a website in the same way you could have 20 years ago?
VueJS is very lightweight and loads almost instantly. It runs on even very old computers well. Native JS will never be able to compete with frameworks because frameworks have the ability to rapidly innovate and try new things without worrying about having to keep them around forever.
IMO the browser should become something like a CPU where it provides the low level components to do anything and the website provides the framework to make it easy.
It doesn’t “feel wasteful” to use C or Python to print hello world when it could have been done in raw ASM.
>
IMO the browser should become something like a CPU where it provides the low level components to do anything and the website provides the framework to make it easy>
Maybe webassembly is the thing that you are looking for?
WASM is where I think the web should be heading. It's been shown time and time again that designing good high level interfaces is very hard and there will always be a better design out later. Platforms like web browsers are not able to innovate like libraries can.
JS has multiple implementations for date interfaces and they are all flawed in ways. Rust decided that date handling should be the job of 3rd party libraries which have the freedom to drop bad ideas and break compatibility for the goal of a constantly improving implementation.
One thing I really like about the current web is that I can still inspect and dissect almost everything with just the developer tools. I couldn't do that with WASM blobs, which of course the ad industry would absolutely love since then they can just obfuscate their binary blobs and hide anything in there, legal or not, malware or not, and it's no longer feasible to rip it out.
They feel wasteful because what I'm doing really is pretty simple in most cases. I can easily build that in plain JavaScript and it feels wasteful to pull in all those layers of abstraction and write Vue components where plain JS ends up being shorter and easier to reason about.
It sounds like you were trying to use a bunch of tools without understanding what the tools actually do.
That said, webpack and jest are bloated messes and easy to break. I'd say just stick to esbuild as your lone dev dependency and get to work writing your framework-less project. Otherwise, take a look at the vanilla Vite template: https://vitejs.dev/guide/#scaffolding-your-first-vite-projec...
If you find that you want a framework (which may be inevitable), give Mithril.js a shot. It's very unopinionated.
These days I tend to only use esbuild. For testing, I use my own homerolled test utility and the built-in Node.js assert module, or uvu.
> It sounds like you were trying to use a bunch of tools without understanding what the tools actually do.
That's true, so far I've only interacted with these tools in vue-cli-generated projects and the like.
I'm not sure if "framework-less" is the right term even. I'd like to be able whip up quick UIs with a few libraries where needed without too much unnecessary complexity. I find there's little benefit in forcing simple UIs into Vue components, but juggling libraries without npm/yarn is cumbersome, too.
I'll have a look at Vite and Mithril.js, thanks for the pointers!
I've had some success with npm, snowpack, mocha, typescript as that sort of stack for more "vanilla" efforts that feel rather more "modern". I think mocha is easier and cleaner than jest. I like keeping all of my transpilation to just Typescript without needing a massive Babel install/pipeline. snowpack (https://www.snowpack.dev/) right now I think is in a sweet spot of a better "ES Module native" developer experience than webpack and has better defaults when left unconfigured. (So much so that while there are snowpack templates/generators provided by the project I mostly don't use them other than for reference.)
Why can't you use npm modules via a CDN like https://unpkg.com/? Add a JS file that downloads whatever package you need and then use them in that JS file? Have your HTML page load that file via a script tag (you can also have the HTML file load the packages in a script tag) and then you're off to the races.
That's what I did before npm came around, but proper package management, hot reload, test runners etc. are creature comforts I'd hate to do without these days. Keeping dependencies up to date when getting them from a CDN is pretty cumbersome.
I think what you're missing here is that as soon as you start answering the questions necessary to get those tools to work together right (for example: how do you split files? how does your routing work? how does injecting replacement code for hot reload work?), you end up with a framework.
Of course any plain JS app I'd write would end up being a kind of nano-framework; for me, the difference is in the unnecessary complexity this approach would avoid. Vue, React etc. bring a lot to the table; sometimes I'd rather just write that tiny, less-than-ideal nano-framework because it's good enough and pulling in tons of dependencies feels unnecessary and might actually increase my app's attack surface. I'd like to keep the creature comforts of npm/yarn etc. though.
