Guidelines on how to author code with less dependencies

[reggi]

Context

I've been messing around with creating a calendar scheduling app. I wanted a simple way someone could pass in time-slot availability, this is a bit annoying to do via just JSON with intervals and breaks in between and days of the week that sort of stuff.

Something like this:

Week
  .weekdays(Span.nineToFive.every(30).excludeSpan(Span.lunch))
   .weekend(Span.lunch.every(30))

What's the best way to author a Deno module?

While I know there's many ways to do any given thing, It left me thinking what's the best way to author a module so that people using it don't have to download all the files in the module. Let me give some examples:

1. If I wrote everything in one file you have to all the code, even unused code, but one request
2. If I wrote every function / class in separate files you'd have only code you need, but many requests

So there's a spectrum and both ends are not great. I'm curious if there's a different way to look at this? Something I'm missing.

If people author code-in-classes (which I tried to stay away from in that example, you have to download the entire class, you can't really provide parts of a class. So functions-first is necessary. Classes in my example are just glue / wrappers around the functions (except when classes get passed around, which I'd have to undo, functions can't take classes as input).

Options

1. A linter
2. Dynamic Files

Linter

A linter that specializes in guiding authors to best practices when it comes to authoring code with less dependencies would be an amazing alternative. Advising people to not author hefty classes that all connect directly?

Dynamic Files

This would mean the url builds a single file with all the code in it.

This is an idea adjacent to the post here about hosting your own deno module server. I'm dubbing this in the category of "#serverMagic" (id like a whole discussion on different "#serverMagic" techniques).

This idea would be source-tree-shaking the modules served, with the URL you have the ability to target a specific export within a file via query parameter, or even path, all bets are off when your generating dynamic TS.

I'm equally attracted to the idea of dynamically generated modules from the server and of the mind that you should just serve a single file no tricks.

I'm curious what other people's thoughts are.

[jtoppine]

Question is a bit confusing because deno is purely server side. But you talk about requests which are a client side concern. I think the best approach for organizing deno/serverside code is clear. Client/browser side code delivery can be a different animal.

Node and other historical platforms have steered us to create all kinds of over-engineered solutions and magic; we forget that with modern javascript and deno, we can forget all that and keep things very simple.

• For server side deno code, forget all build steps, module servers and other contraptions. The standard, built in ES way of import/export is all you need. Just use separate files everywhere where it makes sense for readability of code and separation of loosely related functionalities. Deno takes care of caching and loading everything efficiently. When everything is organized neatly to small modules, you get pretty good tree-shaking for free, as any module you use (import directly), will only load the dependencies it needs, all the way down the dependency graph. You should author your libraries so that users can import modules for the specific functionalities they need, instead of importing huge all-inclusive module that contain all of the project. This is easy with standard ES import/export stuff.

• For non-deno, client side browser code, arguably the same approach can work well, if you serve invidual files with proper caching headers and tuning other aspects of how you serve files. If your client side app is starting to get slow, you can look into some bundling or building solutions that can take a dependency graph and create a monolithic file out of that. But that only if/when the standard approach starts to cause problems and tuning your server and caching isn't enough.

• For code that is common to both deno/server and the client/browser, the same approach works, as long as you have proper entrypoint modules, and use fine grained dependencies/separation of code, so that client is not dragging server-specific dependencies, and vice versa.