DEV Community: theScottyJam

The "write code you can read at 3am" phrase (and similar variations) is getting a little old. Sometimes it's better for code to be more complex if it helps DRY it. I'm glad we don't blindly DRY everything anymore, but the opposite extreme is also bad.

theScottyJam — Sat, 27 Dec 2025 22:20:38 +0000

"exceptions are for exceptional behavior" makes no sense. People realize that "exceptional" means "uncommon", right? If you find out people rarely use a particular feature, you go in and change the code path to an exception, and vice versa? I hope not.

theScottyJam — Tue, 12 Aug 2025 14:38:22 +0000

"multi-paradigm" language is a bit of a mis-nomer that implies explicit support for many paradigms, letting you pick your favorite to use. A better name is "no-paradigm-in-particular". They mix ideas from different paradigms and expect you to do the same.

theScottyJam — Sun, 13 Apr 2025 21:48:16 +0000

In Defense of Using Large Frameworks for Small Problems

theScottyJam — Mon, 10 Feb 2025 00:03:53 +0000

This article is actually quite unlike me - I'm usually someone who advocates against using tools or dependencies when you don't really need them. Stay away from micro-libraries, just copy-past something you find online instead. You probably don't need Lodash in your project - I even made a webpage full of built-in ways to replace every individual Lodash functions with native JavaScript counterparts. But when it comes to frameworks, well, the irony of it all is that even though my little webpage is just static content, I still used a larger framework, and I don't regret it.

There's been a growing outcry against using frameworks on small problems, especially static webpages, and I'm grateful that this pushback exists to help us remember there's other options out there, but if I'm being honest, in many scenarios, the other options just aren't that great. Let's discuss some of them.

No Framework

There are two main things that frameworks give you:

A templating system, to let you easily build a tree of HTML, sanitizing your data before inserting it to help prevent XSS attacks.
A reactive system that allows the DOM to be automatically updated based on changing data.

Without a framework, what would normally be a trivial item can quickly escalate into a complicated, error-prone task. Want to see what I mean? Try making a function without a framework where, every time you call it with a list of user objects, it will render or rerender a table of users. The user objects can be as simple as { "id": 123, "name": "Cookie monster" }. Did you do it? Did you do it right - if you have content selected when this update function gets called, will it stay selected? If you were to add checkboxes to each row, would the checkboxes stay checked after a rerender? Without a framework, a task like this takes quite a bit of intense code. With a framework? Well, in React's case:

const UserList = ({ users }) => users.map(user => (
  <p key={user.id}>{user.name}</p>
));

Some other frameworks may have a bit more boilerplate required to define a component, but they all let you perform this actual task in a relatively terse and easy-to-read fashion.

The opposing voice might argue that bringing this sort of thing up is unfair - framework-less development should only be done on static content, to which I would respond that it's more nuanced than that.

My Lodash replacement's page only has static content, but it could grow to be more interactive over time. For example, at the moment I display all examples in JavaScript, but one day I could choose to add a toggle option to let you view the examples in TypeScript instead, or perhaps a button to display unit tests for the code samples, and so on. An otherwise static webpage can grow and receive interactive behaviors over time. If the website's content was written as a bunch of traditional HTML pages without components, then each time I needed to add these kinds of dynamic behaviors, I would need to do refactor quite a bit to componentize pieces of the webpage so it can support those new behaviors. Even some of the existing behaviors wouldn't be possible if I didn't organize the code by components - when you click on a Lodash function, it'll quickly fade content in using a pop-over side-panel. It doesn't require a full page reload. Perhaps in many scenarios this kind of SPA-like behavior is overkill, but for this webpage, I explicitly wanted users to feel as little friction as possible when navigating between different the different Lodash function alternatives.

Web Components

Just use Web Components! They're like frameworks, except native!

No, they're not.

Remember from earlier the two things I mentioned that frameworks give you?

A templating system, to let you easily build a tree of HTML, sanitizing your data before inserting it to help prevent XSS attacks.

A reactive system that allows the DOM to be automatically updated based on changing data.

Yeah, Web Components don't do either of those things. The vision is that one day they would, and I can't wait for a future where JavaScript has the most important parts of frameworks built-in, but that day isn't today.

Today, what web components give you is:

encapsulation, which is admetidly pretty nice, although they're still working out a couple of kinks related to accessability.
A standard way to define a components so different frameworks can talk to each other, which kind of works, but it is also such a pain to define components this way, use these components, and interop with them. In many cases, it would actually be easier to just make your own ad-hoc component design than using web components. The issues are, in part, because they're trying to mimic the behavior of native HTML elements, and native HTML element lifecycle-management and data-passing is actually quite complex. Now that we get to define native-like elements, we get to inherit all of that complexity, and since frameworks get to interop with them, they too inherit the same complexity. Loads of fun.

Anyways, lots has already been written on this subject, so I won't dwell on it further.

Server side rendering

...is limiting.

Some of the afore-mentioned tasks that are difficult to do without a framework are completely impossible with traditional server-side rendering. Again, consider how I would dynamically populate a pop-up side-panel with content - how would you do that with server-side rendering? An iframe perhaps? That would be quite the hack for an everyday task.

And again, things like being able to toggle between JavaScript and TypeScript examples would, what, require a full page reload and a dedicated URL?

Then there's the fact that this is a GitHub page. GitHub pages, like many other platforms, only lets you host static files. It's much more difficult to find a place that's willing to run your server-side code for you unless you're willing to pay a monthly fee, and I'm not about to do that for a project this small.

What's wrong with frameworks anyways?

As mentioned before, I do like to reduce dependencies when reasonably possible. Each dependency you add is:

Bloat, as you might be depending on a lot more than what you really need. Tree-shaking doesn't always fix this issue - it isn't magic.
Another security hazard - dependencies are often changing owners than going rogue.
A maintenance burden - if you need to use some of the latest features from a dependency, you'd also need to update, which means dealing with breaking changes.

If the benefit of adding the dependency is relatively little, than perhaps it's not worth it. For example, I personally don't see any real reason to install Lodash when the most-used functions are now native functions and the remainder aren't too difficult to just copy from the internet and use. I recognize that there's a maintenance cost associated with copying code and everything, but ultimately, I still favor writing code without Lodash. The amount of time Lodash saves you, all things considered, is typically in the order of minutes or seconds, at least that's been my own experience thus far. On the other hand, opting to go without a framework can cost you many hours of work if future feature requests come in that your framework-less codebase can't support very well.

I also want to add that frameworks aren't inherently as bloated and slow as people make them out to be. Most bloat that you feel when using a React/Angular/Vue/some-other-SPA-framework comes from the webpage being developed with no thought for performance in mind, not from the framework itself. Tell those developers to build something without a framework, and they will still build something that will feel similarly sluggish. On the other hand, take performance-minded individuals and ask them to use a SPA framework to build a webpage, and it's going to be blazingly fast.

Concluding remarks

I'm not trying to preach the opposite extreme here. There are still many, many scenarios where you really should go without a framework and choose one of the other options available. Use your own judgement and some common sense. My main point here is to simply say that, just because your website is small or mostly static, does not automatically mean going frameworkless is best, despite what the current popular opinion may be saying.

Just 'cause something throws an error, doesn't mean you need to catch it.

theScottyJam — Fri, 07 Feb 2025 06:09:01 +0000

Good code has good error handling. Error handling involves the use of try/catch. Therefore, anytime you suspect an error might be thrown, you should catch it. And once you've caught an error, you... um... well, I guess you log it out?

My goal is to convince you to be ok with letting errors go uncaught, regardless of what kind of environment you are coding in. We'll discuss a small handful of environments, but the general idea extends to any environment.

Browsers

What is the problem with the error handling in this code?

document.querySelector('.refresh-button')
  .addEventListener(async () => {
    try {
      redrawRecords(await fetchRecords());
    } catch (error) {
      console.error('Failed to fetch records:', error);
    }
  });

Lets start by asking - do you know what the browser will do if you let an error go uncaught? It'll log it out. So why are we bothering to catch the error and log it when that's exactly what the browser was going to do anyways? You can toss the try/catch, it's just extra noise.

You might argue that the console.error() is adding some valuable context - it's informing you that the error happened while we were trying to fetch records. But that too is redundant, you already have easy access to that same context by looking at the stack trace. If an error really did happen while attempting to fetch records, you will see the function name fetchRecords() in the stack trace, which gives you the exact same context.

In this specific scenario, an even better solution would be to notify the user when an error happens, but when that's done, don't feel ashamed to rethrow that error and let the browser handle logging it out for you.

document.querySelector('.refresh-button')
  .addEventListener(async () => {
    try {
      redrawRecords(await fetchRecords());
    } catch (error) {
      informUserOfError(error);
      throw error;
    }
  });

Node Servers

What's wrong with the error handling in this Node server code?

sendEmailToUser(emailOpts)
  .catch(console.error);

To give some context, when an error goes uncaught in Node, the entire process will crash. But remember, this was an intentional design decision.

The idea is that once an unknown error happens, your server will be left in an unknown state, and the best thing you can do is to let it crash, then automatically spin up a new server in a clean state. This philosophy, however, only works if all of these conditions apply to you:

Your code is crash-ready. You never have a scenario where you're blindly doing await writeThing1(); await writeThing2(), because the server might crash between those two async steps and leave your saved data in an invalid state. In the ideal world, you would be writing robust code anyways that accounts for the fact that a crash can happen at any point in time anyways, but the reality is that you, like many people, might not be writing code to that kind of standard.
Any dependencies you might use should also be crash ready in the same fashion.
You should have auto-restarting set up, so when your server does crash, it'll automatically bring itself back up. Ideally, you would have a cluster of instances running at the same time, so one of them crashing wouldn't cause any real downtime.
Say someone find a particular set of inputs they can give to one of your endpoints, to cause an uncaught error to happen and your server to crash. Is there anything stopping this person from sending a request, every few seconds, to this endpoint, and causing your servers to repeatedly crash, preventing anyone else from using your services? You will need to have protection in place against these kinds of exploits.

If you agree with Node's default error-handling philosophy and are writing the kind of enterprise code that can support it, then stop trying to fight the philosophy with your code by trying to catch and log every error imaginable. When something unexpected happens, let your process crash.

If you're not running a server that can support this kind of unexpected crashing, then Node's default behavior will actually do more harm than good for you. There's a simple solution. Just throw the below code snippet somewhere in your codebase - it'll catch all uncaught errors and log them out, effectively making the default uncaught error behavior match that of a browser.

process.on('uncaughtException', error => {
  console.error(error);
});

If you are in the habit of catching and logging every error in Node to prevent Node from crashing, then you are effectively hand-implementing the behavior of the above code snippet, in a tedious, error-prone fashion.

Libraries

If you're a library author, you can't necessarily globally configure Node to log uncaught errors instead of crashing - it's not your place to make that kind of decision. But that's ok. When things go wrong in the internals of your library, it's your responsibility to make sure those errors become uncaught errors, and it's the consumer of your library's responsibility to decide what to do when unexpected issues happen (whether that's crashing Node, logging the issues to stderr, or something else entirely). Don't try and take that choice away from the consumers. Let your unexpected errors go uncaught.

Concluding thoughts

As always, take everything being said with a grain of salt. While, in general, it's ok to let errors go uncaught, there are specific scenarios where preventing errors from bubbling up is a good thing. In some cases, catching errors just to log them is the best option available. I won't go over the nuances on when these scenarios may or may not be appropriate, instead, I just ask that you use your judgement, and to not be afraid to consider uncaught errors as a valid option as you weigh your options.

Embrace complexity

theScottyJam — Thu, 14 Nov 2024 15:25:00 +0000

There seems to be this ever-present mantra in our programming culture to keep things as simple as possible. We hear it manifest in several different ways:

KISS (keep it simple stupid)
YAGNI (You ain't gonna to need it)
Don't over-engineer
Avoid "accidental complexity"
Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.
Code for readability.
etc

These are good, solid piece of advice, but I worry that some of us (me included) may have been taking this rhetoric too far. What have we been sacrificing at the alter of "simplicity"? Are we avoiding powerful design patterns because they might make the code harder to read? Are we staying away from various tools and libraries because of their learning curve? Conversely, are we hanging on to tools or libraries that we have long outgrown because we are worried about the added complexity of a home-grown solution? Are we avoiding adding features that would really benefit the end-user, because it would require the team to do a complex task (such as building a DSL parser, implementing a technical specification, etc)? Perhaps you can see real value in applying certain philosophies like the hexagonal architecture, dependency injection, the CQRS patterns, railroad programming, etc, but what would the next set of maintainers think? Will they just rewrite it all to be simpler?

Many of these worries are justified to some degree, but that doesn't mean we should always limit ourselves to only picking the simplest options, because, well, that's pretty limiting. Instead, perhaps as a community we need to take a step or two away from the "keep everything simple" philosophy. Life is complex. Programs are complex. Your job is complex. That's ok.

So don't feel bad for introducing complexity into a codebase when the complexity is justified.

Be less judgemental when entering a new codebase. Everything is going to feel complex and abstracted in odd ways. Resist the impulse to rewrite it all, instead, start by walking a mile or two in the previous maintainers' shoes, coding in the fashion they intended you to code in. You might learn a thing or two.

Embrace complexity.

Embrace simplicity.

Balance.