Building Node.js applications without dependencies

Somehow in my career I&#x27;ve never managed to develop the hatred for dependencies and upgrades that so many seem to have.<p>What&#x27;s the big deal?

I’ve tried something similar on the frontend side: I decided to build a UI for Ollama.ai using only HTML, CSS, and JS (Single-Page Application). The goal is to learn something new and have zero runtime dependencies on other projects and NPM modules. Only Node and Parcel.js (<a href="https:&#x2F;&#x2F;parceljs.org&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;parceljs.org&#x2F;</a>) are needed during development for serving files, bundling, etc. The only runtime dependency is a modern browser.<p>Here&#x27;s what I have found so far:<p>- JavaScript (vanilla) is a viable alternative to React.js<p>- HTML entities (UTF-8) are an alternative to, for example, font-awesome<p>- Parcel.js is great for bundling cross-browser compatible Javascript apps: simple to install and no configuration needed. By default Parcel.js supports every browser having 0.25% or more of the total amount of active web users.<p>- The HTML template tag and JavaScript work well as a replacement for template libraries like Pug<p>- ChatGPT4 is great at writing the skeleton code for a project<p>Future plans include experimenting with `node:test` for testing.<p>I would need to add external libraries to fully support the following features, but I think I will continue on the zero-dependencies path:<p>- Sanitizing HTML<p>- Code highlighting<p>- Markdown rendering<p>The code can be found here: <a href="https:&#x2F;&#x2F;github.com&#x2F;christianhellsten&#x2F;ollama-html-ui&#x2F;">https:&#x2F;&#x2F;github.com&#x2F;christianhellsten&#x2F;ollama-html-ui&#x2F;</a>

I have a question for you all:<p>When you&#x27;re building something and you notice one of your dependencies has a bug or is missing a key feature that you need, do you (a) PR the fix into the dependency and then try to &quot;harrass&quot; the maintainer into merging it for you, (b) publish your own fork of the dependency with the necessary fix, (c) inline the source code for the dependency into your project, effectively taking it on as if it&#x27;s your own code, (d) completely rewrite the dependency either as a separate package you control or built directly into your own project, or (e) code around the problem &#x2F; do a hack?<p>I find that often maintainers are so over-worked that it&#x27;s practically impossible to get a merge in a timely manner, and this leads me to rely on a fork until the PR eventually gets merged. However, I think creating a new package under either your own ownership or the company you work for is often really bad as it can become a kind of hidden technical debt. Nowadays, I definitely consider inlining as a way to capture ownership of the technical debt in a way that is highly visible, but this can add 100s or 1000s of lines of code to a project and if eventually the upstream project moves on you don&#x27;t get the benefits of their changes without removing the inlined code and untangling any changes that were made to it.<p>The only other approach I&#x27;ve seen is the &#x27;hack&#x27; approach, in which you try to dodge the bug or semantic issue. Honestly, that might be the right thing to do in some situations, but it isn&#x27;t very hygienic within a long-term project (unless you carefully maintain a TODO list of things that need &#x27;correct&#x27; solutions).

We&#x27;ve made a starter template with minimal dependencies available at <a href="https:&#x2F;&#x2F;github.com&#x2F;stormkit-io&#x2F;monorepo-template-react">https:&#x2F;&#x2F;github.com&#x2F;stormkit-io&#x2F;monorepo-template-react</a>. Instead of opting for frameworks like next.js, you have the flexibility to use this template, which is platform-agnostic.We have another template built with htmx, outlined in detail at <a href="https:&#x2F;&#x2F;stormkit.io&#x2F;blog&#x2F;building-dynamic-web-applications-with-ssr-and-htmx" rel="nofollow noreferrer">https:&#x2F;&#x2F;stormkit.io&#x2F;blog&#x2F;building-dynamic-web-applications-w...</a>. You can find the corresponding template at <a href="https:&#x2F;&#x2F;github.com&#x2F;stormkit-io&#x2F;vite-handlerbar-htmx">https:&#x2F;&#x2F;github.com&#x2F;stormkit-io&#x2F;vite-handlerbar-htmx</a>. I mainy work with Ruby and Go. I have some Nodejs projects like discord bot and whenever I update my dependencies something breaks. I find that managing dependencies in ruby and go is comparatively smoother for me.

I’ve been writing all my side projects without dependencies or only with ones that have no dependencies themselves if I need to do a proof-of-concept or idea and don’t want to write out the whole thing. It’s been so so educating, so fun, I learned a million things. Why companies overwhelmingly choose and allow to rely on 3rd party source code, that needs its own lifecycle support, especially for own domain logic, is not clear to me at all.<p>Sure some specialist tooling is high quality and you should then contribute to it (if it’s in your critical path), but the advantage that is lost by not betting on the platform and properly learning it is huge.

Was curious if author considers node libs like `http` a dependency and the answer is no they don&#x27;t. Looks like they&#x27;re defining a dependency as an npm module, which seems pretty fair.

The article is interesting, though a little messy in its structure.<p>I also don&#x27;t get what the idea is of the JS testing: &quot;I just want to know if some content is or isn’t rendered&quot;. Isn&#x27;t the easiest way to do this to make a request to the URL via the browser and see for yourself? Or am I being unprofessional?

The author says:<p>&gt; Normally, I use express as a webserver, and I use jest for testing. ... Naturally, without dependencies, I can’t use any of these things.<p>But the examples are still using Jest from the look of it.